Often I have seen system administrators secure sensitive CL commands to a select group of users. Commands like DSPUSRPRF and RSTLIB are always good candidates. Often an authorization list is used to secure the commands, which is a great choice.

I came across such an i/OS installation recently. About 15 commands were secured using an authorization list that provided *USE authority to the commands to a selected group profile ITADMIN. Authorization for *PUBLIC is *EXCLUDE, which restricts the commands from *PUBLIC use.

When I see this type of command authorization, I always wonder what licensed programs are installed on this machine. When I did the GO LICPGM and selected the "Display Installed Licensed programs" option, I was unsurprised to see the "System/38 Environment." This pointed to a problem. The System/38 environment contains many of the same commands that had been secured by the authorization list. When I showed the administrator that I could just use the command QSYS38/DSPUSRPRF, he was a bit taken aback--the command in QSYS had been secured by the authorization list but not the older version of the command found in the QSYS38 library.

If you intend to lock down command usage, make sure you find ALL instances of the command and lock them ALL down. You can find all the versions of a command using the command:

WRKOBJ   (*ALL/DSPUSRPRF)  *CMD

Note that some commands, such as WRKUSRPRF, did not exist on the System/38 and therefore have no matching command in the System/38 environment. But the System/38 did have DSPUSRPRF, which is quite similar in function to the WRKUSRPRF in the QSYS library.

For the best protection, remove the old licensed programs you no longer need, including the System/38 and System/36 environments, so you don't have to worry about multiple versions of commands. But always check anyway with the WRKOBJ command--you never know if someone has cloned a command from QSYS into another library.

What about copied commands with a different command name?

If someone has created a duplicate of a command and assigned it an alternate name, that's a lot harder to find. For example, if the DSPUSRPRF command is copied to a new command named DU, you'll need to write a program to locate them both. The program could simply retrieve selected command attrinutes(CPP, VCP, etc) for all commands on the system and store them in a data file. Then, you'll need to write and run a program/process that will detect duplicates. Check the duplicates to see if they are indeed clone commands used as shortcuts or even as rougue commands.

Since the system does not have an i/OS command to retrieve command attributes, you can use the RTVCMDINF command presented by Carsten Flensburg in the June 18th newsletter [2].

The RTVCMDINF command uses the IBM API QCDRCMDI to access command attributes.

What about Proxy Commands?

Be aware that in V5R4 and above, IBM provides proxy commands for many IBM-supplied commands. For example, the STRSEU and STRPDM command in QSYS are proxy commands that point to the real commands in library QPDA.

You can also create your own proxy commands using the command CRTPRXCMD.

Regardless of whether a command is a proxy command or a real command, you can specify the authority for command or proxy. In order to run a proxy command, you must be authorized for both the proxy and the real command.