Re: File left open in QZRCSRVS job

Debugging this issue could be pretty simple, provided you have a
reproducible scenario already.
You can use a regular green-screen debugger and associated "Service Entry
Point" support. Just type in STRDBG yourProgram UPDPROD(*YES) and put a
service breakpoint on the appropriate line:

SBREAK line# USER userProfileConnectingViaClientAccess

When user connects via Client Access, your interactive session will break
and you'll be able to debug the QZSRCSRVS servicing that user.

As for the code itself...

One easy option for your code is to make the _RFILE *fp file handle static
to the program (i.e. by moving its declaration above the main routine).
This way you need only once check for fp == NULL and open the file only once
for the duration of the program and never close it (let the system close it
when client access connection is closed and QZSRCSRVS job is recycled).
You'd need to add an else check to see if file is truly empty (i.e.
_Ropnfbk(fp))->num_records), in case some errors occurred on the previous
run and you didn't clear the file (instead of _Rdelete, you could have a
system("CLRPFM QTEMP/TEMPFILE") run as the last thing in your function).
Of course, if you have an exception in the code and system implicitly closes
your file, you'd have a trouble of not knowing that happened...
So that brings me to exception handling. You show none in your code. You
really ought to add some. I always check return codes and add error
handling around calls to system functions. It helps me sleep at night :)
Also, you don't check for the error return codes from system() function.
Trust me, you want to do this... and probably wrap it with your exception
signaler in case it's not what you expect (i.e. QMHSNDPM(.... "*ESCAPE"...)
type signal),

HTH, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com

-----Original Message-----
Subject: [C400-L] File left open in QZRCSRVS job

Hi,

probably my understanding of the platform speifics is somewhat weak, so I
cannot understand how to solve the problem. May be someone can advise me.

A PC program using Client Access establishes a connection session with
AS/400. As a result a job named QZRCSRVS is started.
The PC program establishes environment for this job (creates library list
and some other preparations) and then starts calling one and the same
program:

CALL H46HMR PARM(PROGNAME, PARM1, PARM2, ....)

H46HMR is a vendor provided ILE RPG program compiled with an activation
group attribute *CALLER.

This program actually calls our program named PROGNAME, passes some
parameters to it and receiving something in response. It is also compiled as
*CALLER.

The problem is in our program.

It does something like:

void main()
{
_RFILE *fp ;

fp = _Ropen("QTEMP/TEMPFILE", "rw") ;
if (fp == NULL)
{
system("CRTDUPOBJ OBJ(TEMPFILE) FROMLIB(MYLIB) TOLIB(QTEMP)
OBJTYPE(*FILE)") ;
fp = _Ropen("QTEMP/TEMPFILE"), "wr") ;
}
/* Generating response */
for (.....)
{
.......
_Rwite(fp, ...) ;
}
_Rclose(fp) ;

/*-------------------------------------*/
/* Sending response back */
_Ropen("QTEMP/TEMPFILE", "rr+") ;
_Rreadf(fp, ...)
for (....)
{
_Rdelete(fp) ;
_Rreadn(fp, ...) ;
}
_Rclose(fp) ;
}

When program is called, it first generates a list of records (reply) and
then starts sending them back to the caller one by one. It is a predefined
logic, works fine.
Now one of our programs of this sort has a bug, that we are searching for a
couple of weeks but with no success. As a result the program crashes and the
file QTEMP/TEMPFILE left open.

When program is called next time, the file opening command with clearing
file content (option "wr") fails because the file is being held by someone.
This someone is probably the crashed previous instance....
So from that moment the program works, in the sense that it consumes
resources, but does not do what is intended.
Is there something, that can be done inside our program to take care of this
situation? Close the file somehow if it was left open or something alike?
I am (of course) not losing the hope to find the original bug, but have no
idea how to proceed.

Advise will be highly appreciated :-)

Jevgeni Astanovski