|
John, This would seem to nicely illustrate why it is not recommended to activate a service program in the DAG. ILE relies on the notion that resources are not reclaimed until the activation group is destroyed. You can't destroy the DAG until the job ends (signoff). There were threads that explored this topic in depth, at one point. I think some of that was distilled in the Midrange.com FAQ. Eric DeLong Sally Beauty Company MIS-Project Manager (BSG) 940-898-7863 or ext. 1863 -----Original Message----- From: Rusling, John B. (Alliance) [mailto:jbrusling@xxxxxxxxxxxxxxx] Sent: Wednesday, January 28, 2004 9:04 AM To: 'rpg400-l@xxxxxxxxxxxx' Subject: Stupey service program thinks file is open -OR- %OPEN is easily f ooled? We run in a mixed enviroment, OPM and ILE. I have a service program ILLD_F that's called from a program running in the default actgrp. It's compiled as actgrp=*caller. The programs that call it are compiled as actgp=*caller, which in our setup puts them in the default actgrp. The programs are SO30, S4ALWD. SO30 calls S4ALWD (normal call). S4ALWD uses ILLD_F srvpgm procedures. After this control is returned to SO30, where a user can enter more orders or back out to our home-grown (RPG/CL) menu system which runs in the default ag. Both the S4ALWD program and the ILLD_F srvpgm use the ILLDR file. What happens - The first time the below occurs, everything runs smoothly. Menu calls-> SO30 calls-> S4ALWD calls-> ILLD_F return-> S4ALWD return-> SO30 ...(finish order then enter more, or exit) If I stay in the SO30 program, things keep running smoothly. If I exit back to the menu, then try the above cycle again I get a hard crash inside the ILLD_F program when it hits the setll for the ILLDR file. dspjoblog messages reveal ------------ Tried to refer to all or part of an object that no longer exists. Call stack entry not found. Exception recursion detected. Application error. *N unmonitored by *N at statement *N, instruction X'4000'. (at the end of this post I've shown more of the first messages...) I've run thru this in debug and stepped "into" the service program at the moment when this crash occurs. What happens is... (procedures are all in ILLD_F srvpgm...) I step into the first procedure called #CHKILLD, it calls #SETLLILLD procedure, which, before it does a setll operation on the ILLDR file, calls #OPENILLD procedure to see if it's open, and if not, is supposed to open it. FILLDR IF E K DISK F USROPN /\/\/\/\/\/\/ D TRUE C CONST('1') D FALSE C CONST('0') /\/\/\/\/\/\/ 10 C IF %OPEN(ILLDR) = FALSE 20 C OPEN ILLDR 30 C ENDIF /\/\/\/\/\/\/ The crash occurs on the setll -BUT- what's really interesting is the ILLD_F srvpgm "thinks" the file is open. In debug, I've watched it go from line 10 to line 30 and NOT do the open, Then in the #SETLLILLD procedure, it hits the setll and crashes. I'm pretty sure the SO30 (1st) program reclaims resources when it's exited and this is what tricks the ILLD_F srvpgm into thinking it's file is still open. I've figured out 2 things that alleviate this - compile the S4ALWD (2nd) program with actgrp=*NEW -OR- compile the ILLD_F srvpgm with actgrp='ANYNAME' . I've hit issues with srvpgms, actgrps, pointers not pointing to procedures etc. I haven't seen this one before and "Inquiring minds want to know". Is it the service program or %OPEN that's stupid? (he asks, bravely, knowing the design he has to work with, even he, himself may be be subject to the same question) Sharing the knowledge :) (or lack of it) John B. |||---- First Message ----||| Message ID . . . . . . : MCH3402 Severity . . . . . . . : 40 Message type . . . . . : Escape Date sent . . . . . . : 01/27/04 Time sent . . . . . . : 14:26:05 Message . . . . : Tried to refer to all or part of an object that no longer exists. Cause . . . . . : The most common cause is that a stored address to an object is no longer correct because that object was deleted or part of the object was deleted. Display Message Details Message ID . . . . . . : MCH3402 Severity . . . . . . . : 40 Date sent . . . . . . : 01/27/04 Time sent . . . . . . : 14:26:05 Message type . . . . . : Escape CCSID . . . . . . . . : 65535 From program . . . . . . . . . : QRNXIO From library . . . . . . . . : QSYS From module . . . . . . . . : QRNXDBIO From procedure . . . . . . . : _QRNX_DB_SETLL From statement . . . . . . . : 10 To program . . . . . . . . . . : QRNXIO To library . . . . . . . . . : QSYS To module . . . . . . . . . : QRNXDBIO To procedure . . . . . . . . : _QRNX_DB_SETLL To statement . . . . . . . . : 10 |||---- Second Message ----||| Message ID . . . . . . : CPF2479 Severity . . . . . . . : 40 Message type . . . . . : Escape Date sent . . . . . . : 01/26/04 Time sent . . . . . . : 09:35:06 Message . . . . : Call stack entry not found. Cause . . . . . : Call stack entry ILLD_F, specified for the send, receive, move or delete message operation, could not be found in the call stack. Recovery . . . : Change the call stack entry name or be sure the specified entry is in the call stack when doing the requested operation. _______________________________________________ This is the RPG programming on the AS400 / 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
