Re: Database I/O Modernization

On Mon, Sep 11, 2017 at 2:36 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

It's not the CALL themselves that's the problem...

I'm not precisely sure what has caused such a big drag on the I/O
performance. I noted in an earlier post that runtime execution path in the
service program entails:

2 procedure calls.
2 monitor, on-error blocks.
2-3 select blocks.

before an I/O op code is invoked.

The commit keyword on the "f" spec forces the service program to run under
commitment control, which may be a factor. I didn't force that in the other
program because reading a file front to back doesn't require commitment
control.

Can't tell for sure what it is without the code, but I'd suspect
- repeated opens

No, the file is opened only once and never closed until the activation
group ends. Look at the source code.

if not %open(cusmstf);
open cusmstf;
endif;

- ACTGRP(*NEW)

No, the service program runs in the *caller activation group.

- data copying

Yes, a factor, I think.