SPXTAPE - the Next Generation!
SPXTAPE - the Next Generation!
Have you always wanted to back up the spool files on your
system? Did you have to do it but dreaded the thoughts of
using the SPTAPE command? Never fear, the next generation
of VM spool backup has arrived! It is called SPXTAPE and
became available with VM/ESA Release 1.2.2.
With a first glance at the documentation for the new
SPXTAPE command you might wonder "What's new?" The command
syntax appears to be very much like that of SPTAPE.
On further reading, you'll find that there is a world of
difference between the two. Many outstanding SPTAPE
requirements have been satisfied by SPXTAPE. Many improvements
have been made in the areas of performance, tape usage, and
usability.
The new SPXTAPE CP command
will be discussed in this article.
Also the answer to the question that probably popped
into your mind when you first saw the title of this
article, "What does the 'X' stand for in SPXTAPE?"
Read on if you've ever considered backing up your
spool files, if you currently back up your spool files
and want a better way, or if you simply are curious
about the 'X' in SPXTAPE.
If you've been dumping large numbers of spool files
to tape using SPTAPE, you know that it can take quite some
time. SPTAPE takes one spool file at a time and processes
it serially. That is, a data page is read in from the
spool DASD first. After that read is completed, the data
page is written to the tape. After that I/O is complete,
another data page is read from DASD. And so on, until all
of the data pages for all
of the selected files have been dumped. This can take hours
if you are dumping large numbers of files.
By contrast, SPXTAPE uses a series of asynchronous tasks
to overlap the DASD I/O. During an SPXTAPE DUMP operation,
tasks are created to read ahead; i.e. many data
pages of a file are read in from DASD before the tape tasks
are ready to write them out to the tape volume.
In this way, records are prepared in advance and the next
record to be written is generally ready to go as soon
as the tape task is ready for it. This keeps the
tape as busy as possible, thus writing the files to tape
as quickly as possible. A similar technique is used
by SPXTAPE to improve the performance of SPXTAPE LOAD
over that of SPTAPE LOAD.
Requesting many spool DASD reads or writes at one time
leads to other advantages. Since SPXTAPE (and spool
code in general) uses CP's paging system to read and write
spool data pages, advantage can be taken of the paging system's
built in performance algorithms.
These algorithms sort the read or write
requests in a way that minimizes DASD head movement and
generally leads to the best possible performance.
The result of these improvements is that SPXTAPE is
much faster than SPTAPE. In performance runs designed to
simulate the spool file size distribution observed on a
local CMS-intensive production system, the VM performance
people obtained the following results.
The system contained 34,000 spool files on four 3390
spool volumes. The reader files ranged in size from
100 to 600,000 80-byte records and occupied, on average,
10.4 pages of spool DASD. SPXTAPE was 9.0 to 10.8 times
faster than SPTAPE for dumping these spool files.
SPTAPE took 3 hours and 24 minutes to dump these files but
SPXTAPE took approximately 20 minutes to dump the same files.
SPXTAPE loaded these files 1.9 times faster than SPTAPE;
1 hour 8 minutes versus 2 hours 10 minutes.
Your exact results will
depend on many factors such as number of spool volumes,
number of tape drives used, other work running on the
system, spool data page distribution, etc..
However, it is clear that SPXTAPE is much faster than
SPTAPE.
For more detailed information on the performance
study done, refer to
VM/ESA Release 2.2 Performance Report, GC24-5673-01.
The format of the records written to tape by SPXTAPE
is completely different from the format of the records
written by SPTAPE. The disadvantage is that SPTAPE
and SPXTAPE cannot be used to read tapes dumped by each other.
The advantage is that there were no
compatibility restrictions on the design, so the tape
format was designed for maximum advantage.
SPXTAPE was designed to write records to the tape in
blocks of slightly more than 32K bytes of data.
Any combination of file description
information (SPFBKs), data pages (SPDBKs), and XAB data
can be written into a block of approximately 32K bytes
in length. A header is used to describe exactly what
data exists in each record.
Using this format significantly increases the number
of spool files and the amount of data that will fit on a
single tape volume. An additional advantage is that
less I/O operations are required to the tape device to
actually dump or load the data to or from the tape.
In the performance study described in the previous section,
the 34,000 files required 11 tape volumes when dumped with SPTAPE.
The same files dumped with SPXTAPE required 7 tape volumes.
There are two major differences in the way SPXTAPE and SPTAPE handle
tape drives.
- With SPXTAPE, more than one tape drive may be used for the
same SPXTAPE operation, so a range of tape drives may be specified
on each SPXTAPE command.
SPTAPE only uses one tape drive per operation.
- Tape drives to be used by SPXTAPE are attached to the virtual
machine that issues the SPXTAPE command. SPTAPE does not
use tape drives that are attached to a virtual machine;
a drive specified on an SPTAPE command must be "FREE".
The SPXTAPE command uses virtual addresses
(either a single address or a range of addresses is accepted)
for its tape drives, while SPTAPE uses
a single real address for its tape drive.
Since more than one tape drive can be used for one
SPXTAPE operation, enough tape drives can be used so that the
maximum capacity of the spool DASD volumes can be utilized.
Clearly the number of tape drives to use will be installation
dependent but a good general guideline is to use
one tape drive for each 4-6 spool volumes with a minimum of
two if you expect the data to fill more than one volume.
Using at least two drives allows SPXTAPE operations to
continue on other drives while rewind is occurring and
new volumes are being mounted.
Using at least two tape drives also allows use of the
capability for dynamically adding or removing drives from
the running SPXTAPE operation. If more than one drive is
being used to dump files and one of them fails, the
operation will continue on the drive that is still working.
The failing drive can actually be removed from the operation
and another can be added to take its place. All of this
can occur while the operation continues on the original
drive that didn't fail. By contrast, if the drive that
SPTAPE was dumping to fails, the operation stops and must
be started all over again.
Below is an example of how this could be done.
SPXTAPE DUMP 182-183 RDR ALL REWIND <==> starts the operation
=============> tape drive 183 fails <=======================
SPXTAPE DUMP 182-184 <========> includes 184 in the operation
SPXTAPE CANCEL 183 <==========> removes 183 from the operation
Notice that the command which started the operation includes
the file selection criteria but when tape drives are dynamically
added to or removed from the operation, the file selection
criteria is not included on the command.
Also, notice that the original virtual address range
is included in the virtual address range of the
command to
add the new drive into the dump operation
(i.e. the original virtual address range is "expanded"
to include the new tape drive).
As mentioned earlier, the syntax diagram for SPXTAPE
looks a lot like the syntax diagram for SPTAPE.
However, there are differences.
A range of virtual tape drives is specified as
opposed to a single real address and
there is much more flexibility in the area of
file selection criteria.
There are additional spool queue keywords. For example,
SPXTAPE DUMP 182 STD ALL
will dump all RDR, PRT, and PUN files. With SPTAPE,
each of those three sets of files had to be dumped
separately. The following command will dump all
of the system data files.
SPXTAPE DUMP 182 SDF ALL
And this command
SPXTAPE DUMP 182 SPOOL ALL
will dump all RDR, PRT, PUN, and SDF files.
The new APPEND option adds even more flexibility
to file selection. This option can be used to
tie several SPXTAPE commands together so that all of
the files selected by all of the commands can be dumped
or loaded or scanned as if by a single command.
For example, the following command only loads files
that are on the reader queue
and
have a FORM set to "std"
and
have a FILE TYPE of "assemble".
SPXTAPE LOAD 181 RDR FORM std FT assemble
However, the following set of appended commands (or "logical
command") dumps reader files that have FORM set to "std"
or
have a FILE TYPE of "assemble". Note that files which
match both of these criteria may be dumped twice.
SPXTAPE DUMP 181 RDR FORM std APPEND
SPXTAPE DUMP 181 RDR FT assemble REWIND
Another example is a way of dumping all printer files
except those that are Class A. The following set of appended
commands accomplishes this.
SPXTAPE DUMP 181 PRT CLASS bcdefghi APPEND
SPXTAPE DUMP 181 PRT CLASS jklmnopq APPEND
SPXTAPE DUMP 181 PRT CLASS rstuvwxy APPEND
SPXTAPE DUMP 181 PRT CLASS z1234567 APPEND
SPXTAPE DUMP 181 PRT CLASS 890 REWIND
For more details on the syntax and use of SPXTAPE, see the
VM/ESA Release 2.2 CP Command and Utility
Reference, SC24-5519-04.
The error recovery approach has been totally changed
from that of SPTAPE. Rather than stop the whole DUMP or LOAD
operation when an error is encountered, SPXTAPE is designed
to continue dumping or loading as much data as possible.
All selected files will be dumped as long as their
control information is readable. If any XAB data is not
readable, the XAB data is omitted. If any of a file's
data is not readable, only the unreadable data is not dumped.
The part of the file that is readable will be dumped.
Similarly, if SPXTAPE LOAD has trouble reading a portion of
the tape, it will keep trying and will continue loading if a
readable record in SPXTAPE format is found after the error.
Even if the reading of one tape fails, the operation will
continue on any other drives started with this operation.
SPXTAPE reduces console output by logging each file rather
than writing a message to the screen for each one. Each
SPXTAPE operation creates at least two log files. One, called
the Command Summary Log (CSL), contains progress information,
error messages (many of which are also displayed on the screen),
and summary data when the command ends. There is one CSL
created for each "logical SPXTAPE command".
In addition to the CSL, a Volume Log (VL) is created for
each tape volume that is written to or read from. The main
information in the volume log(s) is the list of files that
were dumped to or read from the tape volume and any error
indications for each of those files. The list of files
dumped, loaded, or scanned contains much of the same information
about each file that is returned from the
QUERY RDR/PRT/PUN command.
Since each file is no longer displayed as it is dumped,
a progress report (heart beat) is displayed periodically so
that the command issuer knows SPXTAPE is progressing.
This progress report is displayed approximately every 15 seconds
and has the following information:
SPXTAPE DUMPing 182: 35 FILES, 1,019 SPOOL PAGES 23% COMPLETE
As a result of customer feedback a
PROGress_interval
option has been developed and is available as a
local CP modification.
It may be obtained from the VM Download Library on
Your Connection to VM
(part of the S/390 Developer's Association).
This modification allows tailoring of the progress report
time interval with a command option.
With the modification, the interval between
progress reports can be set anywhere from 1 second to
9999 minutes or it can be turned off by setting it to 0.
The default interval remains 15 seconds with the modification applied.
Note: The PROGress_interval option was added to SPXTAPE in
the base of the VM/ESA 2.1.0 and later releases.
And that is not all! The following goodies have also
been included in SPXTAPE.
- Standard Tape Label Toleration - SPXTAPE will not write
over an existing header label group of a standard tape label.
- Huge file support - SPXTAPE allows you to dump a file that
will not fit on one tape.
- Files that are split across more than one tape
are correctly put back together even when you load the
tapes in a different order than they were dumped, as long
as you load all of the tapes with the same SPXTAPE LOAD
command.
- NODUP option - helps you avoid the duplicate NSS problem.
When loading files with SPXTAPE, duplicates
of files that already exist on the system
will not be created if you use the NODUP option.
- Class G users - can use SPXTAPE to dump their own spool files.
- QUERY VIRTUAL TAPE - support added as a result of customer
feedback. This command now reports SPXTAPE status on the
drive that is being queried if SPXTAPE is running there.
It reports whether SPXTAPE is active, waiting for another tape
to be mounted, or waiting for another command to be appended.
At first glance SPXTAPE may not appear
to be much different than SPTAPE, but when you look
a little deeper, there is a world of difference.
SPXTAPE improves on SPTAPE in the areas of performance,
tape usage, and usability.
Spool back up with SPXTAPE will be much faster and
easier than it ever was in the past.
And now the answer to the question you've been
waiting for, "What does the 'X' in SPXTAPE stand for?"
To be honest with you, it doesn't have a real meaning.
The SPXTAPE name came about because SPXTAPE is the
XA-spool-format version of the SPTAPE command. But
we in VM development hope that after you use SPXTAPE,
you will believe it stands for X-cellent!
|
