JES3 relies on sysplex services to perform the message routing functions that prior JES3 versions performed internally. Currently, all JES3 messages originate from the subsystem interface. Because of this, JES3 sites must use the BROWSEMESSAGES parameter to determine which copies of the message go into the OPSLOG. This section provides some background information about the JES3 environment and describes the values you can specify on the BROWSEMESSAGES parameter.
Typically, when a JES3 complex has local processors in addition to a global processor, CA OPS/MVS is active on all processors in the complex. Active Multi-System Facility (MSF) sessions exist between all of the copies of CA OPS/MVS. In this setup, each copy of CA OPS/MVS maintains an OPSLOG Browse data area, but the set of messages accessed by OPSLOG Browse running on a local processor differs from the set of messages accessed by OPSLOG Browse running on a global processor.
The following describes these differences:
OPSLOG can access only those z/OS messages that originated on that local processor. It does not have access to JES3 messages (even those pertaining to work running on a local processor).
Current versions of JES3 allocate extended consoles on each JES3 local processor with an MSCOPE of the JES3 global processor. This causes sysplex services to transport all JES3 messages from the local processors to the global processor. From a historical perspective, this is similar in functionality to the services formerly provided by the IATUX31 exit.
| Copyright © 2012 CA. All rights reserved. | Tell Technical Publications how we can improve this information |