Control CL Commands With Command Exit Programs -- Part 1

7/27/2019 Control CL Commands With Command Exit Programs -- Part 1

1/8

System iNetwork Head NavSubscribe My Profile Contact Us AdvertiseSearch

Primary linksForums Archives Code Blogs Podcasts Webcasts e-Learning Guides Newsletters AboutUs Contact Us About the Network Tech Editor Profiles Editorial Calendar WritersKit Advertise Join Network

CategoriesRPG ProgrammingOther LanguagesApplication DevelopmentDatabase/SQLAvailabilitySecuritySystems ManagementNetworkingIT Mgmt/CareersSite LinksSolutionsStore

EventsUK CentreJobsSystem iPortalHome ContentControl CL Commands with Command Exit Programs -- Part 1Article ID: 54958Posted June 19th, 2007 in RPG Programming Security Systems ManagementBy:Dan Riehl

Ever since the first version of the CPF operating system was shipped with the System/38, system administrators have grappled with the problems inherent in customizing the IBM-supplied CL command set. One major source of irritation was thatwhen a new release of the operating system was installed, any changes made directly to the IBM supplied commands in the QSYS library were obliterated. So, for each new operating system release, the system administrator would have to re-apply all of the command changes.

Over time, we all got a bit smarter and figured out that we could make a copy ofthe IBM-supplied command in our own library and modify the copy. By strategically placing our own library, perhaps named ALTQSYS, ahead of QSYS in the system portion of the library list, we could effectively override the IBM-supplied version. When a new release of the operating system was installed, it would replace t

he IBM-supplied version of the command in the QSYS library but leave our customized version in our ALTQSYS intact.

Because CL commands do not often undergo fundamental changes that affect the majority of us, the ALTQSYS copy of a command that was created at a previous release of the operating system typically functioned correctly. However, there were certainly exceptions in which the ALTQSYS version of the commands would fail aftera new release of the operating system was installed. Still not a perfect solution, but manageable.


2/8

If you examine the system portion of the library list on your System i using thecommand DSPSYSVAL QSYSLIBL, you will most likely see an ALTQSYS library ahead of QSYS. You will often also see the name of a vendor-supplied library. Some software vendors make a habit of placing their library on your system library list ahead of QSYS in order to override the processing of the IBM-supplied command set. This is particularly true in the case of software utility and tool vendors.

Most of us have accepted the fact that we need libraries above QSYS in our library list to support both our customized versions and vendor-supplied versions ofCL commands (and other objects). But there is an inherent danger in this scheme.Any library existing above QSYS on the system library list can potentially openthe system to a severe security exposure -- the Trojan Horse. If a user can create or change objects in a library above QSYS, or in QSYS itself, that user canintroduce his or her own program or command that can do major damage to your system.

In an attempt to eliminate the need for libraries above QSYS, IBM, back in OS/400 V4R5, enabled a facility that may make it possible to remove the libraries above QSYS from the system portion of the library list. I say may because the support provided in V4R5 deals specifically with CL command customization, but it does not account for other customized objects that may need to appear before QSYS.

The enhanced support that came in V4R5 is the CL command analyzer exit points. These exit points provide the ability to change the processing done by a CL comma

nd at runtime.

CL Command Exit Point ProgramsCL has always had validity checking programs and command processing programs. Over the years, IBM added prompt override programs, prompt choice programs, and prompt control programs. V4R5 added the new support for command analyzer exit programs that further enhance CL's capabilities, and more importantly, can enhance and simplify your system administration, configuration, and security.

Two new exit points were added to the OS/400 registration facility (WRKREGINF) that let you control the processing of CL commands. These two exit points are theCommand Analyzer Change exit point and the Command Analyzer Retrieve exit point. This article focuses on the Command Analyzer Change exit point, the Command An

alyzer Retrieve exit point will be covered in part two in a later issue.

The Command Analyzer Change Exit PointThis exit point lets you intercept a CL command before it is executed and perform your own custom processing, which could range from changing some parameter values to running a totally different command in a totally different library.

