Skip to content

Getting Started

Detailed descriptions of exit point locations, exit data formats, and task modify commands are provided in the sections which follow. This brief section should be seen as a checklist of how to get started with this feature.

  1. HLLX started task procedure - Define the JCL procedure for the HLLX address space in a system procedure library from which it may be started. You should also set up security for this started task to be the same as that for the ZMF/Sernet started task. That is, use the same userid. (See sample JCL member HLLXJCL in the CMNZMF CNTL distribution library. See The HLL Exit Processing Address Space for an example.)

  2. Take a look at the samples provided in the CMNZMF SAMPLES distribution library for the kinds of things that can be done in the HLL exits. The samples should have enough comments for you to be able to understand what they do.

  3. Familiarize yourself with the data formats for the different functions. These data formats are described in a later section. Note that there is a standard data structure for each function, regardless of exit point, but that not every exit point has all the information indicated by the full structure.

  4. Set up and start your test ZMF 8.1 (or later) subsystem. ZMF will come up without starting the HLLX address space if no active HLL exit points have been defined yet.

  5. Connect to the ZMF 8.1 (or later) started task through the ISPF client and use admin option A.G.8 to set your exit values. To begin with you must set the correct name for the HLLX started task procedure. On your first HLLX admin session that’s all you need to do. Save this definition away and you will be ready for what comes next.

  6. Decide which exit point you are going to investigate first and prepare the exit code. Note that compiled/linked exits are loaded from the HLLX started task STEPLIB. This means you will need access to an APF-authorized library in which to put these exits. This library is concatenated to the standard ZMF/Sernet started task STEPLIB. (This requirement is the same as for the standard ZMF assembler exits.) REXX execs need only be placed in the library referenced by the HLLXREXX ddname in the HLLX started task procedure JCL.

  7. Using admin function A.G.8, update the HLLX admin definitions to correctly describe and activate your exit points. When you save (PF3) from the table display the changed contents will be saved to the Package Master.

  8. Inform the HLLX address space that the exit definitions have changed. You can use the Administration menu options described in Modify for all these modify commands. In this case you can issue the following modify command:

    /F zmfstcname,CMN,ATTACH,HLLX

    to start the HLLX address space. Note that all modify commands are directed to the ZMF started task, not the HLLX started task.

    The HLLX address space must be notified of any further in-flight changes to exit admin (that is, any changes after the HLLX address space is active) with the following modify command:

    /F zmfstcname,CMN,RELOAD,HLLX

    Note that all in-flight HLLX conversations are invalidated when you enter this command. All in-flight HLLX conversations are also invalidated if you stop the HLLX address space with the following command:

    /F zmfstcname,CMN,DETACH,HLLX

    and restart it again with an ATTACH command (another way of reloading the admin definitions to the HLLX address space). The most intrusive way to reload these definitions is to shut down ZMF (which will automatically shut down HLLX) and restart it.

    Note

    The HLLX started task should never be started or stopped directly. It only exists to service requests from ZMF. ZMF starts it up and ZMF shuts it down. It will also respond to an MVS stop command by shutting down, but that should never be necessary in normal operations.

    Any displays put in the exits will output in the HLLX address space.

  9. Drive the exit(s) by using the relevant ZMF function.

Samples Provided

The CMNZMF SAMPLES distribution library contains a number of members that relate to HLL sample exit code. None of this code is warranted (the exit code belongs to you), but these samples have all been used successfully in testing this feature.

CMNZMF SAMPLES Member Name Contents
HXC* Sample HLL exit code written in COBOL.
HXP* Sample HLL exit code written in PL/I.
HXR* Sample HLL exit code written in REXX.

Use IEBCOPY or ISPF 3.3 to copy these members to your HLL exit source or REXX exec libraries.

Note that compiled/linked exits must be re-entrant.

Copybooks for the exit data areas can be found in the CMNZMF ASMCPY distribution library. They are:

  • CMNCX* - COBOL copybooks

  • CMNPX* - PL/I copybooks

HLLX Activity Logging

Certain key activities related to HLLX are logged to the standard ZMF log file. There are two activity logging facilities reachable from the ChangeMan ZMF Primary Option Menu (=L).

CMNLOGE2                 Select Activity Log Codes            Row 35 to 72 of 81
Command ===> _________________________________________________  Scroll ===> CSR

    Code  Description
    _38   HLLX administration
    _39   HLLX commands

There are two classes of activity, administrative changes (log indicator 38) and state changes via MVS modify commands (log indicator 39). Any activity which results in an update to the exit definitions in the pmast will result in a log entry which looks like this (when browsing the log file). The modify-from-ISPF facility results in two log entries for each modify command. The ISPF admin function writes a log record as soon as it requests the modify action. Then the modify action itself writes a record. For example, if =A.G.8.Z.1 was used to reload the HLLX exit table it would generate two log records, and then selecting 38 might give a result like this output:

CMNLOGDS                  Activity Log Entries              Row 1 to 8 of 8
Command ===>______________________________________________ Scroll ===> CSR

Date     Time    User    Package     Description                            +
20170403 010145 WSER58   HLLX Modfy  Action: RELOAD
20170403 010145 CMNSTAR  HLLX cmd:   RELOAD HLLX
******************************* Bottom of data ********************************

The general format is the usual log timestamp, followed by the userid making the update, an indication of whether we are updating, modifying or deleting, a procedure or an exit definition. For a procedure definition the only other data in the record is the value of the procedure name after the change has been made. For an exit definition there are a number of values all comma delimited as follows:

  • Exit: Internal exit name,

  • Standard exit active Y/N

  • Standard exit LE or REXX L/R

  • Debug exit active Y/N

  • Debug exit LE or REXX L/R

  • First 8 bytes of standard exit external name

  • First 8 bytes of debug exit external name

  • The 10 debug userids

Similarly, selecting 39 might give a result like this output:

CMNLOGDS                  Activity Log Entries                      Row 1 to 8 of 8
Command ===>______________________________________________________ Scroll ===> CSR

Date     Time   User    Package   Description                                     +
20170322 193834 CMNSTAR HLLX cmd: RELOAD HLLX
20170322 200835 CMNSTAR HLLX cmd: RELOAD HLLX
20170322 201120 CMNSTAR HLLX cmd: RELOAD HLLX
20170322 202529 CMNSTAR HLLX cmd: RELOAD HLLX
20170322 202843 CMNSTAR HLLX cmd: RELOAD HLLX
20170323 214011 CMNSTAR HLLX cmd: RELOAD HLLX
20170323 214851 CMNSTAR HLLX cmd: DETACH HLLX
20170323 214912 CMNSTAR HLLX cmd: ATTACH HLLX
******************************* Bottom of data ********************************

Note that the userid for all modify commands will be that of the main ZMF started task, in this case CMNSTAR, as the process is actioned by the ZMF main started task.