---------------------<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

Reply via email to