RE: Changing Command Defaults (was: Problem with SBMJOB andLibraryList)

["Andy Nolen-Parkhouse" <aparkhouse@xxxxxxxxx>]

Tom,

I would extend your method a bit.  You mention discipline as though it
were an optional component of modifying IBM-Supplied objects.  I would
suggest that you make it a requirement.  Rather than maintain a text file
which contains a description of your modifications, I would write a CL
program which performs those modifications.

In the case under discussion, you could perform a CRTDUPOBJ of the SBMJOB
command to the alternate library and then issue a CHGCMDDFT command
against that new command.  With some review at each release upgrade, you
could then re-run the program so that your modified commands are always
using current commands as a base.  This avoids the surprises of missing
or changed parameters when things change during an upgrade.  As you make
additional modifications, the CL program would grow in length to include
them all.

Also, I would not name a user library to something beginning with 'Q'.

Regards,
Andy Nolen-Parkhouse

> On Behalf Of Tom Jedrzejewicz @ San Pedro
> Subject: Changing Command Defaults (was: Problem with SBMJOB andLibrary
> List)
> 
> No the CL programs will not have to be recompiled.
> 
> As this example shows, changed command defaults, subsystem descriptions
> and other "system" objects are a big gotcha when upgrading and even
> when
> debugging.  I learned a method a while back to make this manageable.
> 
> Create a library (say QSYSCUSTOM), and put it AHEAD of QSYS in the
> system library list.  Then, when the need arises to change something in
> QSYS (or even QGPL), duplicate it into QSYSCUSTOM, change it there, and
> note the change in the object description.  If you are really
> disciplined, create a QTXTSRC in that library and describe the changes
> in a member in that file.  Then, when you upgrade, re-create QSYSCUSTOM
> based on the notes.
> 
> Does anyone else have a better way to deal with this?