OPTION(*STDINZ) is the default. It controls how working storage items are initialized during program activation. The problem you describe isn't how working storage is being initialized during program activation, but that the program is still 'activated' and hence no storage is initialized. You have at least two options. Perhaps the simplest would be to use ACTGRP(named-group) and then when you exit the main program execute a RCLACTGRP ACTGRP(named-group). This will eliminate anything left over from the previous activation. Although it might require some reworking of your application to have a driving CL program which is not part of the named-group. I use this approach in combination with the following. A second option, is to automate the build process somewhat. There are some great change management tools available which do this. Their drawback is the cost. While I don't believe they are overly priced, I've had a hard time convincing management they are worth the investment. So in the method we use, we store the required compile parameters in a comment at the top of the program. e.g.: *PARMS CVTOPT(*DATETIME *DATE) BNDDIR(BKXOPUTIL) ACTGRP(WAYOPE) Then we've got a compile CL program which does an OVRDBF to the source file and member, then does a RCVF and interprets the results. It strings in the options from the *PARMS line and does the actual compile including these PARMS. This way takes a little time to get set up, but it's well worth it. Then you can store any needed compile options in the source code and they'll always be available whenever you need to compile a program. cobol400-l-bounces@xxxxxxxxxxxx wrote on 02/07/2007 01:00:04 PM:
date: Wed, 7 Feb 2007 08:14:18 -0500 from: "Michael Rosinger" <mrosinger@xxxxxxxxx> subject: [COBOL400-L] ACTGRP(*CALLER) vs. ACTGRP(*NEW) for CRTBNDCBL (cross-posted to midrange-l list also) List, I've just discovered a dilemma for which I need advice. I have custom compile CL setup for us to use from WDSC - one for CBLLE and one for SQLCBLLE. While testing a program that successfully compiled, I
some strange run-time issues that I traced back to the fact that a subsequent CALL of the program (executing it from the green-screen
line) would have program storage set the way it was left on the previous instance instead of being initialized. It was recommended to me to use ACTGRP(*CALLER) when I set up this CL. I think that using ACTGRP(*NEW) would solve the problem I encountered
but here's the issue. We have programs that are "main" programs and we
those that are called "sub-routines". All of them will be bound COBOL. ACTGRP(*CALLER) would be correct for the sub-routines (since most of
will be called numerous times from a main program) while ACTGRP(*NEW)
be correct for the "main" programs. There is no easy way to determine (from the program name or type) which
is - main or sub-routine. So how do I handle this? Do I need one compile CL for a "main" program (with ACTGRP(*NEW)) and a second for sub-routine (with ACTGRP(*CALLER))? Or, is there a third
that would correctly satisfy both? If so, how can I ensure/enforce that the programmers use the correct CL
they compile? This is not the kind of error that will surface right
It could be that the solution to this is simple and straightforward but
don't see it (being new to the iSeries world). Your suggestions and
will be greatly appreciated! -- Regards, Michael Rosinger Systems Programmer / DBA Computer Credit, Inc. 640 West Fourth Street Winston-Salem, NC 27101 336-761-1524 m rosinger at cciws dot com
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.