OS/360 on Hercules: Bui;ding and installing HASP

10. Building and installing HASP

10.1 Overview

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.

10.2 Allocating HASP datasets: I01ALCIN

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.

10.3 Allocating SYS1.HASPACE: I02ALCSP

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

10.4 Loading the source: I03LOAD

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.

10.5 Loading the JCL procs: I04PROCS

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.

10.6 Installing the IOS hooks: I05MACUP

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.

10.7 Installing the WTO hook: I06WTO2

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.

10.8 Installing the TSO hooks: I07HTSO

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.

10.9 Applying generation parameters: P01GEN

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.

10.10 Applying the MVT retrofit: P02RFIT

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.

10.11 Applying user modifications: P03UMODS

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.

10.12 Assembling HASP: P04Axxxx

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.

10.13 Linking the HASP SVC: P05LSVC

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.

10.14 Linking HASP: P06LHASP

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.

10.15 Bringing up HASP

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

10.16 Operating HASP

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.

10.17 Shutting down HASP

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:
you can end HASP by issuing:
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

Jay Maynard, jmaynard@conmicro.cx

Last updated 29 April 2005