Re: ACTGRP(*CALLER) vs. ACTGRP(*NEW) for CRTBNDCBL

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 

encountered

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 

command

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 

earlier,

but here's the issue. We have programs that are "main" programs and we 

have

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 

them

will be called numerous times from a main program) while ACTGRP(*NEW) 

would

be correct for the "main" programs.

There is no easy way to determine (from the program name or type) which 

it

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 

setting

that would correctly satisfy both?

If so, how can I ensure/enforce that the programmers use the correct CL 

when

they compile? This is not the kind of error that will surface right 

away.

It could be that the solution to this is simple and straightforward but 

I

don't see it (being new to the iSeries world). Your suggestions and 

advice

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