A frequent cause of customer problems that we see in the Support team is related to batch JOBs executing on unexpected LPARs. Even when JOBs are actually submitted on the correct, expected LPAR, a variety of factors may dictate that the JOB is routed away to another LPAR for execution.

If your problem could be related to a JOB running on an incorrect LPAR, it is always worth taking a moment to confirm that it did actually execute on the anticipated LPAR before progressing investigation.

For example, in a JES2 environment, the following kind of message may provoke an assumption that the job actually executed on the LPAR named LPA1:

                   J E S 2  J O B  L O G  --  S Y S T E M  L P A 1  --  N O D E  M A C H I N 1

However, the subsequent $HASP373 message shows that the job actually executed on LPA2:

05.29.19 J0703655  $HASP373 USER01J  STARTED - INIT 2    - CLASS A        - SYS LPA2

The system name (sysname) in the $HASP373 message actually appears after column 80 in the JOB output, so it may be necessary for some users to scroll to the right before they can actually see this information.

If this is the cause of the issue, users can specify /*ROUTE XEQ xxxx, /*JOBPARM SYSAFF=xxxx, or any other JCL appropriate for their specific environment, to force execution on the LPAR where this JOB is required to execute.