CEETREC will basically terminate the Activation Group in which it is being called.

If your Apps are in a *NEW or Named activation group then that A/G will get blown away.

If your Apps are running in *DFTACTGRP (or in *CALLER and called by an OPM program) then the *SRVPGM's will also run in the *DFTACTGRP. This will cause the error you're observing.

Generally that type of error is due to a component remaining active while other parts are closed down. The RCLRSC command does not close down *SRVPGM components regardless of where the *SRVPGM is active (*dftactgrp or elsewhere).

Right Bob, all this I know.  What I need is a way to use *CALLER and not have RCLRSC cause this problem.

You may be able to try an experiment. Using an entry/exit procedure you could re-initialize the variable in the service program. If there are files in the service program, you could do a close/open of those files in those routines. I have some C++ code that I use for my clients in this kind of a situation. I believe I wrote about it previously and published it. 

Basically you create a C++ module using PDM option 15, and bind it to your own service program. In the C++ you name two RPG IV subprocedure names. In those subprocedures you open and close your files and re-initialize your variables.

     extern "C"  int RPG_ENTRY(void);                            
     extern "C"  int RPG_EXIT(void);                             
                                                                 
class Entry_Exit                                                 
{                                                                
                                                                 
public:                                                          
   int  m_nEntry;                                                
   int  m_nExit;                                                 
                                                                 
// Construction                                                  
public:                                                          
    Entry_Exit(void);                                            
   ~Entry_Exit(void);                                            
};                                                               
                                                                 
  Entry_Exit::Entry_Exit(void) {                                 
        m_nEntry = RPG_ENTRY();     //  Call the Entry procedure 
  }
 Entry_Exit::~Entry_Exit() {                                  
       m_nExit = RPG_EXIT();     //  Call the exit procedure  
 }                                                            
 static Entry_Exit my_Entry_Exit;                                                       

The procedure named RPG_ENTRY and RPG_EXIT are normal RPG IV subprocedures that have been exported from an RPG IV module in the service program (probably with Binder Source).

This module basically causes the Constructor and Destructor for the object to be evoked when the *SRVPGM is evoked and ended.

Thanks Bob!  I will defiantly play around with this!  Although, even if it works I am not sure if we will not adopt this as our solution since the extra step binding is something that would be an issue here.  Apparently programmers here don't have the discipline to enter the named activation group. 

I was hoping for some CEE API that might catch this error and allow the service program to perform whatever auto-recovery instead of blowing up. This type of solution would allow for a copybook approach and programmers would have an easier time with that (I think).

I have also been performing some testing and I think I have come up with a good solution for us.  I changed our menu system to DFTACTGRP *NO and QILE activation group and that seems to allow me to use either *CALLER or a name activation group just fine.  I just need to see if an option that calls a CLP throws me back into the OPM default activation group or not.

But like I said, I am going to play around with your solution and present that to the group also. 

Did you just imply that your service programs contain only one module and they use something other than CRTSRVPGM (the "binder") to create it? Otherwise I'm not sure what the extra step is?

For me, I see two options when building a service program, but there are other worse ways:

1. Create all the modules with a generic name, like QTMxxxx and then use MODULE(QTM*) when creating the service program.
2. Create a CL program that re-builds (re-binds) the service program from all related modules. Then call that CL program to create/re-create the *SRVPGM when needed.

There is also the option to create one app per library--but that, I think, get a bit unmanageable.

The extra step(s), if I am understanding how to use this C function, is that they would need to code two new subprocedures (not really a problem with copybook) and when creating the service program they would have to remember to manually key in the name of the C module to include/bind it. This whole problem I am trying to solve was started because developers cannot remember to enter a named activation group when implementing programs.  So I doubt they will remember to enter the name of a C module to bind it to their service programs.

We are looking for a solution that will not scare programmers away from using service programs, a solution that doesn't require anything more than CRTRPGMOD (or whatever) and CRTSRVPGM.  And a solution that will easily flow through Implementer when we are promoting our changes.

Actually, we are looking for a single change that will protect us from the RCLRSC. That is why I thought about chaning the menu system that all users use so that when they sign on they are placed in QILE at that time.  In theory, all options they take should then be running in QILE and the RCLRSC will not impact them.  Then again, the RCLRSC may no longer work either.  And I am wondering if the menu system calls a CLP if that might throw us back into the OPM default activation group.  So I still have some research and testing to do on this idea.

But going forward, I would like a better solution as to how to have service programs perform their own cleanup "by deisgn" and not "by accident" using RCLRSC. 

Here is a question, "if" a proceudre in a service program running in the DAG were to close it's own files before doing a RETURN, would it still be impacted by an application doing a RCLRSC?  I am thinking that it may not be impacted, but this is something I have not tested.

If you're so hip on "copybooks" why not just include a Header spec with "ACTGRP(*NEW)' or similar and be done with it.