As an example, if the SBMJOB command is run, you can use the exit point programto tell the command analyzer to run the SBMJOB command found in another libraryinstead of the one found first on the job's library list. It is this capabilitythat allows us to possibly remove our libraries from the system portion of the library list.

Here's another example that points out other possibilities and is the theme of the sample exit program provided in this article. If the command WRKJOB is executed by someone with a user class *USER, you can, in the exit program, tell the command analyzer to run the DSPJOB command instead. Simple, but still a usable function.

This exit point opens a whole new world of possibilities for software vendors and System i system administrators.

When I first heard of this new capability, I assumed I would be able to add an e


3/8

xit program to a CL command using the Change Command (CHGCMD) CL command. Afterall, that's how you change the command processing program and the validity checker. Upon my first inspection of the documentation for these exit points, it became clear to me that my assumption was incorrect. Over the last several releasesof OS/400 and i5/OS, IBM has really embraced the exit point registration facility. The exit point programs are added to a command through the Registration facility Work with Registration Information (WRKREGINF) and the Add Exit Program (ADDEXITPGM) commands.

Exit Points and Exit Programs RevisitedAn exit point is a point in an application at which an external program can optionally be called to perform customized processing. The OS/400 command analyzer includes exit points where you can hook your own program into the command processing logic. To identify your exit program, and the command for which it will be called, use the ADDEXITPGM command, specifying the command name and library for which this exit program will be used and the name and library of your exit program that will process the particular command. When a request is made to the command analyzer to run a command, the analyzer checks the exit point registry to seewhether you have an exit program assigned to the requested command. If you do, it calls your exit program, passing parameters that contain the information aboutthe requested command. Your exit program then processes that information and takes the appropriate action.

Each exit point has an assigned name and an exit-point interface. The exit-point

interface is a list of input and output parameters that the command analyzer exchanges with your exit program. The name of the exit point for the command analyzer change command exit point is QIBM_QCA_CHG_COMMAND. This exit point occurs before the command analyzer prompts the command and before the validity checking program is called. The name of the exit-point interface for this exit point is named CHGC0100. This exit-point interface is different than most in that your exitprogram is passed the CHGC0100 interface as one big lump of data rather than inseparate parameters. Your program needs to parse out the individual data elements of the CHGC0100 parameter. In addition to the CHGC0100 parameter, your exit program is passed two additional parameters, as shown in the following table.

Parameter 1DescriptionInput or OutputValuesType and LengthExit Point NameInputQIBM_QCA_CHG_COMMANDChar 20Exit Point Interface Format NameInput

CHGC0100Char 8Command NameInputName of the command for which the exit program is registeredChar 10Command Library NameInput


4/8

Name of the library where the Command residesChar 10Change Allowed IndicatorInput0= No Change allowed

1= Change AllowedChar 1Command Prompt IndicatorInput0= Command has not been prompted

1= Command has been promptedChar 1Reserved for future useInput

Char 2Offset to Original Command StringInputThe offset to the beginning of the original Command String

Binary (4)Length of Original Command StringInputThe length of the original Command StringBinary (4)Original Command StringInputThe original Command String before any changesChar * (Variable Length)Parameter 2

Replacement Command StringOutputThe Command String that you want to run in place of the original commandChar * (Variable Length)Parameter 3Length of Replacement CommandOutputThe length of the Command String that you want to run in place of the originalcommandBinary (4)

As with all registered exit points, you can add your own exit point program using the ADDEXITPGM command. In the case of the Change Command exit point, you needto specify the name of the command and the library in which the command residesin the PGMDTA parameter, as in the following example.

ADDEXITPGM EXITPNT(QIBM_QCA_CHG_COMMAND) +FORMAT(CHGC0100) +PGMNBR(1) +PGM(MYLIB/WRKJOBEXIT) +TEXT('Exit program for WRKJOB') +


5/8

PGMDTA(*JOB 20 'WRKJOB QSYS')The PGMDTA parameter must be specified with a data length of 20. You must specify the command name in the first 10 positions, and the command library in the next 10 positions, as in the example. The command analyzer is directed to use the exit program WRKJOBEXIT in library MYLIB whenever a request is made to run the WRKJOB command found in the QSYS library.

