HASP is to MVT what JES2 is to later operating systems: a job entry subsystem. It manages SYSIN and SYSOUT, keeps a queue of jobs ready to begin execution, and starts them according to a priority scheme. It makes running MVT much simpler and more efficient. It was quite rare to find an MVT system that did not include HASP.
Unlike JES2, however, HASP is an add-on, written and maintained
separately from the main OS. As such, there are hooks that must be added
to MVT in order to give HASP control when needed. Those hooks were added
before stage 1 was run, by the HASPHOOK job. HASP itself must
still be generated, however.
HASP generation is done in a somewhat different manner than MVT. HASP
parameters are applied to a source file by HASPGEN, a program
developed for the task. HASP is then assembled, and an SVC linked into the
MVT nucleus. Before HASP itself is linked, however, its overlay structure
must be generated; this is done by another HASP utility, HASPOBLD. Once the
linkedit is complete, HASP may be started; an IPL is necessary if the SVC
has just been installed.
The version of HASP that will be installed is HASP 4.0.
This version was shipped with the first virtual storage MVT successor,
OS/VS2 SVS. As such, it was written to be used with that system. When
it was released, several enterprising folks developed changes to make it
work with MVT; these changes are known as the HASP MVT retrofit mods. One
consequence of this is that the XF assembler, IFOX00, must be
used to build HASP. Fortunately, IFOX00, which was shipped
with SVS, will run unchanged on MVT, and it's even a bit faster and less
cantankerous than IEUASM, the MVT F-level assembler.
The jobs in this section were originally developed by Kevin Leonard. I have retained his job names. There are minor differences fron the JCL he supplies on his HASP web page; I'll mention those changes where needed.
Some of these tasks only need to be performed once to load HASP
onto disk. Some will need to be run whenever changes to the HASP
parameters are desired. The jobs with names beginning with
I are one-time-only; the ones beginning with
P are rerun whenever HASP is to be changed.
This job allocates the datasets that HASP will be
stored in. There are separate source datasets for the HASP source as
supplied by IBM, IBM-supplied HASP APARs, the MVT retrofit
modifications, and the final, modified system. There are also datasets
to store the assembled object decks, the overlay library used by HASPOBLD,
HASP utility programs such as HASPGEN, and the XF assembler. It is
in haspjcl/i01alcin.jcl. One change has been made from Kevin
Leonard's source: the name of the volume allocated was changed from PERM01
to HERC01.
SYS1.HASPACE:
I02ALCSPHASP uses a dataset named SYS1.HASPACE to store its work
areas, as well as SYSIN and SYSOUT data. Since disk space is cheap
on Hercules, we will use a full 3330 volume for this dataset. This job
allocated that dataset as 403 cylinders on the pack SPOOL1, which has gone
unused until this point. It lives in haspjcl/i02alcsp.jcl.
This job loads the HASP source, IBM HASP APARs, the MVT retrofit mods,
the pre-built HASP utilities, and the XF assembler from tape to the datasets
allocated on HERC01 by the first job. It will ask for two tapes: the first
step will call for a tape named HASP4, and the second will call
for a tape named H4SUPB. These tapes may be found in the files
tapes/hasp4.aws and tapes/h4supb.aws,
respectively; they are mounted on the 3420 tape drive in the same way as
card decks are mounted on the card reader, in the Hercules control
panel. The job itself is in haspjcl/i03load.jcl.
Several JCL procs are needed during HASP generation and execution. This
job loads those to SYS1.PROCLIB. It can be found
in haspjcl/i04procs.jcl.
As mentioned earlier, two hooks are needed within the MVT I/O
supervisor to give control to HASP when necessary. If the system was
generated according to the steps listed earlier in this document, this job
is not necessary, as those hooks have already been added to the system. If
not, then this job must be run and the modified modules rebuilt,
as mentioned in the JCL. It's in haspjcl/i05macup.jcl.
One more hook is used by HASP, although it is not strictly required.
This hook captures log messages issued by a running job so they can be
printed in the job log. Unlike the previous job, this step must
be performed after MVT is built, since the module is assembled from scratch.
The JCL is in haspjcl/i06wto2.jcl.
The TSO CANCEL and STATUS commands need to know about HASP, too. This job
installs hooks to perform the communication. This one also needs to be done
after the system is built. The JCL is in
haspjcl/i06wto2.jcl.
Unlike later versions, HASP parameters are set by changing the source
code and reassembling the program. This first job applies the parameter
changes that specify how HASP is to run, as well as the IBM APARs. A work
dataset, SYS1.HASPSRC, is created to hold the modified source
code so that the original IBM source is kept unmodified. HASPGEN
is then run to apply the parameter changes to the freshly copied source.
The JCL is in haspjcl/p01gen.jcl.
The system utility IEBUPDTE is used to apply
this large collection of changes to the work copy of the HASP source. This
job should not be modified; if user changes are desired, they should be
placed in the following job instead. This job is
in haspjcl/p02rfit.jcl.
HASP was one of the most modified programs in any MVT shop, and
this one is no different. At present, only one mod is in the file, but
that will almost certainly change in the future. As with the previous job,
IEBUPDTE is used to modify the working copy. The JCL is
in haspjcl/p03umods.jcl.
This is a series of 16 jobs. The first deletes and recreates the
SYS1.HASPOBJ dataset, used to store the object decks for later
use. The remaining 15 each assemble one HASP module. The tenth job
also links the HASPOBLD program for use later. All 16
jobs are contained in the file haspjcl/p04asm.jcl.
This job links the just-assembled HASP SVC into the MVT nucleus. Unlike
the other P-series jobs, this one must only be rerun if the HASP SVC
source code is changed or if the HASP SVC number is changed. Other
HASP gen parameters do not affect this program. An IPL is required to make
the newly-linked SVC active. The JCL is in
haspjcl/p05lsvc.jcl.
Like other HASP functions, and unlike other MVT programs, HASP does
program overlays its own way. This job contains two steps, one
to build the overlay structure with the HASP utility HASPOBLD,
and the other to use the normal MVT link editor to link the main
HASP module. It's in haspjcl/p06lhasp.jcl.
Before HASP is started for the first time, the system must be IPLed to make the HASP SVC effective. If not, a 0F2 system ABEND will be issued when HASP is started.
One difference in operation between HASP and the standard MVT
RDR task will be apparent: an end-of-file on the card reader
no longer causes the reader task to end. Instead, HASP uses that to signal
the end of the job being read. The intervention required signal that the
native reader task wants is ignored by HASP. When you bring the system
down for that first IPL, it is a good time to change the parameter
of the emulated card reader at 000C from intrq to
eof. If you do not, you can specify eof when you
mount the first deck on the card reader, as a parameter, and it will
remain in effect for subsequent jobs.
Once the system is IPLed, simply start HASP:
s hasp
This will produce a request for HASP startup parameters:
$ hh.mm.ss SPECIFY HASP OPTIONS -- HASP-II VERSION 4.009762
The first time you start HASP, reply, as you would for JES2:
r nn,format,noreq
This will format the SYS1.HASPACE dataset and make it ready
for use. On subsequent starts, you can reply:
r nn,noreq
and HASP will warm start. In either case, HASP will start reader, printer,
and punch tasks, as specified in the parameters, so you will no longer
need to start RDR, WTR, and INITs
manually.
If you know how to operate JES2, you will have no trouble operating HASP. Nearly everything you're familiar with will work, although many functions have fewer options and less capability than later versions. If you're not familiar with JES2 or HASP, I would suggest looking at commonly available JES2 operations documentation for a good start.
To shut down HASP, all devices and initiators must be inactive. The
$DA command will show you what's active and what's not.
An active reader will becomeinactive once it reaches the end of a job; you
can feed it the file jcl/eoj.jcl for a quick end.
Once everything's stopped, and you receive the message:
$ hh.mm.ss ALL AVAILABLE FUNCTIONS COMPLETE
you can end HASP by issuing:
$phasp
HASP will terminate, leaving the system idle. You can now issue the
z eod command to shut down MVT, and exit Hercules.
Up to table of contents Previous: IPLing MVT Next: Building and installing TSO/TCAM
Last updated 29 April 2005