Re: Database I/O Modernization

How did the op-code version open the file? Input?

Blocking was likely used that couldn't be with the file opened for Update.

Also, the op-code version didn't by chance open the file without specifying
it was a keyed file did it?

Charles

On Mon, Sep 11, 2017 at 2:57 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD