Re: V7R1 *SNGLVL vs *INHERIT

[CRPence <CRPbottle@xxxxxxxxx>]

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