There are certain commands for which exit point programs cannot be defined. These include CL compiler directing statements, commands found in libraries QSYS38,and a few others. The following is a list of commands for which exit programs cannot be registered.

CALLPRCCHGVARCNLRCVCOPYRIGHTDCLDCLFDOENDDOENDPGMENDRCVGOTO

IFMONMSGPGMRCVFRETURNSNDFSNDRCVFTFRCTLWAITCALLRTVxxxxxx

The next figure contains a sample exit program that you can use for the WRKJOB command. The exit program checks to see whether the user running the WRKJOB command has a user class of *USER. If so, the program tells the command analyzer to run the DSPJOB command instead. While the functionality of the example is quite simple, it does address the difficult parts of writing your own exit program.

Note: This program is written in CL syntax for V5R2 and earlier so that those who have not yet upgraded to V5R3 (or higher) can still use the program. If you are on V5R3 or higher, the program will still work, but you may want to update thesyntax.

Command Exit Point Program Example

--------------------------------------------------------------------------------

/* Program Name: WRKJOBEXIT *//* Purpose: This is the exit program for the Command WRKJOB. *//* Exit Point IS QIBM_QCA_CHG_COMMAND *//* Parameter format for parm1 is CHGC0100. *//* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *//* Copyright 2002-2007 Dan Riehl All rights reserved */


6/8

PGM PARM(&ExitInfo &NewString &Newlength)

DCL &Class *CHAR 10DCL &OffsetDec *DEC (7 0)DCL &CmdLenDec *DEC (7 0)

DCL &ExitInfo *CHAR 2000 /* CHGC0100 interface data *//* Exit point interface CHGC0100 for QIBM_CA_CHG_COMMAND exit point *//* Input parameters */

DCL &ExitPoint *CHAR 20 /* Exit Point name */DCL &ExitFormat *CHAR 8 /* Exit Point Format */DCL &CmdName *CHAR 10 /* Command name being executed */DCL &CmdLib *CHAR 10 /* Command Library */DCL &Change *CHAR 1 /* Change allowed? 1=yes 0=no */DCL &Prompt *CHAR 1 /* Prompt requested? 1=yes 0=no */DCL &Filler *CHAR 2 /* Reserved by IBM */DCL &Offset *CHAR 4 /* Offset to command string */DCL &CmdLength *CHAR 4 /* Command string length */DCL &CmdString *CHAR 2000 /* Command String */

/* Output Parameters */DCL &NewString *CHAR 2000 /* Replace with this command */DCL &NewLength *CHAR 4 /* Length of new command */

/* 0 = no new command */

/* Error handling variables */DCL &MsgID *CHAR 7DCL &MsgFile *CHAR 10DCL &MsgFLib *CHAR 10DCL &MsgData *CHAR 512

MONMSG CPF0000 EXEC(GOTO ERROR)

/* Parse out the exit info data */CHGVAR &ExitPoint %SST(&ExitInfo 1 20)CHGVAR &ExitFormat %SST(&ExitInfo 21 8)CHGVAR &CmdName %SST(&ExitInfo 29 10)

CHGVAR &CmdLib %SST(&ExitInfo 39 10)CHGVAR &Change %SST(&ExitInfo 49 1)CHGVAR &Prompt %SST(&ExitInfo 50 1)CHGVAR &Filler %SST(&ExitInfo 51 2)CHGVAR &Offset %SST(&ExitInfo 53 4)CHGVAR &CmdLength %SST(&ExitInfo 57 4)CHGVAR &CmdLenDec %BIN(&Cmdlength)CHGVAR &OffsetDec (%BIN(&Offset) + 1) /* Set offset */CHGVAR &CmdString %SST(&ExitInfo &OffsetDec &CmdLenDec)

IF (&Change = '0') GOTO ENDIT /* If Change is not allowed */

RTVUSRPRF USRCLS(&Class)

IF (&Class = '*USER') DO /* If a user class of *USER */CHGVAR &NewString 'QSYS/DSPJOB'CHGVAR %BIN(&Newlength) 11

ENDDO

ENDIT: RETURN /* Normal end of Program */

