| The CL Corner: Use Your Own Names for Supplied Commands |
 |
 |
 |
| Tips & Techniques - CL | ||||||||||
| Written by Bruce Vining | ||||||||||
| Thursday, 04 December 2008 20:00 | ||||||||||
|
Did you know you could use KILL rather than ENDJOB?
Over the years, many users have assigned their own names to various IBM-provided commands. Historically, they may have duplicated the IBM command to another library, changing the name, or they may have written their own command and command processing program (CPP), which then used the IBM-provided command. These approaches have drawbacks--a major one being that release changes to the IBM commands (new parameters, new parameter values, etc.) would often cause those users to have to also change their instance of the command. With V5R4, IBM provides a much easier way to use your own names for existing commands.
The enabler for this new support is the Create Proxy Command (CRTPRXCMD) command, which is documented here. This command allows us to provide an alias, or alternative name, to another command. For instance, to have the system support KILL as being synonymous with the ENDJOB command, you would use the following CRTPRXCMD command:
CRTPRXCMD CMD(VINING/KILL) TGTCMD(ENDJOB)
This command creates a new user-defined proxy command named KILL in library VINING. When you run or prompt the KILL command, you will actually be running or prompting the ENDJOB command.
When you create a proxy command, you do not specify any command definition source. The proxy command does not contain any parameter definition information, prompt control information, validity checking information, or environment information. When the proxy command is used, all of this information is inherited from the target command (TGTCMD) specified with the CRTPRXCMD command. This inheritance by the proxy command is great in that you are no longer tied to the IBM definition of the target command. This means that release-to-release changes will not impact you in the way duplicating the IBM command might have in the past.
This inheritance has a drawback, however. It also means that you cannot selectively change command defaults with the Change Command Default (CHGCMDDFT) command. Any change to the KILL proxy using CHGCMDDFT actually changes the underlying target command ENDJOB. So you cannot, for instance, use the CHGCMDDFT command to have the original command ENDJOB default to OPTION(*CNTRLD) while the KILL proxy defaults to OPTION(*IMMED). Notice though that I have qualified this restriction in terms of using CHGCMDDFT. There is a way to have KILL use OPTION(*IMMED) while ENDJOB uses OPTION(*CNTRLD), and we'll look at this shortly.
As you can see, creating a Proxy command is quite simple. The first proxy command I created was for the SIGNOFF command. Perhaps it's only me, but when I'm in a hurry, I frequently type SINGOFF rather than SIGNOFF. This typo simply delays me when I'm already in a rush. So I was more than happy to use the following command and avoid future delays due to this error.
CRTPRXCMD CMD(SINGOFF) TGTCMD(SIGNOFF) TEXT('Bruce''s SIGNOFF')
You, if moving to the i from another environment, may likewise want to utilize proxy commands. If you are familiar with the S/36 environment, creating a proxy named OFF for SIGNOFF might be useful. In a similar vein, the proxy LOGOFF may be appropriate for some users.
In addition to the CRTPRXCMD command, there is also the Change Proxy Command (CHGPRXCMD) command to change a proxy command. When changing the proxy command, you can only change the target command and the text description of the proxy. Other characteristics of the proxy command are maintained using traditional commands. For instance, to delete a proxy command, you use the existing Delete Command (DLTCMD) command. To change the public authority of the proxy command, you might use the existing Grant Object Authority (GRTOBJAUT) command as in this example:
GRTOBJAUT OBJ(VINING/SINGOFF) OBJTYPE(*CMD) USER(*PUBLIC) AUT(*ALL)
Earlier, I mentioned that you could have the KILL proxy command use OPTION(*IMMED) of the target ENDJOB command while the ENDJOB command itself continued to use OPTION(*CNTRLD) by default. You can do this by using the Command Analyzer Change exit point QIBM_QCA_CHG_COMMAND, which is documented here. The Command Analyzer Change exit point can call a user-written exit program when a particular command is run. The command to run, when using proxies, is the target command--ENDJOB in our case. When the exit program is called, the user program generally can replace the command that was originally requested or, as is our case, specify additional parameters, such as OPTION of ENDJOB. The exit program is passed several fields of information. One key piece of information that we will use is the proxy chain used to finally get to the ENDJOB command being run.
In the next article, we will look at a sample program that is called whenever the ENDJOB command is processed. This sample program will determine if the ENDJOB command was reached by way of the KILL proxy command. If KILL was used, the exit program will then add OPTION(*IMMED) to the command string to be run. More CL Questions?Wondering how to accomplish a function in CL? Send your CL-related questions to me at bvining@brucevining.com. I'll try to answer your burning questions in future columns. | ||||||||||
View all articles by this author
|
||||||||||
| Matt Tyler |
The CL Corner: Use Your Own Names for Supplied Commands
Jan 30 2009 22:12:32 |
#152343 |
| klaborde |
Re:The CL Corner: Use Your Own Names for Supplied Commands
Jan 30 2009 22:21:59 Hello Matt, Unless this has changed, and I am no expert. A User ASP other then 1 can only contain *SAVF or Journal/Receivers. I bet if you create a temp library in ASP1, it will work for you. I will be watching this thread to know if I am wrong. Thanks, Keith
|
#152344 |
| Matt Tyler |
Re:The CL Corner: Use Your Own Names for Supplied Commands
Jan 30 2009 23:05:40 Yes things have chagned. IBM as now a thing called a Indenpendent ASP and its named. The IASP numbers start at 33 and up. We have only one and use it for a hot swap roll over to reduce the time for the roll over and reduce the need to replicate to the hot swap LPAR. I can create a proxy command in QGPL (ASP 1) from a command in a IASP (ASP 33) with no errors. It seems that I cannot create the proxy command into a IASP library (ASP 33). Thanks, Matt
|
#152346 |
| BVining |
Re:The CL Corner: Use Your Own Names for Supplied Commands
Feb 27 2009 22:35:33 If you have not done so already, I would suggest submitting an APAR on this. There is no reason a proxy command cannot exist in an Independent ASP. In most environments I would in fact expect the proxy command to be in the same IASP as the target command. If there was a restriction I would have expected it to be that the proxy and target needed to be in the same IASP -- the opposite of what you're reporting. Bruce (who apologizes for not responding earlier, I just noticed this thread...)
|
#152424 |
| Matt Tyler |
Re:The CL Corner: Use Your Own Names for Supplied Commands
Mar 02 2009 22:15:22 There is a PTF for V5.4 SI32960 (APAR SE34919) that fixes the problem. Thanks, Matt
|
#152429 |
