Skip to main content

Multiple Mainframe Connector Started Tasks and New Password Exits

This section pertains to sites who plan on running multiple Mainframe Connector started tasks on the same z/OS image AND who also want to use z/OS as a trigger system for transparent synchronization. In order to accomplish this, the customer must build a table that maps userids to subsystem names. The generated table is a non-executable load module named PSNCUIDT that must reside in a multi-address space accessible location (most probably either the link pack area or the system linklist).

A table generation macro is provided in the .INSTLIB Mainframe Connector dataset in member UIDSSN . This macro is used for three purposes:

  • To define the table header record that contains, if specified, the default subsystem name to be used by any userid entry definitions that have omitted a subsystem name parameter

  • To define userid entry records that specify userids (that can be fully qualified or masked) and the associated Mainframe Connector subsystem name

  • To define the table trailer record that is used to indicate the end of the table

A sample PSNCUIDT source deck using the UIDSSN macro would look similar to the following:

*
*   HEADER record sets DFLTSSN to PS1.  This indicates that any
*   UIDENTRY record that does not include a SSNAME parameter will
*   have its SSNAME set to PS1.
PSNCUIDT UIDSSN HEADER,DFLTSSN=PS1
*   Target userid MTECH1 to Mainframe Connector subsystem PS1
         UIDSSN UIDENTRY,USERID=MTECH1,SSNAME=PS1
*   Target userid MTECH2 to Mainframe Connector subsystem PS2
         UIDSSN UIDENTRY,USERID=MTECH2,SSNAME=PS2
*   Target userid MTECH3 to Mainframe Connector subsystem PS1
         UIDSSN UIDENTRY,USERID=MTECH3,SSNAME=PS1
*   Target any userid prefixed MTCH to Mainframe Connector subsys PS3
         UIDSSN UIDENTRY,USERID=MTCH-,SSNAME=PS3
*   Target a userid prefixed DBA followed by any other character
*   to the default Mainframe Connector subsystem PS1
         UIDSSN UIDENTRY,USERID=DBA*
*   TRAILER record indicates the end of the table
         UIDSSN TRAILER
         END

The number of UIDENTRY table entry definitions required will obviously depend on the number of Mainframe Connector subsystems that will be operational and the uniqueness of the userids. The more generic the userid, the more likely a masked UIDENTRY table entry can be used.

Once the source deck has been created, it will need to be assembled using a standard assembly job similar to the following:

//ASM      EXEC PGM=ASMA90,REGION=6M,
//    PARM='LIST,NODECK,OBJECT,XREF(SHORT)'
//SYSPRINT DD   SYSOUT=*
//SYSLIB   DD   DSN=mfc.V700.INSTLIB,DISP=SHR
//SYSUT1   DD   UNIT=SYSDA,SPACE=(CYL,(3,3))
//SYSUT2   DD   UNIT=SYSDA,SPACE=(CYL,(3,3))
//SYSUT3   DD   UNIT=SYSDA,SPACE=(CYL,(3,3))
//SYSLIN   DD   DSN=mfc.V702.F1(PSNCUIDT),DISP=SHR
//SYSIN    DD   DSN=psncuidt.source.dataset(PSNCUIDT),DISP=SHR

To create the PSNCUIDT load module table, run a linkedit job similar to the following:

//IEWL     EXEC  PGM=HEWLH096,PARM='XREF,LIST,MAP'
//SYSPRINT DD    SYSOUT=*
//SYSUT1   DD    UNIT=SYSDA,SPACE=(CYL,(2,1))
//OBJECT   DD    DSN=mfc.V702.F1,DISP=SHR
//SYSLMOD  DD    DSN=target.load.library,DISP=SHR
//SYSLIN   DD    *
   INCLUDE OBJECT(PSNCUIDT)
   NAME    PSNCUIDT(R)

Depending on the site’s performance expectation and the anticipated frequency on how often the PSNCUIDT table will change, the two most likely locations for PSNCUIDT are the system link pack area (LPA) or the system linklist (SYS1.LINKLIB or one of the other datasets in the system linklist concatenation).

PSNCUIDT is loaded dynamically by Mainframe Connector each time it is referenced so this allows for the table to be dynamically updated and refreshed as required. This can be accomplished by z/OS operator commands for either location choice - either the system LPA or the system linklist.

In this section: