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.