z/OS MVS Programming: JES Common Coupling Services
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Ending and Restarting the JESXCF Address Space

z/OS MVS Programming: JES Common Coupling Services
SA23-1387-00

For a variety of reasons you might need to end the JESXCF address space and then restart it. Indications that you might need to bring the JESXCF address space down include:
  • JESXCF abended with system code DC5 or EC5
  • One or more members of your system have become unresponsive
  • A review of SYSLOG indicates a JESXCF problem
  • On a JES2 system, you receive the $HASP501 and MVS IXZ0108E messages

If you determine, based on system messages and diagnostic codes, that you must end JESXCF, you must first dump the JES and JESXCF address spaces prior to restarting your JES and JESXCF. Follow the procedures listed here:

  1. Dump the JES and JESXCF Address Spaces
    If the problem appears to be between the JES (JES2 or JES3) address space and the JESXCF address space on a SINGLE MVS image gather the following documentation:
    • Dump of the JES address space and its data spaces
    • Dump of the JESXCF address space and its data spaces
    • SYSLOG from MVS.
    If the problem appears to be between the JES (JES2 or JES3) address space and the JESXCF address spaces on MULTIPLE MVS images gather the following documentation:
    • Dump of the JES address space and its data spaces on each MVS image involved.
    • Dump of the JESXCF address space and its data spaces on each MVS image involved.
    • Dump of the XCFAS address space and its data spaces on each MVS image involved.
    • SYSLOG from each MVS image
    The following scenario helps to illustrate the steps you need to take. Assume the an environment of two MVS images:
          -   SY1 - member name JESA
          -   SY2 - member name JESB
          -   JESA and JESB are running in the same MAS
          -   JES2 is the primary subsystem on each
          -   Both JES2s are members of a JESXCF group called WSC
    1. Member JESA has tried to start an NJE session with another node but the connection does not complete.
    2. SY1 received the following message:
      $HASP501 NJE SIGNONS DELAYED, RESPONSES NOT RECEIVED FROM MEMBER JESB
    3. A review of previous SYSLOG messages finds SY1 has previously received the following message:
      IXZ0108E COMMUNICATION FROM WSC$JESB TO WSC$JESA HAS BEEN LOST, GROUP WSC
    4. To determine the status of the WSC group as detected by MVS XCF, issue the following MVS command on both SY1 and SY2:
                 D XCF,GROUP,WSC,ALL
    5. The response on both SY1 and SY2 is:
      IXC333I  hh.mm.ss  DISPLAY XCF INFORMATION FOR GROUP WSC
                 MEMBER NAME:  SYSTEM:  JOB ID:  STATUS:
                 WSC$JESA      SY1      JESXCF   ACTIVE
                 WSC$JESB      SY2      JESXCF   ACTIVE
    6. The response shows the two JESXCF members to be in a normal (active) state. Therefore, you do not need to take a dump of MVS XCF on either system.
    7. Since the time between the IXZ0108E message and the $HASP501 message has been several minutes it appears there is a problem somewhere in the JESA/JESXCF(SY1) or JESB/JESXCF(SY2) flow. To gather the necessary documentation for problem determination, issue the following MVS dump command on SY1: (Because you can't determine which MVS image is the source of the problem, use this command to dump the JESXCF and JES2 address spaces and associated data spaces on both MVS images.)
         DUMP COMM=(Start of NJE on SY1 hanging)
         r ww,JOBNAME=(JES?,JESXCF),CONT
         r xx,DSPNAME=('JES?'.*,'JESXCF'.*),CONT
         r yy,REMOTE=(SYSLIST=SY2('JES?','JESXCF'),DSPNAME,SDATA),CONT
         r zz,SDATA=(COUPLE,RGN,ALLNUC,CSA,PSA,SQA,SUM,TRT),END

      Refer to OS/390 System Commands for additional information on the DUMP command and the use of the wildcard characters '?' and '*' within the command.

  2. Dump JESXCF and Other JESXCF Group Member Address Spaces. Your system might include other members of the JESXCF group:
    • In JES3 -- other than the JES3 address spaces on the JES3 global and JES3 locals, these members might include:
      • - JES3 writer FSS address spaces on any processor,
      • - JES3 C/I FSS address spaces on any processor,
      • - the JES3DLOG address space on the JES3 global (in release HJS5521 and higher)
    • In JES2 -- the members of the JES2 MAS
      1. To obtain a list of all currently defined XCF groups issue the MVS command:
                    D XCF,GROUP
      2. Then, to obtain the names of all the members of the specified group, issue the MVS command:
                    D XCF,GROUP,groupname,ALL
      3. In a manner similar to the previous example, where the problem appears to be between the JES and JESXCF, if the problem appears to be between JESXCF and any other JESXCF members, dump the JESXCF address space, the other specified JESXCF members, and any associated data spaces.
  3. Ending and Restarting JESXCF

    If you determine the need to end the JESXCF address space due to a failure in the JESXCF address space or you issued an operator-initiated request to terminate JESXCF, follow these steps to restart JESXCF:

    • In a JES2 Environment
      1. Issue the following JES2 command to end JES2:
                    $P JES2,ABEND
        If JES2 does not end, then issue the following JES2 command:
                    $P JES2,ABEND,FORCE
      2. After the JES2 address space ends, issue the following MVS commands to end JESXCF:
                    FORCE JESXCF
        
                    FORCE JESXCF,ARM
      3. After the JESXCF address ends, hot start JES2. Both JES2 and JESXCF will start.
    • In a JES3 Environment

      To restart the JESXCF address space in a JES3 environment a MVS IPL is required to recover critical resources.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014