Jump to content

Houston Automatic Spooling Priority

From Alfawiki
Houston Automatic Spooling Priority (HASP)
Company typeSoftware system
IndustryComputer software, Operating systems
Founded1960s
FounderTom Simpson, Bob Crabtree
Headquarters
Houston
,
United States
ProductsJob scheduling, spooling, printing, punching, remote job entry for IBM OS/360 and descendants

The Houston Automatic Spooling Priority system, commonly referred to as HASP, serves as an enhancement to the IBM OS/360 operating system and its descendants, delivering improved capabilities for managing jobs, handling data, coordinating tasks, and supporting remote job entry operations.

History

Within OS/360, spooling was facilitated by components known as reader/interpreters and output writers. Each reader/interpreter managed a single input job stream from a device, whereas each output writer was responsible for controlling one printer or punch. The spooled information was stored in OS temporary datasets, which were governed by the standard OS mechanisms. Every reader/interpreter and output writer functioned as an independent OS task within its own partition or region. Systems equipped with multiple readers, printers, and punches could operate a large number of these spooling tasks concurrently.

HASP originated from contractors at the IBM Federal Systems Division working at the Lyndon B. Johnson Space Center in Houston, under the leadership of Tom Simpson and Bob Crabtree. It was designed to run on mainframes to oversee scheduling, control job flow, manage spooling, printing, and punching activities. Although HASP did not support the IBM System/360 Operating System Remote Job Entry (360S-RC-536) standard, it offered equivalent functionality.

The shared spool feature was introduced in HASP II V3 by Roger Fajman, Bill Jones, and Jim Oberthaler from NIH, allowing multiple HASP systems to access a unified spool and checkpoint. This advancement enabled workload distribution across several mainframes. Subsequently, HASP II V4 included enhancements to this shared spool capability developed by Don Greb and Dave Miko at Mellon Bank. Don Greb later incorporated these improvements into JES2, IBM’s official successor to HASP within the MVS environment. More than 350 copies of these so-called "Mellon Mods" were disseminated worldwide through SHARE, laying the groundwork for JES2’s Multi Access Spool feature.

While HASP was sometimes referred to by different names informally, IBM itself did not adopt any alternate titles officially. HASP was part of the IBM Type-III Library and competed directly with ASP, which evolved into JES3.

With the advent of MVS, HASP transitioned into JES2, one of the two main Job Entry Subsystems. Despite the renaming, JES2’s source code still contains HASP-related identifiers, and its system messages continue to begin with "$HASP".

A customized version of HASP also provided batch spooling and remote job entry services for the Michigan Terminal System from the late 1960s through the 1980s.

Program structure

HASP was designed to bypass most operating system services by utilizing highly optimized code for performance. It functioned as a single operating system task and internally employed cooperative multitasking to manage processors responsible for handling card readers, printers, punches, spool files, operator interactions, and multiple remote job entry channels.

Developed entirely in System/360 assembly language, a standard HASP installation typically demanded approximately 86KB of memory, which could be allocated as virtual memory on OS/VS platforms.

Pre-JES Job Entry Control Language

Many elements that later appeared in the JES2 JECL were originally introduced in HASP:

  • The /*MESSAGE command delivered messages to the console operator.
  • /*SETUP alerted the operator about necessary resources such as tapes or disks while placing the job into a HOLD queue.
  • /*ROUTE PRINT and /*ROUTE PUNCH allowed versatile output routing options.

Remote job entry

Initially, HASP II supported IBM Synchronous Transmit-Receive (STR) batch terminals but eventually transitioned exclusively to the Binary Synchronous Communications (BSC) protocol. It accommodated IBM devices including the 2770, 2780, 3770, and 3780. Furthermore, HASP II facilitated multi-leaving communications with intelligent workstations like the IBM 1130, IBM System/3, and System/360 Model 20. Multi-leaving describes a fully synchronous, pseudo-simultaneous, bi-directional transmission method that allows multiple data streams to be sent over binary-synchronous communication lines.

Various third-party providers created simulators for the 2770/2780/3780 terminals as well as multi-leaving implementations compatible with HASP and ASP. Although some of these products were marketed as HASP emulators, they functioned primarily as terminals connecting to HASP rather than duplicating its internal operations.

Operator Commands

The RJE console operator had access to a limited collection of HASP Console Operator Commands, which served as forerunners to the JES2 Job Entry Control Language (JES2 JECL).

Command operands were confined to the remote location, so commands such as DJ1-999 would only display jobs pending at that specific site.

Important HASP RJE Console commands could be entered either as single-letter abbreviations or spelled out, and included:

Abbreviation Full Command Operand(s) Example
E restart device_name E rm1.rdr
Z stop device_name Z rm1.pr1
D display (J,I,& others) e.g.
DJ display job Job Number (or range) DJ345 or DJ1-999
DA display active (active jobs) DA
DI display initiators (initiator letters) DI
C cancel (Job or device_name) e.g.
CJ cancel job Job Number CJ678
C cancel device_name C rm1.rdr

For instance, issuing "C rm1.rdr" would terminate the current card deck being processed by that reader. This was particularly useful when a card jam occurred, allowing other jobs to continue without delay.

Job log

The HASP job logs provided an overview of resource consumption for each job, including details such as:

  • Job start timestamp
  • Job end timestamp
  • Duration of execution
  • Amount of memory consumed
  • Spool space utilized
  • Number of cards read
  • Number of cards punched
  • Total lines printed

See also