Re: V7R1 *SNGLVL vs *INHERIT

On Tue 05-May-2011 06:25 , Jeff Crosby wrote:

In the MTU for V7R1, pg 17 is a discussion of *SNGLVL vs *INHERIT as
storage models.

This reared its head for me today as I'm trying to make a few
changes to a service program. I can create the *MODULE object with
CRTSQLRPGI just fine, but the subsequent UPDSRVPGM fails with this
error:

Message ID . : CPD5CD1 Severity . . . : 30
Message type : Diagnostic
Date sent . : 05/03/11 Time sent . . : 08:50:21

Message : Module storage model cannot be changed.
Cause . : Constituent module SUBBILL originally from library JEFF
cannot be replaced by module SUBBILL in library JEFF. Constituent
module SUBBILL is bound into SRVPGM SUBBILL in library JEFF and was
created with storage model *SNGLVL. The replacement module was
created with storage model *INHERIT. The storage model must be the
same on the constituent and replacement modules.
Recovery : Replace the constituent module with another that has the
same storage model value, or re-create the SRVPGM.

This is what pg 17 in the MTU is referring to.

The MTU says (I think) that I can do a CHGSRVPGM(lib/pgm)
STGMDL(*INHERIT) TERASPACE(*YES) and be good to go. Is this right? My
service programs are a mixture, some with SQL and some not, and are
all activation group *CALLER.
The calling programs are also a mixture of SQL and non-SQL.

Can I just do this CHGSRVPGM to all my service programs and all will
be well?

I need a smarter mind.

Perhaps rather than changing what exists, according to the recovery, just keeping the same storage model default\setting as in the past. Should be possible to use the compile option to effect STGMDL(*SNGLVL) instead of defaulting to STGMDL(*INHERIT); i.e. specify COMPILEOPT('STGMDL(*SNGLVL)') on the CRTSQLRPGI?

Regards, Chuck