Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Please help with JES2 EXIT 40
38 views
Skip to first unread message
Joe D'Alessandro
Sep 17, 2013, 2:00:29 PM9/17/13
to
Hello:
I have written an exit 40 to reroute SYSOUT to another spool. This was any SYSOUT with DEST=Unnnn or =Rnnn in the local spool, so that it went to those same destinations in another spool (in fact, for VPS purposes). The exit will get control during "output processing", such as when SYSOUT is created by file I/O thru JCL or dynamic allocation, or SYSOUT which arrives via NJE. From my observation and reading, exit 40 does not get control when SYSOUT is changed via JES2 commands.
What I found was this: PDBDRMT (a binary value) contains an RJE number or a Unnnn destination depending on PDBDNODE:
If PDBDNODE not = Zero and not = "OWNNODE", then it is already going to another node, so I was ignoring this since it was already going away.
If PDBDNODE = OWNNODE, then PDBDRMT contains an RJE number.
If PDBDNODE = Zero, then PDBDRMT contains the Unnnn destination (in this case, PDBDNODE = zero means "local").
To move SYSOUT with DEST=Unnnn to another node, the exit took the data from PDBDRMT and converted this to EBCDIC and created an EBCDIC "Unnnn" character string which was then placed into PDBUSER. Then it zeroed out PDBDRMT. Then it set PDBDNODE to the new node number and returned to JES2. $GETMAIN and $FREEMAIN can be used to obtain a work area so that the exit is JES re-entrant. There may be roon in the PCE for this but that was not my choice.
To move SYSOUT with DEST=Rnnn to another node, the PDBDRMT was left untouched, and the PDBDNODE was set to the new node, and then the exit returned to JES2.
And here is one caveat: if there is more than one ST on the sending side (and therefore more than one SR on the receiving side), the SYSOUT files may land in the target node in a different order due to the independent dispatching of the JES2 PCEs on the receiving side. This may matter to some applications.
regards, Joe D'Alessandro
I have written an exit 40 to reroute SYSOUT to another spool. This was any SYSOUT with DEST=Unnnn or =Rnnn in the local spool, so that it went to those same destinations in another spool (in fact, for VPS purposes). The exit will get control during "output processing", such as when SYSOUT is created by file I/O thru JCL or dynamic allocation, or SYSOUT which arrives via NJE. From my observation and reading, exit 40 does not get control when SYSOUT is changed via JES2 commands.
What I found was this: PDBDRMT (a binary value) contains an RJE number or a Unnnn destination depending on PDBDNODE:
If PDBDNODE not = Zero and not = "OWNNODE", then it is already going to another node, so I was ignoring this since it was already going away.
If PDBDNODE = OWNNODE, then PDBDRMT contains an RJE number.
If PDBDNODE = Zero, then PDBDRMT contains the Unnnn destination (in this case, PDBDNODE = zero means "local").
To move SYSOUT with DEST=Unnnn to another node, the exit took the data from PDBDRMT and converted this to EBCDIC and created an EBCDIC "Unnnn" character string which was then placed into PDBUSER. Then it zeroed out PDBDRMT. Then it set PDBDNODE to the new node number and returned to JES2. $GETMAIN and $FREEMAIN can be used to obtain a work area so that the exit is JES re-entrant. There may be roon in the PCE for this but that was not my choice.
To move SYSOUT with DEST=Rnnn to another node, the PDBDRMT was left untouched, and the PDBDNODE was set to the new node, and then the exit returned to JES2.
And here is one caveat: if there is more than one ST on the sending side (and therefore more than one SR on the receiving side), the SYSOUT files may land in the target node in a different order due to the independent dispatching of the JES2 PCEs on the receiving side. This may matter to some applications.
regards, Joe D'Alessandro
Horn, Skip
Sep 17, 2013, 4:12:36 PM9/17/13
to
Why not just change the DEST parameter in PARMLIB to redirect the DESTINATION?
Office: 585 - 275 - 9134 | Fax 585 - 756 - 4460 | Cell 585 - 734 - 1869
Email:�SKIP...@ROCHESTER.EDU
Office: 585 - 275 - 9134 | Fax 585 - 756 - 4460 | Cell 585 - 734 - 1869
Email:�SKIP...@ROCHESTER.EDU
Joe D'Alessandro
Sep 17, 2013, 4:55:27 PM9/17/13
to
Hello,
In order to redefine a DEST "Unnnn" as other than a LOCAL destination, I believe that the DESTDEF statement must be coded with other than the default values. I considered that alternative, since everyone wants to avoid more exits, but after I reviewed DESTDEF and saw the restrictions (the single member WARM start for LOCALNUM changes), the JES2 exit 40 actually seemed simpler to employ, and if I needed to exclude certain Unnnn values within a range, a table in the exit would not be too difficult to use, although I decided not to do that. The exit can be disabled by command, and refreshed by command.
In most cases, changing DESTDEF and using $ADD DESTID to redefine Unnnn would be easier than a JES2 exit. For me, the JES2 exit was not too big a deal, and provided more flexibility than DESTDEF. I never really tested DESTDEF so I cannot recommend for or against it, but without changing DESTDEF's defaults, $ADD DESTID cannot be used to change Unnnn destinations.
regards, Joe D'Alessandro
In order to redefine a DEST "Unnnn" as other than a LOCAL destination, I believe that the DESTDEF statement must be coded with other than the default values. I considered that alternative, since everyone wants to avoid more exits, but after I reviewed DESTDEF and saw the restrictions (the single member WARM start for LOCALNUM changes), the JES2 exit 40 actually seemed simpler to employ, and if I needed to exclude certain Unnnn values within a range, a table in the exit would not be too difficult to use, although I decided not to do that. The exit can be disabled by command, and refreshed by command.
In most cases, changing DESTDEF and using $ADD DESTID to redefine Unnnn would be easier than a JES2 exit. For me, the JES2 exit was not too big a deal, and provided more flexibility than DESTDEF. I never really tested DESTDEF so I cannot recommend for or against it, but without changing DESTDEF's defaults, $ADD DESTID cannot be used to change Unnnn destinations.
regards, Joe D'Alessandro
Tom Wasik
Sep 17, 2013, 5:09:25 PM9/17/13
to
Changing the node associated with a route code is not the most trivial thing. To see how JES2 does it, look in HASCSIRQ at the service routine USRNEWND. It takes as input a new node (in binary) and the existing route code and user destination. It then alters the node to be the one passed and changes everything else appropriately. The nice thing is that this service can be called from an exit. There is a sample call in HASPCOMM in the routine COFUPDRT. It should do everything you need.
Tom Wasik
JES2 Development
Tom Wasik
JES2 Development
0 new messages