---------------------<snip>---------------------
We upgraded from z/OS 1.6 to 1.8 over the weekend. We have run into one
really bad problem. The z/OS 1.6 JES2 was running in R4 mode. We have a
product which sends output to a specialized printer. This product does
not support the "z" level of the checkpoint. We are adverse to upgrading
the product to the newest release due to the cost. What I am thinking
might work would be to run a secondary JES on z/OS 1.8. This JES2 would
be the 1.6 release with its own SPOOL, in R4 format. We would connect
the 1.8 JES2 to the 1.6 via NJE. We would then point the product to the
alternate, 1.6, JES (JESA) SPOOL and start it SUB=JESA. I think this
would work. The print operator would then change the DEST of the print
from LOCAL to the JESA node to transmit the SPOOL to JESA. Hopefully
this will work.
The question I have is how to get SDSF to access the JESA system. I
think that I'll need to use the 1.6 version of SDSF due to the JES2
dependancies in the SDSF code. True? I am just not figuring out how to
do this. The closest that I've come up with is a second TSO proc which
is STEPLIB'ed to the old SDSF code.
------------------------------<unsnip>-------------------------
John, what you propose might be a usable solution; we tried something
similar years ago at Clearing. Probably the biggest problems you'll
encounter will be human error on the part of the print operator who's
shuffling things back and forth between spools. IMHO, you'll be better
off in the long run to bite the bullet and upgrade your specialized
print processor. If you threaten the vendor with discontinuation of the
product, maybe they'll be a little more friendly with their upgrade pricing.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
