Beware CHGCMDDFT

This is a general warning about using the CHGCMDDFT command to change the default value of command parameters for commands in QSYS.

Why Not?

There are a number of reasons not to change parameter defaults on commands in QSYS…

  1. Any time you upgrade your systems, those default parameter changes will be lost because the commands are completely replaced.
  2. Although you can identify what commands have had parameter defaults changed, there is no indication of WHAT parameter defaults were changed on a command. To identify what commands have had defaults changed display the command objects description (DSPOBJD) with DETAIL(*SERVICE). If an object has had the parameter defaults changed, the APAR ID will show ‘CHGDFT’.
  3. Third party products may be expecting commands to have the IBM provided default values. Because 3rd party products usually have to work on a number of IBM i versions, it’s impossible for vendors to specify a specific value for every parameter. New parameters are added with almost every release.

A Better Approach

A better approach would be to create a library to hold copies of the commands you want to modify …

  1. Create a specific library to hold customized commands
  2. Add that library to the QSYSLIBL system value above QSYS
  3. Duplicate the *CMD objects into that library
  4. Change the default parameter values on the commands in that library.

This way the commands in QSYS are left with the IBM provided default parameter values. Since the custom command library is above QSYS in the system library list, applications that reference those command (that don’t qualify the command to QSYS), will use the modified command.

I like to create a simple CL program that does the work of deleting existing commands from the custom command library, duplicate the command from QSYS, and modifies the command parameter defaults. Not only does this make it easy to recreate the custom command parameter defaults when you do an OS upgrade, it documents what parameter defaults have been made.

CRTPRXCMD

You may be tempted to use the CRTPRXCMD to create a ‘proxy command’, that points to the original command, and change the defaults on the proxy command.

DO NOT DO THAT!

A proxy command isn’t a stand alone object that is independent of the actual command. It’s just a pointer to the real command.

Any real changes you make to a proxy command will actually be made on the real command.

Example

Here’s a very simple example of a CL that will repopulate a custom command library with modified default parameter values.

PGM

DCL        VAR(&LIB) TYPE(*CHAR) LEN(10) VALUE('CUSTCMD')
DCL        VAR(&CMD) TYPE(*CHAR) LEN(10)

/* SAVLIB must default to *PRV target release for compatiblity */
CHGVAR     VAR(&CMD) VALUE('SAVLIB')
CALLSUBR   SUBR(DUPCMD)
CHGCMDDFT  CMD(&LIB/&CMD) NEWDFT('TGTRLS(*PRV)')

RETURN

SUBR       SUBR(DUPCMD)
   DLTCMD     CMD(&LIB/&CMD)
   MONMSG     MSGID(CPF2105)

   CRTDUPOBJ  OBJ(&CMD) FROMLIB(QSYS) OBJTYPE(*CMD) TOLIB(&LIB)

ENDSUBR


ENDPGM  

4 thoughts on “Beware CHGCMDDFT

  1. Larry "DrFranken" Bolhuis

    I support this method, BUT (and it can be a big BUT) When you do an UPGRADE to IBM i you MUST remove that library of customized commands from the library list BEFORE you perform the upgrade.

    After the upgrade and you’ve run your refresh CL then you can put it back above QSYS. Failure to do so can in fact cause you great grief after the upgrade with the worst case being that the system won’t even operate!

    You have been warned!

    Reply
  2. Marina Schwenk

    Good article but, we moved away from custom commands. The reasons being I have seen the flip side to this to where you have too many custom commands and your ability to standardize/automate the development process (including compiling) gets to be a bit of a mess. And Larry’s advice about at system upgrades, you have to remove the library from the system library list. We moved away from custom commands and just keep track of which commands we changed the defaults to and what in the commands we have changed.

    Reply
  3. Barbara Morris

    Be careful copying commands from QSYS when they’re already proxy commands. For example, the QSYS compiler commands like CRTBNDRPG are proxy commands for the actual commands in QDEVTOOLS. If you copy the proxy command from QSYS and do CHGCMDDFT, you’ll change the default for the “real” command in QDEVTOOLS, and for the QSYS command too.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *