Re: Why would a file in a service program get closed?

On 20-Aug-2014 11:46 -0500, Roger Harman wrote:

Batch job - no joblog messages. During testing (new application) the
job didn't complete in a timely manner so I looked at the call stack
and it was showing the "enddo" statement.

Stepping through debug showed the "dow" loop happening although the
record fields were blank. All the key variables were correct - no
corruption. I added a %status() to see what was happening and it
returned 1211.

Added after the READE at the "enddo"?

Testing\review of %ERROR and\or %STATUS after each use of the 'E' extender would be most appropriate. Continuing with the next statement after ignoring an error or undesirable status-condition is very often a poor choice; often leading to confusion.

It's a random problem.

More likely, the pattern has yet to be determined.

Same parameters and the job runs fine several times and then, this
happens.

Something obviously changes. Any chance the arguments passed do not exactly match the declaration for the parameters; parameter mismatches are notorious for seemingly /random/ effects?

As to the file never being opened - not the case. This occurs a few
records into the process so the procedure already executed several
times. Here is the construct:


bLoop = '1';
setll(e) (pCONO : pPNUM : DIVN) OEP33UL1;
reade(e) (pCONO : pPNUM : DIVN) OEP33UL1;
dow bLoop AND NOT %eof(OEP33UL1);
If pDTIN >= SCYM33
and pDTIN <= ECYM33;
retDPAM = DPAM33;
bLoop = '0';
endif;
reade(e) (pCONO : pPNUM : DIVN) OEP33UL1;
enddo;

For lack of ever testing status\error after each use of the 'E' error extender, the code is effectively just ignoring all error conditions for the requested I/O :-( Apparently from earlier comments, the status 1121 was seen on the READE in the DoWhile; apparently we do not know also, the status and error-ind after each of the prior requests?

The variables prefixed with "p" are incoming parms to the procedure.
DIVN is derived locally.

Are these command-line invocations, or prototyped calls? Nuances of the calling conventions for how the OS prepares parameters must be well-understood, to avoid mistakes [with parameter mismatches] when using the command-line CALL.