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

Thanks for the thoughts, Chuck.

Yes, I am guilty of not checking %error and/or %status. Sadly, probably
the majority of us are.

Parameters do match and it is a prototyped call. Job is invoked
programatically and the parameter values were the same.

I'm still leaning towards an AG boundary issue. Changing the top level
CLLE to AG *NEW and everything downstream to *CALLER seems to have resolved
it.

To: rpg400-l@xxxxxxxxxxxx
From: CRPbottle@xxxxxxxxx
Subject: Re: Why would a file in a service program get closed?
Date: Wed, 20 Aug 2014 12:54:06 -0500

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.

--
Regards, Chuck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)

mailing list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.