Re: Procedure to verify OFFLOAD process
Angel, Let me repeat what I gave you earlier. Remember that if the job is across multiple volumes, until that job is completely purged, you cannot free the one volume. Also look for jobs that have not completed OUTPUT processing. They are not readily seen. In SDSF one of the displays I like to do is in the ST panel for all jobs. Then sort on QUE column. Then look for $MASCOM just scroll back from there. You may find some jobs that have not completed output processing and are in OUTPUT que. So you volume may not be draining for those jobs that have OUTPUT in the QUE column PREFIX=* DEST=(ALL) OWNER=* SORT=Queue/A SYSNAME= NP JOBNAME JobIDOwnerPrty Queue C Pos DB2DWLMX STC06960 DB2DWLMX 15 EXECUTION DC0PWLMX STC06991 DC0PWLMX 15 EXECUTION DC0PWLMC STC07037 DC0PWLMC 15 EXECUTION BPXASSTC07047 OMVSKERN 15 EXECUTION DC0PWLMC STC07091 DC0PWLMC 15 EXECUTION DC0PWLMC STC07154 DC0PWLMC 15 EXECUTION TKW9486C JOB01950 KW94869 1 OUTPUT C TKW9486B JOB02847 KW94869 1 OUTPUT C TMA14JOB05088 MA14359 1 OUTPUT Y T571A1F JOB00644 XX571A1 1 OUTPUT D TSAM4JOB09581 SK15491 1 OUTPUT 8 --- NOTICE THE OUTPUT in the QUEUE column This needs to be released to complete processing TDBH8Q STC06788 TDBH8Q 1 OUTPUT TSJM003 JOB01201 SM14440 1 OUTPUT D SK15491X JOB05186 ENDAUTH 1 OUTPUT K TBECKYAA JOB06031 RB09772 1 OUTPUT 8 SASRPT1A JOB04390 CB16159 1 OUTPUT Z BMCMPA01 JOB00636 CB16159 1 OUTPUT Z TROS STC04932 TROS1 OUTPUT BRETTRMF JOB05418 BS41590 1 OUTPUT Z BRETTRMF JOB05428 BS41590 1 OUTPUT Z TSAM4JOB05810 SK15491 1 OUTPUT 8 The other command that is good is $DJOBQ,SPL=(V=xx) $D JQ,SPOOL=(V=DCSPL1) $HASP890 JOB(DSP2010) 243 $HASP890 JOB(DSP2010) STATUS=(AWAITING HARDCOPY),CLASS=A, $HASP890PRIORITY=1,SYSAFF=(ANY),HOLD=(NONE), $HASP890SPOOL=(VOLUMES=(DCSPL1),TGS=1, $HASP890PERCENT=0.0008) $HASP890 JOB(DSP3110) 244 $HASP890 JOB(DSP3110) STATUS=(AWAITING HARDCOPY),CLASS=A, $HASP890PRIORITY=1,SYSAFF=(ANY),HOLD=(NONE), $HASP890SPOOL=(VOLUMES=(DCSPL1,2,3,4,5,6,7), --- Notice the multiple SPOOL volumes used $HASP890TGS=32,PERCENT=0.0274) $HASP890 JOB(DSP3115) 245 $HASP890 JOB(DSP3115) STATUS=(AWAITING HARDCOPY),CLASS=A, $HASP890PRIORITY=1,SYSAFF=(ANY),HOLD=(NONE), $HASP890SPOOL=(VOLUMES=(DCSPL1,5),TGS=2, $HASP890PERCENT=0.0017) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Angel Tamayo Sent: Wednesday, April 30, 2008 10:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Procedure to verify OFFLOAD process Hi everyone, The challenge is change spool dasd type with offload process. We have been draining volumes and replacing them as they draining, but this takes too much time and we want to speed up the process. Other condition is that I can't add new volumes to spool because there is no room to new volumes I reach the limit (255). Some details of the environment: - It is a z/OS 1.8 monoplex. I did the offload process and I have next questions: 1.- The process followed to release a dasd was: 1) Offload a specific dasd, 2) drain the volume. After that the volume was 1% of the spool and never release all the spool that it had. What do I have to do to release all the spool of a volume? 2.- Is there any command to display how many units (jobs, started tasks, sysouts, etc.) were offloaded and any command to display how many units (jobs, started tasks, sysouts, etc.) reloaded ? or any other command or procedure to compare before and after of the process in order to verify it. I did the offload-reload process but until now I don't know how can I confirm that all offloaded was reloaded. Other details of the process: - The offload dataset was defined on a dasd, but I'm planning try it over a tape. - Also I'm planning to try drainning the volume first then offload. Any help will very appreciated Thanks in advance -- 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
Re: Procedure to verify OFFLOAD process
-snip-- The challenge is change spool dasd type with offload process. We have been draining volumes and replacing them as they draining, but this takes too much time and we want to speed up the process. Other condition is that I can't add new volumes to spool because there is no room to new volumes I reach the limit (255). Some details of the environment: - It is a z/OS 1.8 monoplex. unsnip--- Your basic procedure seems reasonable and appropriate. --snip-- I did the offload process and I have next questions: 1.- The process followed to release a dasd was: 1) Offload a specific dasd, 2) drain the volume. After that the volume was 1% of the spool and never release all the spool that it had. What do I have to do to release all the spool of a volume? ---unsnip--- There's a variation of the DISPLAY command that will tell you which jobs, etc. are still occupying space on a particular spool volume. Either offload or purge those entities and the volume should drain completely. ---snip 2.- Is there any command to display how many units (jobs, started tasks, sysouts, etc.) were offloaded and any command to display how many units (jobs, started tasks, sysouts, etc.) reloaded ? or any other command or procedure to compare before and after of the process in order to verify it. I did the offload-reload process but until now I don't know how can I confirm that all offloaded was reloaded. -unsnip Each entity that is successfully offloaded from the spool will be purged and those purge messages should show in your SYSLOG. You should also see a message in the SYSLOG for each entity that is reloaded. Compare those sections of SYSLOG for your verification. --snip-- Other details of the process: - The offload dataset was defined on a dasd, but I'm planning try it over a tape. - Also I'm planning to try drainning the volume first then offload. Any help will very appreciated --unsnip The location of the offload dataset doesn't really matter very much; you might want to use tape and save the tapes until you're sure that the reload is successful. You should issue the DRAIN command first in the process, to prevent other entities being allocated on a volume while you're trying to offload. After you issue the command, use a $DSPL command to monitor the draining process, and to identify what's on that particular volume. 255 volumes of spool is an awful lot; you might want to start looking at report management/distribution software. You might also want to start purging old or unneeded listings, like most of your started task listings and TSO session listings. One other common practice is to purge anything over a certain age that is created by your various development teams. SYSLOG can be written to tape via External Writer if you have an archival or retention need. -- 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
Re: Procedure to verify OFFLOAD process
Hi Angel, You did not indicate which JES your z/OS R8 system is running, JES2 or JES3. I have used only JES2 so if you are using JES3 the information I have provided may not be applicable. First you indicated that your JES system has reached the limit of 255 Spool volumes. According to the VOLUME= parameter of the SPOOLDEF statement in the z/OS R8 JES2 Initialization and Tuning Reference manual: The maximum number of spool volumes in use by JES2 must not exceed 253 at any one time. I have never tried to exceed that limit so I don't know what would happen if you exceed it. Are you sure you haven't reached the SPOOLNUM= limit instead? If you haven't set this value, this limit would be set to the default of 32. The good news is you can increase this value without an JES2 Cold start, etc. If you have some JES Spool volumes that haven't completely drained, it sounds like you have long running tasks that haven't been re-cycled since a JES Spool volume was placed into Draining status. You can use the following JES2 command to query each JES2 Spool volume to see which Spool jobs still occupy that JES2 Spool volume: $DJOBQ,SPOOL=(VOLUMES=vv) Regarding checking the Spool Offload/Reload process, I believe JES2 issues a message for each JES2 job that was offloaded and another message when each JES2 job that was reloaded. Maybe a simple compare of the offload and reload SYSLOG messages might help. I assume you are using the DISP=DELETE on the JES Offload SYSOUT transmitter ( the OFFn.ST ) instead of DISP=KEEP. I have used DISP=KEEP before just for testing, and I have found it very difficult to verify that my OFFLOAD dataset contains what I thought it should. HTH Glenn Miller -- 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
Procedure to verify OFFLOAD process
Hi everyone, The challenge is change spool dasd type with offload process. We have been draining volumes and replacing them as they draining, but this takes too much time and we want to speed up the process. Other condition is that I can't add new volumes to spool because there is no room to new volumes I reach the limit (255). Some details of the environment: - It is a z/OS 1.8 monoplex. I did the offload process and I have next questions: 1.- The process followed to release a dasd was: 1) Offload a specific dasd, 2) drain the volume. After that the volume was 1% of the spool and never release all the spool that it had. What do I have to do to release all the spool of a volume? 2.- Is there any command to display how many units (jobs, started tasks, sysouts, etc.) were offloaded and any command to display how many units (jobs, started tasks, sysouts, etc.) reloaded ? or any other command or procedure to compare before and after of the process in order to verify it. I did the offload-reload process but until now I don't know how can I confirm that all offloaded was reloaded. Other details of the process: - The offload dataset was defined on a dasd, but I'm planning try it over a tape. - Also I'm planning to try drainning the volume first then offload. Any help will very appreciated Thanks in advance -- 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
