× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.