IT Management

Job Entry Subsystem 2 (JES2) removed a restriction for Time Sharing Option (TSO) ids back in z/OS Version 1 Release 4 (V1R4) that prevented a user from logging on to multiple JES2 members in the same Multi-Access Spool (MAS) with the same userid (multiple logon). Before JES2 removed this restriction, a user had to use a different logon id to access another JES2 member in the same MAS. When users began to exploit multiple logon, a number of incompatibilities were discovered with TSO, Interactive System Productivity Facility (ISPF), Spool Display and Search Facility (SDSF), and even JES2 itself.

Back in early 2004, the ISPF SHARE committee (Tom Conley, Lionel Dyck, and Jim Narramore) met to discuss the new feature in JES2 permitting multiple logon. Based on that meeting, Lionel Dyck wrote an article in May 2004, laying the groundwork for overcoming some of the difficulties with implementing multiple logon (see item 1 under “References”). Since then, the requirements for implementing multiple logon have changed significantly. This article reviews the original recommendations from May 2004, discusses changes since then, and describes current requirements for implementing multiple logon. 

Dyck listed four steps to implement multiple logon support:

  1. Ensure the SYSIKJUA enqueue scope is SYSTEM, not SYSTEMS, and the SYSIKJUA enqueue isn’t specified in the exclude list for your serialization product.
  2. Code and install ISPF exit 16 to ensure ISPF temporary data sets (TEMP, CNTL, LIST, LOG, etc.) have unique names for each Logical Partition (LPAR).
  3. Choose one of three ISPF profile data set strategies: a non-shared profile data set unique to each LPAR, a temporary profile data set with primed members, or a shared profile data set for all systems.
  4. When choosing a shared profile data set, change the SPFEDIT enqueue from SCOPE=SYSTEMS to SCOPE=SYSTEM for data sets matching the profile data set name (e.g., *.ISPF.PROFILE).

In the shared profile environment listed in step 3, the last system to update the profile “wins”; any previous updates to the profile are discarded. The last update is reflected the next time the profile is opened. When using non-shared or temporary profile data sets, it was discovered in early 2005 that data loss is also a problem due to ISPF EDIT recovery.

ISPF saves EDIT recovery data in profile member ISREDRT. In a temporary profile environment, EDIT recovery changes are lost because ISREDRT isn’t saved across ISPF sessions. In a non-shared profile environment, a user logs on to SYSA, edits a data set, gets called away and times out, creating a pending recovery for the data set on SYSA. A few hours later, the same user logs on to SYSB and edits the same data set. Due to the non-shared profile, SYSB doesn’t detect the pending recovery because the ISREDRT recovery member is in the non-shared profile data set for SYSA. The user then saves the data set on SYSB. The user later logs on to SYSA to edit a data set, is presented with the ISPF edit recovery screen, recovers the data set and saves it, causing the updates from the SYSB edit session to be lost. The data loss can be anything from a minor nuisance to a major problem, depending on the extent of the recovery. Because the results can vary greatly, it’s difficult to detect. Some sites have taken months to detect this problem.

Due to the problems with non-shared or temporary profiles and ISPF EDIT recovery, a shared profile data set is really the only option. Unfortunately, since the last system to update the profile always won, ISPF development needed to create a solution that was more flexible and addressed the enqueue issues from implementation step 4. In z/OS Version 1 Release 9 (V1R9), ISPF released shared profile support, which modifies the profile enqueue mechanism to allow multiple systems to safely share and update the profile data set. Previously, and with non-shared profile support, ISPF issues an exclusive enqueue while the profile data set is open. With z/OS V1R9 and shared profile support, ISPF uses a shared enqueue when reading a profile member into storage and an exclusive enqueue when updates are written back to the profile member. This new enqueue mechanism eliminates the need to modify the ISPF enqueues as specified in step 4.

ISPF shared profile support is enabled with the ISPF Configuration Dialog ISPCCONF. ISPF also provides the SHRPROF command to control shared profile support for individual sessions. Shared profile support must be enabled for SHRPROF to work. The usage of ISPCCONF is beyond the scope of this article. For more information you can reference the SHARE presentation “Configuring ISPF for Fun and Profit” (see item 2 under “References”).

To enable ISPF shared profile support, enter ISPCCONF and go to option 1.4 to modify ISPF Site-Wide Defaults in the ISPF Keyword File. Scroll down to the ISPF shared profile options section, as shown in Figure 1. Specify a unique identifier for “Temporary Data Sets - Additional Qualifier.” Use the &SYSNAME system symbol in this parameter, which will create ISPF temporary data sets unique to each LPAR. This eliminates the need for an ISPF installation exit as specified in step 2. The ability to use system symbols in this parameter was added in z/OS Version 1 Release 5 (V1R5). Specify “/” for “Multi-logon Profile Sharing” to enable ISPF profile sharing support. Specify “/” for “Prompt for Profile ENQ Lockout” if you want to be prompted when the profile can’t be updated by ISPF due to ENQ contention. For “ENQ Lock Wait” and “ENQ Lock Retry Count,” use the defaults of 1000 (1 second) and 1, respectively, unless you have an experience that would cause you to change them.

For profile conflicts, use the defaults of “Keep” for profile conflicts under TSO,” which works as ISPF currently does (last update wins), and “Discard” for batch, to prevent batch updates from overriding TSO updates. Discard could also be used to make one system the “master,” where that system would specify “Keep” and all other systems would specify “Discard,” but otherwise isn’t recommended. “Prompt” is probably too annoying to be of general use.

2 Pages