This may seem to be a no-brainer … but it’s very important to NOT change command parameter defaults on commands in the QSYS library.
This is especially true if you use 3rd party software that may not expect your commands to have different defaults.
Over the past few weeks I’ve been struggling to help a customer with a particularly tough problem.
I won’t go into the gory details … but suffice it to say, a program that was running a very benign command ended up behaving in a completely unexpected way … which caused a major failure.
It was very hard to nail down … we even involved IBM support … they were baffled too.
After countless emails and a few conference calls, we identified what we thought might be the culprit … asked the customer to remove the modified command default, and the program worked fine.
The best way to have commands with different default values is to duplicate the command into your own version of QSYS and change the parameter defaults on the duplicated command. You then put the library with the modified commands higher than QSYS on your system library list (either changing the QSYSLIBL system value or executing a CHGSYSLIBL command when users sign on).
This way, when you don’t want the customized default values, all you have to do is remove the library from the system library list.
It has the added benefit of documenting the commands that have altered defaults … so you can clearly identify unexpected command behavior.
You can tell if a command has had it’s defaults changed by doing a DSPOBJD on it, displaying the *SERVICE information, and looking at the APAR ID field. If it contains “CHGDFT”, then the parameter defaults have been changed.
Excellent point David! One thing to add is to be very careful with proxy commands. When you change the command default of a proxy the change is actually made to the original command. So if you’ve created any of these be aware of the base command and where it sits before you make changes to the command default.
Larry, yes!
IMO proxy commands were not IBM’s brightest idea, just because of what you mentioned. They should prohibited CHGCMDDFT to proxy commands or something.
I have a program to CRTDUPOBJ/CHGCMDDFT for the commands whose defaults I’ve changed. When proxy commands came along, I enhanced it to use IBM’s command attributes API to determine if the command is a proxy or not, and if it is, where the original command lives, so that I always CRTDUPOBJ from the base command.
The other thing ISVs can do is specify every single command parameter of every single command in their CLs.
Unfortunately, prompt the command, and you lose all the defaults.
The only problem with that is … new parameters are added to commands on a regular basis. Kind of hard to specify all possible parameters if they don’t exist when the program is written.
Additionally, if you need to support multiple releases, you would have to construct the commands as character fields and execute them through
QCMDEXC. Not exactly the most efficient way of doing things.