Is performance so bad that you have to work on how files are opened and closed? With the POWER5 and more so on the POWER7 I've almost completely moved to embedded SQL. The point is not "move to embedded SQL" the point is the SQL interface is constantly opening and closing files and I see virtually no performance issues. Therefore, I don't think it is necessary to consider the legacy RCLRSC design as a viable component in today's world.

As for creating a service program from a single module because programmers can't remember--we'll you need to get different programmers; perhaps actual programmers.

And finally, *SRVPGM's are not influenced by RCLRSC, period.

First off, having a *NEW activation group for EVERYTHING would not be a very wise decision performance wise, and I would expect that none of our hundreds of thousands of overrides would work correctly either.  Second, you CANNOT have ACTGRP on an H-spec for a service program!  And Finally, this would NOT fix the thousands of programs that are in production without checking them out and making the change to the H-spec.   

Yes, the RCLRSC was added to our O/E application for performance purposes. I was not involved in any of that, but I’m told that it is necessary because of all the files that our O/E program opens (everything from customer master, production master files, inventory files, to production plans probably about 400 files and LFs or more).  

We are aware of the differences between DDS and SQL files, but that is not even relevant to this discussion or the problems and systems that we are supporting here.  Remember that this is a real business and we don’t have the luxury of doing things that we would “like” to do, even if we know it might make significant improvements to performance.   Perhaps one day our business community will not have such a backlog and we can do things like move to SQL files and such. But for now, the business doesn’t see the value in doing a major system change like that with everything else they have going on.  Plus management will not allow too many big changes like this since many of our systems are moving to SAP to get away from this “legacy” system.

YES, service programs are indeed affected by RCLRSC.  And because they are, seven of us have wasted several hours this week putting out fires, defending service program usage in our systems with the business who wants them banned, and trying to come up with safeguards for the future.  If you do not believe that a service programs running in the DAG are not affected by RCLRSC then why would you have a possible solution to the problem?  Anyway, most everyone of us out here in the real world have seen this error a time or two and the problem is well documented, there just are not very many good solutions to the problem. We are looking for a solution to be used at the service program level, but also a quick and global solution (which I think I may have).

Finally, programmers are people, and people make mistakes.  But worse than that, programmers are rushed to meet unrealistic deadlines, work long hours, and are CONSTANTLY interrupted to look and other things and answer many other questions during our already busy days.  So hell yes, people are going to forget to do something like enter an addition module to bind to on the CRTSRVPGM command since they are already forgetting to enter a named activation group!  We want to make our lives easier, not more complicated. This has nothing to do with them not being good programmers, and I don’t really appreciate your comments indicating otherwise.  We have been told that we manage more projects and maintenance requests than many other shops, and that is with an SDLC process in place. We have very complex and highly integrated systems here, and the programs did NOT write themselves!  And it’s because of these systems that our company is a Fortune 500 company today.

I meant insert the actgrp keyword in your RPG programs. 

There may be bugs in the OS with RCLRSC and SRVPGM's run in the DAG. HOWEVER ILE (the environment not a programming language) was never designed to allow SRVPGM's in the DAG. And the IBM docs specifically say that RCLRSC does not impact service programs. 

Therefore if you are getting an error, then call support and get the bug fixed. 

I know what the IBM docs say, and technically I guess they are right.  RCLRSC does not end a service program. But what it does is closes all of the files opened by that service program so that the next time a subprocedure inside that service program is called it blows up because it still thinks the files are opened.  This is something that almost everyone developing service programs has experienced and something that is not covered by testing since everything can work fine during testing.

Yes, we can use ACTGRP in programs, and I had already thought about using QILE inside the programs so that if a service program is *CALLER it will run in QILE and I don’t think RCLRSC will close any files in QILE, but I could be wrong since I have not actually test this yet. 

The potential problem with this is that it would require a lot more work to put the fix in all the programs and if we changed O/E (where we are having the most problems with this) then we have a performance issue again because RCLRSC will not close all the files that it closes today. 

What would happen if a CLP was called by a program running under QILE?  Wouldn't it run in the OPM DAG?

Yes any program (CLP, or RPG) that is compiled with DFTACTGRP(*YES) or any OPM program will run in the default activation group when called from QILE or any other A/G.

You might consider testing this (although it may be too much work); the RPG IV language has, as you know, the %OPEN built-in function. I'm wondering if after you call RCLRSC and re-evoke the srvpgm if by testing the open status using %OPEN, if it would allow you to re-open the files accordingly. Of course another option is to simply close all the files and re-open them--using the combination of CLOSE and OPEN(e) opcodes... just trying to help.

No, the %OPEN / %OPEN(e) doesn't work.  The problem is that the RCLRSC closes all files left open by the service programs and the service programs still think it's files are still open.

I am thinking that "if" a service program closes all it's files that it would not be affected by RCLRSC and calling one of it's functions after the RCLRSC would work just fine.

The subprocedures cannot close the files just because they doing a RETURN because many of them are called several times when an order is being created and we don't want to add more overhead to this process (yet they continue to do so!).  I am probably going to suggest that all the service programs that have files be looked at to see about adding a new subprocedure to close *ALL files.  If we can get this done then we can have O/E changed to use the new subprocedure to close all service program files before doing a RCLRSC. 

Whenever I have a service program with file opens, I always create an exported CloseService procedure (where "Service" is the name of the service program).  The only line in the procedure is CLOSE *ALL;  just in case someone needs to perform a clean up.  In all my years I've never needed to call the Close procedure.  I don't even know if it would work in this case.

I must admit I usually find a RCLRSC is a programmers way to clean up after they made a mess and they're too lazy to figure out how they did it.

I am not defending anything really, but our O/E application alone uses MANY files.  But due to the nature of our business and complexity of ordering our products our O/E application branches into many other segments of the business.  So when it calls a module for credit, inventory lookup/assignment, production lookup/assignment, and the many other programs/subprocedures it must call, many other files are opened.  Some of the subprocedures have a subroutine to close *ALL files.  Some that have been done lateley do not because the files are at the subprocedure level, so I guess that means if we use 3 subprocedures with F-specs in the subprocedure that we cannot create a close routine that will be capable of closeing those files.  We will have to add a close parameter to these subprocedures instead. 

I still have not even tested closing the files prior to a RCLRSC to see if that will solve our problem or not. 

I am not sure when the RCLRSC was added to this particular application, and it really doesn't even need to be done if the customer service rep is going to remain in the order entry option.  However, someone must have decided that "if" they leave the program and go into another menu option then the files should be closed for performance purposes.

"I still have not even tested closing the files prior to a RCLRSC to see if that will solve our problem or not."

Yeah - that was my concern.  I'd be interested to know the result of your tests, if you ever get around to it.

"I am not sure when the RCLRSC was added to this particular application, and it really doesn't even need to be done if the customer service rep is going to remain in the order entry option.  However, someone must have decided that "if" they leave the program and go into another menu option then the files should be closed for performance purposes."

I think last time I hit a RCLRSC, I took it out, then took a while to test and figure out why it was added.  Then code the correct fix so I wasn't crapping out everything else.

You could change the CRTSRVPGM command default to ACTGRP(FISH) or whatever. If you go that option, beware of losing that on your next OS upgrade. I'd recommend you NOT use QILE since that's an IBM A/G. If you do a RCLACTGRP(QILE), you might reclaim objects you didn't really want to.

We export If ( Not %OPEN(FILENAME) ) ; OPEN FILENAME ; EndIf ; and CLOSE(e) *ALL ; sub-procedures in every *SRVPGM so the caller can control when files open or close. The first statement of each sub-procedure is the callp MODULENAME_OPENALLFILES(). It's up to the caller to callp MODULENAME_CLOSEALLFILES(). We prefix the sub-procedures with the module name to avoid name collisions, otherwise you have lots of ambiguous OPEN/CLOSE sub-procedures.

Chris Ringer

Chris, you might benefit from the Constructor/Destructor technique I mentioned (above). That's why it was invented; to handle (auto-open and auto-close). That way you don't have to insert it into the start of every subproc. That type of standard can be a messy to enforce.

Question:  If my service program has a bunch of procedures but they all use SQL and there isn't a single F-spec, are the files still being opened and closed as they would be if the files were defined with F-specs and I let the system handle the opening and closing of files?

Bob, how would having a test for %OPEN (or Not %Open) be any more messy than using your constructor/destructor technique?  First, let me make sure I understand what would be involved to use it (I have not yet had time to try it for myself)...it's my understanding that we would have to code two addition subroutines in our service programs, one to open and one to close files.  Then, to compile we would have to include the C module on the CRTSRVPGM command to bind to it.  Is this correct?

How would this help if all the files used in a service program are defined in the subprocedures?

Viking,

I think that would depend on how you created the SQL module.  CLOSQLCSR defaults to *ENDACTGRP.  I would think *ENDMOD is what you would want to use.

Ok, right.   Our service program modules don't have F-specs so everything is done with SQL within the service programs.  We don't use RCLRSC, have *CALLER in most cases, and don't have any performance issues.  Our programs also open a bunch of files to do their stuff but then call service program procedures to do all the newer stuff we have added.

QDMLOPNF will give you a list of open files, but may not work since non-SHARE(*YES) files could be open in a different program.

I would issue the I/O operation and issue a MONITOR ... ON-ERROR ... ENDMON statement around it. If the READ/CHAIN etc. fail, then (re)Open the file and try again. You'd only have to do this on the first I/O operation to the file in each subprocedure in your *CALLER/*DFTACTGRP SERVICE Program.

TFish, I met the same problem as urs. So finally how you solved the problem? Compiling SRVPGM with a named AG works?