Hi, This might not be your issue, but when I was developing our Spool Offload facility (SyzSpool) that offloads output from the JES spool based on criteria like AGE, CLASS, SUBMITTING USER, DEST, FORM, SPOOL VOLUME, and a lot of other parms to sequential files that are HSM/ABR managed/archived/emailed/ftp'ed etc. I had a similar issue that I ended up having to code around. The OC1 will point to random areas in memory because it's just getting random data from the spool and it tries to "deal with it" as if it were actual data. SAPI gets a good return code from the locate on the JOB output, but the data physically in the output is "randomly" bad. Since IBM's offload is an authorized program, it can go where it pleases and mess up anything it wants (even though it really doesn't know that it's being bad).
If your system experienced a JES2 ABEND/outage or a full system outage (which also effects JES) some of your output datasets on the spool volume will have datasets with zero length records, and/or some JES2 datasets with zero lines (as opposed to no lines, which is different), there are also some issues that are caused when JES2 abends where the output datasets can become corrupted (invalid lines) and the checkpoint datasets can also be "in doubt" which is very bad and difficult for IBM's offload program to deal with. Adding your new spool volume gets you away from the problem temporarily, (until you go back to process the old one again). JES will run fine with these problems and actually contains some code to "ignore" these issues when the job is physically printed, but there are many areas where "ignore" is not the response that fits. Spool offload is one of those, that's why I had to provide code for it in our Spool offload facility. Incidentally, our code is quite inexpensive ($2,500.00) and fully supports offloading of the spool in a much more friendly manner with a great deal more options. If you are merely offloading your data to tape so that you can load it again on another JES system, then all you need to do is delete the output with the bad JES datasets components. If you want to do a lot more, I can send you a trial of our software. To find the bad JES datasets manually, if you go back to the jobs that were running when your system experienced the outage, you can select the output via SDSF or IOF and (under SDSF type a ? in the NP column) you will see that some of the datasets are 0-length or 0 lines, and when you attempt to select them, SDSF won't let you, or will let you, but only show you a small number of lines when SDSF says there should be a lot more. If you don't know what was running when you had the problem it becomes a issue of trial and error to fix this with only IBM JSF, you run the offload until you get the error, delete the JOB that JSF was looking at when the OC1 happens, then start it up again and wait for the next error. I know this mode sucks, but waiting for IBM to code the fix into their code could take a while. Brian Westerman Syzygy Incorporated ---------------------------------------------------------------------- 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
