Re: V7R1 *SNGLVL vs *INHERIT

I opened a PMR with IBM. They think I will be fine if I issue the
CHGSRVPGM command as I specified. So I'm going to:

1) Save a copy of every service program into another library
2) Run that CHGSRVPGM command against all service programs in the
production library
3) Hold my breath

I will do this first thing in the morning when thing are slow.



On Tue, May 3, 2011 at 12:32 PM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>wrote:

True. But if I'm reading that page in the MTU correctly, it _seems_ like
the CHGSRVPGM command they recommend against all my service programs (41
total, 6 of them with SQL) would fix it once and for all. Using the
COMPILEOPT parm means I'm dealing with it later on.

I wanted to be sure that if I did the CHGSRVPGM that there would be no
issues no matter what kind of program called it, like it is now.

I set up a test.

1) Copied 4 additional service programs into my test library. This gives
me 5 service programs in my test library (one of them using SQL).
2) Changed them to STGMDL(*INHERIT).
3) Did a DSPOBJD on them to make sure the Days Used was 0.
4) Changed my library list to use my test library.
5) Ran a report program that calls all 5 of these service programs.
6) Got no errors and the output is correct.
7) Did a DSPOBJD on them to make sure the Days Used was 1, meaning they
were indeed used in the test.

This ought to convince me that I can do that CHGSRVPGM and be OK, yet . .
.



On Tue, May 3, 2011 at 10:54 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.

--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.