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

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. It's a random problem. Same parameters and the job runs fine several times and then, this happens. 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;




The variables prefixed with "p" are incoming parms to the procedure. DIVN is derived locally. > To: rpg400-l@xxxxxxxxxxxx

From: CRPbottle@xxxxxxxxx
Subject: Re: Why would a file in a service program get closed?
Date: Wed, 20 Aug 2014 11:19:35 -0500

On 20-Aug-2014 10:45 -0500, Roger Harman wrote:

I have some service programs to retrieve various elements from
several master files.

The files are USROPN and there is a SrvPgm_Init() routine called to
open them. Once open, they don't get closed until the SrvPgm_Close()
routine gets called. Both calls are ONLY in the main report program.

But, somehow, I have files getting closed between calls to the
SrvPgm_GetSomeData() calls. It's happening in two different service
programs. %status returns 1211 if I check it.

I am baffled. It looks like it may be an activation group boundary
issue.

Service programs are ActGrp(*caller) and all the programs (CLLE &
RPGLE) in the job stream have the same defined activation group.

V6R1.

Suggestions?

A job trace will show the close, and thus what led to the close.
Although with status 1121, I wonder if the condition was diagnosed by
CPF5114 "File must be open before input or output is done.", for which
the possible implication is also that the file was never opened.

IIRC had the file(s) been closed due to a prior I/O error, i.e. per
an abnormal close, the error would be different than the 1121; instead
the prior Data Management (DM) error would imply the ODP is in-error per
msg CPF5129 "I/O is not allowed because the ... member ... is in error."

Though maybe the RPG run-time returns the same status irrespective
the prior Data Management error that might have been logged; was there
anything in the joblog prior to that status being raised, indicating an
I/O error or open error [presumably, already the joblog was reviewed for
a message indicating that the file was closed].?

kwd: msg RNX1211 "I/O operation was applied to closed file &7."

In many cases for which there are few close requests, I just use
debug and add a breakpoint on instruction '/1' of the OS program [if an
OPM program] that processes the device-specific close [e.g. QDBCLOSE],
and then check the stack to determine what requested\effected the close.

--
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.