/* Error handling */ERROR: RCVMSG MSGTYPE(*LAST) MSGDTA(&MsgData) +


7/8

MSGID(&MsgID) MSGF(&MsgFile) +SNDMSGFLIB(&MsgFLib)

MONMSG CPF0000 EXEC(RETURN)SNDPGMMSG MSGID(&MsgID) MSGF(&MSGFLIB/&MsgFile) +

MSGDTA(&MsgData) MSGTYPE(*ESCAPE)MONMSG CPF0000 EXEC(RETURN)ENDPGM

--------------------------------------------------------------------------------

Examining the WRKJOB Command Exit ProgramYou can see that the exit program receives the three parameters that were discussed previously. As mentioned, the first parameter contains a CHGC0100 data structure that must be parsed into its individual fields. Then the fields that will be used to store the CHGC0100 format data once it is parsed are defined. The CHGC0100 format is then parsed into its component parts. In this example, some extrawork is done to parse the command string and to determine the offset to the command. While the sample doesn't need nor use this information, the code is provided for instructional purposes so that you can use this section as a template towrite your own exit programs.

Next, the change indicator is queried to determine whether the command is changeable by the exit program. If a command is library-qualified when it is passed tothe command analyzer, as in the command QSYS/WRKJOB, it is not changeable by the exit program and the change indicator will have a value of '0'. There are a fe

w other occasions when a command cannot be changed, these consist of commands that

have a parameter defined with RTNVAL(*YES), for example all CL retrieve (RTVxxxx) commandshave parameters defined with DSPINPUT(*NO) or DSPINPUT(*PROMPT)are running in a System State programBack in V4R5, IBM introduced the new qualifier value of *SYSTEM. The purpose ofthis new qualifier was to allow a sort of "non-qualified" qualified reference toan object. For example, if a command is specified as *SYSTEM/WRKJOB, the WRKJOBcommand in the QSYS library will be used. The *SYSTEM qualifier gets the objectfrom QSYS, while not explicitly identifying QSYS. If you want to qualify commands in your applications and still want to use exit programs to change the comman

ds, use the *SYSTEM qualifier, which under the covers will actually be a qualification to library QSYS.

In the next piece of code, the replacement command is set to QSYS/DSPJOB if theuser running the WRKJOB command has a user class of *USER. The exit program thenends.

You may notice that CL variables used in the exit program to store command strings are 2,000 bytes long. Prior to V5R3, CL character variables could not be longer than 2,000 bytes; now the CL limit is 9,999. While 2,000 bytes is certainly sufficient to hold the WRKJOB command string in this example, the actual length of a command string that can be processed through the exit point interface is 32,000 bytes.

The sample program is written in CL in an attempt to make the exit program simple to read and understand. Exit programs do not need to be written in any particular language, and although they can be, do not need to be written for ILE.

The Exit PointHopefully this walk-through and example code will be helpful to you. This capability to control commands at runtime opens realms of possibilities in applicationdevelopment and system administration. Try this out on a few commands that youwant to customize and you may find that you can remove a library or two that sit


8/8

above QSYS on your system library list. Wouldn't that be worth the time and effort?

In part two of this series I will cover the Command Analyzer Retrieve Command exit point.

Bookmark/Search this post with:Email this page Printer-friendly version

Related LinksManaging Restricted CommandsKiller Club TechKiller Club TechTech TipsKiller Club Tech

ProVIP Sponsors

ProVIP Sponsors

Featured LinksIT Leaders Forum - Gartner, IBM, and more in Denver.Sponsored Links

Modernizing Apps to the Web is way Easier & more Affordable with BCD's WebSmart!Hear how your peers have evolved their legacy apps with RAMP from LANSAReplacing Query/400? View "Elevator, Act 1" with Randall Munson.Modernize CA 2E and CA Plex applications automatically -- ADC AustinModernize to J2EE/JSF/RPGILE- with X-Analysis & Rational Webinar

Footer Site LinksHome Subscribe Now Advertise Contact Us Feedback Terms & Conditions Trademarks Privacy Policy Copyright Penton Media

Documents

Control CL Commands With Command Exit Programs -- Part 1