Re: Stupey service program thinks file is open -OR- %OPEN is easi ly fooled?

["Rusling, John B. (Alliance)" <jbrusling@xxxxxxxxxxxxxxx>]

> ------------------------------
> message: 4
> date: Wed, 28 Jan 2004 09:38:20 -0600
> from: "DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>
> subject: RE: Stupey service program thinks file is open -OR- %OPEN is
>       easi ly f ooled?
> 
> 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.


Well spoken Eric, I agree.

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

Yes, I read many of them last night.  Most I found dealt with not finding
service programs or procedures on subsequent calls etc, pointer not set
for...

I didn't find one that said
"Service program (goes blonde;) thinks file is open when it's not!"
-OR-
"%OPEN gets fooled again by reclaim resources cmd!"

> 
> Eric DeLong
> Sally Beauty Company
> MIS-Project Manager (BSG)
> 940-898-7863 or ext. 1863
> 
> ------------------------------

     <snipping... snipping... snipping... snipping... snipping.../>

Our menu system (a bit dated but works nicely) had a rclrsc command
for the main program(SO30), I removed it and the problem went away.

> ------------------------------
> 
> message: 5
> date: Wed, 28 Jan 2004 10:39:52 -0500
> from: MWalter@xxxxxxxxxxxxxxx
> subject: Re: Stupey service program thinks file is open -OR- %OPEN is
>       easily  f ooled?
> 
> 
> If S030 is running in the default activation group and it issues a RCLRSC,
> then the files will remain open in programs running in named (ie *NEW,
> QILE, ...) activation groups. When running in a mixed environment you
> should explicitly close files and delete overrides.
> 
> Thanks,
> 
> Mark
> 
> Mark D. Walter
> Senior Programmer/Analyst
> CCX, Inc.
> mwalter@xxxxxxxxxx
> http://www.ccxinc.com
> 
> ------------------------------


     <snipping... snipping... snipping... snipping... snipping.../>


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