HASP_II_Manual_Jun72 HASP II Manual Jun72
HASP_II_Manual_Jun72 manual pdf -FilePursuit
HASP_II_Manual_Jun72 HASP_II_Manual_Jun72
User Manual: HASP_II_Manual_Jun72
Open the PDF directly: View PDF 
.
Page Count: 1274
| Download | |
| Open PDF In Browser | View PDF |
J> rog ram, Library
Japan, Ltd.
Systems Engineering Dept.
14,1 Choma Nagata-cho
Chiyoda-ku
Tokyo, Japan
Canadian Program Library
IBM Canada Ltd.
Department 960
5 Yorkland Boulevard
Willowdale, Ontario
Canada
European Program Library
IBM France
23, Allee-Maillasson
F.92-Bouiogne-Billancourt
France
Societe Anonyme Au Capital de
620.256.000 F-R.C.
(Seine 55B-11 846)
Program Information Dept.
IBM Corporation
40 Saw Mill River Road
Hawthorne, New York 10532
United States
South American
Program Library
IBM do Brasil, Ltda.
Avenida Presidente
Vargas 642, 4 Andar
Caixa Postal 1830-ZC-00
Rio de Janeiro, Brazil
South Pacific
Program Library
IBM Austraiia, Ltd.
Box 3318 G.P.D.
Sydney, N.S.W.
Australia
June 26, 1972
Memorandum to:
Users of the HASP II System (360D-05.1.0l4)
Subject:
Transmittal of Version 3, Modification Levell
of 360D-05.1.014
This letter transmits Version 3, Modification Level 1 of the
HASP II System, 360D-OS.1.014.
The program materials needed to update this program to Version 3,
Modification Level 1 are enclosed.
The Basic materials distributed with this letter are:
1.
An update to HASP II System Manual (replacement pages)
2.
A replacement Memorandum to Users for HASP II System
Manual
3.
A complete replacement of the Basic machine readable
material on one Distribution Tape Reel (DTR) recorded
at 9-track 800 or 1600 bpi, or one 7-track 800 cpi
(Data Conversion Feature required)
If you are a user of the Optional program material, it consists of:
1.
A complete replacement of' the Optional machine readable
material consisting of 138 - 96. column cards as a "starter
system" for a remote System!3.
This release of HASP corrects virtually every known problem in
Version 3, Modification Level 0 of HASP. This sytem includes all
PTFs applicable to HASP Version 3.0 through DPA5427. Following is
a list of the more significant maintenance items.
The restrictions prohibiting any extended use of the 3211
Forms Control Buffer have been removed.
Rotational Position Sensing for 3330 and 2305 devices is
now a HASPGEN option.
3M399A
Previously announced support for the 3505 Card Reader and
the 3525 Card Punch is included.
The restriction prohibiting operator control of HASP job
flow based on OS jobnames has been removed.
Multi-tasking jobs are no longer excluded from the execution
dynamic priority group.
The restriction prohibiting restart of the HASP execution
phase of a job has been removed.
The operator is no longer prohibited from changing a printer's
FCB or DCS when the printer is stopped for forms mounting.
For as controlled console support, the operator's replies to
WTORs are no longer omitted from the HASP System Log.
Optionally, the user can now define names other than SPOOLn
for HASP spooling volumes.
HASPGEN efficiently accepts both the IEBUPDTE and IEBUPDAT
formats of modification cards and sequence checks them.
HASP command authority has been extended to local input devices
and is controlled by the central operator.
An optional backspace character can now be defined to support
as controlled consoles with no backspace key.
HASP Remote Job Entry maintenance items:
The 3780 Data Communications Terminal is now supported by
HASP.
The Space Compression/Expansion feature of 2770 and 3780
terminals is supported.
Any of the three optional buffer sizes for 2770 terminals may
now be specified. Current 2770 users must respecify RMTnn
parameters prior to HASPGEN, according~the new definitions
on page 388.
HASP RMTGEN will optionally punch an 80-column card deck for
System/3 remote terminals without 5424 card readers.
This modification is supported on current
as
releases.
This memorandum should be added to your program package for future
reference.
The HASP II System has Programming Service Classification A.
Any discrepancy between the material received and the material
listed above, or any errors in reproduction, should be reported
to the Manager of the Program Library providing your programming
systems.
cc:
IBM Systems Engineering Managers (no enclosures)
IBM Field Engineering Managers (no encloures)
Program Information Department
I
Q. p~~g~~m
a
Library
M Japan, Ltd.
Systems Engineering Dept.
14, 1 Chome Nagata-cho
Chiyoda-ku
Tokyo, Japan
Canadian Program Library
IBM Canada Ltd.
Department 960
5 Yorkland Boulevard
Willowdale, Ontario
Canada
European Program Library
IBM France
23, Allee-Maillasson
F.92-Boulogne-Billancourt
France
Societe Anonyme Au Capital de
620.256.000 F-R.C.
(Seine 55B-11 846)
Program Information Dept.
IBM Corporation
40 Saw Mill River Road
Hawthorne, New York 10532
United States
South American
Program Library
IBM do Brasil, Ltda.
Avenida Presidente
Vargas 642, 4 Andar
Caixa Postal 1830-ZC-00
Rio de Janeiro, Brazil
South Pacific
Program Library
IBM Australia, Ltd.
Box 3318 G.P.O.
Sydney, N.S.W.
Australia
June 26, 1972
Memorandum to: Recipients of HASP II (360D-05. 1.014)
Subject
Replacement Memorandum for HASP II System
Manual
The attached memorandum replaces the memorandum currently
attached to the HASP II System Manual.
Attachment
Program Information Department
3H399C
.1I;p~ogr~m Library
'-1M
J~pan, Ltd.
Systems Engineering Dept.
14, 1 Chome Nagata-cho
Chiyoda-ku
Tokyo,Japan
Canadian Program Library
IBM Canada Ltd.
Department 960
5 Yorkland Boulevard
Willowdale, Ontario
Canada
European Program Library
IBM France
23, Allee-Maillasson
F.92-Boulogne-Billancourt
France
Program Information Dept.
IBM Corporation
40 Saw Mill River Road
Hawthorne, New York 10532
United States
Societe Anonyme Au Capital de
620.256.000 F-R.C.
(Seine 55B-11 846)
South American
Program Library
IBM do Brasil, Ltda.
Avenida Presidente
Vargas 642, 4 Andar
Caixa Postal 1830-ZC-00
Rio de Janeiro, Brazil
South Pacific
Program Library
IBM Australia, Ltd.
Box 3318 G.P.O.
Sydney, N.S.w.
Australia
June 26, ·1972
Memorandum to:
Recipients of HASP II (360D-05.l.0l4)
Subject:
Transmittal of Version 3, Modification Levell of
360D-05.l.0l4
The program materials you have ordered are enclosed. The .following
describes the contents of the Basic and Optional program packages.
Basic program material consists of:
1.
The enclosed HASP II System Manual.
2.
Machine-readable material on one 9-track 800 or 1600
bpi, or 7-track 800 cpi (Data Conversion Feature required)
Distribution Tape Reel (DTR).
For a description of the.
tape contents see the HASP II System Manual.
If you have ordered the Optional program material, it consists of:
1.
A deck of 138 - 96 column cards. This deck is a
"starter system" for the HASP MULTI-LEAVING Remote
Job Entry support for the IBM System/3 to allow a
customized workstation program to be transmitted to
the Remote System/3. See the HASP Remote Terminal
Operator's Guide for the System/3 for instruction on
the use of this deck.
Installations ordering this program to obtain the HASP MULTILEAVING workstation programs for use'with non-HASP systems should
refer to Section 10.4 of the HASP SYSTEM Manual for procedural
information.
The HASP-II SYSTEM has Programming Service Classification A. If,
in the future, a new release is made available for this program,
the period that Version 3, Modification Levell will remain "current"
for programming service purposes will be specified at the time of
the new release.
HASP, Version 3 Modification Levell incorporates all PTFs applicable to HASP Version 3 Modification Level 0 through DPA5427. No
PTF before and including DPA5427 should be applied to Version 3,
Modification Levell. Your local IBM representative will discuss
the standard error reporting (APAR) procedure.
This program has been registered by system type and is listed under
the name and address shown on your order. Program modifications,
as and when made by IBM will be sent to this same address. Should
there be a change in your system type or in your address, we would
appreciate your notifying your local IBM branch office.
Any discrepancy between the material received and the material ordered, or any errors in reproduction should be reported to the
Manager of the Program Library providing your programming systems.
Enclosures
Program Information Department
---- -- ---- ----
----- ------ ---- -_.-
~.
..... a p~og~am Library
~ Japan, Ltd.
Systems Engineering Dept.
14,1 Chome Nagata-cho
Chiyoda-ku
Tokyo,Japan
Canadian Program Library
IBM Canada Ltd.
Department 960
5 Yorkland Boulevard
Willowdale, Ontario
Canada
European Program Library
IBM France
23, Allee-Maillasson
F.92-Boulogne-Billancourt
France
Societe Anonyme Au Capital de
620.256.000 F-R.C.
(Seine 55B-11 846)
Program Information Dept.
IBM Corporation
40 Saw Mill River Road
Hawthorne, New York 10532
United States
South American
Program Library
IBM do Brasil, Ltda.
Avenida Presidente
Vargas 642, 4 Andar
Caixa Postal 1830-ZC-00
Rio de Janeiro, Brazil
South Pacific
Program Library
IBM Australia, Ltd.
Box 3318 G.P.O.
Sydney, N.SW.
Australia
June 26, 1972
Memorandum to:
Recipients of the HASP II System (360D-05.1.0l4)
Version 3, Modification Levell
Subject:
New and Replacement pages for the HASP II System
Manual
Attached are new and replacement pages for the "HASP II System
Manual. These pages have been reproduced in such a manner
as to easily replace their corresponding pages in the HASP II
System Manual.
Program Information Department
3M399B
THE
HAS P
SYST EM
FEBRUARY 26, 1971
TYPE III PROGR~lS WITH
SERVICE A CLASSIFICATION
Type III programs which were given Service A Classification, perform
functions which may be fundamental to the operation and maintainance
of the user's system. These programs have not been subjected to
formal test by IBM.
Until reclassified, IBM will provide for these Type III programs
the follovling: (a) Central Programming Service including design error
correction and automatic distribution of corrections; (b) Field
Engineering Programming Service including design error verification,
Authorized Programming Analysis Report (APAR.) documentation and
submission, and application of Program Temporary Fixes or development
of an emergency by-pass when required.
IBM does not guarantee service results or represent or warrant that
all errors will be corrected. The user is expected to make the final
evaluation as to the usefulness of these programs in his own
environment.
THE FOREGOING IS IN LIEU OF ALL WARRANTIES, EXPRESS OR IHPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRl~NTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
HAS P
PREFACE
This document contains complete instructions for the
generation and use of the HASP SYSTEM.
Also included is detailed
information concerning the internal structure and implementation
techniques of HASP to serve as an aid to systems programmers.
The various HASP OPERATOR'S GUIDES, intended for use as removable
sections, are included as Section 11 of this manual.
HAS P
MAGNETIC TAPE KEY
BASIC
This volume contains two files as described below.
File 1
- Assembled object decks and JCL necessary to perform
a HASPGEN (refer to Section 10 of this manual for
information concerning use of this tape).
Records - 428; Characters/block - 80;
Records/block - 1; Blocks/file - 428.
File 2
- Source decks for HASP-II, Version 3.1.
Records - 52,705; Characters/block - 1600;
Records/block - 20; Blocks/file - 2636.
*Optional
System/3 users only - 138 96-column cards. This deck is a
"starter system" for the HASP MULTI-LEAVING Remote Job Entry
support.
*Optional material will be forwarded only
requested.
whe~
specifically
HAS P
TABLE OF CONTENTS
Section
Page
1.0
- Introduction
1
2.0
- General Description
3
3.0
- HASP Structure
7
3.1
- Allocation of Main Storage
12
3.2
- Allocation of Direct-Access Space
17
3.3
- Allocation of Input/Output units
20
3.4
- Allocation of Central Processing unit Time
22
3.5
- Allocation of Programs
24
3.6
- Allocation of Jobs
26
3.7
- Allocation of Overlay Areas
29
4.0
- HASP Processors
31
4.1
- Input Service Processor
32
4.2
- Execution Control Processor
48
4.3
- Output Service Processor (Print and Punch)
62
4.4
- Purge Processor
76
4.5
- HASP Command Processor
77
4.6
- Operator Console Attention Processor
98
4.7
- Checkpoint Processor
99
4.8
- Asynchronous Input/Output Processor
101
4.9
- HASP Log Processor
102
4.10 - Operator Console Input/Output Processor
103
4.11 - Timer Processor
105
4.12 - Remote Terminal Processor (STR Model 20)
106
Table of Contents - Page i
..
HAS P
Page
section
4.13 - Remote Terminal Processor (System/360)
119
4.14 - Remote Terminal Processor (1130)
138
4.15'- Execution Task Monitor Processor
190
4.16 - Internal Reader Processor
193
4.17 - MULTI-LEAVING Line Manager
195
4.18 - Remote Console Processor
197
4.19 - Execution Thaw Processor
199
4.20 - Overlay Roll Processor
200
4.21 - HASP 5MB Writer
202
4.22 - Priority Aging Processor
204
4.23 - Remote Terminal Processor (System/3)
205
5.0
- HASP Control Service Programs
243
5.1
- HASP Dispatcher
244
5.2
- Input/Output Supervisor
246
5.3
- Job Queue Manager
247
5.4
- Buffer Manager
250
5.5
- unit Allocator
251
5.6
- Interval Timer Supervisor
252
5.7
- $WTO Processing Routine
254
5.8
- Direct Access Storage Allocator
255
5.9
- Disastrous Error Handler
257
5.10 - Catastrophic Error Handler
258
5.11 - Trace Effector
259
5.12 - WTO/WTOR Processing Routine
262
5.13 - Console Buffering and Queueing Routines
266
Table of Contents - Page ii
HAS P
Section
Page
5.14 - Input/Output Error Logging Routine
269
5.15 - Remote Terminal Access Method
272
5.16 - Overlay Service Routines
280
6.0
- Miscellaneous
287
6.1
- HASP Initialization
288
6.2
-. HASP Initialization SVC Routine
297
6.3
- HASP Overlay Build Utility
299
6.4
- HASP REP Routine
302
6.5
- HASP Accounting Routine
305
6.6
- HASP Dump Routines
306
7.0
- HASPGEN and RMTGEN Parameters
309
7.1
- HASPGEN Parameters
310
7.2
- RMTGEN Parameters for System/360 Model 20 STR
422
7.3
- RMTGEN Parameters for System/360 Model· 20 BSC
427
7.4
- RMTGEN Parameters for System/360
446
7.5
- RMTGEN Parameters for 1130
466
7.6
- RMTGEN Parameters for 1130 Loader
481
7.7
- RMTGEN Parameters for System/3
485
7.8
- RMTGEN Parameters for 2922
504
8.0
- HASP Control Table Formats
505
8.1
- HASP Communication Table Format (HCT)
506
8.2
- Processor Control Element Format (PCE)
521
8.3
- Buffer Format (IOB)
527
8.4
- Console Message Buffer Format (CMB)
544
8.5
- Device Control
8.6
- Job Queue Element Format (JQE)
~able
Format (OCT)
546
567
Table of Contents - Page iii
HAS P
Page
Section
8.7
- Job Information Table Element Format (JIT)
569
8.8
- Job Control Table Format (JeT)
570
8.9
- Track Extent Data Table Format (TED)
578
8.10 - Timer Queue Element Format (TQE)
579
8.11 - Overlay Table Format (OTB)
580
Data Definition Table Format (DDT)
582
8.13 - Partition Information Table Format (PIT)
585
8.14 - Message Allocation Control Block (MSA)
588
8.15 - Data Block Format (HOB)
589
8.12
9.0
- HASP Executor Services
591
9.1
- Buffer, Services
600
9.2
- unit Services
602
9.3
- Job Queue Services
604
9.4
- Direct-Access Space Services
613
9.5
- Input/Output Services
615
9.6
- Time Services
622
9.7
- Overlay Services
625
9.8
- Synchronization Services
632
9.9
- Debug Services
638
9.10 - Error Services
640
9.11 - Coding Aid Services
643
10.0
- HASP Maintenance Procedures
651
10.1
- Generating a H..Z\.SP System (HASPGEN)
652
10.2
- OS SYSGEN and Installing a HASP System
666
10.3
- Generating HASP Remote Terminal Programs
676
Table of Contents - Page iv
HAS P
Section
Page
10.4
- Remote Generation for non-HASP Users
687
11.0
- Operator's Guides
689
11.1
- HASP Operator's Guide
691
11.2
- HASP RTP Operator's Guide (STR Model 20)
849
11.3
- HASP RTP Operator's Guide (1978)
875
11.4
- HASP RTP Operator's Guide (1130)
907
11.5
- HASP RTP Operator's Guide (System/360)
935
11.6
- HASP RTP Operator's Guide (BSC Model 20)
963
11.7
- HASP RTP Operator's Guide (2780)
993
11.8
- HASP RTP Operator's Guide (2770)
1021
11.9
- HASP RTP Operator's Guide (System/3)
1051
11.~0
- HASP RTP Operator's Guide (3780)
12.0
- Appendices
1075
12.1
- Reference Listing of HASPJCL
1076
12.2
- HASP Storage Requirements
1080
12.3
- HASP Control Card Formats
1088
12.4
- HASP AC,counting Card Format
1097
12.5
- HASP Print and Punch ID Formats
1098
12.6
- HASP Coding Conventions
1101
12.7
- General HASP Restrictions
1103
12.8
- HASP JCL Processing Program
1106
12.9
- HASP /RJE 'Line Transmission Techniques (STR)
11'22
1074.1
12.10 - HASP Internal Reader
1,135
12.11 - MULTI-LEAVING
1139'
Table of Contents - Page v
HAS P
Section
Page
12.12 - HASP 2770 RJE Support
1155
12.13 - HASP Execution Batch Scheduling
1159
12.14 - HASP Overlay Programming Rules
1163
12.15 - HASP with OS Console Support
1167
12.16 - Multiple Devices on MULTI-LEAVING Remotes
1172
12.17 - 3211 Forms Control Buffer Additional Loads
1174
Table of Contents - Page vi
HAS P
1.0
INTRODUCTION
The HASP SYSTEM operates as a compatible extension to the MFT or
MVT options of the Operating System for System/360 and System/370
to provide specialized supplementary support in the areas of job
management, data management, and task management.
HASP appears as a transparent "front-end" processor to OS to,
via the SPOOLing functions normally associated with OS input
readers and output writers, act as an automatic scheduler
and operator of Os. Because of this relationship between HASP
and the Operating System, various other functional, performance
and operational benefits can be included in HASP.
The use of HASP offers an installation the following advantages:
•
IMPROVED PERFORMANCE - In many cases, because of the
singular, specialized use of resources by HASP, system
performance may be improved. Any improvement is dependent
upon the configuration and job mix and can only be determined by actual measurement.
(See Section 2 of this manual
for additional details.)
•
IMPROVED OPERATIONAL PROCEDURES - HASP acts as an automatic
interface between the operator and OS, to perform various OS
control functions previously done directly by the operator.
Readers, Writers and Initiators in OS are started and scheduled automatically by HASP. Also, many additional operator
commands for controlling job flow and device operation are
provided by HASP.
(See Section 11 of this manual for
additional details.)
•
INCREASED SYSTEM FUNCTION - The use of HASP provides certain
functions which are not otherwise available.
These include
dynamic task ordering based upon CPU - I/O characteristics
(see Section 2 for additional details); the inclusion of
relevant console messages in each job's output (see Section 7
for additional details); the capability of any job to introduce another job into the HASP queue via an internal reader
(see Section 12.10 for additional details); an execution
batching facility to pass jobs directly to a processing program such. as a one-step monitor (see Section 12.13 for addi~
tional details); many additional operational control functions
(~ee Section 11 for additional details); a priority aging
technique (see Section 4.22 for additional details); a preexecution volume fetch facility (see Section 11 for additional
details); and various other functional enhancements.
•
RESOURCE REDUCTION - Because of the dynamic direct-access
allocation techniques utilized by HASP; installations may, in
general, reduce the number of direct-access volumes required
Introduction - Page 1.0-1
1
II ASP
for SPOOLing functions as compared with a non-HASP SYSTEM.
The size of the OS SYSI.SYSJOBQE data set may also be
reduced since all job queueing is performed by HASP.
Certain installations may actually reduce system main storage
requirements (increase problem program space available) by
adding HASP to their system because of the OS functions
replaced by HASP.
In any case, the space required for the
HASP partition or region will be at least partially compensated for by the elimination of duplicate functions.
•
LOW-ENTRY, HIGH-PERFORMANCE REMOTE JOB ENTRY - For a nominal
increase in the size of HASP, an installation can utilize the
HASP RJE support for a wide variety of workstation devices.
Support for Binary-Synchronous, CPU workstations employs an
advanced technique called MULTI-LEAVING which provides for
simultaneous operation of all devices on a remote workstation.
A subset of the HASP operator command language is provided to
all remote sites. Workstation programs are supplied for all
supported CPU workstations.
(See Section 12.11 for additional details.)
•
TRANSPARENT OPERATIONS - HASP is, in general, transparent to
both the Operating System and to user programs. Although
a special SYSGEN is required, no actual modifications to as
are required to utilize HASP. Thus, the same generation of
OS may be interchangeably used with or without HASP. Because
of this transparency, HASP is generally independent of the
OS release level or options selected and can be used as a
stable base for local modifications to customize for local
operational requirements.
Most standard jobs which operate under as can be run with
absolutely no change in a HASP environment. Most installations
can, therefore, implement HASP with little or no changes to
current user programs.
Introduction - Page 1.0-2
2
HAS P
2.0
GENERAL DESCRIPTION
HASP is a specialized program which operates in the same CPU
with OS/360 to perform the peripheral functions associated with
batch job processing.
HASP is loaded as a normal OS/360 program and upon gaining
control enters the supervisor mode via a special SVC routine.
Control of all on-line unit record devices is assumed, the
designated intermediate storage direct-access device(s) are
initialized and job processing begins. The basic interface between HASP and OS/360 is through the Input-Output Supervisor (lOS).
The entry point of lOS is modified so that Input-Output requests
to unit record devices are diverted to HASP rather than being
physically executed by lOS. Jobs which have been previously read
from physical input devices by HASP can now be passed to OS by
simulating a successful completion of the intercepted I/O request.
In a similar manner, print and ~unch output from jobs being processed by OS/360 can be intercepted and queued on intermediate
storage for later transcription to unit record devices.
HASP has four major processing stages which account for its four
major external functions.
These are:
1.
INPUT STAGE - This stage reads jobs simultaneously from an
essentially unlimited number of various types of on-line
card readers, tapes and remote terminals into the system.
These jobs are then entered into a priority queue by job
class to await processing by the next stage.
2.
EXECUTION STAGE - This stage removes jobs based upon priority
and class from the queue established by the Input stage and
passes those jobs to OS/360 for processing.
Input cards are
supplied as required to the executing program and print and
punch records are received and written onto HASP intermediate
storage. This stage can simultaneously control an essentially
unlimited number of jobs being processed by OS/360. At the
completion of a job, it is placed in a queue to await processing by the next stage.
3.
PRINT STAGE - The purpose of this stage is to transcribe the
printed output generated by jobs in the previous stage to
printers. An essentially unlimited number of various types
of printers and remote terminals can be operated simultaneously.
4.
PUNCH STAGE - This stage transcribes the punch output generated
by jobs in the execution phase to punches. An essentially
unlimited number of various types of punches and remote
terminals can be operated simultaneously.
General Description - Page 2.0-1
3
HAS P
All of the these processes are controlled by re-entrable code
so that no additional code is required to support multiple,
simultaneous functions.
Since all of the above functions can
occur simultaneously and asynchronously, a continuous flow of
jobs may pass through the system.
Following are some of the more significant algorithms employed
by HASP to improve function and performance:
•
SPECIALIZED DIRECT-ACCESS STORAGE ALLOCATION
HASP, through the use of an allocation bit map in main
storage, dynamically allocates space for intermediate
storage on a record basis, within definable track groups,
for jobs. The use of this technique offers the following
advantages:
•
1.
Disk-arm motion and interference is minimized by
dynamically allocating space based upon the position
of the access mechanism.
2.
Disk area fragmentation is automatically eliminated
by allocation of the smallest possible increment of
space.
3.
The data for a single data set can be spread across
multiple direct-access volumes.
In addition to further
optimizing arm motion, this capability allows for the
simultaneous use of multiple selector channels to
increase the data rate for a given job.
4.
Since space is allocated only when required, there
will be no unused space as a result of over estimated
output requirements.
5.
The release of previously used space is accomplished
by a simple algorithm which requires no I/O operations.
UNIT RECORD DEVICE COMMAND CHAINING
While operating any reader, printer or punch, rather than
handling each record separately, HASP constructs a chained
sequence of channel command words to pass to the channel.
Thus, instead of the overhead of an EXCP and the ensuing
interrupts for each record transmitted, only one EXCP and
associated interrupt is required for a series of records.
For example, when reading a job into the system, HASP might
chain 40 commands together to instruct a card reader. This
General Description - Page 2.0-2
4
HAS P
would cause the next 40 cards to be read irito memory without
requiring the execution of any CPU instructions.
•
TRANSPARENT BLOCKING
All input, print and punch for every job is automatically
blocked by HASP to improve performance. Since all deblocking
is also done by HASP, any program even if designed to operate
with unblocked records can benefit from the blocking. Also,
because all blocking and deblocking is done by HASP, problem
programs require buffers only the size of a single card or
line.
This can reduce a program's partition or region requirement by several thousand bytes over normal full track blocking.
•
DYNAMIC BUFFER POOL
HASP maintains a dynamic area of memory which is allocated as
required.
This technique allows not only multiple data sets
of a job, but multiple jobs to share this area, thereby
insuring optimum use of storage.
•
EXECUTION TASK MONITOR
A significant item contributing to system performance is the
correct ordering of dispatching priorities of jobs in relation to their CPU-I/O utilization ratios.
It is obviously
straightforward to manually set the dispatching priorities
of two jobs, one of which is completely I/O-bound and the
other completely CPU-bound.
It becomes more difficult to
determine relative priorities of multiple jobs with varying
degrees of CPU-I/O ratios and impossible to determine priorites for multiple jobs which constantly change from CPU to
I/O bound or vice versa.
HASP provides a feature which, at frequent intervals, examines
each eligible job and dynamically re-orders the OS dispatching
chain based upon the measured CPU-I/O characteristics of the
jobs during the previous interval. This capability relieves
an installation of the responsibility of attempting to assign
job dispatching priorities while insuring the optimum ordering.
of jobs being processed by the Operating System.
General Description - Page 2.0-3
5
HAS P
(The remainder of this page intentionally left blank.)
6
HASP
3 .0 HASP STRUCTURE
The primary goal in the design of any execution support system such
as HASP must be the efficient manipulation of the various resources
required for processing.
The first design steps must then include the
determination of what resources will be required and the careful application
of sound programming design techniques to achieve an efficient and
consistent solution to the allocation of these resources.
A study would reveal that HASP requires the following resources:
1.
Main Storage
2 • Direct-Access Space
3 • Input/Output Units
4.
Central Processing Unit Time
5.
Input/Output Channel and Unit Time
6.
Programs
7. Jobs
8.
Interval Timer
Since these resources are essentially the basic facilities provided by
the Operating System
I
it would at first seem that these facilities would
be sufficient to meet the requirements of HASP.
Further studies show,
however, that the philosophie-s of the Operating System's services are not
always consistent with the deSign requirements of a system such as HASP.
HASP Structure - Page 3.0-1
7
HASP
For instance the main storage services provided by the Operating
I
System are very flexible and comprehensive but fail to meet the requirements of HASP in the following areas:
•
As requests for main storage are serviced
I
memory becomes
fragmented in such a way that eventually a request for
storage cannot be serviced for lack of contiguous memory
even though the total amount of storage available far
exceeds the requested quantity.
•
As the amount of available storage decreases
I
the
requestor becomes more susceptible to being placed in
an OS WAIT state or being ABENDed.
These conditions are
both intolerable to HASP.
•
The primary use of main storage in HASP is for buffering
space for input/output purposes. These input/output purposes require that an Input/Output Block be associated
with each segment of main storage which the Operating
System Main Storage Supervisor only naturally does not
I
I
provide. This means that HASP would have to construct
such a block for each main storage segment it required.
HASP Structure -Page 3.0-2
8
HASP
In a similar fashion the Direct-Access Device Space Manager
(DADSM) provides flexible and comprehensive services for normal
job processing requirements but fails to meet the requirements of
HASP in the following areas:
•
Because of the data set concept employed by DADSM,
the "hashing" or "fragmentation" problem described
above also impacts the allocation of direct-access
space.
•
The data set concept complicates the simultaneous
allocation of storage acros s many volumes (for
selector channel overlap).
•
The DADSM limit of extents per volume tends to cause
volume switching, and the as sociated time delays are
intolerable to HASP.
•
DADSM consists of non-resident routines which must
be loaded for each direct-access space allocation
service.
Because of the frequent allocation requirements,
the associated overhead involved in the loading of these
routines would degrade the performance of HASP to a
certain extent.
HASP Structure - Page 3.0-3
9
HASP
Since the unit-record input/output units which the scheduler
allocates to the jobs being processed in other partitions must be
available for use by HASP
I
HASP must be responsible for the allo-
cation of its own input/output units.
The Operating System Task Supervisor is responsible for the
allocation of Central Processing Unit (CPU) time to all tasks in the
system. The different functions of HASP (reading cards
I
printing
I
punching, etc.) could be defined as individual OS tasks except
for the following considerations:
•
Defining each function as a separate task would
prohibit HASP from being used with anything other
than a variable-task system.
•
Inter-task communication and synchronization is
many times more complex than intra-task communication and synchronization.
The Operating System Input/Output Supervisor is responsible
for the allocation of all input/output channel and unit time. It
completely meets all requirements and is used by HASP for all
input/output scheduling.
HASP Structure - Page 3.0-4
HASP
The Operating System Interval Timer Supervisor provides complete
interval timer management services but limits these services to one
user per task.
Since HASP has many functions which have simultaneous
interval timer requirements, an interface must be provided which will
grant unlimited access to the OS Interval Timer Supervisor.
The following sections describe, in detail, the allocation techniques
and algorithms used in HASP to provide the allocation of the resources
listed above.
HASP Structure - Page 3.0- 5
11
HAS P
3.1 ALLOCATION OF MAIN STORAGE
The main storage requirements of HASP are as follows:
•
Storage space for buffering card images and print lines
between intermediate direct-access storage devices
and unit-record devices.
•
Storage space for normally non-resident control tables
during times when they are resident in main storage.
•
Storage for console messages which have been queued
for output to or input from one or more operator consoles.
•
Storage for elements which reflect the status of all jobs
which are queued for any stage of processing by HASP.
•
Storage space for non-resident processing routines (overlays) during times when they are in main storage.
The HASP Buffer Pool
The first two requirements for main storage are provided for by the
HASP Buffer Pool, a group of buffers with the following basic format:
Allocation of Main Storage - Page 3.1-1
HAS P
Input/Output
Block
(IOB)
buffer control
information
buffer
work
space
Figure 3. 1 • 1 - The HASP Buffer
Since the use of this buffer always involves some input/output
activity
I
a standard Operating System Input/Output Block (lOB) is pro-
vided with each buffer for the purpose of being used to initiate this
input/output activity.
The "buffer control information
ll
area is an extension of the lOB used
by HASP for input/output synchronization.
The "buffer work space" is a fixed-length (set by HASPGEN) area into
which data is read and/or out of which data is written.
In addition to a fixed number of buffers (set in accordance with region
or partition size)
I
the buffer pool contains a one-word control field called
the Buffer Pool Control Block which contains the address of the first available buffer in the buffer pool.
Each available buffer contains the addres s
Allocation of Main Storage - Page 3. 1-2
13
HASP
of the next available buffer with the last available buffer containing a
zero address. If no buffers are available, the Buffer Pool Control
Block contains zero.
The above technique is called
.II
chaining, II the buffers are said
to be "chained," and the field containing the addres s of the next
element in the chain is referred to as the "chain field.
II
Chaining
is used throughout HASP for the maintenance of resources.
To obtain an available buffer from the buffer pool, the Buffer Pool
Control Block is tested for an available buffer. If one exists it is
removed from the available chain by moving its chain address into the
pool control block.
To release a buffer to the available chain, the contents of the
pool control block are moved to the chain field of the buffer and the
I
addres s of the buffer is placed in the pool control block.
The Console Message Buffer Pool
The third requirement for main storage is provided for by the
Console Message Buffer Pool. This buffer pool is organized similarly
to the HASP Buffer Pool except for the format of the buffers which is
as follows:
Allocation of Main Storage - Page 3.1-3
14
HASP
chain field
work
space
/
Figure 3.1.2 -
The Console Message Buffer
Since rOB's are provided for each console, it is not necessary to
provide such a control block with each buffer.
The length of the work space is consistent with the maximum
length of a console message.
Buffers in this buffer pool are obtained and released by exactly
the same procedure used in the HASP Buffer Pool.
The HASP Job Queue
The fourth requirement is provided for by the HASP Job Queue.
For more information about this facility see section 3.6.
Allocation of Main Storage - Page 3.1-4
15
The HASP Overlay Area Pool
The HASP Overlay Area is similar to the HASP Buffer in format;
however
I
the size of the "work space" is set to accommodate the
largest non-resident HASP control-section (CSECT). Although the
fixed number of overlay areas (set by HASPGEN) are chained together
I
control fields indicate the area status and contents for the purpose
of sharing areas containing the same CSECT or for selecting an area
to overlay with a new CSECT.
Allocation of Main Storage - Page 3. 1- 5
16
HAS P
3.2
ALLOCATION OF DIRECT-ACCESS SPACE
The direct-access allocation technique employed by HASP must
meet the following requirements:
•
It must use a minimum of CPU time.
•
It must not use an excessive amount of main storage.
•
It must not be susceptible to the "hashing" or
"fragmentation" problem.
•
It must be capable of allocating for any direct-access
device which is supported by Operating System/360.
•
It must be device transparent to the user.
•
It must be consistent with the checkpoint/restart
technique used by HASP.
The HASP Track Address
The standard Operating System track address is defined to be an
eight-byte field with the following format:
where:
M
BB
CC
HH
R
=
=
=
=
=
Module
Bin
Cylinder
Head
Record
Figure 3.2.1 - The Operating System Track Address Format
For the purpose of HASP, this track address can be reduced to a
four-byte field with the following format:
where:
M
TT
R
= Module
(DEB extent number)
True Track Number
= Record
=
Figure 3.2.2 - The HASP Track Address Format
Allocation of Direct-Access Space - Page 3.2-1
17
HAS P
The reduction in the length of the track address permits it to
be kept ina single word of storage or in a general purpose
register simplifying the handling of the track address.
The HASP Master Track Group Map
The HASP Master Track Group Map is a table which represents the
sum total of all track groups or logical cylinders available on
all HASP direct-access SPOOL volumes.
(A track group contains
one or more tracks which are considered a single resource.)
Each bit in the HASP Master Track Group Map represents a single
track group on one direct-access volume.
If the bit is one, it
indicates that the corresponding logical cylinder is available
for allocation; if the bit is zero, the logical cylinder is not
available to HASP or has already been allocated by HASP.
The HASP Job Track Group Map
The HASP Job Track Group Map is identical to the HASP Master Track
Group Map except that one word has been added to the front to save
the last track address which was allocated to the particular job
with which the map is associated.
The bits in the Job Track Group
Map represent the same track groups as the bits in the Master Track
Group Map except that a one bit indicates that the respective track
group has been allocated to the associated job and a zero indicates
that the group has not been allocated to the job.
last track address
track group
Figure 3.2.3 - The HASP Job Track Group
Two Job Track Group Maps are associated with each job. One represents the track groups used to contain the input data (SYSIN),
and the other represents the groups used to contain the output
data (SYSPRINT and SYSPUNCH).
Allocation of Direct-Access Space - Page 3.2-2
.18
HAS P
Direct-Access Space Allocation Procedures
When the direct-access space allocation subroutine is entered, it
first examines the first four bytes of the appropriate Job Track
Group Map to determine if a new track group is required.
A new
group is required whenever no tracks have been allocated to this
job (the last track address is zero) or if all of the tracks in
the last group allocated have been used.
If a new track group is not required, the record or head field of
the last track address is incremented to provide a new track
address.
If a new track group must be allocated, the Master Track Group
Map is scanned for an available group. When the next group to
be allocated is determined, the appropriate bit in the Master Track
Group Map is set to zero, and the corresponding bit in the Job
Track Group Map is set to one.
A track address is then constructed
to represent the first track in the new group, and this track
address is saved in the first four bytes of the Job Track Group Map.
When any direct-access input/output operation is initiated by HASP,
the HASP I/O interface saves the cylinder which was referenced
by module.
When a new track group must be allocated, the allocation routine first tries to allocate a group corresponding to
the last cylinder referenced on each module.
If these groups are
not available, the routine attempts to allocate within one cylinder
of the last references.
If track groups within these cylinders are
not available, the routine tries to allocate a group within two
cylinders, and so on, until the entire track group map has been
examined.
Direct-Access Space De-Allocation Procedure
To de-allocate the direct-access space allocated to a particular
function, it is necessary only to "OR" the track group map portion
of the Job Track Group Map associated with the particular function
into the Master Track Group Map.
This will reset to one all bits
in the Master Track Group Map which correspond to the track groups
which have been allocated to the particular function.
Allocation of Direct-Access Space - Page 3.2-3
19
HASP
3.3 ALLOCATION OF INPUT/OUTPUT UNITS
The HASP Device Control Table (DCT) is used by HASP to allocate
all input/output units. It has the following basic format:
status
device type
other
control
information
device name
work
space
Figure 3.3.1 -
The "status
II
The HASP Device Control Table (DCT)
field is used to indicate whether the device is available
and whether it is in use.
The "device type" field specifies whether this DCT represents a card
reader printer punch or other type of I/O device.
I
I
I
The "other control information" field contains such information as
the Data Control Block (DCB) address
operator commands
I
I
the chain address
I
indications of
and other fields for. synchronization purposes.
Allocation of Input/Output Units - Page 3.3-1
20
HAS P
The "device name" field contains an eight-byte EBCDIC device
name (such as READER1) which is primarily used for console messages.
The "work space" is a device dependent area used by some devices
for extended control of the device.
All DCT's are chained together for allocation purposes.
Theyare
initialized by the HASP initialization phase if the associated devices
are attached to the system.
Input/Output Device allocation consists of "running" the DCT
chain and looking for a DCT of the specified type which is available
and which has not been allocated.
If one is found, the" in use" bit
is set to one to indicate that the device has been allocated.
De-allocation consists of setting the
II
in use" bit to zero.
The Device Control Table is also used as a parameter list whenever
Input/Output activity is initiated through the HASP I/O interface.
Allocation of Input/Output Units - Page 3.3- 2
21
HASP
3 .4 ALLOCATION OF CENTRAL PROCESSING UNIT TIME
The Operating System controls the allocation of Central Processing
Unit (CPU) time to different tasks through the means of a Task Control
Block (TCB) chain. In a similar fashion, HASP controls the allocation
of CPU time to the different functions within HASP through the means
of a Processor Control Element (PCE) chain. The basic format of the
Processor Control Element is as follows:
as
save
area
event wait field
chain field
processor
work
space
Figure 3.4.1 -
HASP Processor Control Element (PCE)
Whenever a particular function is being processed, general purpose
register 13 always contains the address of the Processor Control Element
which is allocating the time to that function.
eighteen words of the PCE are a standard
For this reason the first
as register save
area.
Allocation of Central Proc'es sing Unit Time - Page 3.4'""1
22
HAS P
The "event wait field" is a two-byte field which describes the
dispatchability of the function under the control of this PCE.
If this
field is zero, the function is dis patchable. If this field is non- zero,
the function is not dispatchable and the bit which is one specifies
upon what event the function is "waiting ".
The "chain field" contains the addres s of the next PCE in the PCE
chain.
The" processor work space" is a variable length area which is used
by the program processing the function as a scratch area.
HASP searches the PCE chain looking for a PCE which is dispatchable.
When a dispatchable PCE is located, the general purpose registers are
loaded from the PCE/OS save area and control is passed to the location
specified in register 15.
When control is returned to the dispatching program
I
the general pur-
pose registers are saved in the PCE and the search for dispatchable PCEs
continues.
If a notable event occurred since the last PCE dispatch such
as the freeing of a common resource or the "posting" of a specific event,
the search starts at the beginning of the PCE chain; otherwise, it starts
with the PCE following the last dispatched.
The program returning control
to the dispatching program must set the return address in register 15 before
returning.
When no PCEs are found to be dispatchable
as
I
the HASP task enters an·
WAIT state to allow the Operating System to allocate CPU time to other
tasks.
Allocation of Central Processing Unit Time - Page 3.4-2
23
HAS P
3.5 ALLOCATION OF PROGRAMS
i
The programs of which HASP is composed can be divided into
the following classifications:
•
The Dispatcher
•
Processors
•
Control Service Programs
•
Miscellaneous Programs
The Dispatcher is the dispatching program described in Section
3.4. Its function is to distribute CPU time among the various processors
described below.
Processors are programs which control the execution of various HASP
functions such as reading cards
I
printing, punching, etc. With each
processor is always associated at least one Processor Control Element
which causes the dispatcher to give control to the-processor and allows
the processor to synchronize with various HASP events. The PCE work
space also permits the processors to be written re-enterably such that by
defining more than one PCE for a given processor, the processor can control
an essentially unlimited number of functions simultaneously.
For instance,
by defining ten PCEs for the Print Processor up to ten printers can be serI
viced simultaneously utilizing and requiring only one copy of the processing
program.
Allocation of Programs - Page 3.5-1
24
HASP
The Control Service Programs are subroutines used by the processors
in accomplishing their functions.
By using the peE/OS save area, the
control service programs can maintain the re-enterability of the
proces sors .
Miscellaneous Programs are those special purpose programs which
do not fall into any of the other thre.e categories
I
such as the HASP
Initialization Program. They are executed only once and need not be
considered in the normal HASP job flow .
Allocation of Programs - Page 3.5- 2
25
HASP
3.6 ALLOCATION OF JOBS
HASP maintains its job pointers in the HASP Job Queue, a table of
elements with the following basic format:
priority
type
job number
chain address
JCT track
Figure 3.6. 1 -
The HASP Job Queue Element
The "priority" represents the dynamic priority of the job within the
HASP system.
The "type" represents the function for which the element is queued
or the function in which the job is currently being processed.
The "job number" is the number sequentially assigned to each job
by HASP as it enters the system.
The "chain address" is the address of the next element in the chain.
Allocation of Jobs. - Page 3. 6-1
26
HASP
The" JCT track
II
is the track address of the HASP Job Control Table
described below.
Two chains are maintained in the Job Queue.
The first chain
represents those jobs which are currently awaiting processing or being
processed.
priority.
Elements in this chain are chained in the order of their
The second chain represents the inactive or unused queue
elements.
To add a job to the job queue
the inactive chain
I
I
a queue element is obtained from
initialized with the information shown in figure
3.6.1, and inserted into the active chain according to its priority.
To obtain a job from the job queue, the active chain is searched
for an element of the specified type. When found
I
the "type" field is
modified to reflect the fact that the job is now being processed
To return a job to the job queue
active chain to the inactive chain
here
I
c
I
8
the element is moved from the
Since the priority is of no concern
the element is placed at the head of the chain.
The HASP Job Control Table {JCTl
The HASP Job Control Table contains all of the information neces sary
to process the associated job in the following basic format:
Allocation of Jobs - Page 3.6-2
27
HAS P
data from
JOB Card
accounting
information
first input track
input job
track group map
output job
track group map
work space
output data
set tracks
Figure 3.6.2 - The HASP Job Control Table (JCT)
The HASP Job Control Table is normally resident on a direct-access
intermediate storage device.
obtained
I
Once the HASP Job Queue Element is
the "JCT track II in the element can be used to initiate a read
into a HASP Buffer.
Once this read has been completed
I
all information
necessary to process the job can then be obtained.
Allocation of Jobs - Page 3. 6- 3
28
HAS P
3.7
ALLOCATION OF OVERLAY AREAS AND NON-RESIDENT CONTROL SECTIONS
Portions of the various programs of which HASP is composed are
organized into non-resident control sections (CSECTs) and stored
in an overlay library (OLAYLIB) on a direct-access volume.
These
control sections contain HASP re-entrant subroutines and/or data
which may be requested for use by a Processor.
The user obtains an Overlay Area by requesting from the overlay
control service program for use of a non-resident CSECT.
If the
CSECT requested is in main storage, the user is allowed to use
the Overlay Area for processing.
If, however, the CSECT is not
already in an area, an area must be selected to hold the requested
CSECT.
The requesting Processor is made to "wait" until the
requested CSECT is read from direct-access into main storage.
The algorithms for Overlay Area allocation cause multiple users
of the same CSECT to use only one area, into which that CSECT is
read.
Competition for areas is resolved partially by the priority
associated with each overlay CSECT.
However, a "pre-empting"
(roll) algorithm prevents any Processor from being indefinitely
delayed, even if the system has only one Overlay Area.
The user releases an Overlay Area by requesting that overlay
services remove his PCE from association with the area.
Allocation of Overlay Areas - Page 3.7-1
'10
HAS P
(The remainder of this page intentionally left blank.)
30
HAS P
4.0
HASP PROCESSORS
This section contains detailed internal information about each of
the HASP Processors and is intended primarily for use by system
programmers.
HASP Processors -- Page 4.0-1
31
HAS P
4.1
INPUT SERVICE PROCESSOR
4.1.1
INPUT SERVICE PROCESSOR - GENERAL DESCRIPTION
The functions of the Input Service Processor are as follows:
To read card images from an input device.
To detect and scan JOB cards, extracting parameters for
job accounting, job control, and print and punch identification.
To detect and process other control cards such as the
PRIORITY, MESSAGE, ROUTE, SETUP, COMMAND, DD*, and DD
DATA cards.
To assign a unique HASP job number to each job.
To log jobs into the HASP System.
To assign job priority based upon PRIORITY card or JOB
card parameters.
To generate, from cards read, a JCL file and input data
files, and to record these files on direct-access storage
device(s) for later use by the Execution Control Processor
(see Section 4.2).
To generate HASP Job Control Tables, Job Queue Entries,
and other HASP control blocks required for later job processing.
To queue jobs for processing by the Execution Control
Processor.
The Input Service Processor is coded re-enterably in such a
way that it can accept jobs from a number of different input
devices (with different hardware characteristics) simUltaneously. The re-enterability is attained by retaining all
storage unique to a job in the Processor Control Element
(see figure 4.1.1) which must be unique for each input device.
4.1.2
INPUT SERVICE PROCESSOR - PROGRAM LOGIC
The Input Service Processor is divided into three phases, 13
subroutines, and three non-process exits. This section will
give a functional description of each of these phases, subroutines, and exits to aid the System Programmer in gaining
a working knowledge of the processor.
Input Service Processor - Page 4.1-1
32
H. ASP
PHASES
Phase 1 - Processor Initialization
The Initialization Phase, which is written as an overlay segment, begins by attempting to acquire an input device.
If
no input device is available, the processor is placed in a
HASP $WAIT state until a device is made available; whereupon
the entire procedure is repeated until an input device is
available. Upon acquiring an available input device the
processor continues by acquiring a Device Control Table (DCT)
for the direct-access device(s) and a HASP buffer for use as
an input buffer.
If the input device is not a remote terminal, a chain of
Channel Control Words (CCW's) is then constructed in the
input buffer which will be used to read 80-byte records from
the input device into the rest of the input buffer. These
CCWs are constructed in such a way that the input records
will be read into adjacent areas in the input buffer with as
many cards being read as the buffer will hold. The initialization of the PCE Work Area is then completed and control is
transferred to Phase 2.
If the input device is a remote terminal, transmission is
initiated by calling upon the Remote Terminal Access Method
to open the Remote Terminal Device Control Table. Control
is then passed to Phase 2.
Phase 2 - Main Processor
The Main Processor Phase reads cards from the input device,
scans each card to detect HASP control cards and processes
these cards as follows:
/*control card--The control card scan routine (HASPRCCS) is
called to process the control card and take any appropriate
action.
Job Card--The JOB card scan routine (HASPRJCS) is called to
terminate the previous job (if any), to scan the JOB Card,
and to initialize the PCE work area for the processing of
the following job.
DD* or DD DATA--A track address is obtained for the first
data block of the input data set. A dummy card is added to
the JCL file which contains the track address in columns 1-4.
Input Service Processor - Page 4.1-2
33
HAS P
This card is differentiated from other cards by setting the
control byte (see figure 8.15.1). The DD* or DD DATA statement is then added to the JCL file in normal fashion.
Control
is subsequently turned back to the main processor to process
the input data.
When a hardware end-of-file is detected on the input device,
or when "$DRAIN input device" command is entered by the operator, control is given to Phase 3.
Phase 3 - Processor Termination
Upon receiving control from the Main Processor, the Processor
Termination Phase, which is written as an overlay segment,
terminates the last job (if any), issues a rewind and unload
command to the input device if it is tape, frees the input
buffer, closes the input DCT if it is a Remote Device, releases
the input and direct-access devices, and returns control to
Phase 1.
SUBROUTINES
HASPRCCS -- Subroutine to Process HASP /* Control Cards
The HASPRCCS subroutine, which is written as an overlay segment, is called whenever the Main Processor Phase encounters
a /* control card. The control card type is first determined
and then processing continues as follows:
/*COMMAND Card -- The command is listed on the operator's console and then added to the Command Processor's
input command queue.
/*PRIORITY Card -- The previous job (if any) is terminated, the priority specified is converted to binary and
saved, and the scan is continued with the next card.
If the following card is not a JOB card, the message,
"device SKIPPING FOR JOB CARD", is written on the
operator's console, the effect of the /*PRIORITY Card
is nullified, and the input stream is scanned for
another /*PRIORITY or JOB card.
/*ROUTE Card -- The appropriate routing byte is set to
the value associated with the destination indicated.
If an invalid field is encountered, an appropriate message is issued, both to the .operator. and to the programmer,
and further job processing is bypassed.
Input Service Processor - Page 4.1-3
34
HAS P
/*SETUP Card -- The volumes to be mounted are listed on
the operator's console and the job is placed in "hold"
status.
/*MESSAGE Card -- Leading and trailing blanks are removed
and the message is routed to the operator's console.
If the control card type is not recognized, the card is ignored
and treated like any other /* card.
HASPRJCS--Subroutine to Scan and Initialize Job Control Information
The HASPRJCS subroutine, which is written as an overlay segment,
is called whenever the Main Processor Phase encounters a JOB card.
The previous job (if any) is terminated by calling the RJOBEND
subroutine. The master job number is incremented and its new
value is assigned to the current job. The job control information in the PCE Work Area (see figure 4.1.1) is initialized by
scanning the JOB card and extracting parameters relative to job
control. The first JCL block is initiated, and control is passed
to the Job Initialization Subroutine: HASPRJBI.
RSCAN - RSCANA -- Subroutine to Scan Parameters from JOB Card
This subroutine has two entry points; the entry point: "RSCAN"
is used to scan numeric parameters' from the JOB card, while the
entry point: "RSCANA" is used to scan alphameric parameters from
the JOB card. There are also two returns from the subroutine.
If return is made to the first byte following the Branch and Link
(the call) instruction, it indicates that the final parameter on
the JOB card was returned on the previous call and that there are
no more parameters.
If return is made to the fourth byte following the Branch and Link instruction, it indicates that parameter
register "RI" contains the next parameter, right-adjusted with
leading binary zeroes.
If the parameter was a "null" parameter,
"RI" will be zero.
If this subroutine detects an illegal character (such as a non-numeric character in a numeric field) or
more than four characters in a parameter, control is transferred
to the RBADJOBC subroutine.
RCONTNUE -- Subroutine to Validate Continuation Cards
This subroutine validates JCL continuation cards by ensuring
that columns I and 2 are punched with slashes and that column 3
is blank. The start of the continuation card is located and
Input Service Processor - Page 4.1-4
H. ASP
control is returned to the caller.
If an invalid continuation
card is discovered, control is passed to the illegal job card
subroutine for further processing.
REBCDBIN -- Subroutine to Convert from EBCDIC to Binary
This subroutine expects to find numeric EBCDIC characters with
leading binary zeroes in parameter register "RI". There are
two returns from the subroutine.
If return is made to the
first byte following the Branch and Link (the call) instruction,
it indicates that the parameter register now contains the binary
equivalent of the EBCDIC input.
If return is made to the fourth
byte following the Branch and Link instruction, it indicates
that the parameter register was zero (null parameter) and contained no EBCDIC to translate.
HASPRJBI -- Subroutine to Initialize Job Processing
This subroutine, which is written as an overlay segment, receives control from the JOB Card Scan Routine (HASPRJCS) and
completes the initialization of the various control blocks for
input job processing. A "job on" message is issued to the
operator, the job's priority is assigned based upon JOB card
or /*PRIORITY card parameters, and the job is queued in the
active input queue. Control is then returned to the Main Processor Phase.
RBADJOBC -- HASPRIJC -- Subroutine to Process Illegal Job Cards
This subroutine notifies the operator of an illegal JOB card,
calls the subroutine: "RJOBKILL" to delete the job, and returns
control to the Main Processor Phase.
RJOBEND -- Subroutine to Complete Job Input Processing
This subroutine tests whether the Input Processor is currently
processing a. job, and if it is not, returns control immediately.
The RJOBTERM subroutine is called to terminate the input processing of the job, and the job is queued for the Execution Control
Processor in the logical queue associated with the job's JOB
CLASS. Control is then returned to the calling program.
Input Service Processor - Page 4.1-5
36
HAS P
RGET -- Subroutine to Get Next Card from Input Buffer
This subroutine returns the address of the next card to be processed by the Input Service Processor in register "RPI".
If
the input buffer is empty or if all the cards in the input
buffer have been processed, an lOS read is staged from the input
device and the subroutine places the processor in a HASP $WAIT
state until the input buffer has been filled.
If the input
device is a remote terminal, a "call" is made on the Remote
Terminal Access Method to procure the next card.
If a permanent
error is detected on the input device, no action is taken until
after the last card has been processed and then the JOB currently
being processed is deleted with appropriate comments to the operator.
Processing then continues by scanning the input stream
for the next JOB card.
This subroutine also processes the operator commands n$STOP
input device" and "$DELETE input device" by entering the HASP
$WAIT state and calling the subroutine RJOBKILL to delete the
job, respectively.
There are two returns from the subroutine.
If return is made
to the first byte following the Branch and Link (the call) instruction, it indicates that the last card has been processed
and that an end-of-file has been ~ensed on the input device.
If return is made to the fourth byte following the Branch and
Link, it indicates that register "RPI" contains the address of
the next qard.
RPUT -- RPUTOLAY -- Subroutine to Add Card to Output Buffer
This subroutine accepts 80-byte card images and blocks them
into standard HASP Data Blocks (see section 8.15).
If the current output buffer is full, it is truncated and scheduled for
output, and a new HASP buffer is acquired and used as the next
output buffer.
If no output buffer exists upon entry, it indicates that the processor is skipping for a JOB card and the
subroutine returns without taking any action.
RJOBKILL -- Subroutine.to Delete Current Job
This subroutine tests whether the input processor is currently
processing a job, and if it is not, returns control immediately.
If a job is being processed, the operator is notified that the
job is being deleted, the RJOBTERM subroutine is called to terminate the input processing of the job, and the job is placed in
the Print Processor Queue for subsequent processing. Control i~
then returned to the calling program.
Input Service Processor - Page 4.1-6
37
HAS P
RJOBTERM-- Subroutine to Terminate Job
This subroutine terminates the last output buffer and schedules
it for output. It then acquires a HASP buffer, and from information kept in the PCE Work Area (see figure 4.1.1) constructs
the Job Control Table (JCT) and schedules it for output. Control is then returned to the calling program.
RGETBUF -- Subroutine to Initialize Output Buffers
This subroutine acquires a HASP buffer for an output buffer and
returns with the address of the buffer in register "Rl".
NON-PROCESS EXITS
The following routines are used to put the Input Service Processor in a HASP $WAIT state if a HASP resource is not available.
In all cases Reader Link Register 2 ("RL2") must have been set
to the ,restart address before the routine is entered.
RNOUNIT -- A HASP Unit was not available.
RNOCMB
A HASP Console Message Buffer was not available.
RNOJOB
The HASP Job Queue was full and a new entry
could not be added.
When the respective resource is available, the processor is
$POSTed and another attempt is made to acquire the resource.
Input Service Processor - Page 4.1-7
38
HAS P
Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT
Displacement
Hex.
Dec.
--
--
58
88
r-----------------------
92
96
I
Address of Input Device Control Table
RDADCT
RDRSW
60
----------------~-------1
RDRDCT
RCARDID
5C
4 bytes
I
Address of Direct-Access OCT
RBI END
Address of Last Card in Input Buffer
64
100
RBONEXT
Address of Next Card in Output Buffer
68
104
RBOEND
Address of End of Output Buffer
6C
108
RLSAVEl
Link Register Save Word 1
70
112
RLSAVE2
Link Register Save Word 2
74
116
RLSAVE3
Link Register Save Word 3
78
120
RSAVE:L
General Purpose Save Word 1
7C
124
RSAVE2
General Purpose Save Word 2
80
128
Input Service Processor - Paqe 4.1-8
39
HAS P
Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FO~T (CONTINUED)
Displacement
Hex.
Dec.
80
128
r-----------------------
4 bytes
------------------------1
RJCLTRAK
Track Address of Next JCL Block
84
RME$SAGE
132
........
B8
184
B8
184
Reader Message Area
1
RJOB
RQUEPRI
BC
188
192
Address of Job Queue Element
RQUETYPE
RQUEFLAG
Job Queue
Flags
co
r
RQUEJOBN
Job Number
RDRDLM
RESERVED
I.nput Data Set De11.miter
RQUETRK
Track Address of Job Control Table
I
C4
196
RQUEPRTR
Print Route
C8
RQUEFORM
Punch Route
RQUECLAS
-I
Print/Punch
Forms
200
Input Service Processor - Page 4.1-9
40
HAS P
Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex.
Dec.
~-----------------------
4 bytes
------------------------.,
I
C8
200
I
RJCTJOBN
Job Number (Binary)
CC
204
RJCTPRIO
RJCTROUT
Priority
Input
Route Code
RJCTJOBE
RJCTPNAL
Job Number (EBCDIC)
DO
208
programmer's
Name Length
RJCTPNAM
Programmer's Name from Job Card
.........
....
'"
t:il
H
IJ:l
~
E4
228
~
RJCTJNAM
H
0
~
~
Job Name from Job Card
-
Z
0
U
IJ:l
0
~
>t
EC
236
~~
RJCTACTN
a
Job Accounting Number
FO
240
RJCTROOM
Programmer's Room Number
F4
244
RJCTETIM
Estimated Execution Time
F8
248
RJCTCARD
Current Input Card Count
FC
252
Input Service Processor - Page 4.1-10
41
HAS P
Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex.
Dec.
FC
252
~-----------------------
4 bytes
------------------------~
RJCTESTL
Estimated Lines of Output
100
256
RJCTESTP
Estimated Number of Cards to be Punched
104
108
260
264'
RJCTLOG
RJCTLINC
RJCTCPYC
Lines
Per Page
Print
Copy Count
Log Option
Switch
RJCTDDCT
RJCTFLAG
RJCTFORM
Job Print Forms
lDC
268
Job Punch Forms
110
272
RJCTRDRO
Reader Sign-On Time
114
276
RJCTRDRT
Track Address of First JCL Block
118
280
RJCTCYMX
Maximum MTTR for Current Track Group
llC
284
RJCTMTTR
Last MTTR Allocated
120
288
Input Service Processor - Page 4.1-11
42
HAS P
Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED)
Displacement ~_______________________ 4 bytes
Hex.
Dec.
120
288
I
1
------------------------~
RJCTCYMA
Variable Length Track Allocation Map
I
L-______________
~------
________________________________
1
1
Jl
~
1
RTPCARD
I
r'-------------..IJ
aD-Byte Remote Job Entry Input Card Image Area
Input Service Processor - Page 4.1-12
43
HAS P
Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex. Dec.
58
88
Field Name
Bytes
RCARDID
1
Field Description
Type of card being processed -Hex.
Value
Meaning
00
03
04
13
Normal Card.
Internally Generated Card.
HASP Control Card.
Illegal Control Card.
Last JCL Card.
Dummy Track Address Record.
19
73
58
88
RDRDCT
4
Address of Reader, Tape, Internal
Reader, or Remote Device Control Table.
5C
92
RDRSW
1
Reader Switches -Bit
o
Name
Meaning
1
RJOBQUED Job has been Queued.
RSYSINSW Processing Internally Gener-
2
RXBJOBSW Processing XEQ Batch Class
3
4
5
ROSINSW
RJCLSW
RDREOFSW
RNOSCAN
RJFLUSH
ated DO
6
7
*
Card.
Job.
Processing O/S Input Data Set.
Processing JCL.
End of File Indication.
Not Scanning JCL (DO DATA) •
Job Flush Message has not
been issued.
SC
92
RDADCT
60
96
RBI END
4
Address of Last Card in Input Buffer.
64
100
RBONEXT
4
Address of Next Card in Output Buffer.
68
104
RBOEND
4
Address of End of Output Buffer.
6C
108
RLSAVEl
4
Link Register Save Word 1.
70
112
RLSAVE2
4
Link Register Save Word 2.
74
116
RLSAVE3
4
Link Register Save Word 3.
Address of Direct-Access Device Control
'fable.
Input Service Processor - Page 4.1-13
44
HAS P
Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
78
120
RSAVEl
4
General Purpose Save Word 1.
7C
124
RSAVE2
4
General Purpose Save Word 2.
80
128
RJCLTRAK
4
Track Address of Next JCL Block.
84
132
RMESSAGE
52
B8
184
RJOB
4
Address of Job Queue Element
(when Job has been Queued) •
B8
184
RQUEPRI
1
Job Queue Priority (Before Queueing)
Bits 0-3
Bits 4-7
Reader Message Area.
Priority (0-15).
Zero.
B9
185
RQUETYPE
1
Job Class - X'80' (Before Queueing).
BA
186
RQUEJOBN
2
Job Number (Before Queueing) •
BC
188
RQUEFLAG
1
Job Queue Flags
Bits
o
Name
Meaning
QUEHOLDl Job Held:
TYPRUN=HOLD
or Input Device Held.
Reserved.
1-7
1
Reserved.
RDRDLM
2
Input Data Set Delimiter
192
RQUETRK
4
Track Address of Job Control Table.
C4
196
RQUEPRTR
1
Print Routing:
0 = Local.
n = Remote n.
C5
197
1
Punch Routing:
0 = Local.
n = Remote n.
C6
198
RQUECLAS
1
Job Class - X'80'
C6
198
RQUEFORM
2
Job Print Forms
C8
200
RJCTJOBN
2
Job Number (Binary) •
CA
202
RJCTPRIO
1
Priority from /*PRIORITY Card.
BD
189
BE
190
co
(After Queueing).
(Before Queueing) •
Input Service Processor - Page 4.1-14
45
HAS P
' ' 1'T-1 -T"TTT14''n
, "'................
.. _--,,
I
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
CB
203
RJCTROUT
1
Input Route Code:
CC
204
RJCTJOBE
3
Job Number (EBCDIC).
CF
207
RJCTPNAL
1
Programmer's Name Length.
DO
208
RJCTPNAM
20
E4
228
RJCTJNAM
8
Job Name from Job Card.
EC
236
RJCTACTN
4
Job Accounting Number.
FO
240
RJCTROOM
4
Programmer's Room Number.
F4
244
RJCTETIM
4
Estimated Execution Time.
F8
248
RJCTCARD
4
Current Input Card Count.
FC
252
RJCTESTL
4
Estimated Lines of Output.
100
256
RJCTESTP
4
Estimated Number of Cards to be Punched.
104
260
RJCTLINC
1
Lines per Page.
105
261
RJCTCPYC
1
Number of Copies of Print.
106
262
RJCTLOG
1
Log Option Switch.
107
263
RJCTDDCT
1
Count of Input Data Sets SPOOLed by HASP.
107
263
RJCTFLAG
1
JCT Flags.
108
264
RJCTFORM
4
Job Print Fonns.
10C
268
4
Job Punch Forms.
110
272
RJCTRDRO
4
Reader Sign-On Time.
114
276
RJCTRDRT
4
Track Address of First JCL Block.
118
280
RJCTCYMX
4
Maximum MTTR for Current Track Group.
11C
284
RJCTMTIR
4
Last MTTR Allocated.
0 = Local.
n = Remote n.
Programmer's Name from Job Card.
Input Service Processor - Page 4.1-15
46
HAS P
Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex. Dec.
120
288
Field Name
Bytes
RJCTCYMA
RTPCARD
Field Description
Variable Length Track Allocation Map.
80
Remote Job Entry Input Card Image Area.
Input Service Processor - Page 4.1-16
A7
HASP
4.2 EXECUTION CONTROL PROCESSOR
4.2.1 Execution Control Processor -
General Description
The Execution Control Processor is responsible for the interface
between HASP and OS/360.
It presents jobs to the Operating System
for execution and communicates with the I/O supervisor to supply SYSIN
data for a job and to accept SYSPRINT and SYSPUNCH from a job for
later printing and punching.
This Processor is re-enterably coded and has the capability to
present any number of jobs to OS/360 for simultaneous execution by
maintaining unique INPUT/OUTPUT streams for each job. All storage
un"ique to a job is retained in the Processor Control Element (see
Figure 4.2.2) to provide re-enterability.
The Execution Control Processor is also responsible for monitoring
job limit excessions (such as time, line, or punched card estimates).
Jobs are selected for OS processing based on a logical partition structure
defined by HASPGEN. Each logical partition is controlled by a partition
information table (PIT) which indicates the eligibility of jobs for
execution by that logical partition. There is a direct correlation between
the HASP logical partition and the number of initiators active in the
system. Jobs thus selected for 08 processing are passed to a single
08/360 Reader/Interpreter which remains constantly STARTed to a
Execution Control Processor -
48
Page 4.2-1
HASP
HASP pseudo device which appears
a 2540 card reader.
ClS
Only the
Job Control Language statements of a job are passed to the R/I.
Input stream data sets
I
*
defined by DD
or DD DATA cards have been
previously transcribed to a SPOOL disk by the HASP input service
processor.
The JCL for a job is dynamically modified by HASP to
assign pseudo unit record devices to all SYSIN and SYSOUT data sets
to permit interception by HASP.
The job is interpreted by the R/I and
is placed in the OS job queue for immediate selection by an initiator.
At the completion of a job t s execution
I
it is placed in the OS SYSOUT
queue to be processed by an output writer.
Because of the assignment
of pseudo unit record devices to all SYSOUT files
I
the output
writer is required only to "print" the System Message Blocks from
SYSI SYSJOBQE.
These 5MB· s are intercepted by HASP and are stored
0
on the SPOOL disks as another print data set.
last 5MB
I
HASP terminates the XEQ phase
After receiving the
queues the job for the
I
HASP output processors and indicates that the logical partition requires
another job. All information concerning SYSIN and SYSOUT files
assigned to HASP pseudo devices is kept in Data Definition Table s
(DDT).
There is a DDT for each active file of a job which indicates
buffer addresses
I
file status
I
record count
I
etc. and is correlated with
the proper file through the HASP pseudo device address.
Execution Control Processor -
49
Page 4.2-2
HASP
4.2.2 Execution Control Processor -
Program Logic
The Execution Control Processor (XEQ) consists of the three
following logical phases:
PHASE 1
Job Control -
PHASE 2
Asynchronous I/O Handler -
Initiates and terminates job processing.
Interfaces with OS/360
via the Input/Output Supervisor (lOS) to perform
SYSIN/SYSPRINT/SYSPUNCH I/O requests.
PHASE 3 -
Synchronous I/O Handler -
Performs the SPOOL I/O
required by Phase 2.
_Figure 4.2. 1 indicates the relationship between these three phases and
OS/360.
An
as
execution is initiated by Phase 1 by obtaining a suitable job
from the HASP job queue and reading its Job Control Table from disk.
Job
limit parameters are initialized and the status of the OS/360 R/I is interrogated.
If the R/I is currently processing the input for another job, Phase 1
$WAITs until it has completed. A DDT describing the JCL file for the selected job is constructed and associated with the HASP pseudo 2540 used by
the R/I.
The dormant R/I is then POSTed to signal the availability of
Execution Control Processor -
50
Page 4.2-3
HASP
a job and control is trans ferred to Phase 3 to await I/O requirements
from Phase 2.
The OS/360 Supervisor call table has been modified by
HASP initialization so that all I/O requests are diverted to Phase 2 of
the XEQ processor ~
HASP pseudo device
If the I/O request thusly intercepted refers to a
I
it is processed by HASP; otherwise it is passed
to the Operating System Input-Output Supervisor for normal processing.
Since XEQ has the capability to control the simultaneous execution of
many jobs
I
the PCE for the job issuing the I/O request to a pseudo
device must be identifiable.
This is done by using a combination of
the JOB name and the TCB address (Job Step TCB for MVT).
PCE is located
I
Once the
the DDT for this particular pseudo device is found by
the pseudo device address from the UCB.
Phase 2 verifies that there
is a buffer still associated with the file and simulates the I/O request.
Each channel command word in the request is examined and
data select type is recognized
I
I
when a
the I/O operation is simulated by a
MOVE CHARACTERS to or from the current HASP buffer for that file.
Input requests are serviced by stripping (deblocking) the next card image
from the HASP
buffer and moving it as indicated by the CCW.
These
moves (only) are done while operating under the requesting program's
protect key to prevent an undetected protect violation by HASP
normally operates under protect key zero.
I
which
Requirements for I/O
Execution Control Processor -
51
Page 4.2-4
HASP
activities associated with Phase 2 processing are indicated by a series
of status bits in each DDT.
Requests to get buffers, read buffers and
write buffers, are indicated in the appropriate DDT, Phase 3 of the
XEQ processor is $POSTed and the HASP task is POSTed.
If the re-
quested activity must be completed before an I/O request can be
satisfied by Phase 2, the l/C requestor is made to WAIT.
by saving the current CCW location and using the
hold the requestor.
as
This is done
WAIT routine to
When the required I/O activity is complete, the
WAITing task is POSTed and the pseudo device I/O request is re-issued.
At the end of all successful I/O operations, the appropriate user
appendage (channel-end appendage, etc.) is entered, the I/O is
POSTed complete if required and a CSW is constructed to indicate the
normal I/O completion.
When Phase 3 of the Execution Processor is entered after initiation
of the job it immediately enters a HASP
from Phase 2.
$WAIT state to await direction
Upon being activated via a $POST from Phase 2 or by
a timer interrupt, this PHASE examines various status bits in the PCE
and DDT's to determine the required action.
This action may be either
the priming of an input buffer, writing and re-initialization of an output
buffer, or the notification to the operator of expiration of the estimated
time of the job. An input buffer is primed by obtaining the track address
Execution Control Processor -
52
Page 4.2- 5
HASP
of the next buffer from the current buffer and issuing a read for the record.
Status bits are set in the DDT to indicate that a read is in progress on
this buffer and are reset at channel end time to indicate that the record
is available. A full output buffer from Phase 2 is scheduled for transcription to disk and a new buffer is immediately obtained and initialized
for use. When the buffer is initialized a track address is acquired and
inserted as a forward chain in the buffer to be written.
for any reason unable to get a HASP buffer
Buffer-roll is invoked.
I
If Phase 3 is
a special service called
The function of Buffer-roll is to make a HASP
buffer currently being utilized by another file (in this or another job)
available to the requestor.
This is done by selecting a low frequency
. DDT which owns a buffer and forcing a
primary or secondary input buffer
I
II
free
II
of that buffer.
To free a
a switch is set in the DDT to force
a re-read of the buffer when the input file is next required.
Output
buffers are freed by terminating and writing the buffer to the SPOOL
disk.
Future references to this output file will cause a new buffer to
be obtained and chained to the partial bu ffer •
A count of the number of logical records contained in each output
buffer is maintained by the Phase 2 routine and is used by Phase 3
upon writing a buffer to maintain the total line and card count for this
job.
This accumulated figure is also compared
I
after each write
I
to
Execution Control Proces sor -
53
Page ,4.2 - 6
HASP
the estimated number of output records with the operator being notified
on its exces sion • If a job exceeds either cards, lines, or time, the
operator is so advised and a HASPGEN value is added to the original
estimate which will cause repeated excession messages as this new
estimate is reached.
The job continues through normal OS/360
processing until the end of execution is reached. The job, as part
of normal 08 job termination, is then placed in the OS 8Y80UT queue
for processing by an output writer.
Because of the dynamic modification
of all SYSOUT= cards to pseudo devices, the only data set to be
processed by the output writer is that contqining the System Message
Blocks.
The Output Writer therefore
II
prints
II
the
8MB's to a HASP pseudo device. When the last 5MB is received, Phase
3 is notified (via an OS POST) to return control to Phase 1 for HASP job
termina tion •
The job termination section of Phase 1 must now prepare the job
for passage to the print queue.
First, all partially filled output buffers
are truncated and written out, and all input bu ffers are freed.
The
timer interval for the job is cancelled and all job execution statistics
are added to the JCT. At this point the areas of the SPOOL disks used
to store the job input information are made available to be re-allocated
by HASP (Purged)
I
the JCT is written to disk and the job is passed to
Execution Control Processor -
54
Page 4.2-7
HASP
the print queue for printing.
If no priority card was present
I
the job
priority is recalculated as a function of the number of lines of print
generated before the job is placed in the print queue.
A branch is then made to the beginning of XEQ to begin another
job if available
I
or to display a message indicating that the logical
partition is idle.
The process of dynamic examination and modification of selected
JCL statements is accomplished by invoking the standard
as
Reader/
Interpreter exit list option which allows users to inspect all TCL encoded by the reader. A detailed discussion of the HASP processing
algorithm is contained in Appendix 12.8: HASP JCL Processing.
Execution Control Processor -
55
Page 4.2-8
HAS P
Figure 4.2.1 -- Execution Control - OS/360 Relationship
HASP JCL
PROCESSOR
(XJCLSCAN)
HASP
TASK
\
L----.,.._---'
\
\
\~
R/I
EXIT
LIST
POINTER
\~
\~
\
\
\
\
\
XEQ JOB
CONTROL
(PHASE 1)
\
\
START
OS/360
R/I
\ VIA PO T TASK
\~
~----------~
\~
\
\
$WAIT
~
\ 0
\~
\ ../
I/O REQUESTS
VIA lOS
\
\
\ r----...I.---"-'
SYNCHRONOUS
I/O
PROCESSOR
(PHASE 3)
$POST
ASYNCHRONOUS
I/O
PROCESSOR
(PHASE 2)
Execution Control Processor - Page 4.2-9
56
HAS P
Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT
Displacement ~_______________________ 4 bytes ________________________ . .
Hex.
Dec.
58
88
I
XPCEECB
Job Synchronization Event Control Block Chain
5C
92
XPCEJST
Address of User Task Control Block
60
96
XPCEJOB
Address of Job Queue Entry
64
100
XPCEWAIT
Reader Unit Allocation Event Control Block
68
104
XPCEJOBN
Job Name
I-
70
XPCEDCT
112
XPCESTAT
74
-
Address of Direct-Access OCT
I
XPCEDDB
116
Start of Data Definition Table Chain
78
XPCESTEP
120
-
80
. Step Name
-
128
Execution Control Processor - Page 4.2-·10
57
HAS P
Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex.
Dec.
80
128
~-----------------------
-
88
136
4 bytes
------------------------~
Procedure step Name
-
XPCEPRT
Current Output Line Count
8C
140
Estimated Lines of Output
90
144
Line Estimate Excession Amount
94
148
EBCDIC Constant -- "LINE"
98
152
XPCEPUN
Current Output Card Count
9C
156
Estimated Punched Cards
AO
160
Card Estimate Excession Amount
A4
164
EBCDIC Constant -- "CARD"
A8
168
Execut£on Control Processor - Page 4.2-11
58
HAS P
Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex.
Dec.
A8
168
~-----------------------
4 bytes
------------------------~
XPCEPIT
Address of Partition Information Table
AC
172
XSTQE
-
I-
Execution Timer Queue Element
-
t-
B8
184
XXSTIME
Time Estimate Excession Amount
BC
188
XPCEJSIB
Address of User JSTCB (MVT) or PIB (MFT)
CO
192
Execution Control Processor - Page 4.2-12
59
"
HAS
P
Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
58
88
XPCEECB
4
Job Synchronization Event Control Block
Chain.
5C
92
XPCEJST
4
Address of User Task Control Block.
60
96
XPCEJOB
4
Address of Job Queue Entry.
64
100
XPCEWAIT
4
Reader Unit Allocation Event Control Block.
68
104
XPCEJOBN
8
Job Name.
70
112
XPCESTAT
1
Status
Name
Bit
0-1
4
5
XPOSTBIT
XRDRACT
XEOJMES
XDUPBIT
6
XUCBDDB
7
XEOJBIT
2
3
Meaning
Reserved.
POST Request for XTHAW.
Reserved.
End Execution Message Sent.
Job with Duplicate Job Name
Waiting.
UCB/DDT Required by
Execution Interface.
End of Job Flag.
70
112
XPCEDCT
4
Address of Direct-Access DCT.
74
116
XPCEDDB
4
Start of Data Definition Table Chain.
78
120
XPCESTEP
8
Step Name.
80
128
8
Procedure Step Name.
88
136
4
Current Output Line Count.
8C
140
4
Estimated Lines of Output.
90
144
4
Line Estimate Excession Amount.
94
148
4
EBCDIC Constant --
98
152
4
Current Output Card Count.
9C
156
4
Estimated Punched Cards.
XPCEPRT
XPCEPLN
"LINE".
Execution Control Processor - Page 4.2-13
60
HAS P
Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT (CONTINUED)
Dis12lacement
Hex. Dec.
Field Name
B;ttes
Field DescriEtion
AO
160
4
Card Estimate Excession Amount.
A4
164
4
EBCDIC Constant --
A8
168
XPCEPIT
4
Address of Partition Information Table.
AC
172
XSTQE
B8
184
XXSTIME
4
Time Estimate Excession Amount.
BC
188
XPCEJSIB
4
MVT
MFT
12
"CARD".
Execution Timer Queue Element.
Address of Job Step Task Control Block.
Address of Partition Information Block.
Execution Control Processor - Page 4.2-14
61
HAS P
4.3
OUTPUT SERVICE PROCESSOR (PRINT AND PUNCH)
4.3.1
OUTPUT SERVICE PROCESSOR - GENERAL DESCRIPTION
The functions of the Output Service Processor are as follows:
To convert the print and punch output generated by the
Execution Control Processor to hard copy.
To provide for the unique identification of both print
and punch output to facilitate collection and delivery.
To provide for the routing of special data sets to printers
and punches reserved for special fOrms processing.
To produce multiple copies of print output upon request.
To count print lines and produce automatic page overflow.
To translate all illegal print characters to blanks (optional) •
To load the Universal Character Set Buffer (optional).
To load the Forms Control Buffer (optional).
To provide additional information for checkpoint which
allows print to continue in the event of a "warm start".
'To punch a Job Accounting Card (optional).
To process all printer and punch I/O errors with automatic
error recovery (no operator intervention).
To respond to all operator commands directed toward any
printer or punch.
To queue jobs for the next stage of processing when the
current print/punch function has been completed.
The Output Service Processor is coded re-enterably in such a
way that it can deliver output to a number of different output
devices simultaneously. The re-enterability is attained by
retaining all storage unique to a job in the Processor Control
Element (see figure 4.3.1) which must be unique for each output
device.
Output Service Processor - Page 4.3-1
62
HAS P
4.3.2
OUTPUT SERVICE PROCESSOR - PROGRAM LOGIC
The Output Service Processor is divided into three phases,
nine subroutines, and two non-process exits.
This section
will give a functional description of each of these phases,
subroutines, and exits to aid the system programmer in gaining
a working knowledge of the processor.
PHASES
Phase 1 -- Processor Initialization
The Initialization Phase begins by attempting to get an output unit.
If an output unit is not available, the processor
enters a HASP $WAIT state until a device is made available
and ,then the process is repeated.
Next, an output function is determined.
If the device acquired is a remote printer, the appropriate entry in the
Remote Message Table is examined to determine if any remote
messages have been queued, and if so processing continues.
The general purpose register:
"JCT" is set to zero to indicate that remote messages are being processed.
If the device is not a remote printer, or if there are no
messages queued, an attempt is made to obtain a job from the
Job Queue which matches the type, routing and special forms
of ' the device obtained.
If no jobs are queued which fit these
qualifications, the special forms processing type is checked
to see if the forms requirement can be dropped.
If so, another
attempt is made to obtain a job from the Job Queue which
matches the type and routing specifications only.
If a job cannot be found, then the output unit is released
and control is returned to the start of the Initialization
Phase.
If the output device is a remote terminal, output activity is
initiated by calling upon the Remote Terminal Access Method
(RTAM) to "open" the Remote Device Control Table.
The processor then acquires a direct-access Device Control
Table (OCT) and a HASP buffer into which the Job Control
Table (JCT) is then read. A message is sent to the operator
notifying him that a particular job is now on the respective
device and the initialization of the Processor Control Element
Work Area (see figure 4.3.l) is completed.
Output Service Processor - Page 4.3-2
63
HAS P
If the processor is processing prin~ output, and if the output:
is not a, data set which has been routed for special forms, .
the PRINTID subroutine is called to generate the print identi-~
fication header and control is 'transferred to Phase 2.
If the processor is processing punch output, and if the output
is not a dat'a set which has been 'routed for special forms,
the Punch ID Card is generated for later punching, and control
is transferred to Phase 2.
Phase 2 - Main Processor
The function of the Main Processor is to read the data blocks
which are produced by the Execution Control Processor and build
a channel program to print or punch the data. The PRDBUF and
PRDCHK subroutines are used to read the data blocks, thePPPUT
subroutine is used to construct the channel program and the
PPWRITE and PPCHECK subroutines are used to initiate and check
the execution of the channel program.
If the processor is processing print output, the "Control
Byte" fields of the' Data Block (see figure 8.15.1) are used
to build the CCW operation codes.' These control bytes are
also used to count the actual lines of paper spaced and when
:this line count exceeds the parameter JCTLINCT, an eject is
inserted to force a new page and the count is restarted.
If
an illegal control byte is encountered, or if the operator
has entered a n$T PRTn,C=l" command, a single-space CCW is
generated and used rather than the one provided in the data
block.
In such cases line counting continues and automatic
page overflow is still provided.
If the processor is processing punch output, a "Punch, Feed,
and Select Stacker P2" command is generated.
When the last data block has been printed or punched, control
is transferred to Phase 3.
Phase 3 - Processor Termination
The Processor Termination Phase first reads the Job Control
Table and scans the Peripheral Data Description Blocks (see
figure 8.8.1) for the next data set to be processed.
If
~nother data set is encountered, control is returned to Phase
2 for processing.
If no more data sets are to be processed,
the termination phase then proceeds depending upon the type of
output which is being processed.
Output Service Processor - Page 4.3-3
64
HAS. P
If the processor is processing print output, the "PrintCoP¥'
Count" field in the JCT (see figure 8. 8.1) is compared Vii tq .;
the current number of copies which have been printed.
If
more copies are" needed, control is transferred, to Phase 1 fOJ:" $
the production of another copy.
If no more copies are required,'
the PRINTID subroutine is called to generate the print idcintification trailer.
If the processor is processing punch output, the job acc6unting
subroutine is called, and the accounting-card is punched followed by a blank card to clear the punch and check the punching
of the Job Accounting Card.
The Job Control Table is then re-written, the Job Queue Element
is passed to the next proce~sor queue, the Device Control
Tables are released, and control is transferred to the start
of Phase 1.
SUBROUTINES
PLOADUCS -- Subroutine to Load the UCSBand FCB
This subroutine determines the Universal Character Set Type
from the Printer Device Control Table. The UCSB Table is then
searched and the corresponding ues image (if one is found) is
$LOADed and moved into a HASP buffer. The UCS Buffer is then
loaded using the PPPUT, PPWRITE, and PPCHECK subroutines.
If the output device type specifies a 3211 printer, then the'
Forms Control Buffer is loaded in a manner similar to the UC~
Buffer~
After loading the FCB, the FCB type is reset so that
no more FCB loads will occur until the operator specifies that
the buffer should be re-loaded.
PRINTID -- Subroutine to Generate Print Identification
This subroutine builds up the line image which is used to produce the Print Identification ~age from information in the Job
Control Table and information passed to the subroutine at the
time it is called. This line image is built up in the "Job
Accounting Storage" section of the Job Control, Table (see figure 8.8.1). The subroutine then builds a channel program
which starts with an eject command and follows with enough
print commands to completely fill a page with print identification lin~s. The channel program is then executed and checked
and contrpl is returned to the calling program. The PPPUT
subroutin~ is used to construct the channel program, and the
PPWRITE arid PPCHECK subroutines are used to initiate and check
the ~xecution of the channel program.
Output Service Processor - Page 4.3-4
65
HAS P
PPFORMCK -- Subroutine to Mount Forms
This subroutine compares the forms being requested with the
forms currently mounted on the associated device.
If a match
is found, the subroutine returns immediately. Otherwise, a
forms mount message is issued to the operator and the subroutine $WAITs for a "$Sdevice" command to be entered. The
DCT Forms field is then set to reflect the new forms type and
processing continues.
PRCOMENT -- Subroutine to Add Comment to Printer Output
This subroutine constructs and adds to the printer output
(using the PPPUT, PPWRITE, and PPCHECK subroutines) a comment
of the form:
PRINT xxxxxxxxx BY OPERATOR.
"xxxxxxxxx" is specified at subroutine entry by parameter
register "RI" and will be one of the following:
DELETED
RESTARTED
REPEATED
BACKSPACED
FWD-SPACED
SUSPENDED
PRDBUF -- Subroutine to Initiate Read from Direct Access Storage
This subroutine initiates a read from the track address specified by register "PNP" into the appropriate HASP buffer.
PRDCHK -- Subroutine to Check Read from Direct Access Storage
This subroutine checks the read initiated by the PRDBUF subroutine.
If the read is not complete, the processor is placed
into a HASP $WAIT state until the read is completed.
If an
I/O error is detected, a "$IOERROR" macro-instruction is issued
and the processing of the rest of the data set is deleted.
This subroutine also checks for any operator command which
would cause the Main Processing Phase to be completed and forces
any indicated completion by zeroing the chain track in the data
block just read.
Output Service Processor - Page 4.3-5
66
HAS P
PPPUT -- PPUTOLAY -- Subroutine to Build a Channel Program
This subroutine accepts a CCW from the calling program and,
if the output device is not a remote terminal, constructs a
channel program in the Processor Control Element Work Area
(see figure 4.3.1). Each command is examined and if it is an
immediate printer space or skip, and if the previous command
was a "Write, No Space", the two conunands are combined into
one. When the channel program storage area is full, this subroutine calls the PPWRITE subroutine to initiate the execution
of the channel program. Upon the next entry, the execution
of the channel program is checked by calling the PPCHECK subroutine.
If the output device is a remote terminal, the Remote Terminal
Access Method is "called" to process the output line or card.
Control is then given to the PPCHECK subroutine to test for
operator commands.
PPWRITE--Subroutine to Initiate Execution of the Channel Program
If the output processor is being deleted by operator action,
this subroutine returns immediately. Otherwise a write is
initiated on the respective output device, using the channel
program developed by the PPPUT subroutine.
PPCHECK--Subroutine to Check the Execution of the Channel Program
This subroutine checks for the successful completion of the
channel program execution initIated by the PPWRITE subroutine.
If the execution has not yet completed, the subroutine enters
the processor into a $WAIT condition until the output has
been completed,.
If an unsuccessful completion is detected,
the subroutine performs the error recovery described in the
paragraph below. This subroutine also interprets all operator
commands directed at the processor and initiates appropriate
action.
NON-PROCESS ·EXITS
The following routines are used to place the Output Service
Processor into a HASP $WAIT state if a HASP resource is not
available.
In bot;h cases the non-process register ("PNP")
must have been set to the restart address before the routine
is entered.
Output Service Processor - Page 4.3-6
67
HAS P
PNOUNIT -- A HASP unit was not available.
PNOBUF -- A HASP buffer was not available.
When the respective resource is made available, the processor
is $POSTed and another attempt is made to acquire the resource.
PRINTER "WARM START" LOGIC
When the Output Service Processor is successful in acquiring a
job from the print queue, the print checkpoint area is searched
for an available Print Checkpoint Element (see figure 4.3.2).
This element is thereafter used to record the job number, copy
count, and line and page counts.
In the event of a "warm start", the elements are searched and
each Print Checkpoint element is moved into the Job Control
Table for the job which it represents.
When the job is printed, the JCT is examined, and if the Print
Checkpoint Element is present, the processor continues printing
from the point when the last checkpoint was taken.
OUTPUT PROCESSOR BUFFER LOGIC
The buffer logic that the output processor employs is determined
by the HASPGEN parameters: $PRTBOPT, $PUNBOPT, $RPRBOPT, and
$RPUBOPT.
Buffer Option
=
1
One buffer will be obtained at the beginning of output processing and will be used through the entire processing of a job's
output. A read for the following data block will not be initiated until the current data block has completed its output.
Periods of high Input/Output activity could cause the printers
and punches to operate at less than their maximum rate when
this option is used.
Buffer Option
=
2
Two buffers will be obtained at the beginning of output processing and will be used through the entire processing ofa
job's output. A read for ~he following data block will be
output Service Processor - Page 4.3-7
68
HAS P
initiated as soon as the previous data block has completed
its output and will be performed while the current data block
is completing its output. This option represents the most
efficient utilization of the output devices.
PRINT AND PUNCH ERROR RECOVERY
Print Errors
The operator will be informed of all printer errors, but they
will be ignored by the Output Service Processor.
Punch Errors
The card which causes a punch check and the card following
this card are selected automatically into the reject stacker.
The Output Service Processor will attempt to punch these two
cards correctly until no error occurs or the operator deletes
the job. Since all normal punch output is selected to another
stacker, no operator intervention will be required to clear
tpe punch. Every error will be recorded on the operator's
console.
Output Service Processor - Page 4.3-8
69
HAS P
Figure 4.3.1 -- OUTPUT SERVICE PCE WORK AREA FORMAT
Displacement
Hex.
!2!£.
58
88
r------------------------
92
I
PDADCT
PDCTFLAG
60
------------------------~
PDCT
PPFLAG
SC
4 bytes
96
PJOB
I
Address of Print/Punch/Remote OCT
Address of Direct-Access OCT
Address of Job Queue Entry
64
100
PRCHKPTE
PUERRPT
68
104
Address of Print Checkpoint Element
Address of Punch Error CCW
PTIMEON
Print/Punch Sign-On Time
6C
108
PBUFSAVE
Address of Next Print/Punch Buffer
70
112
PCCWPT
Address of Last Print/Punch CCW Set Up
74
116
PCCWEND
Address of Last Possible Print/Punch CCW
78
PMESSAGE
120
....
1~_________________p_r_~_n_t_/_p_u_n_c_h_M
__
e_ss_a_g_e__A_r_e_a________________
8C
....,
~J
140
Output Service Processor - Page 4.3-9
70
HAS P
Figure 4.3.1 -- OUTPUT SERVICE PCE WORK AREA FORMAT
Displacement
Hex.
Dec.
8C
140
~_______________________
4 bytes ________________________ ~
I
'
PDDBSKIP
Count of Pages to Skip
90
144
PDDBDISP
148
PPRCFLAG
PPRCPYCT
Checkpoint
Flags
Copy Count
PDDBPGCT
Current PooB Displacement
94
(CONTINU~)
Current PoDB Page
Coun~
PPLNCDCT
Current Line or Card Count
98
152
PRPAGECT
Current Page Count
9C
PDEVTYPE
156
P:SUFOPT
AO
I
Print/Punch Device Type
PLSAVE
160
Link Register Save Word
A4
164
PRLINE~T
Maximum Lines per Page
A8
PCCWCHN
168
........
1~___________
v_a_r_1_a_b_l_e_,_L_e_n_g_th
___
p_r_1n
__
t_/p_u_n_C_h__C_C_W
___
Ch__
a_1n____________
~r
Output Service Processor - Page 4.3-10
71
H. ASP
::Figure 4.3.1 -- OUTPUT SERVICE PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex. Dec.
58
88
Field Name
PPFLAG
Bytes
1
Field Description
Print/Punch Synchronization Flags -Bit
Name
a
3
PPWSW
PPDELSW
PPNOJOB
PRDELSW
4
PRRSTSW
5
PPRDERR
1
2
6-7
Meaning
Write has been Initiated.
Function has been Deleted.
No Job is Active.
Print was Deleted by
Operator.
Print was Restarted by
Operator.
Function Terminated by
Read Error.
Reserved for Future Use.
58
88
PDCT
4
Address of Print/Punch/Remote
Device Control Table.
5C
92
PDCTFLAG
1
Print/Punch/Remote Operator Commands -Bit
Name
a
DCTSTOP
DCTDELET
DCTRSTRT
DCTRPT
DCTBKSP
DCTSPACE
1
2
3
4
5
2+4
6-7
Meaning
$Z ($STOP) Command.
$C ($DELETE) Command.
$E ($RESTART) Command.
$N ($REPEAT) Command.
$B ($BACKSPACE) Command.
$T ... ,C=l Command.
$1 Command.
Reserved.
5C
92
PDADCT
4
Address of Direct-Access Device Control
Table.
60
96
PJOB
4
Address of Job Queue Entry.
64
100
PRCHKPTE
4
Print Only:
Address of Print Checkpoint
Element.
64
100
PUERRPT
4
Punch Only:
Address of Punch Error CCW.
68
104
PTIMEQ\J
... 4
6C
108
PBUFSAVE
4
Print/Punch Sign-On Time .
Address of Next Print/Punch Buffer.
Output Service Processor - Page 4.3-11
72
HAS P
Figure 4.3.1 -- OUTPUT SERVICE PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
70
112
PCCWPT
4
Address of Last Print/Punch CCW Set Up.
74
116
PCCWEND
4
Address of Last possible Print/Punch CCW.
78
120
PMESSAGE
20
8C
140
PDDBSKIP
2
Count of Pages to Skip.
8E
142
PPRCFLAG
1
Checkpoint Flags --
Print/Punch Message Area.
Bit
o
1
Name
Meaning
PRCHKUSE Checkpoint Element Assigned.
PRCHKJOB Job Active Indication.
Reserved.
2-7
8F
143
PPRCPYCT
1
Current Copy Count.
90
144
PDDBDISP
2
Current PDDB Displacement.
92
146
PDDBPGCT
2
Current PDDB Page Count.
94
148
PPLNCDCT
4
CUrrent Line or Card Count.
98
152
PRPAGECT
4
Current Page Count.
9C
156
PBUFOPT
1
Buffering Option
Value
1
2
Meaning
Single Buffering.
Double Buffering.
9C
156
PDEVTYPE
4
Device Type from UCB (UCBTYP).
AO
160
PLSAVE
4
Link Register Save Word.
A4
164
PRLINECT
4
Maximum Lines per Page.
A8
168
PCCWCHN
Variable Length Print/Punch CCW Chain.
output Service Processor - Page 4.3-12
73
HAS P
Figure 4.3.2 -- PRINT CHECKPOINT ELEMENT FORMAT
,Displacement
~. Dec.
o
0
l.----------------------I
4 bytes
PRCJOBNO
Checkpoint Job Number
4
4
PRCPDDBD
8
PRCFLAGS
PRCCPYCT
Checkpoint
Flags
Checkpoint
Copy Count
PRCPDDBP
Checkpoint PDDB Displacement
8
------------------------J
.I
Checkpoint PDDB Page Count
PRLINCT
Checkpoint Total Line Count
C
12
PRPAGCT
Checkpoint Total Page Count
10
16
output Service Processor - Page 4.3-13
74
HAS P
Figure 4.3.2 -- PRINT CHECKPOINT ELEMENT FORMAT (CONTINUED)
Dis12lacement
Hex. Dec.
Field Name
B:i tes
Field Descri12tion
0
0
PRCJOBNO
2
Job Number.
2
2
PRCFLAGS
1
Checkpoint Flags
Bit
0
1
Name
Meaning
PRCHKUSE Checkpoint Element in Use.
PRCHKJOB Job Active Indication.
Reserved for Future Use.
2-7
3
3
PRCCPYCT
1
Current Copy Count.
4
4
PRCPDDBD
2
Current PDDB Displacement.
6
6
PRCPDDBP
2
Current PDDB Page Count.
8
8
PRLINCT
4
Total Line Count.
C
12
PRPAGCT
4
Total Page Count.
Output Service Processor - Page 4.3-14
75
4.4.1
PURGE PROCESSOR - GENERAL DESCRIPTION
The Purge processor frees the job's acquired HASP direct-access
space and removes the Job Queue Element from the system.
4.4.2
PURGE PROCESSOR - PROGRAM LOGIC
The processor first acquires a Job Queue Element and issues the
$ACTIVE macro to inform the HASP Dispatcher that the processor
is active. Then a direct-access Device Control Table (DCT) and
a HASP buffer are acquired and initialized so that the job's
Job Control Table (JCT) may be read into the buffer from the
SPOOL disk.
If a DCT or buffer is not available this processor
will be placed in a HASP $WAIT state until a DCT or buffer can
be acquired.
If no permanent I/O errors occur while reading
the JCT, a $PURGE macro instruction is then issued to return
the job's direct access tracks.
If a permanent I/O error occurs
while the JCT is being read, the DISASTROUS error routine is
called and the $PURGE macro instruction is not executed. Next,
the Job Queue Element is removed from the HASP Job Queue and
the following message is issued to the operator:
JOB xxx IS PURGED
Finally, the buffer and DCT are freed, and the $DORMANT macro
instruction is issued to indicate to the HASP Dispatcher that
the processor is inactive and control is returned to the start
of the routine for the processing of the next job to be purged.
Purge Processor- Page 4.4-1
76
HAS P
4.5
HASP COMMAND PROCESSOR
4.5.1
HASP Command Processor - General Description
The HASP Command Processor receives all HASP commands entered
from acceptable local or remote HASP input sources.
The Processor
is responsible for decoding each command and performing the processing necessary to cause appropriate action to the operator's
request.
4.5.2
HASP Command Processor - Program Logic
The HASP Command Processor is initially entered at the beginning
of the Control Section (CSECT) HASPCOMM which is a part of the
resident portion of HASP.
Subsequent re-entrles are returns from
the various command sub-processors with optional requests for the
displaying of the "OK" message or other message contained in the
COMMAND area of the PCE. After displaying any requested replies
the HASP Console Message Buffer queue $COMMQUE is examined for
the presence of the next command to process.
If no buffer is
queued, the Command Processor waits on WORK. When $POSTed or if
a buffer is present upon entry, the Command Edit Routine is
entered via $LINK macro.
Command Edit Routine - HASPCOME
VERB CONVERSION - The Command Edit. Routine converts the command
text from the long form to the standard single character verb form.
The data portion of the Console Message Buffer up to the first
comma (,) or apostrophe (') is made upper case and non-blank
characters are shifted to the left. The resulting text is compared
against arguments in the VERB CONVERSION TABLE.
If a match is
found, the corresponding standard form of the command is substituted.
COMMAND EDIT AND BREAK OUT - The information in the HASP Console
Message Buffer is moved to the COMMAND field in the PCE work area.
The two bytes CMBFLAGS and CMBCONS of the buffer are moved to the
COMFLAGS and COMROUTE fields of the PCE workarea.These two
bytes when combined with the two succeeding bytes in the PCE form
the list form of the $WTO used for all responses to the operator
from the Command Processor.
--The COMMAND area of the PCE is primed with blanks and the buffer
is scanned.
~olid characters are ORed (moved with upper casing)
into the COMMAND area.
Blanks encountered in the buffer will
HASP Command Processor - Page 4.5-1
77
HAS P
normally be skipped (blank elimination); however, if an apostrophe
vis encountered, blanks will not be skipped until the next apostrophe.
Double apostrophe characters will cause the blank compression status to remain as previously set; however, the second
apostrophe of the pair will be eliminated.
As each comma is encountered an entry of the next available
character position is,made in the COMPNTER area of the PCE.
(The
first entry is the address of the character after the verb.
The
second is the address of the second operand, etc.)
When the
COMPNTER area is full, recording is discontinued.
Upon completion
of the scan, the buffer is released, the COMNULOP field in the
PCE is set to the address of the second character beyond the last
solid character (null operand), and the operand pointers are
shifted down adjacent to the COMMULOP field (see Figures 4.5.1
to 4.5.3).
Control registers are set as follows:
WD
WE
WF
=
=
=
address of the first operand pointer in the COMPNTER field
4
address of the last operand pointer in the COMPNTER field
SELECTING THE COMMAND SUB-PROCESSOR - The SELECTION TABLE is used
to determine the appropriate command sub-processor which must be
entered.
Starting with the first element, the SELECTION TABLE is
scanned for a matching verb. When the verb is located, the first
character of the first operand is then used for comparing.
If a
match is found on the operand or if the table entry contains an
X'FF.' for operand argument, the table entry for the command is
considered "located".
If the end of the entries is encountered
for the verb or table, the command is considered invalid and the
edit routine returns to the main processor with INVALID COMMAND
message in the COMMAND area for display.
(See $COMTAB macro in
Section 4.5.4 for format of the SELECTION TABLE element.)
VALIDATING THE SOURCE AND ENTERING THE SUB-PROCESSOR - Each entry
of the SELECTION TABLE may have restriction indicators as follows:
COMRMT
COMS
=
=
COMO
=
COMJ
=
1 - Reject remote sources
1 - Reject consoles which are restricted from
entering SYSTEM COMMANDS
1 - Reject consoles which are restricted from
entering DEVICE COMMANDS
1 - Reject consoles which are restricted from
entering JOB COMMANDS
The restriction indicators correspond with the restriction indicators which appear in the COMFLAGS field.
The COMFLAGS indicator
is previously set from the CMBFLAGS field,of the HASP Console
Message Buffer which in turn is set by other HASP processors as
follows:
1.
CMBFLAGS when set by the remote console processor or
remote reader processors will contain the remote
indicator. This indicator corresponds to COMRMT bit
in the SELECTION TABLE.
HASP Command Processor - Page 4.5-2
78
HAS P
2.
3.
CMBFLAGS when set by the local console support routines
will contain the restriction flags assigned to the
Console Device Control Table.
(Restriction is the
opposite of authority which is set by the operator
command $TCONn,A=authority or by the system programmer.)
CMBFLAGS when set by the OS console interface is
the OS authority indicators inverted with the
Exclusive Or Immediate (XI) instruction.
The restriction indicators are used as the second operand of a
Test Under Mask (TM) instruction.
If any restriction indicator
in the COMFLAGS field corresponds to any restriction indicator
in the SELECTION table entry, the command is rejected as invalid.
Otherwise Register 1 is set with the value in the SELECTION TABLE
entry COMTOFF field and control is passed to the CSECT indicated
by the Overlay Constant ($OCON) field of the SELECTION TABLE
element via the $XCTL macro.
Command Sub-Processor Control Sections
The Entry routine of each command sub-processor control section
will, if applicable, use the offset value in register 1 (set by
the edit routine) to determine the "relative" entry point for the
designated sub-processor. Normally the sub-processor is entered
directly by the special Command Processor macro: "Branch
Re-lative Register" on Rl ($BRR Rl). However, some control section
entry routines will pre-process the operands of the command prior
to entering the sub-processor. Each sub-processor performs the
desired functions and returns to the main command processor for
the next command.
HASP Command Processor - Page 4.5-3
79
HAS P
4.5.3
HASP Command Processor Organization
The HASP Command Processor is created by a single assembly with
multiple Control Sections (CSECT).
The main CSECT HASPCOMM is
the only portion of the Command Processor that is part of the
HASP resident load module.
It contains all V type address
constants required by the sub-command processors and all "BASE2"
service routines. The Command Edit Routine HASPCOME receives
control from the main processor and determines which COMMAND
SUB-PROCESSOR CSECT to enter for processing of the command entered.
One or more of the various COMMAND SUB-PROCESSOR CSECTs are used
in processing each HASP operator command. Although the physical
CSECTs are organized in accordance with the size of the overlay
work area, the logical organizational grouping is as follows:
JOB QUEUE COMMANDS
JOB LIST COMMANDS
MISCELLANEOUS JOB COMMANDS
DEVICE LIST COMMANDS
SYSTEM COMMANDS
MISCELLANEOUS DISPLAY COMMANDS
REMOTE JOB ENTRY COMMANDS
HASP Command Processor Workarea
The HASP Command Processor PCE workarea shown in Figure 4.5.1 is
the primary workarea for the processor and is the only area which
may be used to save information in the event a $WAIT is issued by
the processor or any of the "BASEl" service routines on behalf of
the processor.
The fields are generally used as described in the
following paragraphs.
COMFLAGS to COMCLASS - This field contains a list form of the $WTO
macro. The $WTO is referred to by a single execute form of the
$WTO located within the resident portion of the Command Processor
which is used for all operator messages generated by any routine
within the processor. The CMBFLAGS and CMBCONSfields of the HASP
Console Message Buffer for each command is inserted into the
COMFLAGS and COMROUTE cells and are used to provide correct route
codes for replies. The three low order bits of COMFLAGS are
restriction indicators and are set to zero prior to each $WTO reply.
COMEWORK - This field is used as a workarea and by function routines
identified by the macro instructions as follows:
HASP Command Processor - Page 4.5-4
80
HAS P
macro
contents upon exit from routine
$CFCVE
$CFDCTL
$CFJDCT
$CFJMSG
last character is blank
first four characters of requested device name
address of HASP job queue element for requested job
same as $CFCVE
COMDWORK - This field is aligned on a double word boundary and is
used as a workarea and by function routines identified by the macro
instructions as follows:
macro
contents upon exit from routine
$CFCVE
$CFDCTL
$CFJMSG
five character number in EBCDIC with leading blanks
last four characters of requested device name
same as $CFCVE
COMMAND - This field contains the compressed form of the operator
cqmmand with trailing blanks at the time each command sub-processor
is entered. The command is overlayed by the reply message text for
all $WTO messages issued by any Command Processor routine.
Some
command sub-processors use the area as scratch areas and in some
cases the right end for storage of critical information while
message replies are generated in the left end of the area.
COMPNTER-COMNULOP - These fields are set by the Command Edit
Routine and are used to locate the beginning of each of the
specified operands in the command currently being processed.
COMNULOP contains a pointer to the second character beyond the
last operand specified, i.e., points to a non-existant or "null"
operand. Operand 1 through n pointers are right adjusted in
COMPNTER so that operand n pointer is adjacent to the "null"
pointer (see Figures 4.5.2 and 4.5.3 for illustrations). Command
sub-processors use these areas for additional workspace after the
operand pointers are no longer needed. Examples of other uses
are listed as follows-:
1.
2.
3.
Job queue command $DN and $DQ commands place queue
scanning control elements in the COMPNTER area.
Job list commands place the job range numbers (j-jj)
in the corresponding operand pointer element area.
$DR uses the right end of the COMMAND area and
COMPNTER-COMNULOP area to hold the reply ID numbers.
HASP Command Processor - Page 4.5-5
81
II ASP
Figure 4.5.1
Displacement
Hex.
Dec.
58
88
HASP COMMAND PCE WORK AREA FORMAT
r-----------------------COMFLAGS
4 bytes
COMROUTE
------------------------~
COMLNGTH
COMCLASS
List Form of $WTO
5C
92
COMEWORK
Function Work Area
60
COMDWORK
96
Function Work Area
~
68
104
COMMAND
COMVER:B
COMOPRND
Message Area
Command Verb
First Operand
-
-
.....
..... :--
EO
224
Command Text and Message Area
......
...... ,..
COMPNTER
Address of n-4 Operand
E4
228
Address of n-3 Operand
E8
232
Address of n-2 Operand
EC
236
HASP Command Processor - Page 4.5-6
82
HAS P
Figure 4.5.1 -- HASP COMMAND PCE WORK AREA FORMAT (CONTINUED)
Displacement
Hex.
Dec.
EC
236
~-----------------------
4 bytes
------------------------.j
Address of n-l Operand
FO
240
Address of n Operand
F4
244
COMNULOP
Address of n+l Operand
F8
248
HASP Command Processor - Page 4.5-7
83
HAS P
Figure 4.5.2
COMMAND - COMNULOP Areas With Single Operand Command
COMMAND- $PPRTlbb
COMPNTER
- - - -
Upon exit of Edit Routine,
Registers WD, WE and WF
are set for testing
instructions:
not used
not used
not used
not used
WD,WF
COMNULOP
-+
- - - -
Figure 4.5.3
operand It t-null
BXLE WD,WE,loop
(for next operand)
BXH WD,WE,exit
(if no more)
t
COMPNTER -COMNULOP Areas With Five Operand Commands
COMMAND - $PPRTl,PRT2,PUNl,RDRl,RD2bb
COMPNTER - WD
-+
operand It
operand 2t
operand 3 t
operand 4t
WF
COMNULOP
NOTE:
-+
operand 5t
null
t
Upon exit of Edit Routine,
Registers WD,WE and WF
are set for testing
instructions:
b = blank character
BXLE WD,WE,loop
(for next operand)
BXH WD,WE,exit
(if no more)
HASP Command Processor - Page 4.5-8
84
HAS P
Coding Conventions
The symbols with the command processor conform to the following
conventions:
1.
All main processor, Edit Routine, and PCE workarea symbols
start with the characters "COM".
2.
All Function macro generated symbols start with "COF".
3.
All command sub-processors have entry point symbols
of the following form:
form
Cvo
example
CON
Cv
Cvxx
CB
C070
comments
v = the verb of the command
o = the first operand character
single character identifier
$B device
$O'jobname ' apostrophe is hexadecimal 70
command
$ON
4.
All symbols created for the support of the command will start
with characters which identify the entry point (CONxxxxx
identifies a location which was originally written for the
$ON command). Commands with no unique operand character
symbol have the character "x" as the third character.
(CBX ....• identifies a location which was originally written
for the $B device command.)
These conventions may be altered
in cases where the command identification characters are
redefined after original development.
5.
The main processor CSECT is HASPCO~~, all other CSECTs are
defined via the symbol field of the $COMGRUP macro; specified
starting with the characters "HASPC".
HASP Command Processor - Page 4.5-9
85
HAS P
Register Conventions
The Command Edit Routine passes control to the control section
(CSECT) which contains the appropriate command sub-processor.
At the point the Command group entry routine receives control,
the registers will contain the following:
reg
RO
Rl
WA
WB
WC
WD
WE
WF
BASE3
BASEl
BASE2
SAVE
LINK
RIS
contents
unpredictable
entry offset from the Command entry offset
unpredictable
unpredictable
unpredictable
first operand pointer (zero if no operand)
4
last operand pointer
base for CSECT
HCTDSECT address
beginning of main Command Processor
PCE address
unpredictable
unpredictable
If more than one command appears within the group, the value of
register Rl will be set by the $COMGRUP entry routine to a value
so that a $BRR Rl will enter the command sub-processor.
HASP Command Processor - Page 4.5-10
86
HAS P
4.5.4
HASP COMMAND PROCESSOR MACROS
To facilitate flexibility in the development and possible modification of the Command Processor a macro package is included
within the assembly source deck. This section is intended to
supplement the HASP Command Processor Source listings obtainable
from the HASP generation and assembly process in assisting the user
to understand the generated code as specifically used in the
current HASP as distributed.
Each HASP Command Processor macro may be dependent upon the
definitions contained within the Command Processor source deck as
well as other members of the HASP source library. These macros
are catagorized as follows:
ORGANIZATIONAL
Macros which.provide basic definitions and
are closely associated with the organization
of the processor.
BASE2 SERVICES
Macros which call upon the main Command
Processor to perform a service (display a
reply) •
CONDITIONAL IN-LINE FUNCTIONS - Macros which perform the function
in-line or links to a routine which performs
the desired function.
RELOCATABILITY AIDS - Macros which assist in keeping the overlay
CSECT relocatable around $WAIT or implied
$WAIT situations.
The macros which are supplied under each cateqory are summarized
in Table 4.5.4.
The following conventions are used in specifying
parameter requirements:
"parameter=** -"
keyword parameter is required
"parameter=text -"
the assumed value if the keyword parameter
is not specified
"parameter _"
the parameter is an optional positional
parameter
"parameter - Required" . . . the parameter is a required positional
parameter.
HASP Command Processor - Page 4.5-11
87
HAS P
Table 4.5.4
Command Processor Macro Summary
Op-Code
Definition
ORGANIZATIONAL:
$COMWORK
$COMGRUP
$COMTAB
COMMANDPROCESSORWPRKAREA (symbolic (iefinitions)
DEFINE GROUP OF COMMAND SUB-PROCESSORS
DEFINE COMMAND TA~LE ELEMENT
BASE2 S~RVICES:
$CRET
$CWTO
RETURN TO MAIN COMMAND PROCESSOR
WRITE TO OPERATOR
CONDITIONAL IN-LINE FUNCTIONS:
$CFCVB
CONVERT TO BINARY
$CFCVE
CONVERT TO EBCDIC
$CFDCTD
DEVICE CONTROL TABLE DISPLAY
$CFDCTL
DEVICE CONTROL TABLE LOCATE
$CFINVC
REPLY INVALID COMMAND
$CFINVO
REPLY INVALID OPERAND
$CFJDCT
FIND JOB'S DEVICE CONTROL TABLE
$CFJMSG
DISPLAY JOB INFORMATION MESSAGE
$CFJSCAN
SCAN JOB QUEUE ASSISTANCE
SELECT A ROUTINE BASED ON CHARACTER
$CFSEL
VERIFY CONSOLE CONTROL OVER JOB
$CFVQE
REL0C,ATIBILITY AIDS:
$ARR
ADD RELATIVE· REGISTER
$BRRBRANCH RELATIVE REGISTER
$SRR
SUBTRACT RELATIVE REGISTER
HASP Command processor - Page 4.5-12
88
HAS P
Organizational Macros
$COMWORK
- COMMAND PROCESSOR WORKAREA (symbolic definitions)
This macro adds to the PCEDSECT definitions for
fields located in the Command Processor PCE workarea.
Additional
symbolic constants for BASE2 services
and some externally defined parameters are defined.
$COMGRUP
- DEFINE GROUP OF COMMAND SUB-PROCESSORS
This macro defines the Command Processor overlay
control section via the $OVERLAY macro.
It provides
an optional entry point routine which locates the
command sub-processor for the commands which belong
to the group and sets register Rl to the relative
address.
(The symbol field must be specified for
this macro.)
n positionals - Each positional specifies the command
identification characters for the corresponding
command sub-processor located within the group.
Example:
specification
command
AA
$AA
DA
$DA
$B device
$C device
$p
$S
$D I jobname I
B
C
P40
S40
·D7D
sub-processor entry point name
CM
CDA
CB
CC
CP40
CS40
CD7D
PRTY=** - Priority of the HASP overlay defined by
the macro.
DELAY=NO - The sub-processor will be entered via
$BRR Rl macro instruction.
If "YES" is specified
Rl will contain the appropriate relative entry point
address and control will be given to the statement
following the macro statement.
(More than one positional must be specified if Rl is to be set or the
branch is to be executed.)
HASP Command Processor - Page 4.5-13
89
HAS P
$COMTAB·
l)EFlNECOMMAND TABLE ELEMENT
'rphiarntiloro defines an e:Lement in.the command
. SELECTION TABLE which is \1sedby the Command Edit.
Routine for identifyingle.gal cQmmands, eliminating
u~authorized input sources, . and entering the correct
. • command group CSECT".
.
verb- Required. - The .command identification
character(s) corresponding to the $COMGRUP positional
parameter. specific~t;.ionfor the command. No two
$COMTAB macro staternentsmay specify the same identificationcharacter string. All macro statements
creating entries for the same command verb will
appeaX' in consecut.i.y~ statements with the statement
which specifies a single identification character
last.
2roue -:-.Re9uir7d -.The exact c::haracters used in ~he
spec~f~cat~on ~n the sytnbolf~eld of the appropr~ate
$COMGRUP macro statement.
REJECT= - The command source rejection mask. One or
more of the following symbols may be specified as
follows:
"COMRMT" - reject command if entered from a
remote
.
"COMS"
- reject command if entered from a
console not authorized for SYSTEM
control
"COMO"
- reject command if entered from a
console not authorized for DEVICE
control
.
"COMJ"
- reject conunand if entered from a
console not authorized for JOB
control
Rejection of either a remote or a console not
authorized for SYSTEMappear$'as follows;
naEJECT=COMRM'r+COMS"
HASP
90
Command
~roQ~ssor
-Page 4.5-14
HAS P
Figure 4.5.5 - Selection Table Element
(variable)
COMTOFF
COMTFL
COMTVB
identifiers
overlay constant
COMTOFF
=
Offset for the overlay control section to
locate the command sub-processor entry point.
COMTFL
=
Rejection flags.
COMTVB
=
Command identification characters.
Verb with:
1.
First character of the first operand.
2. "
X' FF'
If X'FF' is specified all commands which
have not been specified by the previous
entries in the table will be considered
"selected" .
HASP Command Processor - Page 4.5-15
91
BASE2 Services
$CRET
.... RETURN TO MAINCOMMi\NP'PROCESSOR
"/:' ....:
. . ....
.'
'.:.':':<~'::';"':
MSG= .... "Addressu~i~~heIllesSage to be moved to
COMMAND area fordispl.ay,.(I,.::::Qperand, of a
non-register fOrrnis reqUi+ed.) uMSG=OK" indicates that themai:n.processori.st6display the
OK mes S. age • '
,
L= .... "Value" reptesen'tingthe len.gth of the message
that is to be mcrV'ed or has already been moved.
$CWTO
- WRITE TO OPERATOR
REGISTERS USED: RO,Rl, WA, LINK, Rl5
MSG:::: - "Address" of the message to be moved to
COMMAND area and d;L~pJ.C1yed. (L=operandof a nonregister form is required.)
L=** -,"Value" representing the length of the message that is to be moved or has a1re~dybeen moved.
HAst? Co~~ndProce$SQ):,'~
92
,Page 4.5 .... 16
HAS P
Conditional In-Line Functions
The HASP Command Processor as distributed provides for the
ability of the author of the command sub-processor to specify
whether or not the code which performs the function is in-line or
out of line.
If an out of line routine is used the name and
location of the subroutine must be defined. This is accomplished
with parameters standard for all function macro instructions
with the exception of $CFJSCAN as follows:
TYPE=CALL - The macro statement is not a definition form of
the macro.
"TYPE=DEF", the macro statement defines the
subroutine form of the function and return linkage must be
provided.
SYMBOL=address - The address of the "TYPE=DEF" version of
the macro instruction. This indicates that only linkage
to the "TYPE=DEF" version is to be provided.
If neither
"TYPE=DEF" or "SYMBOL=" parameters are specified the code
will be generated in-line with no return linkage.
$CFCVB
- CONVERT TO BINARY
This macro converts the numeric portion of a
command operand to one or two numeric values.
REGISTERS USED: RO, Rl, LINK, Rl5
RO - contains the last number converted.
Rl - contains the next to last number converted
(last number if the only one or the last is
smaller than the previous).
POINTER=(Rl) - The address of the COMPNTR field
which addresses the operand containing one or more
numerical values separated by dash (-).
.
NUM=2 - return two values.
"NUM=l", one value is
sufficient (Rl will be unpredictable on return) .
NOK=** - Address of the error exit routine if the
operand does not qontain a number or if the number
is too large.
$CFCVE
- CONVERT TO EBCDIC
This macro converts the number in register (RO) to
printable EBCDIC and sets the five resulting digits
in the first five characters of the PCE area
COMDWORK.
REGISTERS USED: RO, LINK
VALUE=(RO) - The positive binary half-word value
to convert to EBCDIC.
If the register form is not
used, the value is contained within the address~
half-word.
HASP Command Processor - Page 4.5-17
93
HAS P
$CFDCTD
'- DEVICE CONTROL TABLE DISPLAY
This macro di~playsthedevice name, unit address,
and status Of thfiiDCT"requested.
REGISTERS USED: RO,Rl, w~, LINK, Rl5
DCT=(RI) - The address of ,theDCT to displaYL
$CFDCTL
- DEVICE CONTROL TABLE LOCATE
This macro converts the abbreviated form of the
device name to the long form (if abbreviated form
is specified) and searches the OCT chain for a
matching device.
,
REGISTERS USED: RO,Rl, R15, LINK
RI - contains the'address of the DCT found or zero
if no DCT found.
POINTER =(RI) - The address of theCOMPNTER field
which addresses the operand containing the device
name (abbreviated).
$CFINVC
-REPLY INVALID COMMAND
This macro returns to the Main Command Processor and
causes the display "tNYJ\LID COMMAND".
$CFINVO
- REPLY INVALID OPERAND
This macro move:seight characters, starting with
the first character'of the "current" operand to
the COMMAND area and returns to the Main Command
Processor caus:i.ng the display of "operand INVALID
OPERAND"
OPERAND=(RI) -The address of the operand to display.
$DFJDCT
- FIND JOB'S DEVICE CONTROL TABLE
This macro searches the DCTchain for an active
printer, punch, or reader DCT which is assigned
to a procesor who~e PCE contains a pointer to the
HASP, job queue entry belonging to the desired job.
If the device is not found exit will be to. the
instruction inullediately follOwing the $CFJDCT statement(in-line codever~ion);otherwise, exit will be
to the instruction plus 4 "(NSI+4).
REGISTERS USED: aI, LINK, Rl5
JOBQE= (Rl) -< The address of the HASP job queue
entry for, the desired job.
HASP .Command Processor' - Paqe 4.5-18
94
HAS P
$CFJMSG
- DISPLAY JOB INFORMATION MESSAGE
This macro sets into the COMMAND area of the PCE
the information required for the JOB INFORMATION
MESSAGE and displays the message.
REGISTERS USED: RO, Rl, WA, LINK, R15
JOBQE=(Rl) - The address of the HASP job queue
entry for the desired job.
JDCT= - The address of the $CFJDCT TYPE=DEF macro
which may be used· to locate the job's DCT.
Register
form is prohibited~
CVE= - The address of the $CFCVE TYPE=DEF macro
which may be used to convert numeric information
to EBCDIC. Register form is prohibited.
JOB= - This parameter may be ignored by the macro~
however, if specified as "JOB=SET" the text "JOBj"
is assumed by the expanded routine to have been set
in the COMMAND area for the desired job.
OPT= - This parameter may be ignored by the macro~
however, if specified as "JOB=Q" all jobs given to
the macro expansion are queued (not active) or
if specified as "JOB=A" all jobs given to the
expansion are active.
$CFJSCAN
- SCAN JOB QUEUE ASSISTANCE
This macro is used to assist in scanning the job
queue. As each entry is located the user's PROCESS
routine is entered. The user examines the entry,
performs whatever function desired on the entry;
and returns to the symbol specified by the "NEXT="
operand. When the end of the queue is encountered,
control is given to the instruction following the
macro instruction. An optional feature of the macro
is to allow the PROCESS routine an "IGNORE' entry
to the generated code to indicate the current job
entry is not acceptable to the PROCESS routine.
If
the "IGNORE=" option is specified the corresponding
"EMPTY=", option is required.
Register 1 is the
scan register and is assumed to be unaltered by the
user PROCESS routine.
The "TYPE=DEF" option is not
permitted for this macro.
REGISTERS USED: Rl, BASE2
RI - scan register
BASE2 - found/not found switch (in addition to
processor base.
HASP Command Processor - Page 4.5-19
95
HAS P
PROCESS=** - Address of the user's job queue element
processing routine.
Register form prohibited.
IGNORE= - Symbol to be used to define the entry to
continue scan when the current job entry is not
of the desired type.
NEXT=** - The symbol to be used to define the entry
to continue scan when the current job entry is
of the desired type.
EMPTY= - The name of the user exit routine desired
to be entered when the job queue is found to be
empty of jobs of the desired type.
Register form is
prohibited.
$CFSEL
- SELECT A ROUTINE BASED ON CHARACTER
This macro matches the designated input character
against a list of arguments and transfers control to
the routine designated by the corresponding address.
If no match is found, the next sequential instruction
is entered.
REGISTERS USED: Rl, LINK, Rl5
n positionals of form: (character, address) - Each
positional "character" sub-parameter specifies an
argument to compare against.
The corresponding
address sub-parameter indicates the address of
the desired routine to enter if the character matches
the argument.
Regi'ster form is prohibi ted.
OPERAND=(Rl) - The address of the designated input
character to examine.
$CFVQE
- VERIFY CONSOLE CONTROL OVER JOB
This macro tests COMFLAGS field of the PCE to determine if the input source is a remote.
If the source
is a remote, the not OK routine will be entered
unless either the print or punch route codes for the
indicated job specify the remote. Otherwise the OK
routine will be entered.
REGISTERS USED: Rl, LINK
JOBQE=(Rl) - The address of the HASP job queue entry
for the desired job.
OK= - Address of the routine desired to be entered
if the console has control over the job. The
address may be the symbolic register containing the
address if specified as "OK=(register,BCR)" or
"OK=(relative register,$BRR).
HASP Command Processor - Page 4.5-20
96
HAS P
NOK= - Address of the routine desired to be entered
if the console does not have control over the job.
The address may be the symbolic register containing
the address if specified as ''NOK=(Register,BCR)" or
"NOK=(relative register,$BRR).
Either "OK=" or
"NOK=" parameters must be specified.
Relocatability Aids
$ARR
- ADD RELATIVE REGISTER
This macro instruction is used in conjunction with
$SRR to restore the specified register to refer to
the true address of relocated information.
register - Required - The symbolic register containing the address to be made true.
$BRR
- BRANCH RELATIVE REGISTER
This macro instruction is used in conjunction with
$COMGRUP to enter a sub-processor routine using the
offset provided by the $COMGRUP routine.
condition - Condition required to be met in order
to branch.
If this parameter is omitted, no comma
should be written to signify its omission.-"Condition code" may be specified by the character
strings:
(E, NE, H, L, NH, NL, Z, NZ, P, M,
NP, NM, 0 or NO) .
Register - Required - The symbolic register containing the offset.
$SRR
- SUBTRACT RELATIVE REGISTER
This macro instruction is used to make an addr~~s
pointer relative for possible relocation before
next referral to the information contained at
the address.
register - Required - The symbolic register containing the address to be made relative.
HASP Command Processor - Page 4.5-21
97
HAS P
4.6
OPERATOR CONSOLE ATTENTION PROCESSOR
This processor is included in HASP only if the value of the
HASPGEN variable &NUMCONS is greater than 0 (see section 7.1).
The HASP interface to OS Console Support if &NUMCONS=O, is
described in Appendix 12.15.
4.6.1
Operator Console Attention Processor - General Description
The function of this processor is to stage a read on a console
whenever an attention is received from that console.
4.6.2
Operator Console Attention Processor - Program Logic
During HASP initialization, the first three words of the OS Console
Attention Routine (IEEBA1) are overlayed with instructions which
cause lOS to enter the HASPATTN routine of this processor whenever an
attention interrupt occurs.
When an attention request is signalled by a console device, HASPATTN
saves the device address in the processor's PCE workarea, $POSTs
the PCE, and POSTs HASP.
When the Attention Processor is dispatched, it locates the physical console whose address is in the processor's PCE workarea and
links to the $WTO Processing Routine (see Section 5·.7) to queue
a read on. that console.
Console Attention Processor - Page 4.6-1
98
HAS P
4.7
CHECKPOINT PROCESSOR
4.7.1
CHECKPOINT PROCESSOR - GENERAL DESCRIPTION
The purpose of this processor is to write the necessary information onto disk to affect a subsequent restart of the system.
This processor will write the information at a predefined time
increment and at the completion of each stage of each job.
4.7.2
CHECKPOINT PROCESSOR - PROGRAM LOGIC
The first entry into the Checkpoint Processor is into a section which initializes the processor. This section issues a
&GETUNIT macro-instruction to obtain a DCT for a disk and
completes this DCT by inserting the event wait field address,
track to be written, and the buffer address.
The information to be checkpointed consists of the Job Queue
which contains the status of each job in the system, the track
allocation map which indicates the track groups of each disk
that have been assigned, a save area wh"ich contains added information as to the status of the system, the print checkpoint
table which is used to effect a warm start of the jobs being
printed, and (if generated) the Job Information Table which
contains additional information concerning each job in the
system. The Job Queue and the Job Information Table reside
within the checkpoint buffers, but the remaining fields must
be moved into these buffers.
The track allocation map is the first to be moved and the
track groups that have been reserved for the jobs that are
currently executing and reading in are returned to the track
allocation map to avoid loss of tracks in case of an emergency
restart. Next the write buffers are completed by moving the
save area and the print checkpoint tables. An :;iEXCP is issued
to write the checkpoint buffers and a $WAIT on I/O is initiated.
The Job Information Table (if generated) is written with CCW's
which are chained to the CCW's used to write the rest of the
checkpoint information. The Job Information Table is not
written with each checkpoint but only when the processor
which requests the checkpoint indicates that he wishes the
JIT to be written. This indication is made by setting the
"JITJCKPT" bit in the n$JITSTAT" field to one.
Checkpoint Processor - Page 4.7-1
99
HAS P
At the completion of the I/O operation, the HASP ECB is posted
and the timer is reset to a predefined time increment thqt was
specified as a HASPGEN parameter. A test is now executed to '
determine if the previous write was successful and if so, a
$WAIT macro-instruction is issued to place the processor into
an inactive state until the time increment has expired or a
stage of a job is completed.
If the previous write was unsuccessful, a message is issued
to indicate to the operator that a restart is needed and a
permanent HASP $WAIT state is entered so that no further checkpoint will be attempted.
Checkpoint Processor
100
~
Page
4.7~2
4.8
ASYNCHRONOUS INPUT/OUTPUT PROCESSOR
4.8.1
ASYNCHRONOUS INPUT/OUTPUT PROCESSOR - GENERAL DESCRIPTION
Since the completion of all HASP I/O operations are signalled
asynchronously with HASP operation via lOS channel-end appendages, these completions must be queued by the appendage
until all HASP processors can be synchronized to receive the
notification. The purpose, then, of the Asynchronous Input/
Output Processor ($ASYNC) is to, at non-interrupt time,
notify all processors of their I/O completions which were
indicated by the OS I/O supervisor at interrupt time.
4.8.2
ASYNCHRONOUS INPUT/OUTPUT PROCESSOR - PROGRAM LOGIC
The buffers (and respective lOBs) associated with I/O channelends are chained, by the HASP channel-end appendages, for
later processing by $ASYNC.
In addition to the POST of the
HASP task by lOS on any I/O completion, the channel-end appendages also $POST the Asynchronous Input/Output Processor to
initiate its processing when the HASP task receives control.
When $ASYNC receives control, it dequeues the first buffer
from its chain of work (operating disabled, for this operation
only, since its chain is updated at interrupt time).
The
Device Control Table entry (OCT) associated with this buffer
is located and the active I/O count for the device is reduced
by one. Next the user's EWF address is extracted from the
buffer and interrogated, and action is taken according to the
following algorithm:
EWF = 0
User does not want notification of completion
of I/O operation (always a write). The buffer will be returned to the HASP buffer pool
by $ASYNC.
EWF
>
0
$POST the !'1/O!! bit in the EWF specified and
take no further action.
EWF
<
0
Enter a user provided routine at the address
specified by the absolute value of the EWF
field.
Addressability for the processor
routine is established and the address given
is entered via the Branch and Link instruction
with the buffer address in register "Rl."
No further action is taken upon return by the
processor.
After performing the indicated action, $ASYNC returns to dequeue
the next buffer from its chain and the above procedure is repeated. When the end of the chain is reached, $ASYNC enters
the $WAIT state until additional I/O completions occur.
Asynchronous Input/output Processor - Page 4.8-1
101
HASP
4.9
HASP LOG PROCESSOR
4.9.1
HASP Log Processor - General Description
The function of the HASP Log Processor is to construct output
buffers for eventual processing as part of each Job's printed
output.
Input to the Log Processor is through a queue of CMBs
associated with the queue pointer $LOGQUE which is defined in
the HCT.
The nature of the information in the input queue, and
consequently the printed output, varies as a function of the
HASPGEN Parameters &NUMCONS and &WTLOPT.
4. 9 • 2
HASP Log Processor - Program Logic
Log processing of a message buffer is started by locating the
corresponding execution PCE. PCEs for output buffers are found
by using the job number in the buffer, and "reply" message PCEs
are located by using the TCB address which is placed into bytes
six through eight of the buffer by the Operator Console Input/
Output Processor's asynchronous exit.
Reply message processing
is valid only for &NUMCONS>O.
A test is made to ascertain if the message will fit in the HASP
buffer currently being used by the job for log output.
If space
is available, the message is placed in the HASP buffer and the
CMB is processed as follows:
If the CMB status bits indicate a
"read" or a "log only" condition, then the CMB is returned to
the free queue via the routine $FREEMSG. The IIlog onlyll condition is used when &NUMCONS=O.
"Read" and "Write" have meaning
only when &NUMCONS>O. If the status bits indicate a IIwrite ll
condition, then the CMB is queued for display via the $WQUEBUF
subroutine.
HASP
102
L~g
Processor - Page 4.9-1
HAS P
4.10
OPERATOR CONSOLE INPUT/OUTPUT PROCESSOR
This processor and associated routines are included in HASP only
if the value of &NUMCONS is greater than 0 (see Section 7).
The HASP interface to the OS console support which is included
if &NUMCONS=O, is described in Appendix 12.15.
4.10.1
Operator Console Input/Output Processor - General Description
The function of the Operator Console Input/Output Processor is to
process all I/O activity on all operator consoles. The processor
also processes all console errors, making a number of retries.
If the error continues, the message is ignored.
4.10.2
Operator Console Input/Output Processor - Program Logic
The Operator Console Input/Output Processor examines each entry
in the console message buffer I/O queue,$BUSYQUE. Each bit in
the console byte is tested for an available console.
If one is
found the appropriate operation is initiated with a $EXCP macroinstruction and testing of the queue is resumed. When all available consoles have been processed, the processor enters a $WAIT
condition until an I/O interrupt is received on one of the consoles,
or until another console message is added to the queue.
Console Input/Output Processor - Page 4.10-1
103
HAS P
4.10.3
Operator Console Input/Output Appendage - Program Logic
The Operator Console Input/Output Processor's asynchronous exit
is entered from the Asynchronous Post Processor following the completion of an I/O operation on a console device. The lOB completion
code is tested for abnormal end, and if an error exists, an error .
routine is entered to retry the operation.
If the completion is normal the appropriate physical console bit
is shut off and the console byte is tested to see if the operation
is complete on all consoles.
If any bits are still on the Operator
Console Input/Output Processor is $POSTed and an exit is taken.
If all bits are now off and the operation code is a write, a link
is made to $FREEMSG, the Input/Output Processor is $POSTed and an
exit is taken.
If the completed operation is a read, the response is processed
according to type.
If the buffer contains a HASP command (i.e.,
an input message whose first character is a dollar sign ($)), it
is chained to the end of a queue for the Command Processor
($COMMQUE), the processor is $POSTed, and an exit is made with a
$POST of the Input/Output Processor.
If the message is a "reply", the reply number is converted to
binary and the corresponding entry in $WTORQUE is located.
Using
the information in the entry, the message is moved to the WTOR's
reply area and the WTOR's ECB is POSTed. The reply queue entry
is merged into the free queue ($WTORFRE), and a link is made to
the Log Queuing Routine. The Input/Output Processor is $POSTed
and exit is made.
If the message is not a "reply" or a HASP command, it is assumed
to be an OS command.
The message buffer is set to the proper
format for the Master Command Routine and an SVC 34 is issued.
When control is returned from the Master Command Routine, the
buffer is released, the Input/Output Processor is $POSTed and an
exit is made.
Console Input/Output Processor - Page 4.10-2
104
HAS P
4.11
TIMER PROCESSOR
4.11.1
TIMER PROCESSOR - GENERAL DESCRIPTION
The function of this processor is to reset the OS interval
timer after a timer interrupt has occurred.
4.11.2
TIMER PROCESSOR - PROGRAM LOGIC
This processor calls the IPOSTIT and ISETINT subroutines in
the $STlMER/$TTlMER Control Service Routine (see Section 5.6),
which causes the expired TQEs to be POSTed and the time interval specified in the first TQE in the TQE chain to be set
into the OS interval timer. The processor then waits for
another timer interrupt to occur. When the next timer interrupt
is processed, the asynchronous exit routine $POSTs this processor and the above procedure is repeated.
Timer Processor - Page 4.11-1
105
HASP
4.12
REMOTE TERMINAL PROCESSOR (360/20-STR)
4. 12. 1
Remote Terminal Processor (360/20) - General Description
The Remote Terminal Processor (RTP), although not a part of HASP
proper, can be considered in the same catagory as other HASP processors.
RTP is created by HASPGEN to operate as an extension of HASP on a
System 360 Model 20 used as a remote terminal to HASP.
RTP, in
the Model 20, maintains constant communications with HASP at the
central computer site via severalclas se s of telephone line s to 1) encode
and transmit jobs submitted at the remote site to HASP for execution on
the central computer, and 2) print and/or punch the output from
jobs thus submitted as the output becomes available.
Various techniques
are utilized by RTP and HASP to obtain maximum performance of both
the Model 20 devices and the communication line s used.
RTP currently
requires an 8K Model 20 with any reader and printer attached.
The
program can be made to operate in a 4K environment at a somewhat
degraded performance, with reduced ease of operation.
RTP has been designed to allow the addition of "background" functions
to operate in a multiprogrammed environment with normal remote terminal
proces sing.
Remote T'erminal Processor (360/20) -
106
Page 4.12-1
HASP
4.12.2
Remote Terminal Processor (STR Model 20) - Program Logic
Upon completion of the loading of the RTP program deck, control is
transferred to the initialization phase of the program to prepare for job
processing. Initialization first checks the card reader for the presence
of patch (REP) cards and, if present, makes the appropriate patches
(the RTP REP card format is identical to the HASP REP card as described
in Section 6.4). Encountering a /*SIGNON card within the REP cards
I
will cause initialization to replace the default remote SIGN-ON identification
and password by the contents of the card. After loading REPs, or if no REP
cards are present the dynamic configuration card (which follows REPs if
I
present) is decoded and appropriate commands for the system punch
s.elected are established.
(The formats of the SIGN-ON and dynamic
configuration card are given in the Model 20 Operator's Guide-Section 11.2).
The final proces s of initialization is the dynamic construction of the buffer
pool.
Buffers are built, according to the HASPGEN parameter &TPBFSIZ
until the memory size of the machine is reached or the assembly parameter
&NUMBUFS is reached. Construction of the buffer pool ov·erlays the complete
initialization routine. Control is then passed to the processing section of RTP.
Remote Terminal Processor (360/20) -" Page 4.12-2
107
HASP
The processing phase of the program consists of four principal processors
and a communications adapter (CA) I/O supervisor.
Allocation of CPU
time to the various processors is accomplished via a commutator.
A
p.roce s sor is entered into contention for CPU time by changing its commutator entry from a NOP to a BRANCH command.
Through the use of the
WAIT macro, a processor may await the occurrence of a certain event
and be entered, via the commutator, below the wait instruction upon
completion of the event.
Remote Terminal Processor (360/20) - Page 4.12-3
108
HASP
PROCESSORS
Card Read Proce s sor
Upon initial entry, this proces sor checks the system card reader
for ready status.
If the device is not ready, HASP is notified, via a
SEND EOT, of the lack of jobs to transmit, the CA receive processor
is activated, the card read processor is deactivated, and entry is made
to the commutator.
If the card reader was ready, the transmission phase
is immediately begun.
Cards are read (double buffered) and are passed
to the ENCODE subroutine which compre s se sand tran slate s the card
for transmission.
The encoded card images are blocked in a buffer
obtained from the dynamic buffer pool until the capacity of the buffer is
reached.
The buffer is then chained into a queue of buffers awaiting
transmission by the CA transmission processor to HASP in the central
computer.
Another buffer, if available, is obtained from the buffer pool
and is processed in a like manner.
When, and if, the supply of buffers
is exhausted, the reader proce s sor enter s a WAIT state to await the freeing
of a transmitted buffer by the CA transmis sion proce s sor.
When the
last card of the job stack has been read, a SEND EOT (zero word count
buffer) is queued for transmission and the steps described previously
are done to terminate transmission and activate reception.
In order to
Remote Terminal Processor (360/20) - Page 4.12-4
109
minimize CPU utilization, the card read processor-compression routine
only compresses "n" or more blank characters (where I'n" is the value
of the assembly parameter &CCT).
The format of transmission records
to HASP is described in Section 12. 9. 3.
Remote Terminal Processor (360/20) - Page 4. 12-5
110
HASP
Communications Adapter Transmission Processor
The CA Transmission processor removes buffers from an ordered
queue, dynamically being built by the Card Read Processor, and transmits their contents to HASP in the central computer.
All transmissions
are via the Communications Adapter-I/O Supervisor (CAIOS) which provides for line re-instruct at interrupt time to make optimum use of the
line (See CAlOS description).
As posting of successfully completed
writes occurs, the buffers are returned to the free buffer chain for
reuse by another processor.
This processor continues to dequeue and
transmit buffers, as they become available, until a buffer with a transmission word count of zero is encountered.
An EOT is then sent to HASP
to indicate the end of the input stream, the CA T ransmis sion Proce s sor is
deactivated and return is m.ade to the comm.utator.
Remote Terminal Processor (360/20) -
III
Page 4.12-6
HASP
Communications Adapter-Receive Processor
The CA Receive Processor is activated by the Card Read Processor
when it is determined that no jobs are available to transmit to the central
computer.
Upon being entered, CA Receive establishes communication
with HASP in the central computer to await the output of a previously
submitted job.
The lack of jobs to transmit is indicated by HASP with an
immediate EOT signal to the Model 20.
When this EOT is received, the
CA Receive Processor deactivates itself and activates the Card Read
Proce s sor to again check for the pre sence of job s to send to HASP.
If a job is avialable to be printed or punched, the CA Receive
Processor activates the Print/Punch processor and immediately begins
reading transmittal records into buffers obtained from the dynamic
buffer pool.
Buffers, thus filled, are placed in an ordered queue to
await processing by the Print/Punch Processor.
All CA reads are
via the Communications Adapter I/O Supervisor (CAIOS) which provides
for line re -instruct at interrupt time to make optimum use of the line
(see CAlOS description).
Processing continues, as buffers and/or
transmittal records become available, until an EOT signal is received
from HASP indicating end-of-job.
A buffer with a word count of zero
is added to the queue to inform the Print/Punch processor of the endof-job.
Remote Terminal Processor (360/20) -
112
Page 4.12-7
HASP
Communication is then, once again, established with HASP to
ascertain if additional output for this
121>
is available
output of the job which has just completed printing).
(i. e. the punch
After the additional
output has been processed, or if none existed, the CA Receive Processor
is deactivated, the Card. Read Proce s sor is activated, and return is
made to the commutator.
Note that this logic, of acti~ating the Card
Read Processor prior to beginning processing output from the next job,
allows the Model 20 Operator to interrupt print/punch processing, at
a job boundary, to transmit a job to the central computer.
Remote Terminal Processor (360/20) -
113
Page 4. 12-8
HASP
Print/Punch Processor
When activated, the Print/Punch Proce s sor begins dequeuing and
processing buffers from the queue (being) created by the CA Receive
Processor.
Records to be punched are indicated by "carriage control"
characters of X'OFOF' and are routed to the punch section of the processor.
In order to minimize CPU requirements, the print processor
does not provide for 1-7/8 encoding of print characters (see Section 12.9).
The 16 4 of 8 character s normally re se rved for 1-7/8 encoding are redefined for print records only, as additional print characters, thus
yielding a 64 character print set.
After reconstructing and printing or punching all records in a buffer,
that buffer is returned to the buffer pool for use by another processor.
When a buffer with a zero word count is encountered in the queue (indicating end-of-job), the Print/Punch Processor is deactivated, unless
records from the next job have already been queued, and return is made
to the commutator.
If a dynamic configuration card described the system punch unit as
DUMMY, the punch section of the proce s sor is dynamically altered (by
initialization) to immediately free all punch buffer encountered in the
Print/Punch buffer queue.
This results in eliminating punched output;
however, punch records are still transmitted to the Model 20.
Remote Terminal Processor (360/20) -
114
Page 4. 12-9
HASP
By setting the assembly parameter &PUNCH to 0, all code concerned
with processing punched output will be eliminated from RTP.
The
appropriate HASPGEN must be done on the central system to force all
punch output for a "punchless ll terminal to be processed locally.
Remote Terminal Processor (360/20) -
115
Page 4.12-10
HASP
Communications Adapter I/O Supervisor
The primary purpose of CAIOS is to assure the maximum possible
communication line utilization by re-instructing the line at the earliest
possible moment after completion of a previous generation.
All requests to read and/or write the communication line are passed
to CAIOS for execution by the CA processors. Upon receipt of an I/O
request
I
CAIOS immediately initiates the operation if the line is dormant
I
or queues the request to await completion of the currently active operation.
The completion of a CA I/O operation causes an interrupt which
immediately transfers control to CAIOS. If the operation indicated as
complete by the interrupt was successful (error free)
I
any queued I/O
request is immediately initiated. The Event Control Block 6f the requestor of the just completed I/O operation is posted (with a X' 7F') to
indicate the successful completion of the request.
Return is then made
to the interrupted processor. CAIOS recognizes and attempts to
correct all transmission errors encountered on any CA I/O operation.
Since both CA processors are designed to double buffer I/O requests
I
CAIOS insures virtually total line utilization during transmission periods.
Remote Terminal Processor (360/20) -
116
Page 4.12-11
HASP
4. 12.3
Remote Terminal Processor (360/20)-Assembly Parameters
The following indicates the variable name and function of certain RTP
assembly parameters which can be of general use.
&TPBFSIZ
defines the size of the buffers used for
transmission to and from the HASP system.
(Since this variable must exactly agree with
the corre sponding variable s in the HASP
system, the value s of both are automatically
set at HASPGEN time.
&NUMBUFS
limits the number of CA buffers created
dynamically at initialization time.
Initial-
ization will create buffers until the capacity
of memory, or the value of &NUMBUFS is
reached.
It is suggested that this value be
made large enough to allow sufficient buffering
(hence line load-leveling) to occur.
&CCT.
represents the minimum number of consecutive
blank characters which will be compressed
by the Card Read Processor.
This value
should never be less than 4 and, significantly
Remote Terminal Processor (360/20) -
117
Page 4. 12 .. 12
HASP
reduces CPU requirements by the Card Read
Processor as it is increased.
A value of 80.
will effectively prevent all blank compre s sion
(except on totally blank cards).
The value of
&CCT may never exceed 80.
&PUNCH
controls the existance of code within RTF to
process punch output received from HASP.
If &Pu.NCH= 1, punching capabilitie s will exist
in RTP.
&PUNCH=O, no punching capabilities will be
created in RTP (NOTE: the HASPGEN of the
central computer system must agree with this
option. )
&MACHINE
defines the Model of SYSTEM/360 on which
RTP is to operate.
be set to 20.
This value must presently
This option can subsequently be
used to assemble RTP, at HASPGEN time, for
any Model of SYSTEM/360 being utilized as a
HASP remote terminal.
Although certain parts
of this feature are currently in RTP, it is
incomplete and totally unte sted.
Remote Terminal Processor (360/20) -
118
Page 4. 12·-13
HASP
REMOTE TERMINAL PROCESSOR (SYSTEM/360-BS~
4.13
The following sections outline the basic logic flow of the MULTI-LEAVING
Remote Terminal Processor program for System/360 (including Model 20)
workstations utilizing Binary Synchronous communications devices. The same
workstation program is utilized for both the Model 20 and System/360 workstations with generation parameters for the machine type.
4 • 13 • 1
General Description
The MULTI-LEAVING Remote'Terminal Processor program is created by
HASPGEN to operate as an extension of HASP on any Model of SYSTEM/360
.
~
used as a remote workstation for HASP. This terminal program maintains
constant communications with HASP at the central site via several classes
of telephone
line~
to (1) encode and transmit jobs submitted at the remote
site for OS/360 processing on the central computer
I
and (2) print and/or
punch the output from jobs thus submitted as the output becomes available.
Optionally
I
if an operator console is attached to the remote system
I
informational and control facilities are provided. All of the above functions
may occur simultaneously. Various techniques are utilized by HASP and
the workstation program to obtain maximum performance of the remote
devices and the communications line.
Figure 4. 13. 1 indicates the basic
information flow through the system.
Remote Terminal Processor (System/360) -
119
Page 4. 13-1
HASP
Figure 4.13.1 MULTI-LEAVING Information Flow Diagram
HASP
A
• $COMSUP
y
$COMSUP
..
$COMSUP
CBUFFER
r'
~~
$COMSUP
$OUTBUF
$BUFFER
Queue
Pool
.. ~
~~
$TPPUT
~,
OACTBUFF
$TPGET
-...$TPPUT
TCTBUFER
Queue
A
·
• $TPPUT
,
· $TPGET
Pool
oJ
• $RRTNl
• $WRTN:L
INPUT DEVICE
TCTTANK
$TPGET ..
$TANKPOL
Device
Tank
N.otes:
$PRTNl
$URTNl
$WRTNla
--
Queue
· $PRTNl
• $URTNl
• $WRTNl
,
OUTPUT DEVICE
Solid lines indicate buffer or decompression tank flow with or without data.
Broken lines indicate data flow only.
Line comments indicate
process~r
responsible.
Remote Terminal Processor (System/360) 120
Page 4.13-2
HASP
4.13.2
Program Logic
The MULTI-LEAVING Remote Terminal Processor consists of an initialization
section
I
four principal processors
I
three communications interface processors
and a communications INPUT/OUTPUT supervisor. Allocation of CPU time to
the various processors is accomplished through a basic program commutator.
A processor is entered into contention for CPU time by changing its commutator
entry from a NOP to a BRANCH command. A single control block
I
the Total
Control Table (TCT) is utilized by all processors to provide for synchroni'zatlon
of concurrent operations
I
processor status information1re-enterabllity and both
inter and intra processor communication.
The following sections discuss the basic logic flow of the various
components of the program.
Communications Interface Processor - Output ($TPPUT)
This processor serves as the interface between the various input processors
and the communications INPUT/OUTPUT supervisor. Its function is to compress
and encode records for subsequent transmission to HASP at the central site.
$TPPUT is utilized as a subroutine by the various input processors and relieves
the input routines of the responsibility of data compression and transmission
buffer management. As records are submitted for transmission
I
$TPPUT
compresses the records according to a compression type generation parameter
Remote Terminal Proces sor (Sys tem/3 60) 121
Page 4. 13- 3
HAS P
(&CMPTYPE) and add the encoded record to its current output buffer.
When the current buffer is filled or terminated, it is chained in
an ordered queue for transmission to. HASP by the communications
INPUT/OUTPUT supervisor and a new buffer obtained.
Details of the
compression and encoding technique utilized by $TPPUT are included
as an appendix to this manual.
Communications Interface Processor -.Input ($TPGET)
This proces'sor serves as the interface between the various output
processors (Print, Punch, Console, etc.) and the Communications
INPUT/OUTPUT processor.
Its function is to decode and uncompress
transmission buffers received from HASP and to queue the decompressed
records to the appropriate processor for processing.
$TPGET is en-
tered from the commutator and processes buffers from a ordered queue
of received buffers established by the Communications INPUT/OUTPUT
supervisor.
Records received are deblocked into "decompression
tanks" and passed to the appropriate processor.
Synchronization and
passage of the tanks to the processors is accomplished through the
Total Control Table (TCT) for each processor.
$TPGET additionally
is responsible for metering the flow of each type of record from
HASP.
This also is accomplished by utilizing the various buffer and
tank limits indicated in the TCT for each processor.
Control Record Processor ($CONTROL)
This processor provides synchronization between the various processing
Remote Terminal Processor (System/360) - Page 4.13-4
122
HASP
functions at the workstation and the HASP SYSTEM at the central site.
Records from HASP (i. e. Request to start a function
processor by the$TPGET processor.
record
I
transmits a response
I
I
Control
etc) are queued on this
$CONTROL then processes the control
if required, through $TPPUT and initializes the
required functional proces sor.
Communications INPUT/OUTPUT Supervisor (COMSUP)
COMSUP maintains communications with HASP in the central CPU at all
times and is responsible for the transmission of all data to and from the remote
site. The data processed by COMSUP is .always in compressed buffer form
and passes to and from COMSUP via ordered queues esta0lished by $TPPUT
and for $TPGET.
The communications I/O is primarily interrupt driven and is completely
maintained by COMSUP (i. e. COMSUP is both the initiator and executor
of communications I/O).
During periods requiring no data transmission
I
COMSUP maintains a ."handshaking" cycle with HASP at approximately 2
·second intervals to insure full bi-directional capabilities and to avoid
unprogrammed
II
time-outs
II
of the adapter.
In addition COMSUP maintains
I
verifies and corrects (if necessary)
the MULTI-LEAVING block sequence checking feature and detects
I
logs
and retries all communications errors •
Remote, Terminal Processor (System/360) -
123
Page 4.13-5
HASP
Initialization Processor
The Initialization Processor receives control from the loader and
initializes the remote terminal program as follows:
1.
If the CPU is not Model 20, general registers 1, 2, and 3
are loaded to establish 16 K addressability.
2.
Replacement (REP) cards are read from READER 1 for possible
modifications to the program. The format of the REP card
is as follows:
Col.
2-4
REP
Col.
9-12
Replacement address - hexadecimal address
of the first half word of storage to replace
(if blank the previous REP card is continued)
Col.
17-n
XXXX I
xxxx
I
•••
xxxx replacement data -
one or more half word groups of hexadecimal
data separated by commas
Col.
n+1
Col.
n+2 - 8 0 comments - any text
blank - terminator for the replacement data
Each REP card is printed on PRINTER 1 when read as a record of program
modification. REP reading is terminated when either a blank card (blank in
Col. 1-5) or a /*SIGNON card is encountered.
3.
The HASP ENVIRONMENT RECORDING ERROR PRINTOUT (HEREP)
is printed if the recording table is 1ntact from the last execution
Remote Terminal Processor (System/360) -
124
Page 4.13-6
HASP
of the program; otherwise, a new table is created for future
recording and print out.
4.
Interrupt PSW' s are set for non Model 20 CPU's.
5.
The communication adapter is enabled and communications
established with HASP as follows:
a. Write SOH-ENQ to HASP
b.
Read for DLE-ACKO from HASP
If I/O errors occur or HASP responses do not match the expected
sequence
6.
I
the sequence is repeated.
The proces sor constructs a buffer pool over itself and queues
the SIGN-ON record for transmission to HASP.
7.
I/O PSW' s are set (I/O old points to commutator) and control
is passed to the communication adapter interrupt routine.
Print Service Processor -
$PRTN1
The Print Service Processor's major functions are dequeuing decompression
tanks containing print information from the printer Total Control Table,
examining the sub-record control byte for carriage control information,
performing required carriage control, printing the information on the designated
printer, and releasing the used decompression tank to the pool. The processor
also provides event control upon dequeuing and releasing the "tanks". If
no console typewriter is attached to the system and the value of the user
option &PRTCONS is not zero, the processor will set status information
Remote Terminal Processor (System/360) 125
Page 4.13-7
HASP
at the end of each print data set which allows the console processor to queue'
operator messages for printing.
Input Service Processor -
SRRTNI
The Input Service Processor supports various card readers used for the
purpose of submitting job streams to HASP and in the case of Model 20
DUAL 2560 MFCM serves the functions of punch service processor. The
processor provides error analysis and recovery for supported devices.
Execution begins with the initial read routine which continuously attempts
to read cards from the designated card reader.
In the case of a DUAL 2560
control is passed to the punch routine if the primary feed is empty. If reader
is a DUAL 2520 or 1442 the routine will check the first card for blank and
if so pass control to the punch preparation routine; otherwise subroutine
$TPOPEN is called which sends a request to send a job stream to HASP.
When permission is received the job stream submission routine is entered
which reads cards into one of two decompression tanks calling the $TPPUT
processor which compresses the data and schedules transmission to HASP.
At end-of-file $TPPUT is used to signal HASP and control is passed to the
initial read routine.
The DUAL 2560 punch routine attempts to dequeue a decompression tank
from the Total Control Table. If successful the card image is punched and
the used "tank" is released to thp. pool.
The routine continues to dequeue
and punch for a maximum of 100 cards;
this time tests are made to determine
Remote Terminal Processor (System/3.60) 126
Page 4.13-8
HASP
the existance of cards in the primary feed.
The tests are also made in the
event of no tanks available for dequeuing.
If the tests are negative the
processor continues to punch cards; otherwise control is passed to the
read routine following the initial read.
The processor provides event control
upon dequeuing and releasing decompression tanks.
DUAL 2520/1442 punch preparation routine tests for:
1.
Operator Signal -
changing of the data dials, . SRI command,
or unsolicited device end.
2.
(Depends upon configurati6n).
Presence of Decompression tanks for punching.
If the operator signals, the routine passes control to the initial read
routine.
If a
II
tank
II
is queued to the device Total Control Table control
is passed to the Punch Service Processor ($URTNl).
Punch Service Processor -
$URTNI
The Punch Service Processor's major functions are dequeuing decompression
tanks containing print .:.rlformation from the punch Total Control Table
the information into cards on the designated punch
II
tanks
II
to the pool.
I
I
punching
and releasing the used
The proces sor also provide event control upon de-
queuing and releasing the "tanks
erroneous punching of data.
II
in addition to error recovery upon
If the device is a DUAL 2520 or 1442 control
is passed to the Input Service Processor ($RRTNl) after servicing output
"tank" .
Remote Terminal Processor (System/360) -
127
Page 4.13-9
HA,SP
Console Service Processor -
$WRTN1
If the remote terminal has an attached operator printer keyboard
..
the
I
console processor performs the following functions:
1.
Reads operator commands from the console keyboard.
2•
Examines the input for local commands (Model 20 only)
passing local commands to the command processor and
pas sing all other commands to HASP.
3.
Type operator messages contained in decompression tanks
queued to the console Total Control Table.
4.
Convert codes in the error mes sage log table to readable form
and type the resulting mes sages.
Execution begins with the processor testing for an operator command
in the console input
II
tank II waiting to be transmitted to HASP. If so the
console read in function is skipped and an attempt is made to send the
command to HASP. Control is passed to the console output routine which
tests for output messages.
the message
I
If so
I
the processor dequeues the tank
and releases the tank.
I
types
Control is then passed to the beginning
of the proces sor . If no output mes sages are pending the console logging
routine is entered 'which converts, types the message, and passes control
to the beginning of the processor. The console read routine tests for
operator requests and if so, reads the command from the keyboard
I
calls
the $TPPUT processor to compress the data and transmit the command to
HASP, and passes control to the console output routine. If the remote
Remote Terminal Processor (System/360) -
128
Page 4.13-10
HASP
terminal is a Model 20 the read routine tests for local commands and
calls the command processor which in case of ". S" command , posts. the
appropriate Service Processor and retur"ns.
Local commands are not
transmi tted to HASP.
The Console Service Processor without a console keyboard exists only
when the value of the user option &PRTCONS is not zero.
Execution begins
with a test for printer availability. If available, any console messages are
removed from the console output queue by the dequeue routine and attached to
the printer queue, allowing the Print Service Processor to print the message.
If no console messages are queued the processor will convert any log messages
into readable form, move the resulting message into a
II
tank II obtained from
the pool, queue it to the console output queue and pass control to the console dequeue routine. If the value of &PRTCONS is one and the printer is
not available console messages are allowed to accumulate to a maximum
queue limit. If the limit is reached prior to the printer becoming otherwise
available the printer is forced available and the messages are queued to the
printer with the sub-record control byte of the first message set to skip to
channel 1 before print. If the value of &PRTCONS is two and the printer
is not available to the console the processor will dequeue console tanks
and release them to the pool.
Remote Terminal Processor (System/360) -
129
Page 4.13-11
HASP
Total Control Table (TCT)
The Total Control Table is the major working storage area for the unit
record processors and is customized for each configuration and device supported
by the remote terminal program. Each basic TCT field may be referred to by using
symbols defined in the DSECT named TCTDSECT, however, each processor has
the option of uniquely referting to the fields directly by using the al terna te
three character prefix to each field name as follows:
TCT
=
General TC T prefix
CCT
=
Control record TCT
PCT
=
Printer TCT
RCT
=
Reader TCT
UCT
=
Punch TCT
WCT
=
Console TCT
Appropria te DSEC T' s are provided by generation macros in the event more
than one TCT of a given type is supported by the system. Basic control
fields appearing only in systems with model numbers above the Model 20
are as follows:
NAME
$pCTCOMn
DESCRIPTION
TCT addressability field - The commutator
branches to this field to give control to the
appropria te proces s or - the field contains a
BALR R7 ,0 instruction which sets up TCT
Remote Terminal Processor (System/360) 130
Page 4.13-12
HASP
NAME
DESCRIPTION
addressability for the processor - symbol
characters "p" and "n" uniquely identify the
TCT for the commutator
TCTSTRT
First two characters of unconditional branch
instruction
TCTENTY
.. S" type address constant pointing to the
appropriate proces sor - the field completes the
branch instruction which passes control to the
processor at the desired entry pOint
TCTRTN
Return to next entry in commutator - each
processor waits by branching to this field
of the TCT which in turn branches to the
commutator
TCTCCW
Actual CCW op-code used in last I/O on the
device - set by the processor and unit record
lOS
TCTDATA
Address of data area used for last I/O transfer
or address of input "tank" currently being
Remote Terminal Processor (System/360) 1 ') 1
Page 4.13-13
HASP
NAME
DESCRIPTION
compressed for transmission to HASP
TCTFLAG
CCW flags
TCTOPCOD
Op-code which will be inserted into the
TCTCCW field upon normal entry to unit record
IDS
TCTCCWCT
CCW count field - length of data last transferred or to be transferred
TCTSENSE
Sense information - set by unit record IDS
for error diagnostic purposes
TCTUCB
Device Address - contains hexadecimal
device address for SID and interrupt recognition
purposes - the high order bit of the field is set
on by the proces sor when wa.iting for HASP to
authorize job submission
TCTECB
Event Control Block - contains all bits stored
in CSW byte 4 since the last SID instruction for
the device - busy bit is set at SID and when
the processor desires to wait for unsolicited
Remote Terminal Processor (System/360) -
132
Page 4.13-14
HASP
NAME
DESCRIPTION
device end - busy bit is reset at device end
TCTALTOP
Alternate op-code for DUAL reader/punch
devices - processors requiring alternate opcodes have the option of setting the TCTCCW
field with the contents of this field prior to
entry to unit record lOS
TCTSAV1
Save area for the processor subroutine LINK
register
Basic fields which may appear in remote terminal programs for all
360 models are as follows:
TCTNEXT
Next TCT in the chain of TCTs
TCTFCS
Function Control Sequence Mask - used by
$TPGET processor to setup the FCS transmitted
to HASP for backlog control
TCTRCB
Record Control Byte - records from HASP which
have RCB bytes identical to this field will be
queued for output on the corresponding device
Remote Terminal Processor (System/360) 133
Page 4.13-15
HASP
NAME
TCTSTAT
DESCRIPTION
Status Flags - each bit has one or more meanings
which are dependant upon the processor
involved:
bit 0
=
TCTOPEN - always off indicating
device is in use by HASP output
(as appropriate)
bit 1
=
TCTACT - used by $TPGET to
determine which output devices
need more data - proces sors set bi t
1 when dequeuing output "tanks"
bit 2
=
TCTSTOP - device has been stopped
and is awaiting a· start command.
bit 3
=
TCT1052, TCT2152 - console
device identifier
bit 4 -
PCT only = TCT1403, TCT1443,
TCT2203, TCTPRTSW - indicates the
status of the corresponding printer if set the printer is available for
printing operator mes sages
bit 4 -
WCTonly
=:
TCTREQ - console request -
operator desires to enter a command
Remote Terminal Processor (System/360) -
134
Page 4.13-16
HASP
NAME
DESCRIPTION
bit 4 -
UCT only
= TCT1442
- the device is a
1442 with single stacker pocket
bit 5 -
RCT or UCT
= TCT2540
- TCT is for
a 2540
bit 5 -
WCT only
= TCTREL -
release requested -
an unsuccessful attempt has been made
to obtain a bu ffer for command transmission to HASP - the command is in
compressed form in the consoles "tank
waiting for a free buffer
bit 6 -
RCT/UCT = TCT14420, TCT25600 TCT is for a DUAL 1442 Reader Punch
or DUAL 2560 MFCM
bit 7 -
RCT/UCT
= TCT25200
- TCT is for a
DUAL 2520 Reader Punch device
TCTCOM
Pointer to corresponding commutator entry
TCTID
Optional field - two character identification
for local command processors
TCTINRCB
Optional field - exists when DUAL devices are
attached to the system - identifies the Input
Remote Terminal Processor (System/360) -
135
Page 4.13-17
ll
HASP
NAME
DESCRIPTION
Service Processor function as opposed to the
Punch Service Processor function identified by
TCTRCB - TCTINRCB is equated to TCTRCB if
no DUAL devices are attached
The following fields are normal device extensions and do not exist for
card reader devices when DUAL devices are not attached to the remote
terminal:
TCTTANK
Beginning of output "tank" queue - output records
appear in unit record image form
TCTBUFER
Beginning of output buffer queue - contains
records in compressed form
waiting for de-
compression into tanks
TCTTNKLM
Tank limit - maximum number of "tanks" which
may be placed in the "TCTTANK queue
TCTTNKCT.
Tank count - actual number of "tanks
II
queued
to the TCT
TCTBUFLM
Buffer limit - maximum number of output buffers
which may be placed in the TCTBUFER queue
Remote Terminal Processor (System/360) 136
Page 4.13-18
HASP
NAME
DESCRIPTION
before signalling HASP to suspend sending the
streams - limit is ignored for WCT
TCTBUFCT
Buffer count - actual number of buffers queued
to the TCT
Reader and console TCT's have extensions which are used as "tanks"
for records which are transmitted to HASP. These "tanks" belong to: the
device (2 for readers and 1 for the console) and are not released to the.
fltank~'
pool. The following field symbols are only defined for theTCT 's with.
prefix designators. RCT, WeT I and with DUAL devicesptJOT:
RCTTANK1, RCTTANK2
II
Tank" origin and working storage
RCTTRCB1, RCTTRCB2
Input RCB for HASP identification
RCTTSRC1, RCTTSRC2
Sub-record control byte = X'SO'
RCTTCT1, RCTTCT2
Count field - length of data portion
RCTTDTA1, RCTTDTA2
Data area - input card or operator command will be blank for the DUAL 2520 and 1442
while in output status
Remote Terminal Processor (System/360) -Page 4.13'"'!19
137
HASP
TABLE OF CONTENTS
PAGE
SECTION
4.14
Remote Terminal Programs (1130)
Introduction
4.14-1
4.14-1
4.14.1
Remote Terminal Processor (RTPl130)
Introduction
Commutator Processors
TPIOX - SCA I/O Control
TPGET ... TP Buffers From HASP
TPPUT - TP Buffers To HASP
RDTFO - 2501 Card Reader
RPFFT - 1442 Reader Punch
PRFOT - 1403 Printer
PRETT - 1132 Printer
CONSL - Console Keyboard/Printer
RTPET - Initializ.ation
System Subroutines
SGETQEL - Dequeue An Element
SPUTFQL - Enqueue A Free Element
SPUTAQL - Enqueue An Active Element
STPOPEN - Initiate Control Record
'8SRCHB - SearchUFCB Chain
SWTOPR - Type Message
SLOGSCA - Log SCA Error
SMOVE - Move A Variable Number Of Words
SXPRESS - Convert Card Code To EBCDIC
SXCPRNT - EBCDIC To Console Print
8XPPRNT - Convert EBCDIC To 1403 Print
SXCPNCH - Convert EBCDIC To Card Code
STRACE - Trace Machine Registers
SSDUMP - System Core Dump
Processor Subroutines
BSXIOS - SCA I/O Supervisor
DBLOCK - Deblock Data From HASP
TPCOMPR - Construct Output To HASP
DBUGSCAL - Trace SCA Interrupts
TPBUILD - Build TP Buffers·
4.14-3
4.14-3
4.14-4
4.14-6
4.14-6
4.·14 - 6
4.14-7
4.14-7
4.14-7
4.14-8
4.14-8
4.14-9
4.14-10
4.14-11
4.14-11
4.14-11
4.14-11
4.14-12
4.14-12
4 • 14 -12
4.14-13
4.14-13
4.14-13
4.14-13
4.14-13
4.14-13
4.14-13
4.14-16
4.14-17
4.14-17
4.14-18
4.14-18
4.14-20
HASP Remote Terminal Processor (1130) - Page 4.14-1
138
HASP
TABLE OF CONTENTS
(Continued)
SECTION
4.14.1
Continued
PAGE
Control Block And Data Formats
Chained List General Format
UFCB - Unit-Function Control Block
TPBUF - TP Buffer Format
Output Element (Tank) Format
Object Deck Format
REP Card Format
4.14-21
4.14-21
4.14-22
4.14-25
4.14-27
4.14-28
4.14-29
4.14.2
Remote Terminal Main Loader (RTPLOAD)
4.14-32
4.14.3
Remote Terminal Bootstrap (RTPBOOT)
4.14-33
4.14.4
Remote Terminal Program 360 Processing
(LETRRIP)
4.14-38
1130 Instruction Macros
4.14-39
General Information
Variable Internal Parameters
4.14-44
4.14-44
4.14.
4.14.5
4.14.6
HASP Remote Terminal Processor (1130) - Page 4. 14-ii
139
HASP
4.14
REMOTE TERMINAL PROGRAMS (1130)
Introduction
The 1130 MULTI-LEAVING terminal program is designed to operate on a
system with 8K words which contains the standard Binary Synchronous Communications Adapter.
The unit-record equipment supported may include any or all of the following
devices:
•
1442 Reader/Punch or Punch
•
2501 Reader
•
1132 Printer
•
1403 Printer
•
Console keyboard/Printer
Programs developed for the 1130 in conjunction with the HASP Remote Job
Entry feature are assembled using the OS/360 Assembler.
The 1130 instruction
set is generated thru the use of macro instructions (See Section 14.4.5) corresponding to the actual 1130 hardware commands. Additionally, pseudo (assembler)
operations are available to aid in the development of 1130 programs on the System
360.
The object decks produced by the
as Assembler are
subjected to further
processing by a program (LETRRIP) which condenses and changes the format of
the EBCDIC decks to facilitate 1130 loading ..
HASP Remote Terminal Processor (1130) - Page 4.14-1
140
HASP
The remote terminal system for the 1130 is composed of several programs
briefly described in the following paragraphs:
RTPBOOT - A bootstrap loader consisting of a single "load mode" format
card and several column binary and EBCDIC program cards.
The function
of RTPBOOT is to lib ootstrap" an EBCDIC format loader (RTPLOAD) into
1130 core.
RTPBOOT will load from either a 1442 or a 2501 card reader.
RTPLOAD - Loads into the upper segment of defined 1130 core and then
loads the main terminal program (RTP1130) into the lower extent of 1130
core. RTPLOAD also processes REP cards and performs the initial processing of /*SIGNON control cards.
RTP1130 - The main terminal processing program which provides the
MULTI-LEAVING support for the 1130.
The following sections provide more detailed information on the design
and implementation of the above programs.
HASP Remote Terminal Processor (1130) - Page 4.14-2
141
HASP
4.14.1
Remote Terminal Processor (RTP1130)
Introduction
The subsequent sections present the basic structure of the terminal program
for the 1130. Included, are descriptions of the commutator logic and associated
processors; system subroutines; processor subroutines; control block formats
and data block general formats.
The documentation presented is intended to be introductory in nature.
The user intending to modify the system should use the documentation in conjunction with a program listing which contains commentary in much greater detail.
HASP Remote Terminal Processor (1130) - Page 4.14-3
142
HASP
Commuta tor Proces sors
Distribution of CPU time to the processors concerned with the functions
necessary to support terminal devices is through programmed commutator
logic.
Each proces sor which needs CPU time and is dependent on external
I/O device rates is represented by a commutator entry.
The commutator
entry consists of the following basic elements:
•
A named commutator "gate" which takes the form of a branch to
the next commutator entry (gate closed) or a "NOP" if the entry
is active (ga te open).
•
A long form branch to the active commutator main ·':>utine used if
the gate is open.
•
A named return pOint for reference by the main commutator routine.
•
A named end to the commutator entry which is the address of the
next commutator entry.
The basic structure as defined may also contain register save-restore
sequences to be used for each entry-exit cycle through the commutator.
The processors entry from the commutator (gate open) usually provides
for a method of setting a variable entry to the segments of the processor
which are involved with waiting for I/O to complete or some system resource
to become available.
HASP Remote Terminal Processor (1130) - Page 4. 14-4
143
HASP
The general operation of the commutator involves the opening and closing
of processor gates
I
the setting of variable entry pOints within the processors
I
the initiation and associated wait period for I/O operations and the return to
the commutator to "share" the CPU during wait periods.
The last instruction
in the commutator is a branch to the "top" or first instruction in the commutator
which initiates the next cycle.
The current system does not provide for a
priority relationship among commutator processors.
The main commutator processors contained in the RTP1130 system and
briefly described in the following sections.
HASP Remote Terminal Processor (1130) -Page 4.14-5
144
HASP
TPIOX - SCA Input/Output Control Processor
Controls the transmission of data and/or control records between HASP
and RTPl130 via the SCAt All adapter I/O is initiated using the SCA I/O
Supervi Bor - BSXIOS.
TPGET - Processor for TP Buffers From HASP
Processes data received from HASP in the form of TP buffers or control
records preprocessed by TPIOX.
Control record processing is in the form
of "Request to start" or "Permission to send" functions.
Da ta buffers are deblocked, decompres sed, converted to appropriate
codes (1403 printer, 1442 punch, etc.) and queued for the specified comm·uta tor I/O proces sors •
Control information pertinent to the unique requirements of each data
type is provided through the associated UFCB.
TPPUT - Processor For Data Destined For HASP
Acquires a TP buffer from the free chain and collects data from defined
sources (card reader(s), console keyboard, etc.) to be processed (con,verted, truncated, compressed, etc.) and inserted into the buffer which is
queued for TPIOX transmis sion to HASP.
HASP Remote Terminal Processor (1130) - Page 4. 14-6
145
HASP
RDTFO - 2501 Card Reader Processor
A conditionally assembled processor which supports the 2501 card
reader as a job entry device.
The functions of monitoring for a 2501 "ready"
condition; reading cards; requesting permission to transmit to HASP; waiting
for permission to send; queueing data for TPPUT; transmitting "end-of-file"
conditions and device error recovery are contained in this processor.
RPFFT - 1442 Reader And/Or Punch Processor
A conditionally assembled processor which supports the 1442 - 5, 6 or 7
as a card reader, card reader/punch or as a card punch only.
The functions
to be performed are controlled by the assembly variables chosen and the use
of local operator commands, when applicable.
The reader sections of code
monitor for a "ready" condition; reads cards for transmission to HASP via
TPPUT; processes "end-of-file" communications and provide error recovery.
The punch sections of code wait for data to be punched through interrogation
of a queue developed by the TPGET processor and provide error recovery and
and punch termination procedures.
PRFOT - 1403 Printer Processor
A conditionally assembled processor which supports the 1403 printer
as a terminal output device.
The functions of monitoring for input to be
printed; simulating carriage control operations; processing
II
end-of-file"
HASP Remote Terminal Processor (1130) - Page 4. 14-7
146
HASP
. conditions; setting UFCB status information and error recovery are included
in this processor.
PRETT - 1132 Printer Processor
A conditionally assembled processor which supports the 1132 printer as
a terminal output device.
The functions of monitoring for input to be printed;
initialization of interrupt processing routines for the 1132 print scan operations; simulation of carriage control operations; processing "end-of-file"
conditions; setting UFCB status information and error recovery are contained in this processor.
CONSL - Console Keyboard/Printer Processor
Proces s es console keyboard input and prints on the typewriter mes sage s
originating from HASP or internal sources.
Keyboard input is initiated by activation of the "INT REQ" key and by
the interrupt routine which sets a flag and opens the console routine gate.
Note: The position of the "keyboard/console" switch is not interrogated and
input is assumed to be from the keyboard.
The value of the console entry keys
is read every communtator cycle and, if key
0
is on, stored in location
$ENTKEYS. All non-control character input is printed and the card code value
stored for investigation at EOF time.
If the first character of input is ".
II
(period) then the data is assumed to be a local command. All other data is
transmi tted to HASP for action as a HASP opera tor command.
HASP Remote Terminal Processor (1130) - Page 4. 14-8
147
HASP
Print input is obtained from a queue which originates locally and/or
from HASP.
Data to be printed may be EBCDIC or tilt-rotate code and
black or red ribbon.
RTPET - Initialization Processor
This special commutator processor is responsible for the initialization
functions necessary for the commencement of the 1130 terminal operation
ih conjunction with HASP.
The major functions performed are:
•
Sets the interrupt transfer vectors for RTPl130 operation.
•
Dynamically builds the TP buffer pool using the defined extent
of 1130 core; the end of the 1130 program and the defined TP
buffer si z e .
•
Builds a TP buffer containing the sign-on information processed by
RTPLOAD for transmission to HASP.
•
Establishes SCA communications with HASP and prepares TPIOX
for
II
sign-on II •
•
Opens the commutator gates for all SCA and input processors.
•
Disconnects ini tializa tion from the commutator.
•
Branches to commutator which initiates MULTI-LEAVING operation.
HASP Remote Terminal Processor (1130) - Page 4.14-9
, A 0
HASP
System Subroutines
The following are brief descriptions of the major subrou tines contained
in the RTPl130 program.
These subroutines are available for use by any
system commutator processor with the restriction that they; may not be used
at interrupt time.
input values
I
Detailed information concerning the calling sequences
I
etc. may be found in the listing of the RTPl130 program.
HASP Remote Terminal Processor (1130) - Page 4.14-10
149
HASP
SGETQEL - Dequeue An Element From a Chained List
Given the address of a chained list, SGETQEL returns the address of the
first element available in the list and removes the element and rechains the
list.
The chain field of the dequeued element is set to zero before returning.
If the chain is null, an indication is returned to the, us er.
SPUTFQL - Enqueue An Element In A Free Element Chain
Given the address of a free element chain pOinter and the address of an
element to be returned to the free chain
chain.
the element is returned to the free
I
The construction of the free chain is in random order depending on
system processor utilization of the free element chain.
SPUTAQL - Enqueue An Element In An Active Chained List
The address of an element supplied by the caller is used to build a
chained list in first-in, first-out order.
RTPOPEN - Initiate Control Record Transmission
Control record communications with HASP in the form of "Request to
start and IIPermission to send II sequences is the function of this routine.
ll
Input includes an indication of the control record type and a pOinter to the
UFCB for the device being processed.
HASP Remote Terminal Processor (1130) - Page 4.14-11
1
~
()
HASP
SSRCHB - Search UFCB Chain For Matching RCB
The RCB code supplied by the user is used to search the UFCB chain
for a UFCB with a matching RCB code. An indication of the status of the
search is returned to the caller.
SWTOPR - Type Message On Console Typewriter
The caller supplies the address of a message in EBCDIC and with
control information indicating red or black ribbon and the number of characters to be typed.
The addres s of a routine to be given control in the
event that the message cannot be processed immediately m'.lst also be
supplied.
-The message is queued for processing by the console typewriter
commutator routine.
SLOGSCA - Log SCA Error Messages On Console Typewriter
Error conditions associated with the SCA operation are logged on the
console typewriter for information and possible remedial purposes.
The
format of the message logged is:
SCA
LOG XXXXXXXX
Where the value of "XXXXXXXX is determined by the caller and is in
II
fact the contents of the ACC and EXT on entry to the routine.
An indication of the status of the request to log is returned to the caller.
HASP Remote Terminal Processor (1130) - Page 4.14-12
151
HASP
SMOVE - Move A Variable Number Of Words
This routine provides for the moving of a specified number of words
from a source block to a target block.
RXPRESS - Convert Card Code To EBCDIC
The card code (12 bit) input is converted to EBCDIC using a high
speed conversion algorithm in conjunction with a minimal conversion table.
Special consideration is given to "blank" conversion under the assumption
that most cards are dense with "blank" data.
SXCPRNT - EBCDIC To Console Printer Code Conversion
Converts a single EBCDIC character to the equivalent console printer
Tilt-Rotate code using a table look-up method.
SXPPRNT - EBCDIC To 1403 Printer Code Conversion
Converts a single EBCDIC character to the equivalent 1403 printer 6 bit
wi th parity code using a table look-up method.
SXCPNCH - EBODIC To Card Code Conversion
Converts a single EBCDIC character to the equivalent 12 bit card code
using a table look-up method and conversion algorithm.
HASP Remote Terminal Processor (1130) ... 4.14-13
IS?
HASP
STRACE - Trace Machine Registers
Stores the information shown below in a table of variable length.
entry is the result of the execution of the I inkage created by the
macro.
Each
STRACE
The trace table created at assembly time is circular.
Trace table entry:
Word
Description
1
Count of the number of entries for this $ TRACE
2
Location +1 of caller to $TRACE
3
Contents of ACC
4
Contents of EXT
5
Contents of XR1
6
Contents of XR2
7
Contents of XR3
The count of the number of entries is also stored in the STRACE
macro linkage.
The assembly of srRACE is a function of the variable &TRACE.
~SDUMP
- System Core Dump
A condition311y assembled subroutine which allows post-mortem or
dynamic dumps on either the 1132 or 1403 printer. SSDUMP is assembled if
&DEBUG SETA 1 is included in the RTP1130 source deck.
HASP
Remot~
153
Linkage to SSDUMP
Terminal Processor (1130) - Page 4.14
HASP
via location 0 is also established so that a post-mortem dump may be
taken by pressing system reset and start.
The linkage to use this subroutine dynamically is contained in the
system listing.
Note: The logic of the subroutine does not allow concurrent
operation of the selected printer and other devices.
HASP Remote Terminaf Processor (1130) - Page 4. 14 -15
1 '14
HASP
Processor Subroutines
The following are brief descriptions of the major subroutines which
may be used by commutator processors subject to the restrictions that these
routines are processor dependent in their operation. For example
I
the SeA
I/O Supervisor (BSXIOS) is used at initialization time and by the TP buffer
manager but cannot be simultaneously used by these commutator processors.
HASP Remote Terminal Processor (1130) - Page 4.14-16
155
HAS P
BSXIOS - Low Speed BSCA Input/Output Supervisor
Processes requests for transmit, receive or program timer functions
on the low speed binary synchronous communications adapter.
BSXIOS
initiates the requested function and prepares the interrupt programs for the
associated interrupt processing of the desired functions.
The status of the function performed by BSXIOS is contained in a communication cell which is addressed by a variable pOinter word. A communication cell is defined for both read (receive) and write (transmit) operations.
Various completion codes stored in the cells provide the status of the function
with respect to normal or abnormal termination.
BSXIOS expects the caller to provide the address of an appendage routine
to be entered at the termination (interrupt time) of every write operation.
The
purpose of the write end-of-operation appendage is to allow re-instruct (read
operation) of the communications adapter as soon as possible after the write
completion.
HASP Remote Terminal Processor (1130) - Page 4. 14-17
HASP
DBLOCK - Deblock, Decompress, Convert and Store Data From HASP
Locates a record (defined by RCB) in a TP buffer as specified by a
given UFCB, decompresses
area.
II
I
edits and moves data to a selected target
The target area must have the same format as described under
Output Element (Tank) Description
II •
The operation of DBLOCK includes the priming of the output tank
with an initialization value supplied by the user (usually the value of
a blank for the associated device); the updating of .control information in
the UFCB; the setting of control information in appropriate fields of the
output tank; the automatic entry to conversion and store routines unique
to the device associated with the UFCB supplied and the communication
of the status of the buffer being processed (end-of-file
I
end-of-block
conditions) •
HASP Remote Terminal Processor (1130) - Page 4.14-17.1
157
HASP
TPCOMPR- Construct Records For Insertion In TP Buffers
Constructs a logical record consisting of a physical input record ..
attached 1130 devices (card reader(s) I console I etc.).
The logical record
constructed consists of the original input after code translation, data truncation and/or compression (optionally) and attachment of the control bytes
necessary for HASP processing.
The control bytes are per the standard HASP
MULTI-LEAVING conventions.
The options listed below are set at assembly time to generate the
supporting code.
•
No compression or truncation
•
Trailing blank elimination only (truncation)
•
Blank and duplicate compression and blank truncation
The current version of TPCOMPR assumes card code input.
DBUGSCAL - Trace Routine For Low Speed SCA
This routine is conditionally assembled as a function of
II
&DEBUG II
and provides a trace of all SCAinterrupts in the form shown below. Entry
.is from BSXIOS .interrupt processing routines. External disabling of the SeA
trace function is provided through the entry keys.
The trace table 11mi ts are
preset to use the upper 8K of a 16K 1130 and must be changed either by
assembly or by the appropriate
II
REP " • See the program listing and refer to
locations DBUGSTRT and DBUGSTND •
. HASP Remote Terminal Processor (1130) - Page 4.14-18
158
HASP
The trace table format is:
Word
Description
1
Operation type (BSXIOPT)
2
DSW at interrupt time
3
BSXIOS Completion Code (BSXOPF)
4
Loca tion of interrupt
5
Data received/transmitted
6
Data transfer count
7
Read or write sequence index
8
Spare word
HASP Remote Terminal Processor (1130) - Page 4.14-19
159
HASP
TPBUILD - Constructs TP Buffers
Constructs TP buffers for TPIOX transmission to HASP.
inserted and length of insert are provided by user.
Data to be
TPPUT initializes this
routine by providing the buffer to be used and setting pointers and variables.
The data to be inserted is usually in the form a logical record as constructed by TPCOMPR.
HASP Remote Terminal Processor (1130) - Page 4.14-20
160
HASP
RTP 1130 Control Block And Data Formats
Chained List General Format
All
qu~ues
maintained within RTPl130 are of the chained list form and
consist of free queues and free queue pOinters and active queues and active
queue pointers. Free queues are chained in a random fashion while active
queues are maintained in a first-in, first-out order.
The general form of
a queue is:
QUEUE POINTER ...-__
Address of next element chain word.
Set to zero if no element.
ELEMENT CHAIN WaR
• • '. Variable length element.
ELEMENT CHAIN WORD
•
, • Variable length element •
•
• • La st variable length element
•
•
o
(Chain Word Set to zero).
Examples of chained lists are: TP buffers, console message tanks,
printer data tanks, punch data tanks.
The size and number of elements in
the queue is variable according to the nature of the queue.
HASP Remote Terminal Processor (1130) - Page 4.14-21
161
HASP
UFCB - Unit-Function Control Block Description
Each device which transmits data to or from HASP via the communications
adapter processors must be represented by a unit-function control block.
The general format of a UFCB is:
REFERENCE
WORD
DESCRIPTION
UFCBCNW
o
Chain word to next UFCB
UFCBNFO
1
Informa tion word •••
Input: Byte 0 = Reserved
Byte 1 = Input Code
= 0 for IBM Card
=1
for PTTC/8
= 2 for EBCDIC
UFCBSAR
2
Sta tus and RCB Code •••
B~eO=Sta~scluni~fuootioo
= X'90' if request to start sent from
input unit-function or if request to
start received for output unit-function
HASP Remote Terminal Processor (1130) - Page 4.14-22
162
HASP
= X'AO
I
If permission to start
received for input unit-function or
1f permission to start sent for output
uni t-function.
Byte 1 = RCB code associated with this UFCB
UFCBFCS
3
Function control sequence bit associated with this
UFCB (and RCB)
UFCBCOM
4
Address of commutator processor gate address for
processor associated with this UFCB
UFCBFQP
5
Tank free queue pointer for output devices or
address of input element for input devices
UFCBBFP
6
Queue pOinter for active TP buffers for output
deVices or end-of-file flag for input devices
UFCBBFC
7
Count of active TP buffers for associated device
UFCBBFL
8
Limit of active TP buffers for associated device
UFCBPBP
9
Buffer address of 'current buffer being processeca
by TPGET proces sor
UFCBPBA
10
Addres s of next RCB in buffer being proces s ed
HASP Remote Terminal Processor (1130) - Page 4.14-23
163
HASP
UFCBPBS
11
Position indicator for next RCB in buffer being
processed. Set to 0 if RCB right justified. Set
to 1 if RCB left justified.
UFCBPWD
12
Output device width
= 2*W/P where W = actual
width in characters and P
= 2 for
packed output
tanks or P = 1 for unpacked output tanks.
UFCBPRO
13
Address of data processing routine (usually a conversion program) for each character processed by $DEBLOCK .
UFCBSTO
14
Address of routine to store data processed by
"UFCBPRO" program.
HASP Remote Terminal Processor (1130) - Page 4.14-24
164
HASP
TPBUF - TP Buffer Element Description
All data transmitted to or from HASP is contained in variable length buffers
(variable at generation time) with the following general format:
REFERENCE
WORD
DESCRIPTION
TPBUFCW
0
Chain word to next TP buffer,
TPBUFST
1
Reserved
TPBUFCB
2
Buffer control word
Byte 0
=0
(Reserved)
Transmi t function •••
Byte 1
= Number of bytes
to be transmitted minus 2
for end sequence which is inserted bySSXI()S .•'
Receive function •••
Byte 1
=Number of bytes received"
Tim er function .•.
Byte 1 = Number of program tim$ 1ntenvpts processed
before ending timer operation
TPBUFDT
3
Start of data~rea of length d~f1ne4 QY .·;&TPStJF$~ti'
which includes •••
TPBUFHD
3
BSC header value indicating the function (Read,write,
timer) to be performed as defined bySCAfunCtion' indicators
HASP Remote Terminal Processor
165
-{l'l~ct
- Page 4.14-25
HASP
TPBUFBF
TPBUFFR
TPBUFSR
4
5
6
Controls equence •••
Byte 0
= BCB
Byte 1
= first
byte of FCS
Control sequence •••
Byte 0
= Second
Byte 1
= RCB
byte of FCS
Control sequence •••
Byte 0
= SRCB
Byte 1
= SCB
HASP Remote Terminal Processor (1130) - Page 4.14-26
166
HASP
Output Element (Tank) Description
Local terminal output devices (printers, punch, etc.) receive data via
elements or tanks which are built by the commutator routine responsible for
proces sing TP buffers transmitted by HASP.
The general format of thes e tanks
is described below.
REFERENCE
WORD
DESCRIPTION
TANKWRDA
0
Chain word to next tank
TANKWRDB
1
Reserved
TANKWRDC
2
Control wOlid
Byte 0 = Reserved for device use
Byte 1 = SRCB from record received
TAN KWRD D
3
Control word
Byte 0 = Reserved for device use
Byte 1 = Actual tank data count
TANKWRDE
4
Start of variable length data area determined at
generation time
Note:
The element chain word and the data area must start on even
1130 word boundaries.
HASP Remote Terminal Processor (1130) - Page 4.14-27
167
HASP
Object DeS(k Format
The following is the format of the object decks (RPT1130" RTPLOAD)
produced from OS/360 assembler output by LETRRIP.
Text Card
Qolumn(s)
Description
1
'T' for text card identification
2-3
Absolute 1130 load address
4
Word count of data field
5-72
Da ta field (maximum of 34 words)
73-74
Checksum of columns 1-72
75-76
Identifica tion
77-80
Sequence number
End Card
Columrt(s)
Description
1
1£' for end card identification
2-3
Entry point to program loaded
4-72
Reserved
73-74
Checksum of columns 1-72
75-76
Identification
77-80
Sequenc,e number
HASP Remote Terminal Processor (1130) - Page 4.14-28
168
HASP
REP Card Format
Column(s)
Description
1
Any legal EBCDIC punch
2-4
II REP II
5
Blank
6
Load address format field:
IIL" for listing option where the specified load address
corresponds to the OS/360 assembler listing.
"X" for absolute 1130 core addres s
7
Currently unused but usually punched "0 II for continuity
8-11
Load address for 'first data word and is incremented by 1
for each additional data word.
REP cards may be con-
tinued by leaving this field blank
12
Blank
13
Format field for data following.
Subject to same definition
as column 6.
14-17
Data field to be loaded in the location computed as a
function of columns 8-11
18
II
II
I
•
•
•
HASP Remote Terminal Processor (1130) - Page 4.14-29
169
HASP
Columns 19 through 78 in the same format as columns 13-18 with the
exception of column 78 which must be blank. A blank in columns 18, 24, ••• 72
terminates the scan of the card.
Note: The "L" option causes the specified data to be divided by 2
for conversion from 360 byte data to 1130 word data.
HASP Remote Terminal Processor (1130) - Page 4.14-30
170
HASP
Examples of REP Cards
1.
The following cards:
o
00
J,1,
],
56
23
RREP L02208 X4C00,L004E,X4400,XOOOF
RREP
X74FF,XOOOO,X7],0],
Would result in the code represented below starting in 1130 core
location 1104 (Hex):
2.
],],04
$B
39, ,L
J,1,06
$TSL
],5
],],08
$MDM
0,-]'
J,1,OA
$MDX
The following card:'
o
00
J,1,
],
56
23
RRER LO]'772 X4C],S,X],FFS
Would be ignored because columns 2-4 not equal to "REP"
HASP Remote Terminal Processor (1130) - Page 4.14-31
171
HASP
4. 14. 2
Remote Terminal Main Loader (RTPLOAD)
RTPLOAD is an EBCDIC format loader which is loaded by RTPBOOT
into the upper part of defined 1130 core.
The 1130 core definition (which
is a RMTGEN variable) is used to specify the origin of RTPLOAD.
The format
of RTPLOAD (and RTP1130) is given in Section 4.14.1 under Control Blocks
and Da ta Forma ts •
RTPLOAD also reads and processes "REP" cards as well as the optional
/*SIGNON control card.
The major functions of RTPLOAD are:
•
Clears core from location 0 to "&RTPLORG-1"
•
Tests for a 2501 or 1442 card reader and initializes the card
read routine for the appropriate device.
• .
Reads RTPl130 program cards
I
performing the conversion from
card code to EBCDIC and loading the data into the specified locations.
•
Sets up the entry to RTPl130 when the end card is processed.
•
Reads and processes REP cards
•
Reads
I
I
if they exist.
converts and stores/*SIGNON and sets indicator for
RTP1130 signalling existance if /*SIGNON encountered.
•
Transfers control to RTPl130
HASP Remote Terminal Processor (1130) - Page 4.14-32
172
HASP
4.14.3
Remote Terminal Bootstrap (RTPBOOT)
The bootstrap loader
distribut~d
in object form as shown in the
subseq~ent
pages is specifically constructed to "bootstrap" the EBCDIC main loader
(RTPLOAD) into the core locations defined by "&RTPLORG" at RMTGEN time.
RTPBOOT loads into lower 1130 core via the load-mode format first card and
following binary program cards and EBCDIC conversion table cards. RTPBOOT
will load from a 2501 or 1442 card reader which is wired for the load-mode
sequence initiated by Ule console "LOAD" button.
HASP Remote TeJrnina1 Processor (1130) - Page 4.14-33
173
HASP
Figure 4.14.3 -Remote Terminal Bootstrap Card Format
Card
Col.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Card No. 1
12-11-7
1-2-9
12-11-1-8
12-11-7-8-9
11-0-1-6-9
0-2-6
4-7-8-9
blank
4-6
0-1-2
blank
11-2-5
4-5-9
12-0-1-2-5-6
1-2-8
12-11-1-3-4-5-6-8-9
12-11-3-4-5-6-7
1-2-8-9
12-11-1-3-4-5-6-8
12-3-4-5-7-9
12-11-1-3-4-5-7
12-11-4-7
1-6
12-11-1-4-8
12-4-7-8
12-11-1-4-7-9
12-4-8
12-11-1-4-9
12-11-3-4-6-9
1-6-9
12-11-1-3-4-6
1-2-6
12-11-1-4-6-7-9
12-11-1-5-6-7-8
12-11-1-5-6-8-9
12-11-1-3-4-8
12-11-1-3-4-7-9
2-3-5-6-7-8
2-3-5-6-7-8-9
11-0-1-3-4-5-6-7-8-9
.
Card No 2
12
11-0-3-5
11
blank
5
11-0-1-5
12-11-0-1-2-4-5
12-11
blank
12-11-1-5
5
1-2
12-11-0-1-4-5
12-11-1
blank
12-11-3
5
blank
12-11-0-1-2-3-4-5
11-0-1-3
11-2-4-5
blank
12-11-3-4-5
11-0-1
2-3-4-5
11-0-1-3
11-2-4
blank
12-11-3
11-0-1
3-5
11-0-5
3-4-5
11-0-1-3
11-2-4
blank
blank
I
11-0~3-4
11-0-2-4-5
4
Card No. 3
12-11-1-2-3-4-5
blank
5
11-0-1-5
4
11-0-1-5
0-1-2-3-4
11
blank
12-11-1-4
5
11-0-1-4
12-11-0-1-2-3-4-5
11-0-1-4-5
12-11-0-1-2-4
11-0-1
12-3-4-5
12-11
12-0-3
11-0-1
blank
12-11-3
12-11-1-2-3
blank
blank
11-0-3-4-5
2-3-4-5
4
0-2-4
11
5
11-0-1
3-4
11-0-1
blank
11-0-3-4-5
12-11-0-1-5
5
0-3-5
11
Card No. 4
12-11-1
12
12-11-2-3-4-5
12-11-1
5
11-0-1-5
12-11-0~2-3~4-5
11-0-1
blank
11-0-3-5
0-3
5
blank
12-1-5
5
12-1-5
12-11-2
12-11-1
1-5
11
12-11-3-4
12-11-0-1
1-2
11-2-3
11-0-2-3-4-5
blank
12-11-0-1-2-3-4-5
11-0-1
5
11-0-1-4-5
12-11-0-1-2-3-4-5
11-0-1-4
12-11-0-2
11-0-1
12-11-0-1-2-3-4-5
11-0-1
5
blank
blank
12-11-0-1-4-5
HASP Remote Terminal Processor (1130) - Page 4.14-34
174
HASP
Figure 4.14.3 (C ON T) - Remote Terminal Bootstrap Card Format
Card
Col.
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
Card No. 1
9
2-3-4-8
12-11-3-5-6-7-8-9
12-8-9
12-11-1-3-5-6-7-9
2-3-5-6-7
11-2-3-4-5-6
9
11-0-1-3-4-5-6-7-8-9
9
12-11-6-7-9
12-3-4-5-6-8-9
12-11-1-6-8-9
12-11-6
12-3-4-5-6
12-11-1-8-9
12-3-4-5-7-8
12-11-1-7
3-7
blank
1-2-6
1-2
blank
1
blank
12-11-7-8-9
12-1-3-4-6-7
12-11-1-7-9
11-2-4
11-0-1-3-4-6-7
2-3-7-9
2-3
11-2-3-4-5-6
4-7-8-9
11-0-1-7
8
blank
blank
0
1
Card No. 2
1-3
11-0-1-3
2-3
blank
12-0-1
11-0-1-4
12-0-4-5
11-0-2-4
12-1-2-3-4
11-0-2-4
11-2-3-4-5
12-11
blank
12-11-1-4
12-11-0-1-2-3-4-5
11-0-1-5
12-0-1-2-5
11-0-1
1-2-4-5
11-0-1-3
11-2-4
blank
12-0-1-3-4
11-0-1
blank
11-0-3-5
12-11-1-2-3-5
blank
11-3-4
11
blank
12-11-1-5
12
11-0-3-4
12-11-1-2-3-5
blank
12
11-0-3-4-5
0
2
Card No. 3
12-11-0-1-4-5
11-0-1
11-2-3-4-5
11-0-1-3
12-0-2-5
blank
1
1-2
12-11-1-2-3-4-5
12-11-1
12-0-1-3-4
11-0-5
blank
12-11-3-5
0-3-4
5
blank
11-0-3-4-5
0-2-3
5
blank
11-0-3-4
blank
5
1-2
11
1-4-5
11-0-1
blank
12-11-3
4-5
blank
12-11-0-1-2
12-1
blank
12-11-1-3-5
0-3-4
5
0
3
Card No. -4
0
11-2-3
12-0-1-3-5
blank
5
11-0-1-3
12-0-2-3-4-5
blank
blank
12-11-0-1-4-5
12
11-2-3
12-0-2-3-4-5
blank
11-1
blank
blank
12-11-5
2
1
5
12-11-0-2-5
12
11-2-3
12-0-1-2
blank
blank
11-0-3-5
12-11-1-2-3-5
blank
12-11-0-1-3-4-5
11
5
12-11-1
blank
11-2-3
blank
blank
0
4
, HASP Remote Terminal Processor (1130) - Page 4. 14-35
175
HASP
Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format
Card
Col.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Card No. 5
0
1
2
3
4
5
6
7
8
9
12-11-0-2-8-9
12-11-0-3-8-9
12-11-0-4-8-9
12-11-0-5-8-9
12-11-0-6-8-9
12-11-0-7-8-9
blank
·
·
·
··
·
··
·
··
·
·
··
·
·
·
·
·
·
·
·
Card No. 6
11-0-1-8
11-0-1
11-0-2
11-0-3
11-0-4
11-0-5
11-0-6
11-0-7
11-0-8
11-0-9
11-0-2-8
11-0-3-8
11-0-4-8
11-0-5-8
11-0-6-8
11-0-7-8
12-11-0-1-8
12-11-0-1
12-11-0-2
12-11-0-3
12-11-0-4
12-11-0-5
12-11-0-6
12-11-0-7
12-11-0-8
12-11-0-9
12-11-0.... 2-8
12-11-0-3-8
12-11-0-4-8
12-11-0-5-8
12-11-0-6-8
12-11-0-7-8
12-0
12-1
12-2
12-3
12-4
12;"5
12-6
12-7
Card No. 7
12
12-11-1-9
12-11-2-9
12-11-3-9
12-11-4-9
12-11-5-9
12-11-6-9
12-11-7-9
12-11-8-9
11-1-8
11-2-8
11-3-8
11-4-8
11-5-8
11-6-8
11-7-8
11
0-1
11-0-2-9
11-0-3-9
11-0-4-9
11-0-5-9
11-0-6-9
11-0-7-9
11-0-8-9
0-1-8
12-11
0-3-8
0-4-8
0-5-8
0~6-8
0-7-8
12-11-0
12-11-0-1~9
12-11-0-2-9
12-11-0-3-9
12-11-0-4-9
12-11-0-5-9
12-11-0-6-9
12-11-0-7-9
Card No.8
12-0-1-8-9
12-1-9
12-2-9
12-3-9
12-4-9
12-5-9
12-6-9
12-7-9
12-8-9
12-1-8-9
12-2-8-9
12-3-8-9
12-4-8-9
12-5-8-9
12-6-8-9
12-7-8-9
12-11-1-8-9
11-1-9
11-2-9
11-3-9
11-4-9
11-5-9
11-6-9
11-7-9
11-8-9
11-1-8-9
11-2-8-9
11-3-8-9
11-4-8-9
11-5-8-9
11-6-8-9
11-7-8-9
11-0-1-8-9
0-1-9
0-2-9
0-3-9
0-4-9
0-5-9
0-6-9
0-7-9
HASP Remote Terminal Processor (1130) - Page 4.14-36
176
HASP
,"
Figure 4 .14.3 (CONT) - Remote Terminal Bootstrap Card Format
Card
Col.
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
Card No. 5
blank
··
··
·
·
··
·
··
·
·
·
··
·
··
·
··
··
··
··
··
··
·
·
··
··
blank
.
Card No 6
12-8
12-9
12-0-2-8-9
12-0-3-8-9
12-0-4-8-9
12-0-5-8-9
12-0-6-8-9
12-0-7-8-9
11-0
11-1
11-2
11-3
11-4
11-5
11-6
11-7
11-8
11-9
12-11-2-8-9
12-11-3-8-9
12-11-4-8-9
12-11-5-8-9
12-11-6-8-9
12-11-7-8-9
0-2-8
11-0-1-9
0-2
0-3
0-4
0-5
0-6
0-7
0-8
0-9
11-0-2-8-9
11-0-3-8-9
11-0-4-8-9
11~O-5-8-9
11-0-6-8-9
11-0-7-8-9
.
Card No 7
12-11-0-8-9
1-8
2-8
3-8
4-8
5-8
6-8
7-8
12-0-1-8
12-0-1
12-0-2
12-0-3
12-0-4
12-0-5
12-0-6
12-0-7
12-0-8
12-0-9
12-0-2-8
12-0-3-8
12-0-4-8
12-0-5-8
12-0-6-8
12-0-7-8
12-11-1-8
12-11-1
12-11-2
12-11-3
12-11-4
12-11-5
12-11-6
12-11-7
12-11-8
12-11-9
12-11-2-8
12-11-3-8
12-11-4-8
12-11-5-8
12-11-6-8
12-11-7-8
Card No. 8
0-8-9
0-1-8-9
0-2-8-9
0-3-8-9
0-4-8-9
0-5-8-9
0-6-8-9
0-7-8-9
12-11-0-1-8-9
1-9
2-9
3-9 '
4-9
5-9
6-9
7-9
8-9
1-8-9
2-8-9
3-8-9
4-8-9
5-8-9
6-8-9
7-8-9
blank
12-0-1-9
12-0-2-9
12-0-3-9
12-0-4-9
12-0-5-9
12-0-6-9
12-0-7-9
12-0-8-9
12-1-8
12-2-8
12-3-8
12-4-8
12-5-8
12-6-8
12-7-8
HASP Remote Terminal Processor (1130) - Page 4.14-37
177
HASP
Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format
CARD 1
I II 1111 1I1I1I I 1I11I
I
II I II I I II I 111I1
III
I
I
III
11I111I1
I I I I II
1
I III I I
I
000011000100010000000000000000000000000100000000100000ooooo~oooooooooloooolooolo
12345&189ro"UQ"B~O~"~~nn~~unu~~~n~~~~VD~~~~u«a«~~a~~~~~ ~~~~"~~~~M~~"~~ronnnMmnnnn"
111111 1 1 111 1 11111111111111111111111111 11 1 1 1 111 1 11 11 11 1 11 111111111 1111.111 1 1111
J
11
21222122212121122122222222222221222221122122211222222222222211222221121.12222222
33333333333313311311133333331313333111113113111313313313131333333313311113333333
44444414144414411411114111111414144114414144441414414414144444444414114411444444
55555555555111511511155555555555511551115515181515515515155555555555555515555555
6 6 6 6116 616 6 6 61611616 6 616 6 6 6 sllllilis 6111 6 sl 6111 61 6111116 6 6 6 61 6 6.66616 61s 616 6 6 6 6 66
17717717777117171771117711717177117711117717111117177777111771717111711711171777
8811s81S888t8S11811818811s1888888111a1118111888818sl.ssl18888888tl88888881al8888
a
sl911919 9 9 9 91991sIs19 9 99 919111991 91 919111sIIIs 91 1IIIs91s 9 9 9 9 9 S9 9.191.9919 919 9 9 9 9 9
1 2 3 4 5 6 7 8 9 to II 12 13 14 15 16 111819 20 21
[3i""'-tC'!'D
2t 23 24 25 26 27 2i 29 SO 31 ;'2 33 34 35363138394041 42 ~3« 454641 484950 51
~253
54 55 56 51 58.59 SCEl 62 63 S4
5~
06 61 68€g 70 11 12 13 74 15 16
n 78 1960
CARD 2
I
II
I
I
II I
II I
I
III I
II I
III II II I I I II
I I I
II
I
I II I
I
I
II
I I
I
0 0 0 II 0
I 11I111I1111I1 II I II
o I 0 0 0 II 0 0 0 0 0 I 0 00 0 0110 0 0 I 0I 0 0 01 0I 0I 0 0 0II 0 o. 0 0IIII 0I 00 0 0III1 0I 0 0110 I 0 0 0 0 0 0 0 I
123456189ro"U~"BqOq~~~nD~~uDn~~~n~~~~UD~~~~u«a~~~~~~~~~~$~~~~~~~U~~UMUMnnn~mnnnn"
1 1 1 1111 1 111111 1 1 1 JII 1 1 1111 111111 11 1 1 J 1 1111 1111 1 11 1 1 1 11111111 1 111 111 1 1 1 11 1 11111 1 1
2 2 2 2 221 22221 2 2 2 2 221212 2 2.1 212 2 2 2 2 2 21 2 2 212 2 212 2 2 21111 22 21.212!
21 2 2 2 2 212 2 2 2 2 2 212 2 2 21
31 3 3 3 3 3 333 33 3 3313 3113 31 3113 3131311. 3 3 31·3 311133 3331313 3313 33·31 3313311313 3 3 3113 313 3
44444414444414444414141414144444141441114444411111144114441414144444144441444144
515 51115 511515 5515151 51515555 51115 5 5 5 5155 55 5 5 515551 555.111515 5 5 5 5 51155 5515515 5155
6 6 6 6 6 6 6 6 6 6666 6 6 666 6 6666 6 66 6 66 6 6 6 66 66 66 6 6 66 6 6 66 6 6 666 6 686 6 66 66 6 6 66 6 6 6 66 6 6 6 6 6 6 6 66 6 6
777 1177 1 711 7J 1177 777177117777777 17 7 11 7 71 7 7777 7 7 77 171 711 7 1117 J 7 771177 177 11 7 7 7 17 7 7
8 8 8 8 8 8 8 8 88 8 8 8 8 8 8 8 88 8 8 8 8 8 8 8 8
a.
8 888 8 88 8 8 i 8 8 8 88 8 8 8 8 8 88 8 88 8.8 8 8 8 a88 8 8 8 88 888.8 8 88 8 8 8 88 I
999999999999999999999999999 9't9 9 99 9 9 9999999999999999999999999999999.99999999999999
1 2 3 4 5 • J 9 9 10 l1J213
Q:tEJillITJ •
14.1516 11 18 13 20 ~ 2hl2~ 252621 ZU930 31 n 3334 3536 U 38 3940 41 42 4344 45 4647 4849 5051 5~ 535455 565J 585t&0 61 62 SHHS SHI U 69 liHI n 73 74 1576 n
.
.
.
.
7.1910
.HASP Remote Terminal Processor (1130) ~Page4.14-37.1
178
HASP
Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format
CARD 3
I
I I III
I I I I I
11111
I
II
I I II I
I I I II
I
I
1I111
III I
II I I
I II I
I I I I I
I
I
00010110000111110011000001001001010110101101100000110010011001000001000010001010
1 2 3 4 5 6 1 I 9 10
11
12 13 14 15 16 11 18 19 2021 222324 25 26 21 2829 30 31 323334 35363138 394J 41 42 4344 45 46 47 48495051 525354 55
I 1 11 111 1 11 111111 1 1 11 1 11 1 1 1 1 1 1 1 11 11 1 11 1 1 111
~5 ~~ ~.:
5960 61
~2
63 64 &HUH8 E9 70 71
72
73 74 15 76 7111 19 10
11 1 111111 1 1 1 1 1 1 1 1 1 1 1 1 111 DI 1 1 1 111 111 1 1 1
12222212222212122222221222121222222222222212122112222222221222221222222212222222
13333313333313331313311331133333133133133311333313133113311331333333313333311331
14441414414111141444444441111444144144441414444414144414414441444414441444441444
15115155551511551555555551155515555111151515155515515151515155515515551555515155
66666666666666666666666666666666666666666666666666666666666666666666666666666666
77777777777777777777777777777777777777777777771777171711711711117177711771777117
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8' 8 8 8 ! 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
99999999999999999999999999999999999999999999999999999999999999999999~99999999999
1 2 3 4 5 6 1 8 9 10 11 12 13 14 15 15 11 18 192021
G~~~EJ
n 23 24252627 l8 29 3031 32333435363738394041424344 45 46 47 4849 SO 51 ~2 53 54 5: !.; :: ~ 5300616263 64 SHU) EH9 7J
i! 12 7l 74 75 )5 71 13 ;g 80
CARD 4
11I1
I
I II III I
I III II
I I I I
II III II II 1111111
I I I II I
I
I I I I I I I
I I I
I I· II II I I
II I
00000111011000000000010010110111111100011010011001001000000001001001001000000010
123456
7891011UUU~~n~"~21nn~~nnn~~~HD~§~V~~W~a044~~O«~~~~~~~~~~~W~~6364~~U~"ron1271U15nnnnR
11111111111111111111111111111111111111111111111111111111111111111111111111111111
.
22122212222222221222221112122212121222222122221222211222221221211222122222212222
.
33133313311333333333133113133313331333333113311333311333333333313331131333313333
44144414444444444444144414144111441444414444441441441444444444444444441444444441
55151115515151115515555515151115551515515515151551551555515511555551151515555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
11777777177177111777171771111177771777717777171177777777771771717777171777777177
888888888888888888888888888888888888888~8888888888888888888888888888888888888888
99999999999999999999999999999999999999999999999999999999999999999999999999999999
123456
1S91011UU~~~na"~~nn~~~n3~~~nD~§~V~~o~ao«~~o«~~~~~~~~~~~~~~~~~~uunron72n~~nnnn~
O~14 5uoD.
;HASP Remote Terminal Processor (1130) - Page 4.14-37.2
179
HASP
Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format
CARD 5
111III
111111
10000000001111110000000000000000000000000000000000000000000000000000000000000000
123456189W"~UK~~n~a~~nn~ll~n~n~~~nM~~~~~U.~Q«~~na~~~~~~ ~~~~~~~~~~~"~u~ronn»~~nnnn~
1I 1 1 lIt 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 1 1 1 .1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 tIt lIt 1 tIl 1 1 1 1 1 1 1 1 1 1 1 lIt
22122222221222222222222222222222222222222222222222222222222222222222222222222222
3331333333313333333333333333333333333333333333333333 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 333 3 3 3 3 3 3 3 3
44441444444414444444444444444444444444444444444444444444444444444444444444444444
55555155555551555555555555555555555555555555555555555555555555555555555555555555
6 6666 61 6 6 6 6 6 661 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 666 6 6 66 6 6 6 6 6 6 6 66 66 6 6 6 6 6 6 6 66 666 66 6
77777771177777711177177777777777777777777777777777777777777777777777777777777777
88388888181111118888888888888888888888888888888888888888888888888888888888888888
9 9 9 9 9 9 9 9 9 1IIIIII 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9
1 2 3 4 5 & 1 8 9 lr !1 12 13 14 15 16 11 18 192021 n 23 24252. 2728233031 323334353637383940414243« 45 464748495051 5253 S4 55 5657 58 ~9 6061626364 G5 €6 616a 6970 11 n 73 14 1576 n 131980
L<':'5_"-'lJ
CARD 6
III11I
III1II111IIIII111111111111111111
II11III1IIII1I11
I111IIIIII1I11I11111111111111111
I
IIII1I
111111110111111111111111111111111000000000111111100000oooooooooolllllllDDllllBl1
123456
789;0"UUM~~nmaW21nn~~~Vnn~~Hn~~~n~~~~~~«~~~~~~~~~~~~n~~ ro~~~M~~u~~mnnn~nnnnn~
11111111111111111111111111111111111111111111111111111111111111111111111111111111
22122222221222222212222222122222221222222212222222122222221222221212222222122222
333133333331333333313333333113333331333!3~31333333313333333133333331333333313333
44441444444414444444144444441444444414444444144444441444444414444444144444441444
55555155~55551555555515555555155555551555555515555555155555551555555515555555155
66666616666666166666661666666616666666166666661666666616666666166666661666666616
77777771717777717771777177171171717777717117717177777771777777717177777177777771
18888888181111111888888818111111888888881811111188888888181111111388888818111111
91999999919999999999999991999999999999999111111199999999911111119199999991111111
1 2 3 4 5 6 7 8 9 :0 11 12 13 14 15 16 17 1. 192021 222324252621 2829 3031 3233343536373839404142434445464148495051 52
L'.~·" ~~f!.'J
~3 ~
5S SCi 51 S3 59&: 61 €2 6;5$
6~ i:H16~
£970
n 72 il 74 i516 17 iB ;9 80
HASP Remote Terminal Processor (1130) - Page 4.14-37.3
180
HASP
Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format
CARD 7
11I1I1111
I
11111I1111111111 1111111 I
11II111I1
1I1111111
11111111111111111111111100110111
IIIIIIIIIBIIIDII
00000000000000000111111111011111111111111000000011111111111111110000000000000000
1 2 3 4 5 & 7 • • 10 1\ 12 13 14 15 16 17 18 19 20 21 222324 2!J 26 21 ;.:; 29 30 31 32 33 34
3~
3& :i1 3!
3~ 4~
41 42 4344 45 46 41 4a 49
~O ~l ~2
53
~4
55 56 51 sa 59 i;} f' t: 6364 t5 66 67 68 6910 n 72 7l 74 15 i6
n 111980
til t 1 t 11111111111111111111111111111111111111111111111111111111111111111111111111
22122222221222222212222222222222221222222212222222122222221222222212222222122222
33313333333133333331333333313333333133333331333333313333333133333331333333313333
44441444444414444444144444441444444414444444144444441444444~14444444144444441444
55555155555551555555515555555155555551555555515555555155555551555555515555555155
"
66666616666666166666661666666616666666166666661666666616666566166666661666666616
77777771777777717777777177117771717177711117777171777171771777717777717171771771
88888838111111118888888811811111888888881111111118888888181111111888888818111111
91111111199999999911111119999999911111111999999999999999919999999999999991999999
j.: "
n
1 2 3 4 5 6 1
~
9 10 11 12 13 14 15 16 11 18 192021 2:::3;,25262728 2S 30
!3"'-'.'·(;'!...1
~I
32 3334353637 :is 39 40 4142434445464748495051 525354555657 Sd 51
f2 £3 G4 65 66 61 LS 63 70
7<
Jj
,4751;; n 161980
CARD 8
I111III11I11I1111
1II1I1I1III111111
IIIIIIIIIBIIIII
I
I
10000000000000000000000000000000111111111111111110000000000000000111111110000000
1 2 3 4 5 & 1 8 9 10 1\ 12 13 14 1516 1118192:121 2223242526 2128 29 30 313233343535 37 ~ 3. 404142434445464748495051 525354 55 56 57 sa 5960 61 &2 63 646566 67 68 69 70 n 72 73 74 75 J5 n.ll 19 80
11111111111111111111111111111111111111111111111111111111111111111111111111111111
2 21 2 2' 2 2 2 2 21 2 2 2 2 2 2 21 2 2 2 2 2 2 21 2 2 2 2 2 2 21 2 2 2 2 2 2 21 2' 2 2 2 2 2 21 2 2 2 2 2 2 21 2 2 2 2 2 2 21 2 2 2 2 2 2 21 2 2 2 2 2
33313333333133333331333333313333333133333331333333313333333133333331333333313~33
44441444444414444444144444441444444414444444144444441444444414444444144444441444
55555155555551555555515555555155555551555555515555555155555551555555515555555155
6666661666666616666666166666661666666616666666166666661666666£166666661666666616
11111111177177717117777117117171117111717777717171771771717717117177777117777771
188888881111111118888888111111111888888~1111111118888888111111118888888811111111
11111111111111111111111111111111111111111111111111'111111111111119111111119999999
4.41 48 49
~o
51 525354 S5 565158 5.
5~
61
~
&5 6S 61 SS £3 ;: 11 J2 )) 74 7576 1118 79 80
HASP Remote Terminal Processor (1130) - Page 4.14-37.4
181
HASP
4.14.4
Remote Terminal Program 360 Processing (LETRRIP)
LETRRIP (Loader for Eleven-Thirty Relocatable Remote Interleaving Processor)
is a 360 program executed under OS/360 as part of the RMTGEN procedure.
The purpose of this program is to condense the object deck produced by the
360 assembler; relocate address constants according to the requirements of the
1130 and to produce a new object deck in the format as described in Section
4.14.1.
HASP Remote Term1nalProcessor (1130) - Page 4. 14-38
182
HAS P
4.14.5
1130 Instruction Macros
The OS/360 Assembler Macro instructions listed on the following
pages are used to assemble the RTPl130 and RTPLOAD programs as a
part of the RMTGEN process necessary to create the 1130 workstation
program.
The general format of the instructions to be assembled with the
macros is:
LABEL $OP ADDR,TAG,FMT,MOD
Where:
"LABEL" is the statement label subject to the OS/360 assembler
rules and restrictions.
n$OP" is a macro from the set listed at the end of this section.
"ADDR" is the address field of the 1130 instruction.
"TAG" is the index register (TAG) field of the 1130 instruction.
"FMT" is the format indicator for the 1130 instruction:
FMT=L for long form
FMT=I for long form indirect address
FMT=X for short form absolute address
FMT='blank' for short form relative address
"MOD" is the modifier bits field required for some 1130 instructions.
Listed below are some of the conventions which must be followed to
successfully use the macro package in producing a program for
operation on an 1130.
1.
All symbols starting with the character "$" are deemed to be
absolute in value.
2.
The symbols WA, WB and we are assumed to define absolute values.
Note: WA, WB and we cannot be used as the first two characters
of any relocatable symbols.
3.
All other symbols are assumed to be relocatable as defined by
the OS/360 assembler SRL.
4.
Parenthetical expressions are considered to be relocatable if
contained in an instruction, e~g.,
$AXT ( *- *) , WA , L
is considered relocatable, where.
$AXT *-*,WA,L
is considered absolute.
HASP Remote Terminal Processor (1130) - Page 4.14-39
183
HASP
1130 Instruction Macros
Macro Form
Description And Notes
$LD
ADD, TAG, FMT
Load ACC
$LDD
ADD,TAG,FMT
Load double (ACC, EXT)
$STO
ADD, TAG, FMT
Store ACC
$STD
ADD, TAG, FMT
Store double (ACC, EXT)
$LDX
ADD, TAG, FMT
Load index
$LXA
ADD, TAG
Load index from address. A variation of $LDX
with F= 1 and IA = 1.
$AXT
ADD, TAG, FMT
Address to index true. Identical to $LDX.
$STX
ADD,TAG,FMT
Store index
$STS
ADD, TAG, FMT
Store status
$LDS
ADD, TAG
Load status
$A
ADD, TAG, FMT
Add
$AD
ADD,TAG,FMT
Add double
$S
ADD, TAG,FMT
Subtract
$SD
ADD, TAG, FMT
Subtract double
$M
ADD, TAG, FMT
Multiply
$D
ADD,TAG,FMT
Divide
$AND
ADD,TAG,FMT
Logical AND
$OR
ADD, TAG, FMT
Logical OR
$EOR
ADD, TAG,FMT
Logical
Exclusiv~
OR
HASP Remote Terminal Processor (1130) - Page 4.14-40
184
HASP
Macro Form
Description And Notes
$SLA
ADD, TAG
Shift left ACC
$SLCA
ADD, TAG
Shift left and count ACC
$SLC
ADD, TAG
Shift left and count ACC and EXT
$SRA
ADD, TAG
Shift right ACC
$SRT
ADD, TAG
Shift right ACC and EXT
$RTE
ADD, TAG
Rotate right ACC and EXT
$BSC
ADD, TAG, FMT,MOD Branch/Skip on condition
$BOSC
ADD, TAG, PMT, MOD Branch/Skip and reset interrupt
$BP
ADD, TAG, PMT
Branch ACC positive (long)
$BNP
ADD, TAG, PMT
Branch ACC not positive (long)
'$BN
ADD, TAG, PMT
Branch ACC negative (long)
$BNN
ADD, TAG, PMT
Branch ACe not negative (long)
$BZ
ADD, TAG, FMT
Branch ACC zero (long)
$BNZ
ADD,TAG,FMT
Branch ACC not zero (long)
$BC
ADD, TAG, FMT
Bra nch on carry (long)
$BO
ADD,TAG,FMT
Branch on overflow (long)
$BOD
ADD, TAG, FMT
Branch ACC odd (long)
$SKPP
Skip ACC positive (short).
$SKPN
Skip ACC non-~ero (short)
$SKPZ
Skip ACC zero (short)
$SKPO
Skip overflow off (short) .
HASP Remote Terminal Processor (1130) - Page 4. 14-41
185
HASP
Macro Form
Description And Notes
$SKPC
Skip carry off (short)
$SKPX
Skip ACC not equal zero and carry off (short)
$B
ADD, TAG,FMT
Branch unconditionally. FMT = L or I generates
long form $BSC with MOD
FMT
=
= X or blank generates
0.
$MDX
$BSI
ADD, TAG, FMT,MOD Branch conditionally and store IAR
$TSL
ADD, TAG,FMT
ADD, TAG, FMT
Transfer and store location counter. Assembled
as a $BSI with FMT
= L, MOD =
° (long form
unconditional branch and store IAR).
$MDX
ADD, TAG, FMT
Modify index and skip
$STL
ADD,FMT
Store location counter. Assembles as $STX
ADD,O,FMT.
$MDM
ADD ,VALUE
$WAIT
·Modify memory.
Wai t for interrupt
$XIO
ADD, TAG, FMT
Execute I/O
$BSS
N,X
Block started by symbol
N = number of words.
X =E ..for even storage.
$BES
N,X
Block. ended by symbol
·~·.=='nUmbetof·words
iC==~Af6t
evens torage
:Btr'R~~~~:;·T.fiR.trial'W&cess()r (1130) -Page 4.14-42
~1$6;
HAS P
Macro Form
Description and Notes
$NULL
Null operation for symbol definition
$ADCON
ADDR
Address constant. Assembles as an
absolute 1130 address.
"ADDR" must
be a relocatable symbol by the
as
assembler definition.
$NOP
No operation. Assembles as $SLA 0
$ZAC
Clear ACC. Assembles as $SRA 16
HASP Remote Terminal Processor (1130) - Page 4. 14-43
187
HAS P
4.14.6
GENERAL INFORMATION
OS/360 ASSEMBLY OUTPUT
If the value of &FULLIST is set to 1 at the time of generation
of RTPl130 or RTPLOAD then the listing produced by the OS/360
Assembler will contain the following informatio~:
1.
The location counter value for each 1130 instruction or
storage location in terms of bytes. The actual 1130
location in terms of words can be determined by dividing
the displayed value by 2. The REP facility allows a
specification of either byte or word form.
2.
The 1130 instruction is printed in 1130 format. The long
form address is in terms of 1130 words and the short form
is true relative format.
VARIABLE INTERNAL PARAMETERS
The generation of the RTPl130 program using RMTGEN provides
the user with a simple and flexible means of changing common
parameters germane to the configuration of the 1130. Additional internal parameters may be varied by using the source
file update feature of the RMTGEN program.
Listed below are the major parameters, with a brief description of each, which the user might consider altering as a
function of hardware and software performance considerations.
VARIABLE
DESCRIPTION
&DEBUG
Conditionally assembles the RTPl130 internal
core dump program ($SDUMP) and the BSC adapter
trace routine (DBUGSCAL). Default value
inhibits the assembly of these debugging
programs.
&CNPSIZE
Maximum console printer message size.
value is 120 bytes per message.
&CONINSZ
Maximum console keyboard input buffer size.
Default value is 120 characters per command.
&PRFOTKL
Number of 1403 printer buffers (tanks) provided
at assembly time. Default value is 2. The
TPGETprocessor.will buildup to the value of
&PRFOTKL and then suspend operation for the l40J
until the count of buffers falls below &PRFOTKL
Default
HASP Remote Terminal Processor (1130) - Page 4.14-44
188
HAS P
VARIABLE
DESCRIPTtON
&PRETTKL
Number of 1132 printer buffers (tanks) provided
at assembly time. Default value is 2. See
&PRFOTKL for TPGET action.
&PUNFTKL
Number of 1442 punch buffers (tanks) provided
at assembly time. Default value is 2. See
&PRFOTKL for TPGET action.
&CONSTKL
Number of cons~le printer buffers (tanks) provided at assembly time. Default value is 5.
See &PRFOTKL for TPGET action.
&PRFOBFL
Maximum number of TP buffers containing data
destined for the 1403 printer which will be
accepted by TPIOX before setting the transmission suspension bit defined in the FCS for
the 1403. HASP will suspend transmission of
1403 print data until the FCS bit is reset
when the number of l4-03TP buffers becomes
less than the value of &PRFOBFL. Default value
is 2.
&PRETBFL
Same definition as &PRFOBFL except it applies
to the 1132 printer. Default value is2.
&PUNFBFL
Same definition as &PRFOBFL except it applies
to the 1442 punch. Default value is'2.
&CNSPBFL
Same definition as &PRFOBFL except it applies
to the console printer. Default value is 1.
&NPTFBFL
Maximum
devices
Default
of card
number of TP buffers allotted to input
collecting data to be sent to HASP.
value is one greater than the number
readers defined for RTP1l30.
HASP Remote Terminal Processor (1130) - Page 4.14-45
189
HAS P
4.15
EXECUTION TASK MONITOR
4.15.1
Execution Task Monitor - General Description
The Execution Task Monitor is a processor which periodically examines the CPU utilization of user tasks within a dynamic priority
group and rearranges the OS/360 task dispatching chain giving
higher priority to those tasks, within the group, which use the
least amount of CPU time. Tasks above and below the dynamic priority group are not affected by the rearrangement of the dispatching chain. Tasks with all of the following characteristics are
included within the dynamic priority group:
I
I
1.
The task belongs to a job scheduled by HASP.
2.
The current dispatching priority of the task is
3.
a.
equal to priority of the dynamic group as specified
by the value of the &XZPRTY parameter for MVT or
b.
not greater than the value &XZMFTH and not less than
the value of &XZMFTL for MFT.
The HASPGEN parameter &XZMULT is set to "YES n or if not
"YES" the task is a job step with no daughters.
The interval between the periodic examinations is controlled by the
value of the &MONINTV parameter. Setting &MONINTV value to a positive integer will cause the processor to be generated. OS/360 must
support Job Step Timing and must not have a Time Slicing Group Defined at the priority 1evel(s) cor;esponding to the priority range
of the dynamic group.
Users must not use TlME=1440 on Job or
Execute cards for jobs to be correctly adjusted within the dynamic
group.
Execution Task Monitor Processor - Page 4.15-1
190
HASP
4.15.2
Execution Task Monitor - Algorithm
The Execution Task Monitor determines the CPU utilization history (h t , n)
for each task within the dynamic priority group using the following formula:
h t n=cPUt, n +ht - 1 , n - Ht/N
I
= Total CPU counts observed for the N tasks being
monitored plus the sum of the previous history values.
N = The number of tasks being monitored at the end of
the time interval.
h t, n
= The history of CPU utilization for task (n) during
the current time interval.
ht - 1 , n
= The history of CPU utilization for task (n) taken at
the previous time interval.
New tasks, entering the monitored group, will be assigned a hi-story
value of zero and temporarily placed at the low priority end of the group.
Task with continuous low values of CPU counts will have (h) values. which
become increasingly negative. The (h) values will be prevented from falling
below the range of one time interval; thus providing responsiveness to
erratic changes in the corresponding task's CPU utilization.
Low values of h indicate the task (1) has not been able to utilize the
CPU time given to it because of waiting for events such as I/O or (2)
Execution Task Monitor Processor -
191
Page 4.15-2
HAS P
has not been given the opportunity to utilize the cpu. High values
of h indicate the task has had the opportunity and has utilized the
cpu. The Execution Task Monitor performs a partial sort and rechains
the monitored tasks, insuring that the task with the largest history
of cpu utilization will have the lowest effective priority within the
dynamic priority group during the next time interval. This will by
default raise the effective priority of other tasks in the group.
When HASPGEN parametsf:' &XZMULTis set to "YES" all tasks for a jobstep falling within the priority group are ordered as a single unit
allowing each task to maintain the same relative priority with
other monitored tasks within the jobstep. In MVT systems, a task
within the group that changes OS dispatching priority is removed
from the group.
In MFT systems, all monitored tasks are assigned an as dispatching
priority ~pecified by the &XZMFTL parameter. A CHAP or ATTACH that
specifies a change in priority will have the effect of changing
relative priority; however, as long as the task remains within the
range &XZMFTH and &XZMFTL the assigned priority will be changed to
&XZMFTL at the end of the monitor interval &MONINTV. A CHAP in an
MFT system may therefore not produce the intended result.
Execution Task Monitor Processor - Page 4.15-3
192
HASP
4 . 16
INTERNAL READER
4. 16 . 1
Internal Reader - General Description
The Internal Reader Processor is an Input Service Processor which
reads card images from any system or user task running under OS/3 60 .
The Internal Reader recognizes
Processor interface routines
I
I
through the use of Execution Control
an attempt by other tasks running under 08/360
to punch information into "cards" on pseudo 2520 punch devices
the function of the Input Service Processor on each card
I
I
performs
and via OS/360
POST macro signals completion of I/O to the submitting task.
4 . 16 .2
Internal Reader - Program Logic
The Internal Reader uses the code of the Input Service Processor with
modifications in the following areas.
1.
Processor Initialization -
The Internal Reader attempts to
obtain an internal reader device control table (DCT) which
contains an 80 byte buffer area rather than a normal
reader DCT. When a device is received the processor
continues by acquiring a direct-accessDCT and passes
. control to the main processor.
2•
Main Processor -
The Internal Reader RGET routine tests
for the existance of a submitting task punch channel program.
Internal Reader Processor 193
Page 4.16-1
HASP
If no channel program exists the Processor will wait for
WORK.
If a channel program exists RGET will simulate the
punching of one card into the 80 byte OCT buffer area (no
data chaining). If the channel command represents the
end of the channel program RGET posts completion of I/O
and resets channel program indicators.
RGET returns to
the main processor passing the card image for processing
or in the event the "card
lf
has If/*EOF" in columns 1 to 5
returns indicating end of file.
3•
Processor Termination -
Termination of the Internal Reader
involves terminating the last job (if any), rei.easing the
direct-access and internal reader device OCT's, and passing
control to the processor initialization routines.
The Internal Reader requires supporting routines in the Execution Control
Proces sor Asynchronous I/O Handler which perform the following functions:
1.
Recognize EXCP macro references to designated internal readers
as setup by HASP initialization.
2.
Make the internal reader available to the Input Service Processor
on first use.
3•
Set up the first channel command word and lOB pointers.
4.
Force the submitting task in the wait state if required.
5.
Post the Input Service Processor for WORK.
Internal Reader Processor -
194
Page 4. 16-2
HASP
4. 17
MULTI- LEAVING LINE MANAGER
4. 17. 1
MULTI- LEAVING Line Manager -
General Description
The function of this proces sor is to control all line activity with remote
terminals. This includes line initiation/termination, remote terminal
synchronization, line error recovery
I
and sign-on/sign-off processing.
This processor interfaces very closely with the Remote Terminal Access
Method described in section 5.15.
4. 17. 2
MULTI- LEAVING Line Manager -
Program Logic
When this processor receives control from the dispatcher it first
determines whether an I/O operation has completed.
If not, it then scans
each line (via the line Device Control Tables) to check for requested
processing. When all processing has been completed the processor then
returns control to the dispatcher ($WAIT ' s) until such time as more work
becomes available.
When a channel end is detected, the channel end routine determines
the sequence type of the Channel Command Word chain and branches to the
appropriate section to analyze the channel end and initiate any error
recovery procedures required.
The line Device Control Tables (DCT's) are scanned and when one is
found to be available the Line Initiation routine is entered which acquires
MULTI- LEAVING Line Manager -
195
Page 4. 17-1
HASP
the DCT, acquires a TP buffer, constructs an initial CCW chain and
I
initiates
I/o
on the line.
A single timer queue element is maintained by the Line Manager to
initiate delays in line processing. This facility provides the capability
of delaying a null response to a remote terminal and decreases the
associated degradation. Various other timer queue elements are maintained
by individual line processors to initiate other delays of varying intervals.
The code in this processor is assembled conditionally such that only
the instructions required to process a given configuration will be generated.
MULTI-LEAVING Line Manager 196
Page 4.17-2
HAS P
4.18
REMOTE CONSOLE PROCESSOR
4.18.1
Remote Console Processor - General Description
The function of this processor is to process all console
messages to and from remote terminals.
This routine
optionally saves messages to remotes which are not "signed
on" MULTI-LEAVING terminals for later printing on the
remote terminal printer.
4.18.2
Remote Console Processor - Program Logic
This processor receives control whenever a console message
is queued for a remote terminal or whenever a console message is received from a remote terminal.
The processor
first examines the output queue of messages and upon encountering a message queued for a remote terminal examines
the current status of the terminal.
If the terminal is
not an active BSC MULTI-LEAVING terminal the message is
purged (the console message buffer is returned to the
available queue) or the message is saved on the SPOOLI
volume if operator message SPOOLING is requested.
If the message is to be written, a Remote Console Device
Control Table is constructed for the specific remote terminal, the DCT is chained onto the other DCTs for this
remote, the DCT is "OPENed" by calling the Remote Terminal
Access Method, all messages which are queued are written
to the terminal, and the DCT is "CLOSEd" and unchained.
If the message to be written is for a currently inactive
or for a non-MULTI-LEAVING active remote and HASP operator
message SPOOLING space is specified (&SPOLMSG ~ 0), an attempt to save the message on the SPOOLI volume for later
printing at the remote by printer support routines is made.
The remote MESSAGE SPOOLING QUEUE ($MSPOOLQ) element for
the designated remote is examined for a queue HEADER entry
of zero.
If zero, a record is allocated from the MESSAGE
ALLOCATION ($MSALLOC) Table, and the corresponding MTTR for
the record is placed in both HEADER and TRAILER entries
for the remote.
(Non-zero but equal HEADER and TRAILER
entries signify that the queue exists; however, since the
last record of each remote element is always empty no data
is currently queued). A record is allocated from the
$MSALLOC table to represent the new end of message queue
and the associated MTTR is placed in the chain field of the
current HASP buffer. The HASP buffer is then filled with
the operator message and any more messages for the same
remote currently queued and· written on the SPOOLI volume
Remote Console. Processor - Page 4.18-1
197
HAS P
at the record location designated by the TRAILER MTTR for
the remote. Upon completion of I/O the chain field replaces
the TRAILER MTTR. The above process is repeated for additional buffers as required to empty the console message
queue for the remote.
In the process of allocating message records the $MSALLOC
table bit map is used. Each bit in the map when on represents a free record on the SPOOLI volume. Allocatron consists of finding the highest numbered bit that is on,
turning the bit off, and converting to a corresponding MTTR.
When all bits in the map are off indicating that no records
are available, the messages are purged.
If an input message is to be read, a Remote Console Device
Control Table is constructed and the Remote Terminal Access
Method is utilized to "GET" the message. The message is
written to the local console and then queued for the Command
Processor.
Remote Console Proc"essor - Page 4.18-2
198
HAS 'P,'
4.19
4.19.1
'EXECUTION THAW PROCESSOR
EXECUTION THAW PROCESSOR - GENERAL DESCRIPTION
XTHAW is a companion to the main Executionp'to:ces.~cjriIC)S;
interface routine called XFREEZE. XTHAW is,res:ponsible :fot
discovering which tasks have been forcibly placed iri '(in: 'OS
WAIT state by XFREEZE (frozen) and should 'now ,be activClted
(thawed) thru the OS POST ECB mechanism.
'
4.19.2
EXECUTION THAW PROCESSOR - PROGRAM LOGIC
XTHAW uses an lOB (HASP buffer) chain constJ:'ucte~'thrutn.e
XTHAW PCE or the Execution Processor PCE(s) ,in the 'XPCEECa
field of the PCE work area. The chain iscohstructedusing
the XTHAW or an Execution PCE depending on the reason fqr
invoking XFREEZE. If the lOS interface $ection J..s'~ntered
while an Execution processor is active, th~n, theXTHAW PCE
is used. If an I/O request cannot be, proc~$'sedClnd an
Execution processor is not active at the tiITl;~ 9f"1;.he'req'uest:"
then the PCE controlling the caller is used 'to' build the
chain.
XTHAW is activated ($POSTed) by the Execution Processor
whenever a Job or the HASP controlled OS ;Reader/Interpreter
is active and just prior to $WAITing f()r.wor~ •.
A spe¢~Cll
status bit (XPOSTBIT) in the XPCESTAT field., 'of ail ,Execution
PCE is used as the primary test for processingeh:~:\q~~Bcl'l.ail1.
This bit is not turned on when the OS ReaderlIIl~E!t"pr~'te'~ , .
is active and assigned to a PCE but does nothav~ajob to
process. This prevents unnecessary activ~ti~Il(th4~ing).of
the Reader/Interpreter when noJobsare.av~i~apl'c!'::~for,' j,.niti:ation.·
.. "
' ,
XTHAW performs the. following major
funci:i()~~::~~:';;
!;~': '::
(1)
(2)
(3)
.".
Examines theXPCEECB field of,the·Xw~w'pr()ceSl$or.
'
If this field ianon-zero, itiS'\ls~d·~,:'~p.e,.,~.q,;l.nt~r
to a chain of. ,lOBs (HASP b.tffers) Wl'li'?tl<:QQntr~~~i;::I:Ca'S
t9 be POSTed' (thawed) and the HASl?/(JS"'~cg~,+,).•:\ibi9.ij~ine
(WPOSTECB) is used ~o perform ,the .POS~4!?,:~'Tfle,i:cb~in
aSldress for ~he lOBs is contained'in.th@;.lOJa~,$W< £l~ld
which is set to zero for the last I013.-.,;:-" .,:~. ",,,,>.:
..
Next, . the ,Exepution PCEs are sea;r:',c;h~4::<';9.~,);;,tbex~o~~lJIT
condition ,and the XPCEECB field is, Pr.9<:
~
Ii::! 0
.,-l
O+J
E-t
.,-l
~ro
'0
Ii::!~
Z
H...c::
H U
lL-________________
~- - -L-1-.n-e- '-'n- "-T-e-x-t- - - - - - - - - - - ~r ~~~
WTO/WTOR Processing Routine -- Page 5.12-6
265.2
HAS P
5.13
CONSOLE BUFFERING AND QUEUING ROUTINES
The following routines are responsible for the queuing and
de-queuing of all conso·le and log messages.
5.13.1
CONSOLE BUFFERING ROUTINE - PROGRAM LOGIC
The Console Buffering Routine is used to prepare a message
buffer with the information required to process a console
message. At entrance registers zero and one contain the information shown in figure 5.13.1.
The routine makes use of three tables comprised of one-byte
entries. The bits in each byte specify the physical consoles
which are to be used for the respective entry. In the first
($WCONTBL) each byte corresponds to one of eight consoles.
The bytes are ORed for each specified symbolic console to
set the physical byte for a write operation.
A second table ($WCLASTB) has an entry for each of the sixteen possible .message classes. The appropriate byte is ANDed
with the physical consoles byte to screen out consoles with
the class set too high.
In addition to setting the console routing byte, the Console
Buffering Routine supplies the other information shown in
figure 8~4.l. Prior to returning to the caller, the routine
places the message in the log queue (non-HASP messages with
a job number); or in the queue of messages to be processed
by the Console Input/Output Processor (all other output
messages and all reads).
5.13.2
CONSOLE QUEUING ROUTINE - PROGRAM LOGIC
This routine places a console buffer into a queue of messages,
according to priority, to be processed by the Operator Console
Input/Output Processor and $POSTs that processor.
5.13.3
LOG QUEUING ROUTINE - PROGRAM LOGIC
This routine places a console buffer at the end of the queue
of messages to be processed by the HASP Log Processor and
$POSTs that processor.
Console Buffering and Queueing Routines- Page 5.13-1
266
HAS P
5.13.4
CONSOLE BUFFER FREEING ROUTINE - PROGRAM LOGIC
This routine places the console buffer in the free queue.
The Attention Processor's PCE is examined to determine if
the Attention Processor is $WAITing for a console buffer,
and if it is, the Attention Processor is $POSTed and exit
is made. If the Attention Processor is not $WAITing, the
$WTORQUE is tested and the first ,task found is POSTed. If
no tasks are waiting, the HASP Event Control Field is $POSTed
and exit is made.
Console Buffering and Queueing Routines - Page 5.13-2
267
HAS P
Figure 5.13.1 -- CONSOLE BUFFERING ROUTINE PARAMETER REGISTERS
Displacement
Hex.
o
Dec.
0
r------------------------
4
Consoles
Specified
Message
Length
Priority
& Class
( RJ')
XI 00 I = $WTO
X ' 80 ' = WTO
8
------------------------~
(RO)
Flags
4
4 bytes
Message Address (or Zero for Read)
8
Console Buffering and Queueing Routines - Page 5.13-3
268
HASP
5.14
INPUT/OUTPUT ERROR LOGGING ROUTINE
5 . 14. 1
Input/Output Error Logging Routine -- General Description
This routine is entered whenever an unrecoverable Input/Output error
occurs on a HASP direct-access intermediate storage device
I
or whenever
line errors occur which may require the attention of the operator. A
message is generated describing the error and this message is routed to
the operator via the operator's console.
The routine then returns without
taking any further action.
5. 14.2
Input/Output Error Logging Routine -
When this routine is entered
I
Program Logic
register" RI" contains the address of
the Input/Output Block (lOB) which is as sociated with the Input/Output
operation in error. The channel status
information track address
I
I
I
channel command code
I
sense
and line status are retrieved from the lOB
and formatted; the unit address and volume serial are obtained from the
Unit Control Block (UCB); the device name (if applicable) is acquired
from the Device Control Table (DCT); and the message is written to the
operator's console.
The format of the message describing a direct-access error is as
follows:
Input/Output Error Logging Routine 269
Page 5.14-1
HASP
I/O ERROR ON SPOOLn
uuu, cc, ssss, iiii, bbcchhr
where:
n
-
identifies the SPOOL disk in error
uuu
-
unit address of disk
cc
-
channel command code being executed
ssss
-
channel status code
iiii
-
unit sense information
bbcchhr
-
track addre s s a s follows:
bb
bin (always -zero)
cc
cylinder
hh
head
r
record
The format of the message describing a line error is as follows:
I/O ERROR ON LINEm
uuu,cc,ssss,iirr,ttee
where:
m
-
line number
uuu
-
unit addres s of line
cc
-
channel command code being executed
ssss
-
channel status code
ii
-
unit sense information
Input/Output Error Logging Routine 270
Page 5.14-2
HASP
where:
rr
-
STR - sense information
sse tt
ee
-
terminal response
internal sequence and command code
STR - alway s blank
sse -
expected response
Input/Output Error Logging Routine 271
Page 5.14-3
HASP
5.15
REMOTE TERMINAL ACCESS METHOD (RTAM)
5.15.1
Remote Terminal Access Method -- General Description
The Remote Terminal Access Method provides an interface between the
HASP Processor and the Remote Terminal.
RTAM provides blocking/deblocking,
compression/decompression, and synchronization with the remote terminal
in such a way that the processor need not be concerned with the characteristics of the remote with which he is communicating.
The MULTI-LEAVING
Line Manager synchronizes very closely with RTAM through a series of
subroutines, the more important ones, of which, are briefly described
below .
. 5.15.2
Remote Terminal Access Method -- Program Logic
The Remote Terminal Access Method consists of four main sections
and some miscellaneous subroutines.
This section discusses the four
main sections: OPEN, GET, PUT, and CLOSE.
The primary subroutines
are discussed in Section 5.15.3 below.
OPEN
The OPEN routines convert the line from an idling mode of opera tion
to a transmit or receive mode of operation. In the case of the MULTILEAVING interface, this routine also generates the request or permission
to begin a new function.
Remote Terminal Acces s Method -- Page 5. 15-1
272
HASP
The GET routines convert data received from the line into EBCDIC
images suitable for processing by the HASP processors.
This conversion
includes deblocking, decompression, and conversion from line code to
EBCDIC.
The PUT routines convert data from EBCDIC into a form ready to be
transmitted to the remote terminal.
This conversion includes compression,
blocking, and conversion from EBCDIC to line code.
CLOSE
The CLOSE routines convert the line from a transmit or receive mode
of operation to an idling mode of operation.
5. 15. 3
Remote Terminal Acces s Method -- Subroutines
This section describes the primary subroutines used by the Remote
Terminal Access Method and the MULTI-LEAVING Line Manager.
MSIGNON -- Sign-On Card Processor
This subroutine is passed the address of a /*SIGNON card in register
"Rl". If the line from which the Sign-On Card was read was defined to be a
"leased" line, the Sign-On Card is ignored and the subroutine returns immediately. If the line is a "dial" line, the MABORT and MDISCON subroutines
are called to disconnect any other remote which may have been attached to
Remote Terminal Access Method -- Page 5. 15-2
273
HASP
this line.
The password is then checked and if not valid, an error message
is issued and the subroutine returns.
If the password is valid the specified
Remote Terminal's DC T' s are loca ted and examined.
If the specified remote
is already attached to another line or if the specified remote is not locatable,
the subroutine issues an error message and returns.
Otherwise, the specified
remote is attached to the line and a confirmation message is issued.
MCCWINIT -- Channel Command Word Sequence Setup Subroutine
This subroutine is passed a sequence type in bits 24-27 of register
"Rl".
The subroutine then constructs a CCW chain based upon this value
and returns.
Figure 5.15.1 depicts the various CCW sequences which can
be constructed by the subroutine.
MINITIO -- MULTI-LEAVING Input/Output Interface
This subroutine analyzes t}:le status of a MULTI-LEAVING Remote Terminal
and takes appropriate action to minimize degradation while insuring maximum
line throughput.
The subroutine first establishes the status of every pro-
cessor currently active on the MULTI-LEAVING line.
Then, based upon the
active input processor count, the active output processor count, the status
of the remote terminal, and the status of input and output buffers queued
wi thin HASP either transmits an ACKO to the terminal, transmits a text buffer
to the terminal, or initiates a one-second delay.
Remote Terminal Access Method -- Page 5.15-3
274
HASP
MEXCP -- Remote Terminal Input/Output Interface
This subroutine interfaces the Remote Terminal Access Method with
the standard HASP" $EXCP" Input/Output Interface.
I/O
I
In addition to initiating
this subroutine also provides the MULTI-LEAVING Block Control Byte
sequence count
I
and the BSC 2770/2780 parity check (ACKO-ACK1)
conversion.
Remote Terminal Access Method -- Page 5.15-4
275
HASP
Figure 5. 15. 1 -
HASP Remote Terminal CCW Sequences
STR Hardware Terminal Prepare Sequence (code = 4)
FLAGS
INTERNAL
CODE
0
60
40
1
LCBMCB
60
4:L
2
ENABLE
0
60
42
1
IOBCCW4
TEST SYNCH
0
60
43
15
IOBCCW5
SEND INQUIRY
0
20
4A
6
FLAGS
INTERNAL
CODE
0
60
50
1
LCBMCB
60
51
2
CCW
COMMAND
IOBCCW:L
DISABLE
IOBCCW2
SET MODE
IOBCCW3
DATA ADDRESS
BYTE COUNT
S TR CPU Terminal Prepare Sequence (code = 5)
CCW
COMMAND
IOBCCW:L
DISABLE
IOBCCW2
SET MODE
IOBCCW3
ENABLE
0
60
52
1
IOBCCW4
TEST SYNCH
0
60
53
15
IOBCCW5
SEND EOT
0
60
5B
6
IOBCCW6
PREPARE
0
60
57
1
IOBCCW7
READ
TPBUFST
20
54
STPBFSIZ
DATA ADDRESS
BYTE COUNT
'Remote Terminal Access Method -- Page 5. 15-5
276
HASP
Figure 5. 15. 1 (continued) -
HASP Remote Terminal CCW Sequences
S TR Read Sequence (code =0: Hardware; code =1: CPU)
CCW
CQ\1MAND
DATA ADDRESS
FLAGS
INTERNAL
CODE
BYTE COUNT
IOBCCW:L
TEST SYNCH
0
60
03/1.3
1.5
IOBCCW2
PREPARE
0
60
07/1.7
'1.
IOBCCW3
READ
TPBUFST
20
04/1.4
&TPBFSIZ
IOBCCW4
STEP COUNT
0
60
00/1.0
1
IOBCCW5
ERRCR
0
60
00/:L0
1
IOBCCW6
TIC
IOBCCW3
00
00/10
0
S TR Write Seguence (code =2: Hardware; code = 3: CPU)
CCW
COMMAND
DATA ADDRESS
FLAGS
INTERNAL
CODE
BYTE COl,J\JT
IOBCCW1.
TEST SYNCH
0
60
23/33
1.5
IOBCCW2
SEND INQUIRY
0
60
2A/3A
6
IOBCCW3
WRITE
TPBUFST
20
28/38
*-*
Remote Terminal Access Method -- Page 5.15-6
277
HASP
Figure 5.15. 1 (continued) -
HASP Remote Terminal
eew Sequences
Bse Prepare Sequence (code =C)
FLAGS
INTERNAL
CODE
0
60
CO
:L
LCBMCB
60
CJ,
:L
0
60
C2
:L
MBSCSYN
60
CA
4
IOBCCW5
NOP/WRITE MBSCENQ/MBSCEOT
60
CA
:L
IOBCCW6
READ
20
C6
2
CCW
CCl-1MAND
IOBCCWJ,
DISABLE
IOBCCW2
SET MODE
IOBCCW3
ENABLE
IOBCCW4
NOP
DATA ADIRESS
LCBRCB
BYTE COUNT
Bse MULTI-LEAVING Terminal Seguence (code =9)
FLAGS
INTERNAL
CODE
0
60
92
:L
MBSCSYN
60
99
4
WRITE
LCBRCB
60
99
2
IOBCCW4
READ
TPBUFST
20
94
&TPBFSIZ
IOBCCW5
NOP
MBSCSYN
60
98
4
IOBCCW6
WRITE
TPBUFST
60/AO
98
*-*
IOBCCW7
WRITE
METBSEQ
60
98
2
IOBCCW8
READ
TPBUFST
20
B4
&TPBFSIZ
CCW
COMMAND
IOBCCWJ,
ENABLE
IOBCCW2
NOP
IOBCCW3
DATA ADDRESS
BYTE COUNT
Remote Terminal Access Method -- Page 5.15-7
278
HASP
Figure 5. 15. 1 (continued) -
HASP Remote Terminal
eew Sequences
Bse Hardware Terminal Read Seguence (code =8)
FLAGS
INTERNAL
CODE
0
60
82
:L
MBSCSYN
60
89
4
WRITE
LCBRCB
60
89
2
READ
TPBUFST
20
84
&TPBFSIZ
FLAGS
INTERNAL
CODE
BYTE COUNT
0
60
A2
:L
CCW
COMMAND
IOBCCW:L
ENABLE
IOBCCW2
NaP
IOBCCW3
IOBCCW4
DATA ADDRESS
BYTE COUNT
Bse Hardware Terminal Write Sequence (code =A)
CCW
CO'1MAND
IOBCCW:L
ENABLE
IOBCCW2
Nap
MBSCSYN
60
AA
4
IOBCCW3
WRITE
MBSCENQ
60
AA
:L
IOBCCW4
READ
LCBRCB
20
A6
2
IOBCCWS
NaP
MBSCSYN
60
A8
4
IOBCCW6
WRITE
TPBUFST
60
A8
*-*
IOBCCW7
WRITE
METBSEQ
60
A8
2
IOBCCW8
READ
LCBRCB
20
AS
2
DATA ADDRESS
Remote Terminal Access Method -- Page 5.15-8
279
HAS P
5.16
OVERLAY SERVICE ROUTINES
5.16.1
Overlay Service - General Description
These routines, together with the Overlay Roll Pr6cessor described in Section 4.20, respond to calls from other HASP Processors
when the macros $LINK, $ LOAD , $XCTL, $ RETURN , and $DELETE are
executed in HASP coding.
This enables certain executable and table
portions of HASP coding (assembly control sections created by use
of the $OVERLAY macro) to be brought into main storage from their
normal direct access residence for use during HASP execution.
Major objectives of Overlay Service and Roll logic are:
to allow
multiple Processors to use a single copy of the same overlay routine
simultaneously, and to prevent any system lockout due to SWArTs in
overlay routine coding.
The overlay data set is constructed as part of HASP installation
by the HASP Overlay Build utility, described in Sections 10.2.2
and 6.3, and is referred to by the ddname OLAYLIB in the job which
invokes HASP.
All Overlay Service and Roll Processor coding is located in module
HASPNUC.
Service entry points are addressable by register BASEl
and are referenced by macro expansions through the HASP Communication Table.
Actions necessary to initialize HASP Overlay Service are contained
in module HASPINIT and are de~cribed in Section 6.1.2.
See Sections 8.3.3, 9.7, and 12.14 for descriptions of Overlay
Area(s) format, macros mentioned above, and coding rules relating
to use of overlay routines.
5.16.2
$LINK Service - Program Logic
On entry, register "RIS" contains the address of the next instruction after $LINK and register "LINK" contains the called routine's
Ocon. An Ocon is an index into the HASP Overlay Table, which is
the control section HASPOTAB created by the HASP Overlay Build
utility, whose individual entries are defined in OTBDSECT, created
by the $OTB macro.
The calling Processor's registers "RO-WC" are saved in the caller'$
PCE.
Overlay Service base address is established in register "WC".
Register "RIS" is saved in PCEORTRN.
"RIS" is set to the relative
displacement of the calJed routine entry point from the beginning
of an' Overlay Area lOB, i.e., OACEPROG-BUFDSECT.
The called
routine Ocon is saved in PCEOCON, then used to compute the address
of the Overlay Table entry for the called routine.
If &DEBUG is set
Overlay Service Routines - Page 5.16.1
280
HAS P
to YES, field OTBCALLS is incremented by one.
priority is moved to PCEOPRIO.
The called routine's
If the Overlay Table indicates that the called routine was made a
permanent part of the HASP Load Module at Overlay Build time,
register BASE3 is loaded with the address of a theoretical Overlay
Area containing the res~dent routine (BUFSTART-BUFDSECT bytes prior
to the routine itself), caller's "RO-WC" are reloaded, and control
is passed to the called routine at its entry point.
If the called routine is not permanently resident, a search is made
of all Overlay Areas in the system. If the called routine is found
in an area (PCEOCON equal to area's OACEOCON), the caller's PCE is
added to the chain of all active users of the area.
This chain
begins at OACEPCE and continues through PCEOPCE of each PCE, if
several user~ are on the chain, and ends with a zero chain word. A
test is made for illegal nested $LINK if &DEBUG is set to YES, see
Operator's Guide for error message.
If the called routine is in
process of being read into the area from direct-access, the calling
Processor is made to $WAIT on OLAY, to be later activated by the
Overlay $ASYNC Exit (see 5.16.9). Otherwise, caller's "RO-WC" are
reloaded and control is passed to the called routine entry point,
with register BASE3 containing the address of the Overlay Area lOB
for use as the overlay routine base address.
If the called routine is not found while searching all Overlay Areas,
the search attempts to find an Overlay Area which is not currently
in use. It may contain an overlay routine but may not have active
users (OACEPCE must be zero). The inactive area containing the routine of lowest priority (OACEPRIO) will be used, subroutine OLOD
(see 5.l6.8) will be called to start reading the called routine from
direct-access, and the calling Processor will be $WAITed on OLAY,
to be later activated by Overlay $ASYNC Exit (see 5.l6.9).
If no inactive areas are found, the calling PCE is placed on a Queue
waiting for an Overlay Area. The Queue be-gins at the word $WAITACE,
continues in descending priority order by PCEOPRIO using chain word
PCEBASE3, and ends with a zero chain word.
If several PCEs are on
the Queue requesting the same overlay routine (PCEOCONs equal), only
the first PCE is on the above chain, the others are chained from it
using word PCEOPCE. All PCEs in the Queue are $WAITed on OLAY.
This Queue is emptied by the Overlay Roll Processor, as described in
Section 4.20, or by the OEXIT subroutine, as described in 5.16.7.
Overlay Service Routines - Page 5.16.2
281
HAS P
5.16.3
$LOAD Service - Program Logic
$LOAD shares almost all logic with $LINK (see 5.16.2).
register conditions are identical to those for $LINK.
Entry
"R15" is not saved in PCEORTRN.
"R15" is not set to the relative
entry point of the called routine.
When the called routine is found in an Overlay Area or read into
one by later system actions, "R15" still contains the address of
the next instruction after $LOAD. subsequent use of "RI5" as an
absolute entry point results in control being returned to the caller
with the routine in an actual or theoretical area, addressable by
BASE3 as with $LINK.
5.16.4
$XCTL Service - Program Logic
$XCTL logic shares almost all logic with $LINK (see 5.16.2).
register conditions are identical to those for $LINK.
Entry
"R15" is not saved in PCEORTRN. $XCTL is legal only when it logically follows another $XCTL or an original $LINK. Subsequent
$RETURN uses PCEORTRN as stored by the original $LINK to return
control from Overlay Service to the original caller.
Before doing entry actions for the new called overlay routine, the
OEXIT,subroutine is called (see 5.16.7) to remove the calling
Processor's PCE from the cha~n of users of the current overlay
routine.
5.16.5
$RETURN Service - Program Logic
On entry, register LINK points to the next instruction after $RETURN
and also contains the condition code and program mask as set by a
BAL instruction. BASE3 points to an actual or theoretical area containing the current overlay routine.
Caller's "RO-We" are saved in the PCE.
is established in WC.
Overlay Service base address
The OEXIT subroutine is called (see 5.16.7) to remove caller's PCE
from the chain of users of the current overlay routine.
Returned condition code is re-established using an SPM instruction.
Caller's "RO-WC" are reloaded. Control is returned to the address
previously saved in PCEORTRN by $LINK.
Overlay Service Routines - Page 5.16.3
282
HAS P
5.16.6
$DELETE Service - Program Logic
$DELETE is nearly identical to $ RETURN , except that it is used to
release control of an overlay routine previously $LOADed.
On entry, register LINK points to the next instruction after $DELETE.
This is stored in PCEORTRN and all actions described for $RETURN
are performed.
5.16.7
OEXIT Subroutine - Program Logic
This subroutine is used by service routines for $XCTL, $RETURN, and
$DELETE to release use of the current overlay routine by the calling
Processor. On entry, register WA contains the subroutine return
address and register BASE3 contains the address of an actual or
t~eoretical (permanently resident routine) Overlay Area containing
the current overlay routine.
If the current overlay routine is permanently resident, OEXIT returns
immediately. Otherwise, the chain of all users of the area (beginning at OACEPCE and continuing through PCEOPCE) is searched and the
caller's PCE is removed.
If other Processors are still using the
area, OEXIT returns.
If the above actions result in the Overlay Area becoming inactive
(OACEPCE equal zero), the $WAITACE Queue (see 5.16.2) is inspected.
If PCE(s) are waiting, the top priority group of one or more requesting the same overlay routine i~ de-queued, the address of the first
such PCE is placed in register "RI", and OEXIT simply falls through
to 'the OLOD subroutine (5.16.8), which eventually returns to the
caller of OEXIT.
5.16.8
OLOD Subroutine - Program Logic
This subroutine is used by service routines for $LINK, $ LOAD , $XCTLi
by the Overlay Roll Processor (see Section 4.20); and indirectly
by users of the OEXIT subroutine (5.16.7).
Its purpose is to start
a read for a requested overlay routine from the direct-access device
containing the overlay data set. On entry, register WA contains the
subroutine return address, register BASE3 contains the address of an
actual Overlay Area to be used, and register "Rl" contains the address of the first of a group of one or more PCEs requesting the
same overlay routine, chained from the first PCE by PCEOPCE.
OACEPCE of the Overlay Area is pointed to the first PCE. OACEPRIO
and OACEOCON are set to indicate the routine which will reside in
Overlay Service Routines - Page 5.16.4
283
HAS P
the area.
The Overlay Table entry for the requested routine is
accessed and, if &DEBUG is set to YES, field OTBLODS is in~remented
by one.
The relative T and R in the overlay data set of the requested
routine is obtained from the Overlay Table.
The address of the
Overlay DCT is loaded into register "Rl".
If the overlay data set
is on any SPOOL volume (device type DA in the DCT} , an absolute
form of MTTR is computed and stored in DCTSEEK. This conforms to
$EXCP requirements for SPOOL volumes (see S.8) and allows $EXCP to
remember SPOOL arm positions.
If the overlay data set is on a
non-SPOOL direct-access volume, the standard OS form of MBBCCHHR
is computed and stored in IOBSEEK.
See Section 6.1.2 for initialization of the Overlay DCT and data set.
Hardware read operation is requested by using the $EXCP macro.
The
Overlay DCT specifies that when the read operation is complete,
Overlay $ASYNC Exit is to be entered. All PCEs chained from
OACEPCE are already $WAITing oLAY , to be later activated by Overlay
$ASYNC Exit (see S.16.9). OLOD then returns to its caller or caller
of OEXIT.
5.16.9
Overlay $ASYNC Exit - Program Logic
This routine is entered when under control of the Asynchronous Input/
Output Processor ($ASYNC) PCE (see Section 4.8) an overlay read opera.
tion (started by OLOD subroutine, see 5.16.8) is posted complete.
On entry, register "RI" points to the Overlay Area.
BASE2 is set
to the base value for the Oyerlay Roll Processor, which is used for
local addressability.
"RlS" contains the return address to $ASYNC.
The chain of all users of the overlay routine just read (begins at
OACEPCE, continues through PCEOPCE) is processed.
Each PCE's
re-entry address ("RlS", now stored in PCER15) is absolutized by
adding the address of the Overlay Area, if the value in PCERlS is
determined to be relative.
The address of the Overlay Area is also
stored in each PCEBASE3, to provide addressability when the Dispatcher activates each Processor.
The function $POST for OLAY is
performed on each PCE to make it dispatchable.
If OS lOS has posted the read complete with a permanent I/O error,
each PCE's (on OACEPCE chain) re-entry address (PCERlS) is pointed
to a routine which types the message "UNREADABLE OVERLAY
"
and enters a permanent $WAIT. The Overlay Area is freed for other
use.
If &OREPSIZ is set to zero, this Exit returns to $ASYNC. Otherwise, the Overlay REP storage area is examined to see if any REPs
were read during HASP Initialization (see 6.4) which may apply to
Overlay Service Routines -.Page 5.16.5
284
HAS P
this overlay routine.
REPs whose CSECT name (last four characters)
match OACENAME are applied. The assembly origin (OACEASMO) of the
routine is subtracted from the REP address and the BUFSTART address
of this Overlay Area is added, to determine the memory location to
be patched.
Return is finally made to $ASYNC to allow other processing to continue. The Dispatcher will enter each Processor using the overlay
routine just read.
Overlay Service Routines - Page 5.16.6
285
HAS P
(The remainder of this page intentionally left blank.)
286
H.A S 1)
6. ()
iv1ISCELLANEOUS
This section contains d.::tai.led internal inf·;rrnation about miscel1aneou:;
routine S 1nl.bedded in
0:1'
i.nvulved w'ith the HAS
primarily for use by sy ~·;tenH~
Sv
f3tern an(1
is intended
r,l :)grarnrner s.
Miscellaneous -_. Fag,
287
().
.l
HAS P
6.1
HASP INITIALIZATION
6.1.1
HASP Initialization - General Description
The purpose of HASP initialization is to initialize for HASP job
processing.
Initialization builds the required control blocks and
makes modifications to the Operating System nucleus which allows
HASP to monitor the execution of jobs.
HASP Initialization is designed to provide either a "cold" or "warm"
starting capability. A "cold" start is one which starts the system
anew.
Only those jobs which are entered after a "cold" start will
be processed. A "cold" start does not have any requirements as to
configuration except as defined in the HASP generation parameters.
A "warm" start is a restart.
Checkpointed information is read from
the SPOOLl volume and the queued jobs and data from the last processing are recovered.
This type of start requires, as a minimum,
that the SPOOL volumes that were used during the previous execution
be on-line. Extra SPOOL volumes, up to a total of &NUMDA volumes,
may be added.
6.1.2
HASP Initialization - Program Logic
Initialization begins with the issuing of the HASP Supervisor Call
which turns control over to the HASP Initialization SVC Routine.
On
return the HASP task will be in the Su~ervisor State with protect
key of zero.
Register I points to a 11st of resolved nucleus
addresses and a return point for resetting HASP to problem state.
These addresses are moved into the HASP Communication Table (HCT)
for later use by the system.
Since HASP Initialization resides in the same area as the main HASP
buffer pool as designated by the HASP parameter &NUMBUF and portions
of the initialization routines are executed from overlay control
sections, all HASP processors except those required for initialization and console processing are placed in the hold status. The
command processor peE is altered to tefer to the Root Segment of
HASP Initialization, which resides in the data portion of the
first buffer used for HASP SPOOLING. The HASP Initialization WTOR
is then displayed via OS WTOR facilities.
Initialization then waits
for the operator to respond with the desired options. The options
are then compared again'st the Initialization Options table and the
appropriate bits in the' $OPTSTAT field in the HCT are set or reset
in accordance with the options specified.
If any option is incorrectly entered, an error message is issued and the $OPTSTAT field
is set to the default option configuration.
(Refer to STARTING THE
HASP JOB Section of the HASP Operator's Guide.)
HASP Initialization - Page 6.1.1
288
HAS P
The HASP REP routine (described in Section 6.4) is entered for
optional alteration of the resident portions of the Operating
System or HASP (resident or overlay control sections)
a
Preparation Of. Overlay Service
The Overlay OCT is prepared by indicating that it is in use, usc,'
only for reading, that Overlay $ASYNC Exit is to be entered on
completion of any operation which was started by using Overlay
DCT, and that Overlay Roll Processor is the owner of the DCT.
The overlay data set is described by a DO card having ddname of
OLAYLIB.
DEVTYPE and OPEN macros are used to determine the number of tracks/cylinder of the overlay volume and data set extent.,
which is placed as the last (&NUMDA+l) extent in HASP's single
multi-extent direct-access DEB. The overlay data .set is closed,
since HASP uses its own constructed I/O control blocks.
The overlay data set ueB address is stored in a table used to
withdraw or abort HASP and the ueB is made allocated, permanently
resident, and private.
The number of tracks/cylinder and extent are used to compute a
beginning absolute TT of the overlay data set, which is stored
. in the Overlay OCT for later use by the OLOD subroutine (see
Section 5.16.8).
Locating Spool Volumes
AlIOS ueBs are searched via the DCB lookup table and direct-acee 2
volumes with volume serials of SPOOLx are examined for use for HASP
SPOOL volumes. As each device is examined, the ueB is allocated
by turning on the private, reserved, permanently resident, and
allocation indicators. The UCB locations and sixth volume serial
character are saved in a temporary workarea for later reference.
If during the ueB search multiple volumes with the same serial'
or too many SPOOLx volumes are found, an error message is displayed/
SPOOL volume ueBs are deallocated and the HASP job is terminated
Upon completion of a successful allocation of SPOOL volumes, control is passed to Direct-Access Initialization.
0
HASP Initialization - Page 6.1.2
289
HAS P
Direct-Access Initialization
Direct-Access Initialization (NGDAINIT) gains control after all
Spool devices have been found by initialization; initialization has
built a table of six-byte entries (NSPOOLLI) describing the directaccess devices upon which Spool disks are mounted, of which each
entry appears as follows:
o
1
I I
dev
vol
2
lueB
4
I
unused
where:
dev
is the low-order byte of the direct-access
device type;
vol
is the low-order byte of the volume serial
number; and
UCB
is the device1s UCB address.
Before checking for warm start, NGDAINIT establishes where the
checkpoint record is to be placed on SPOOL1. To do this, it first
calls the DEB/TED setup routine to establish certain statistics
about all mounted Spool volumes and then issues an OBTAIN macroinstruction for SYSl.HASPACE on SPOOLl. The checkpoint information
will reside on the first track of this data set (the first two
tracks if &JITSIZE is not zero); accordingly, NGDAINIT sets up
the necessary channel programs using the OBTAINed information.
WARM START
If the operator requested a warm start, NGWARM reads the checkpoint
information directly into the area from which the checkpoint
processor will write it; the information consists of the HASP job
queue, the track group map, printer checkpoint information, mis~
cellaneous status information (including direct access checkpoint
information) and, optionally, the job information table (JIT).
The direct access checkpoint information, $DACKPT, consists of
&NUMDA six-byte entries of the following form:
2
0
1
Idev
I vol Is s s s
4
Ie e e e
where:
dev
is the low-order byte of the direct-access device type;
vol
is the low-order byte of the volume serial number;
HASP Initialization - Page 6.1.3
290
HAS P
ssss is the starting absolute track number of data set
SYSI.HASPACE on the indicated SPOOL volume; and
eeee is the ending absolute track number of the first
extent of data set SYSI.HASPACE on the indicated
SPOOL volume.
For SPOOLl, the starting track number excludes the checkpoint
tracks.
NGWARM insures that each volume specified in the direct-access
checkpoint is mounted and, with the help of subroutine NGALLOC,
that its extents are unchanged.
If not all volumes are mounted,
or if any extents have been changed, or if a cursory check of
a volume shows that it is not properly formatted, NGWARM writes
a message and sets a quit switch to cause HASP to quiesce.
If all volumes specified by the direct-access checkpoint are
correct, NGWARM checks for (and formats if necessary) newlymounted volumes. Then it again calls subroutine NGDEBSET to
allow for the possibility that the order of Spool volumes in
NSPOOLLI (by unit address) may not have been the same as in $DACKPT;
the final order is that of $DACKPT.
Now NGWARM relocates the HASP job queue, if necessary. The job
queue as recorded in the checkpoint record contained main storage
addresses; if HASP does not now occupy the same core locations as
it did before, each main storage address in the HASP job queue (and
in pointers to the job queue) must be adjusted to reflect the current main storage location of the job queue.
After relocation, NGWARM scans the job queue to check the busy bit
of each active entry and to reset certain flags.
If a busy bit is
on, NGWARM turns it off and issues a WTO to inform the operator
that the job was reading,- executing, printing, or punching. Additionally, if the job was reading, NGWARM uses HASP queue management routine $QREM to delete the job's queue entry.
At the end of the job queue, NGWARM gives control to NGEXIT,
which assembles and format-writes the checkpoint information;
restores the HASP appendage table pointer in $DADEBl, the HASP
multi-extent direct access DEB; counts the number of allocated
track groups (one-bits) in the track group map; and gives control
to NINITWTO.
COLD/FORMAT START
If the operator specified cold or format start, NGCOLD first zeros
out the track group map. Then NGCOLD processes each mounted SPOOL
volume.
For each volume, NGCOLD uses subroutine NGALLOC to process the DSCB
for SYSI. HASPACE. This subroutine issues, the OBTAIN macro-instruction to retrieve the DSCB; if OBTAIN's return code is not zero, an
appropriate error message is printed via WTO.
If the return code is
HASP Ini tia'lization - Page 6.1.4
291
HAS P
zero, NGALLOC computes and saves lower and upper absolute track
numbers.
If NGALLOC operated normally, NGCOLD now tests for an operator
specification of COLD; if the test is positive, NGCOLD calls subroutine NGREADCT to read and validate the count field of the first
record of the last track of the first extent of SYSI.HASPACE on the
volume.
If the count field is invalid, or if the operator specified
FORMAT, NGCOLD calls NGFORMAT to format the first extent. NGFORMAT
issues an unconditional GETMAIN for core in which to build a formatting channel program and data, builds them, and formats each
track by calling NGEXCP, which merely issues an EXCP and a WAIT
and checks the post code.
After the volume has been inspected (and formatted if necessary),
NGCOLD calls NGMAP to calculate the number of track groups in this
volume and the track group number of the first track group. NGCOLD
increments the overall number of track groups available for allocation by the quantity returned from NGMAP and then calls NGBITMAP
which turns on in the master track group map the bits corresponding
to available track groups on this volume. Then NGCOLD processes
the next volume.
When all volumes have been processed NGCOLD refreshes certain
checkpoint information (the HASP job queue, the print checkpoint
information, and some miscellaneous checkp'oint information) and
gives control to NGEXIT, as above.
The DEB initialization subroutine, NGDEBSET, initializes certain
HASP and OS control blocks and allows a great degree of SPOOL
device independence.
When called, NGDEBSET first puts into $DADEBI the address of the
HASP TCBi it also changes the DEB appendage address to point to
the standard lOS appendage.
(The appendage address is restored
by NGEXIT.)
It checks for SPOOL I and quiesces HASP if SPOOL I is
not found. Then NGDEBSET processes the Spool volumes.
For each volume, NGDEBSET calculates number of records per track
using information from the device characteristics table IECZDTAB
in the OS nucleus and the formula given with the DEVTYPE macroinstruction in the OS System Programmer's Guide. Then it sets up
certain information in an entry of the Table of Extent Data (TED).
Then, after setting the UCB address in $DADEBI, NGDEBSET performs
the same functions for the remaining volumes and returns to the
caller.
HASP Initialization - Page 6.1.5
292
HAS P
Activation of Overlay
If the overlay data set is contained on a SPOOLx volume, the
Overlay Device Control Table is adjusted so that $EXCPs done by
the OLOD subroutine (see 5.16.8) will use MTTR addresses and M
which refers to the DEB extent for the SPOOLx volume rather
than the overlay data set extent. The first Processor Control
Element (PCE) in the HASP chain is connected to the as save area
chain and, with register 13 pointing to the first PCE, Initialization enters the HASP DISPATCHER as though the first processor
had executed a $WAIT macro.
The HASP DISPATCHER will run the PCE
chain and dispatch the Initialization ROOT segment.
The ROOT
segment will $LINK to the first overlay control section HASPIOVA~
Unit Record Initialization -HASPIOVA
The OS UCBs are scanned for unit record devices. Devices which
are on-line on a DUAL Processor Model 65 system, have OS
scheduled I/O activity, or answer positively to a TID instruction
are considered real devices. Otherwise the devices are considered pseudo devices.
PSEUDO DEVICE INITIALIZATION - Pseudo devices are initialized by
flagging the UCB for later identification by the HASP Execution,
Processor SVC 0 intercept routines and are varied on-line.
Pseudo 2540 reader, 1442 special forms punch, and 1443 special
forms printer devices are especially noted and counts are maintained
for the HASP Execution Processor Device Allocation Routine.
Pseudo
1403 Printer UCS feature is removed from the UCB. Pseudo 2520
devices are identified and matched with an internal reader INTRDR
Device Control Table which is initialized for processing.
REAL UNIT RECORD DEVICE INITIALIZATION - Each device is matched with
a corresponding Device Control Table which is initialized for processing.
If the device is allocated by as, the DCT will remain
in the drained status causing HASP not to use the device unless
the operator starts the device by command. Automatic starting
reader and (as appropriate) HASP console UCB attention index values
are set to four allowing HASP to recognize the readying of the
readers or the pressing of the enter key(s).
(At least one HASP
console device is reserved for a 1052 type of device.)
If more
real unit record devices of each particular type are found than
available DCTs, an error message is displayed and the additional
devices are ignored.
Control is then passed to the Remote Job Entry or console initialization routines as appropriate via a $XCTL macro.
HASP Initialization - Page 6.1.6
293
HAS P
. Remote Job Entry Initialization - HASPIOVR
LINE INITIALIZATION - The OS UCBs are scanned for Synchronous
Communication Adapter devices.
The UCBs found are first matched
with one or more DCT and corresponding line descriptions (LINEmm
HASP Generation Parameters). Any DCT with a line description
which specifically designates the UCB will be initialized for the
UCB.
If no line description designates the UCB, tests are made
to determine if the adapter is physically on-line and, if so,
a DCT with a line description with "***" specified will be located
and initialized. Line devices will not automatically be started.
REMOTE DEVICE INITIALIZATION - Remote Device Control Tables are
connected and initialized with information contained in the corresponding remote description (RMTnn HASP Generation Parameter).
Each
group of RMr.RDn, ... ,RMr.PRn, ... ,RMr.PUn, ... for a given remote
are chained together for control by the MULTI-LEAVING-line manager
and RTAM.
In addition the printer and punch DCTs are removed from
the chain of all HASP DCTs and reinserted directly behind the
reader DCT for the corresponding terminal.
The device description
is converted to internal flags and placed in each of the corresponding DCTs.
If the line number is designate·i in the description
the line DCT is located, DCTs are chained together, and flags are
set to indicate non-signon remote.
-The HASP Remote Job Entry Buffer Pool is initialized and control
is passed to the remote console initialization routine or console
(local) initialization routine as appropriate by $XCTL.
Remote Console Initialization - HASPIOVS
The Operator Message Space is allocated and control blocks are inilialized.
The Remote Console Processor PCE and a direct-access DCT
are connected (the OCT is flagged IN USE).
The origin of the first
available track in the SYSI.HASPACE data set of the SPOOLI volume
and the base track address for operator message record allocation
is set into the MSAMTTR field of the MESSAGE ALLOCATION ($MSALLOC)
Table in the form:
OTTI (TT is the first track available for
messages).
The number of records per track for the mounted SPOOLI
volume is inserted into the MSARPTRK field.
If "cold" start was
performed by direct-access initialization, the Cylinder map for
SPOOLl is altered to reflect the allocation of sufficient adjacent
track groups starting with the group of the base track. The number of the last group is saved in the checkpoint records for
future "warm" starts.
If a "warm" start was performed by directaccess initialization, a check is made against the checkpoint record
to insure that the space required is within the allocated space.
Control is given to the console (local) initialization routine
by $XCTL.
HASP Initialization - Page 6.1.7
294
HAS P
Console Initialization - HASPIOVB
OS CONSOLE INITIALIZATION - Information is extracted from the OS
UCM and the Console processor is made ready for interfacing with
OS.
HASP CONSOLE INITIALIZATION - The Console DCTs are initialized
for HASP console support.
Each DCT that was matched with.. a UCB
by the unit record initialization routine is initialized for I/O
processing.
The corresponding authorization for each console
is converted to console restrictions and set into the DCT.
The
operator command $S console is simulated.
Control is passed to the intercept initialization routine via $XCTL.
Intercepts Initialization - HASPIOVC
The following intercepts are made in accordance with the, type of
the HOST Operating System MVT or MFT and the HASP generation
options as follows:
-
EXCP interface used for control of user I/O
LINK interface used to recognize events within as
XCTL interface used to recognize events within OS
and to interface with OS console support
SVC 35 - WTO interface for console support
SVC 36 - WTL interface for write to log support.
SVC
SVC
SVC
0
6
7
start Initiator, reader, and writer (optional) commands are issued
which start the procedures contained on SYSl.PROCLIB.
The reader
will be directed to the pseudo device & RDR and the writer will be
directed (if started) to the pseudo device &WTR.
In the event the HASP writer is selected in lieu of the OS writer,
the HASP writer module "HASPWTR" is attached.
If OS console support is selected, the HASP communications task is attached, via the
attaching of module "HASPBRl" which enters the console processor.
Control is passed to the HASP buffer building routine via $XCTL.
HASP Initialization - Page 6.1.8
295
HAS P
Buffer Build - HASPIOVD
An OS variable GETMAIN is issued to obtain storage for the alternate
buffer pool from the hierarchy as designated by the &BUFHICH
generation parameter. The actual amount of core is reduced by the
amount of reserved core (&RESCORE*1024) and used to determine the
number of buffers which may be created in the alternate buffer
pool along with the actual amount of storage needed.
Extra core
if any is released via OS FREEMAIN. The number of buffers which
may be created in the alternate pool is compared against the
expression of generation parameters:
&MINBUF - &NUMBUF
where &MINBUF
~
&NUMBUF = number of buffers
in the main buffer
pool
If the alternate buffer pool will not contain at least the number
of buffers specified by the expression a warning is issued.
The origin of the main and alternate buffer pools are examined to
determine which has the lower storage address. The pool with the
lowest address is created and chained to the $BUFPOOL chain of
buffers. The pool remaining is then created and chained to the
end of the first.
The operator is then asked to ENTER HASP REQUESTS (optional) and
the ROOT segment of HASP INITIALIZATION is entered via the $RETURN
ma~ro.
Activation Of Normal Processing
The ROOT SEGMENT returns the PCE to the Command Processor and, if
the operator specified REQ in the WTOR, enters the Command Processor.
If NOREQ was specified by the operator, all HASP Processors
are $POSTed and the Command Processor is entered.
HASP Initialization - Page 6.1.9
296
HAS P
6.2
HASP INITIALIZATION SVC ROUTINE
6.2.1
HASP Initialization SVC Routine - General Description
This program is a Type-I SVC routine which resides in the Operating
System Nucleus and provides the following basic functions:
1.
For HASP:
•
•
•
To give HASP a zero storage protection key.
To place HASP in supervisor state.
To return the address of key symbols in the nucleus
which are required for HASP processing.
To guard against recursive entries in order to prohibit
mUltiple copies of HASP from being initiated.
To provide the address of an entry which will cause
the SVC routine to be reset for HASP withdrawal and
cause the PSW to be reset to its initial value.
•
•
2.
For the HASP Reader/Interpreter Appendage:
•
To place the HASP JCL Exit routine in supervisor
state.
To return the left half of the PSW which was in use
when the SVC was invoked.
•
3.
For the non-HASP program:
•
To give an indication to any other program as to
whether HASP is currently active or not.
6.2.2
HASP Initialization SVC Routine - Program Logic
This program is a Type-I OS SVC routine.
It must be link-edited
with the nucleus to resolve the external address constants required
for HASP processing.
Upon entry, register 1 is compared with the EBCDIC characters "HASplI.
If the register does not compare, a condition code is returned to
the user in register 15 as follows:
Rl5 = 0 - HASP has not been initiated and is not currently
active.
R15
~
0 - HASP has been initiated and is currently active.
HASP Initialization - Page 6.2.1
297
HAS P
If register I contains "HASP", a test is made to determine if
HASP has been invoked.
If not, then this switch is set to
indicate that HASP is now active and the left half of the PSW
is saved for the "reset entry".
If HASP has been invoked, the protect key of the caller is
interrogated.
If this protect key is non-zero, the caller
is ABENDed with an appropriate ABEND code.
The SVC OLD PSW is modified so that the return to HASP will
place HASP in the supervisor state and give HASP a zero storage
protection key.
Register I is then loaded with the address of
a table of address constants of key nucleus addresses and return
is made through the os SVC FLIH. At this time register 0 contains the left half of the PSW which was in use when the SVC
was invoked.
One of the addresses in the nucleus address table is the address
of the SVC reset routine. When this routine is entered, it
resets the switch to indicate that HASP is no longer active.
It
then returns to the user by loading a PSW constructed by concatenating the left half of the original PSW with register 14.
HASP Initialization - Page 6.2.2
298
HAS P
6.3
HASP OVERLAY BUILD UTILITY
6.3.1
HASP OVERLAY BUILD - GENERAL DESCRIPTION
The purpose of this program is to process the object deck
output from the ten primary HASP assemblies. Overlay CSECTs
are extracted and written (each as a single record) to the
sequential overlay data set (ddname OLAYLIB), all references
to overlays from resident and overlay routines are resolved,
and all resident CSECTs (even if programmed as overlayable)
are passed to the OS Linkage Editor in a sequential data set
(ddname SYSLIN). Optional control cards are processed which
allow changing the status of any overlayable CSECT from actual
overlay to permanently resident and vice-versa.
The use of this program to install HASP (control cards, listings produced, etc.) is described in section 10.2.2.3, which
should be read as background to this description. Overlay
sJicvices and Roll logic, and Overlay Programming Rules are
de~cribed in sections 5.16, 4.20, and 12.14 respectively.
6.3.2
HASP OVERLAY BUILD - PROGRAM LOGIC
On initial entry, the time is sampled. A truncated "timelike" value is saved. This value will be placed into one
resident CSECT and one overlay CSECT. During HASP Initialization, if these two values do not match, an error message
is produced and HASP terminates.
All data sets are OPENed and the listing title line is printed.
If the control card data set is present (ddname SYSIN), cards
are read, printed, and processed until end-of-file is encountered. Each card contains an overlayable CSECT name beginning
in column 1, which must begin with "HA$". A SYM table entry
is made for each such name. An Oeon (index into the Overlay
Table, HASPOTAB) is assigned and a priority, if present in
column 16 of the card, is remembered. This 'information is
later used to override the normal processing of that CSECT,
when encountered in the object decks. A listing header line
is printed at the end of control card processing.
All objects decks are p'rocessed as a single sequential input
data set (ddname SYSOBJ). Only the four object card types
ESD, TXT, RLD, and END; as documented in OS/360 Loader PLM,
Y28-6714, Figures 30-34; are processed. All other cards are
wiitten directly to SYSLIN. If an object card with a valid
ESID number greater than the program's table limits (internal
assembly variable &MAXESID) is encountered, the program abends
with a UOlOl code.
HASP Overlay Build Utility - Page 6.3.1
299
HAS P
ESO card processing is essentially the construction of two
Tables from ESO information. The SYM table contains the
names of and information about any external names under overlay control (i.e. beginning with "HA$"). It is a global
table covering all object decks together. A name is entered
when a reference to it or CSECT definition of it is first
encountered, or during control card processing as previously
described. An overlay name in an ESO card item is first
searched for in the SYM table, and if found, changes are
made to the'existing entry. An error message is produced
for each duplicate definition of a previously defined overlay CSECT name and only the first definition is used. An
Ocon is assigned to each entry. When a name becomes a defined CSECT, if the fourth character is "0", the overlay
routine is actually to be made disk resident, and storage
is assigned to load its text.
The ESIO table is cleared at the beginning of each object
deck and constructed as ESO items are encountered, under
control of SYM table contents.
It is a table of words, in
order by ESID number. TXT and RLD card processing access
this table only.
It contains relocation values, Ocons, and
flags controlling the disposition of text and RLD items.
ESO items, for references to overlays or for definitions of
overlay CSECTs which are to be disk resident or are duplicated, are eliminated from an ESO card when processed, before
the ESO card is written to SYSLIN. This elimination is done
by changing them to type NULL or, if type LO, by physically
removing them and compacting the card.
TXT card processing has "three possible results. Text belonging to an actual overlay is loaded into memory, subject
to relocation according to storage assigned by ESD processing. Text of any overlay CSECTwhich is a duplicate of one
encountered previously is discarded. Text of non-overlay
CSECTs or overlays being made permanently resident is written
un-altered to SYSLIN.
RLD card processing concerns individual RLO items, as follows.
If an item applies to a discarded duplicate overlay CSECT, it
is eliminated.
If an item references a non-overlay CSECT,
it is left un-altered. An overlay reference item describes
a 2 byte Q type constant assembled in the expansion of the
$LINK, $LOAD, $XCTL, and $OCON macros. The reference is
resolved by substituting the Ocon value assigned to the referenced overlay routine, and the item is eliminated.
If the
Q constant exists in an actual overlay routine, the Ocon value
is simply moved to the proper address of the text already loaded in memory.
If the Q constant exists in a non-overlay CSECT
or overlay being made resident, a new TXT card containing the
Ocon value is created and written to SYSLIN. Eliminated items
are physically removed and the RLD card compacted before.
writing to SYSLIN.
HASP Overlay Build Utility - Page 6.3.2
300
HA S P
END card processing is really end-of-object-deck processing.
The card is written unchanged to SYSLIN. The entire SYM table
is then scanned for selected processing. Each actual overlay
whose text was loaded from the most recent object deck is
written to OLAYLIB as a fixed length record of length &OLAYSIZ
(internal assembly variable set to 1024 bytes in unmodified
HASP). A listing line is printed for each overlay CSECT defined in the most recent deck, with its length and assigned
OCON value. Priority and disk address in two forms are printed
for actual overlays. An error message is printed if an actual
overlay length exceeds &OLAYSIZ~
Processing of multiple object decks continues as above until
end-of-file for SYSOBJ is signalled. The entire SYM table is
then processed to produce the Overlay Table, which is written
to SYSLIN as a new object deck (did not exist in the input)
containing a single resident CSECT, HASPOTAB •. An error message is printed for any name in the SYM table which is ·still
not defined as a CSECT.
Each entry in HASPOTAB is 4 bytes or, if &DEBUG is set to YES,
12 bytes. The last 4 characters 'of the CSECT name are included
if entries are 12 bytes, to facilitate identification in a memory dump. If a routine is actual overlay (disk resident), the
TR (relative form) of disk address and the priority are placed
into the table entry for that routine. If an overlay routine
was written to SYSLIN by previous processing (to become permanently resident in the HASP load module), aV type constant
is created in its table entry. An appropriate RLD item referencing the CSECT name is created.
I
When HASPOTAB is complete, an END card for it is written to
SYSLIN, all data sets are CLOSEd and the program terminates.
Completion code 0 is returned normally, 4 if duplicate CSECTs
were encountered, and 8 if any overlays were too long or
undefined.
HASP Overlay Build Utility - Page 6.3.3
301
HAS P
6.4
HASP REP ROUTINE
This routine gives the systems programmer the capability of
applying absolute or relocatable value patches to HASP, at
absolute or relocatable memory addresses, as part of the HASP
Initialization process.
6.4.1
REP Card Format
Columns
1
2-5
6
7-12
13-16
l7-blank
Contents
Any identification - ignored by REP routine
CSECT name, "REP", or "ABS"
Blank
Address at which to apply patch (6 hex digits)
or blank
Blank
Half word absolute value patches, 4 hex digits
each, separated by commas, patch data
terminated by first blank,
or one full word (8 hex digit) relocatable
-value patch, followed by a comma and the
name of the resident CSECT which defines the
relocatable part of the value
The above format allows patches to be applied at any absolute
memory location (by use of REP or ABS beginning in column 2) or
at addresses in HASP CSECTs (resident or overlay), subject to
relocation. Relocatable addresses should be taken directly from
a HASP assembly listing containing the CSECT to be patched. A
blank address field is interpretted as one greater than the last
address patched by the previous card, but the card will be used
only if columns 2-5 match those of the previous card.
The patches may be absolute values or one relocatable word per
card, whose value is relative to any resident HASP CSECT.
Relocatable values should be punched as if they were the assembled
value of an A type constant in the CSECT which defines the
referenced relocatable symbol.
Use of the term "CSECT name" in the above description means the
fifth and following characters of a HASP CSECT name, as taken from
the External Symbol Dictionary of a HASP assembly listing.
A deck of one or more REP cards should be terminated by a card
having "1*" punched in columns 1-2.
HASP REP Routine - Page 6.4.1
302
HAS P
6.4.2
REP Routine - Program Logic
REP cards, as described in Section 6.4.1, are read from the card
reader, whose address is given by the HASPGEN parameter $REPRDR,
immediately after the operator replys to HASP's initial WTOR, if
the operator specifies "REP" in the reply options. Each card is
listed on the printer, whose address is given by the HASPGEN
parameter $REPWTR, unless the operator specifies "NOLIST" in the
reply options. All I/O is performed using CPU instructions SIO
and TIO with the CPU disabled for all interruptions.
Cards are
read and processed until a card having "/*" in columns I and 2
is encountered or until the card reader signals unit exception.
The value or data portion of each card is processed first.
If
the value is relocatable (indicated by comma in column 25), eight
hex digits beginning in column 17 are converted to a binary, value.
The CSECT name (last four characters beginning in column 26) is
located in an internal table of standard resident module names.
A value is taken from this table which is the memory address at
which the resident module is loaded. This value is added to the
value taken from the card.
If the value portion is absolute, groups of four hex digits (separated by commas) beginning in column 17 are converted to binary
values until a blank is encountered instead of an expected comma .
. ~he values are concatenated to form a single variable length
binary value.
The address portion of the card is processed next.
If non-blank,
six hex digits beginning in-column 7 are converted to a binary
address. An attempt is made to locate the to-be-patched CSECT
name (last four characters beginning in column 2) in the standard
resident module name table.
If located, the loaded memory address
of the resident module is added to the address taken from the card.
If the CSECT name is not in the standard resident module name
table, the overlay table is searched to determine if the CSECT is
an overlay which was made permanently resident.
If so, the nonzero assembly origin of the overlay CSECT is subtracted from and
the loaded memory address is added to the address taken from the
card.
In both of the above cases, the patch value as previously
computed is applied by moving it to the memory address determined
by one of the two methods described.
If the CSECT name is not located by either search just described,
it is assumed to be an overlay CSECT which is not permanently resident.
The name, unrelocated address, and value are saved in a
reserved area, to be applied each time the overlay is read from
direct access during HASP operation.
If the address field of the card is blank, the to-be-patched CSECT
name is compared with that from the 'preceeding card.
If they are
not equal, the card is ignored. Otherwise, the card is considered
HASP REP Routine - Page 6.4.2
303
HAS P
to be a continuation of the preceeding card and the patch value
is applied at the next higher memory address or saved as appropriate.
If no area was reserved to save patch information for application
to non-resident overlays (HASPGEN parameter &OREPSIZ=O) or if the
capacity of the reserved space is exceeded, the operator message
"OVERLAY REPPING ERROR" is issued and HASP operation is abortively
terminated.
HASP REP Routine - Page 6.4.3
304
HAS P
6.5
HASP ACCOUNTING ROUTINE
6.5.1
HASP Accounting Routine - General Description
The Accounting Routine accumulates statistics for each job at the
completion of the Punch phase and produces the HASP Account Card
(see Section 11) which is punched by the Punch Processor.
This
feature is optional and may be deleted at HASPGEN time.
6.5.2
HASP Accounting Routine - Program Logic
The HASP Accounting Routine is a separately assembled overlay segment which gains control at the end of the Punch phase.
Its function is to construct an accounting card such that the Punch
Processer can punch this card upon return.
Upon entry, the following registers contain the following information:
Register 1 - Address of the HASP Job Queue Entry Priority Byte.
Register 2 - Address of the Accounting Card Image Area.
Register 10 - Address of the HASP Job Control Table.
Register 14 - Return Address.
All registers must be saved and restored before return to HASP.
This routine blanks out the Accounting Card Image Area and then
extracts information from the HASP Job Control Table and HASP Job
Queue Entry and constructs the Accounting Card Image in the Accounting Card Image Area.
Special consideration is made for the clock
passing midnight.
In such cases the elapsed time is negative and
a correction factor (24 hours) must be added.
The accounting card which is normally punched when this routine
returns to the punch processor may be deleted by setting the
condition code to zero before returning.
HASP Accounting Routine - Page 6.5.1
305
HAS P
6.6
HASP DUMP ROUTINES
HASP provides two dump routines which are optionally included as
debugging aids. The HASP Dump Routine for printer formatted dumps
and the HASP High Speed Dump to Tape Routine are discussed in the
following sections.
6.6.1
HASP Dump Routine - General Description
The $Dump routine is available as a debugging aid (effective only
if &DEBUG=YES) and will, when the console PSW RESTART key is depressed, dump memory according to specified limits.
6.6.2
HASP Dump Routine - Program Logic
This routine gains control via the PSW RES~ART key on the console.
Upon activation of the key, a specially formatted HASP PSW is loaded
from location HEX'O'. The format is HEX'0004000F' for the first
word; where· 0004 is the mask that allows only· a machine check interrupt, and OOOE is the address of the printer that is referenced in
the routine. The second word will contain the address of the $Dump
routine of HASP.
.
.once activated, $Dump will reference the low core address of HEX'34'
for its beginning limit. This limit defaults to a value that will
dump all of the memory unless the operator changes the limit prior
to pushing the PSW RESTART key. If· a change is desired, the limit
should be entered at its location in the following format:
HEX'OOXXXXXX'. Also, if an operator should care· to change the limit
while $Dump is activated, the routine will immediately note a change,
will immediately stop the previous dump, and will start dumping memory from the new limit. It should be noted at this point that a
machine check will destroy the limit values within their position
in core. To avoid undetected machine checks, however, the dump program is, at all times, enabled for machine check interrupts.
The routine also allows the operator to route the printing to a
printer with an address other· than HEX'OOE'. A change of the
printer address in the HASP preformatted PSW, prior to activation
of $Dump, will accomplish this.
At the normal end of the routine, the system will be placed in a
"wait" state via the LPSW command. At this point in time, the registers will have been restored back to their values prior to $Dump
and the default limits of $Dump will have been returned to their
respective values.
HASP Dump Routines - Page 6.6.1
306
HAS P
6.6.3
HASP HIGH SPEED DUMP TO TAPE ROUTINE - GENERAL DESCRIPTION
The High Speed Dump to Tape Routine, available as an optional
debugging aid, dumps all of main storage to tape for post
processing by the IBM System/360 Operating System Service
Aids program IMDPRDMP or an equivalent processor.
6 .6. 4
HASP HIGH SPEED DUMP TO TAPE ROU'l'INE - PROGRAM LOGIC
ENTRY TO IDMTAPE - If the system programmer sets the HASPGEN
parameter &DMPTAPE to the address of an attached magnetic tape
drive the High Speed Dump to Tape Routine (IDMTAPE) will be
created to write on the specified drive when entered. Initialization will display on the operator's console the message
"SET RESTART PSW TO 0004000000aaaaaa FOR TAPE DUMP" where
"aaaaaa" is the address of the entry point IDMTAPE. This
message not only verifies that the routine is present; it is
sufficient information for the operator to manually activate
the dump. Via the REP processing routine or via manual key
entries the system programmer or operator is able to insert
code within the system to detect errors and cause dumps by
program entry to the routine simulating the loading of the
requested PSW.
(Example: set program new PSW as directed to
dump on the first program check.)
IDMTAPE assumes that the device generated is an appropriate
tape drive to use, that the tape is at load point ready for
writing, and that the recording mode status is correctly set.
If these conditions are not true unpredictable results will
occur.
CHANGING THE TAPE ADDRESS - The halfword located in storage
at IDMTAPE-4 contains the address of the tape drive upon which
the routine will write when entered. This address may be
altered manually to any other tape drive address as appropriate
prior to executing the routine.
PROGRAM LOGIC - The general registers and selected fixed
storage areas are saved in location 84 hexadecimal to be
compatible with the OS Service Aids dump program.
HASP control section locator elements are moved into low
storage adjacent to the fixed area information. These elements
contain the last four characters of the "HASPxxxx" control
section names of basic assembly modules. Following each CSECT
identification is the address of the beginning of the identified CSECT.
(HASP control sections may then be easily located
in the dump after post processing.) Location 80 hexadecimal
HASP Dump Routines - Page 6.6.2
307
HAS P
is set to the negative of address 2048. Location 80 hexadecimal
for 4 bytes is written followed by 2048 bytes of storage (first
part of which contains saved data).
Each succeeding record is written by adding the address 2048
to the address in location 80 (hex), storing the memory protect
key in the high byte, "and writing 2052 bytes of storage (four
from location 80 (hex) and 2048 from the designated address) .
When the address is greater than zero the program new PSW is
set to provide an end of storage exit which, when entered,
will cause the writing of EOF, a rewind unload, and the loading
of a wait state PSW.
HASP Dump Routines- Page 6.6.3
308
HAS P
7.0
HASPGEN AND RMTGEN PARAMETERS
This section.describes the parameters used to specify
the HASP System,' HASP MULTI-LEAVING Remote Terminal
Programs, and the System/360 Model 20, STR Remote
Terminal Program.
Generation of the HASP System is. called HASPGEN, and
generation of the HASP MULTI-LEAVING Remote Terminal
Programs and the System/360 Model 20 STR Program
for HASP Remote Job Entry is called RMTGEN.
Both
generation processes are described in Section 10.
HASPGEN and RMTGEN Parameters - Page 7.0.1
309
H.
ASP
7.1
HASPGEN PARAMETERS
Generation of a HASP System invplves specification
of cer~ain parameters, called HASPGEN parameters.
With these parameters, the installatiqn system
p~ogrammer specifies the characteristics of the
System/360 or System/370 with which he will use
HASP and the optional HASP features he wishes to b~
included in the generated HASP System.
The following pages describe ~he HASPGEN parameters.
For each parameter there is an explanat~on, the default value, and frequently notes which expand upon
the explanation and refer to related HASPGEN
parameters.
The H~SPGEN parameters are given in alphabetical order
(neglecting the first character if it is & or $)
except for parameter $$x, which appears last.
HASPGEN Parameters - Page 7.1.1
310
&ACCTNG
HAS P
&ACCTNG
Explanation: Variable symbol &ACCTNG specifies the
HASP job accounting option. If it is specified as
YES, HASP will call the HASP accounting routine and
punch a HASP,accounting card for each job processed
by HASP. The specification must be either YES or NO.
Default:
&ACCTNG=YES
Notes:
1.
The HASP accounting routine and the HASP accounting card are dis6ussed in other sections
of this manual.
2.
If &NUMPUNS=O, parameter &ACCTNG should he
set to NO.
HASPGEN Parameters - Page 7.1.2
311
&AUTORDR
HAS P
&~UTORDR
Explanation: Variable symbol &AUTORDR specifies
the inclusion or exclusion of code in HASP to recognize automatically when a physical card reader
available to HASP becomes ready. The specification
must be either YES or NO.
Default:
&AUTORDR=YES
Notes:
1.
If &AUTORDR=NO, HASP's physical card readers
remain in the INACTIVE state when they become
ready; the operator must issue a $SRDRn command
to cause HASP to begin reading cards from
READERn.
HASPGEN Parameters - Page 7.1.3
312
&BSCCPU
HAS P
&BSCCPU.
Explanation: Variable symbol &BSCCPU specifies inclusion
or exclusion in the HASP Remote Terminal Access Method
of support for HASP MULTI-LEAVING Remote Job Entry.
Default:
&BSCCPU=NO
HASPGEN Parameters - Page 7.1.4
313
&BSC2770
HAS P
&BSC2770
Explanation: Variable symbol &BSC2770 specifies inclusion or exclusion in the HASP Remote Terminal Access
Method of Remote Job Entry support for the 2770 Data
Communication System. The specification must be either
YES or NO.
Default:
&BSC2770=NO
HASPGEN Parameters - Page 7.1.5
314
HAS P
&BSC2780
&BSC2780
E~lanation:
Variable symbol &BSC2780 specifies inc1u810n or exclusion in the 'HASP Remote Terminal Access
Method of Remote Job Entry support for the 2780 Data
Transmission Terminal. The specification must be
either YES or NO.
Default:
&BSC2780=NO
HASPGEN Parameters - Page 7.1.6
315
&BSC3780
HAS P
&BSC3780
Explanation: Variable symbol &BSC3780 specifies
inclusion or exclusion in the HASP Remote Terminal
Access Method of Remote Job Entry support for the
3780 Data Communications Terminal. The specification must be either YES or NO.
.
Default:
&BSC3780=NO
HASPGEN Parameters - Page 7.1.6.1
315.1
HAS P
&BSHPRES
&BSHPRES
Explanation: Variable symbol &BSHPRES specifies
inclusion or exclusion in the HASP Remote Terminal
Access Method of support for the Space Compression/
Expansion feature of 2770 and 3780 terminals. The
specification must be either YES or NO.
Default:
&BSHPRES=NO
Notes:
1.
This support must be included if any terminal
will transmit to HASP using the Space
Compression/Expansion feature.
2.
Use of this support for 'output to any terminal is controlled by specification in the
RMTnn parameter for that terminal.
HASPGEN Parameters - Page 7.1.6.2
315.2
&BSHPRSU
HAS P
&BSHPRSU
Explanation: Variable symbol &BSHPRSU specifies inclusion or exclusion of the HASP Remote Job Entry Printer
Interrupt feature for binary synchronous hardware
terminals. If this feature is included, the Remote
Terminal operator may interrupt printing to transmit
jobs or HASP commands to HASP. The specification
must be either YES or NO.
Default:
&BSHPRSU=YES
Notes:
1.
If &BSHPRSU=YES, HASP will recognize certain
control characters from the binary synchronous
hardware terminal which indicate that the printer
has stopped. The HASP Remote Terminal Operator's
Manual for hardware terminals contains more information.
HASPGEN Parameters - Page 7.1.7
316
HASP
&BSHTAB
&BSHTAB
Explanation: Variable symbol &BSHTAB specifies inclusion or exclusion in the HASP Remote Terminal
Access Method of support for the Printer Horizontal
Format Control feature of 2770, 2780, and 3780 terminals. The specification must be either YES or NO.
Default:
&BSHTAB=YES
Notes:
1.
Use of this support for any terminal is controlled by specification in the RMTnn parameter for that terminal.
HASPGEN Parameters - Page 7.1.7.1
316.1
HAS P
$BSPACE
$BSPACE·
Explanation: Ordinary symb.ol $BSPACE specifies the
character which will be interpreted as the 360 hardware defined hackspace character X'16'. The $BSPACE
character when entered on any OS controlled system
operator console will be removed from the command
text along with the previously entered character (if
any). Characters following the $BSPACE character
will be shifted ,left to replace the removed characters. The $BSPACE-edit is performed on all commands
entered via OS system operator command input sources
regardless of its position within the text of the
data entered. $BSPACE is active only for HASP Systems using the &NUMCONS=O option and does not apply
to HASP card reader or remote workstation sources.
$BSPACE is specified using the two hexadecimal digit
representation of the EBCDIC character.
Default:
$BSPACE=5F
Notes:
1.
The default specification indicates that the
EBCDIC character "~" is to be used to backspace command entry on OS controlled system
operator consoles.
2.
The character selected for the backspace function must be chosen with extreme caution since
it eliminates the use of that character (except
as a backspace operation) in all commands and
replies to WTORs.
HASPGEN Parameters - Page 7.1.7.2
316.2
HAS P
&BSVBOPT
&BSVBOPT
Explanation: Variable symbol &BSVBOPT specifies inclusion or exclusion in the HASP Remote Terminal Access
Method of code to recognize an EM (End of Media) punch
in card images transmitted nontransparently by the
2780 Data Transmission Terminal. The specification
must be either YES or NO.
Default:
&BSVBOPT=NO
HASPGEN Parameters - Page 7.1.8
317
&BUFHICH
HAS P
&BUFHICH
Explanation: Variable symbol&BUFHICH specifies the
storage hierarchy for which HASP initialization will
issue a GETMAIN in an attempt to get more than &NUMBUF
buffers for HASP. The specification must be either
o or 1.
Default:
&BUFHICH=l
Notes:
1.
&BUFHICH has meaning only with OS storage hierarchy support.
2.
See HASPGEN parameters &NUMBUF, &MINBUF and
&RESCORE for additional information concerning
the use of this parameter.
HASPGEN Parameters - Page 7.1.9
318
HAS P
&-8 UFS I ZE
&BUFSIZE
Explanation: Variable symbol &BUFSIZE specifies the
size in bytes of each HASP buffer. If the value
specified is not a multiple of eight, HASPGEN will
adjust it upward to a multiple of eight. The specification must be an integer not larger than the track
size of any SPOOL device and not smaller than the
number given by
300+2*&NUMDA*&NUMTGV/8+5*S+8*F
where S = maximum allowable number of SYSOUT
speci~ications per job, including
special' forms requests
F = maximum allowable number of special
forms requests per job.
Default:
&BUFSIZE=688
Notes:
1.
The above formula is. the approximate size of a
HASP control block called the JCT.
&BUFSIZE is
the data length of each physical record on the
portion of a SPOOL volume used by HASP, and
JCTs are written on SPOOL volumes. A JCT's initial size is about 300 + 2*&NUMDA*&NUMTGV/8; it
increases in size as a job is being executed.
When HASP recognizes a job step change, the JCT
is increased in size by five bytes for each n6nspecial-forms SYSOUT data set, or by thirteen
by~es for each speci~l-forms SYSOUT data set,
that was written upon since the previouslyrecognized step change. But if an increase of
five (or thirteen) bytes would cause the JCT
size to become greater than &BUFSIZE, HASP instead writes to operator the me'ssage
JeT OVERFLOW--OUTPUT LOST
for the SYSOUT data set, and its output is lost.
2.
The default &BUFSIZE of 688 is optimized for the2314 track size.
If &NUMTGV and &NUMDA are left
at their default values of 400 and 2, the
&BUFSIZE default allows a maximum of 37-- (no
speoia1 forms>' and a minimum of 14 (all special
forms) SYSOtiT data sets per job. A good value
of &BUFSIZE optimized for the 3330 would be 736.
3.
&BUFSIZE must be 416 or greater if &XBATCHC is
altered from its default null value.
4~
&BUFSIZE must be 536 or greater if 3211 printers
are used by HASP.
HASPGEN Parameters - Page 7.1.10
319
$CKPTIME
HAS P
$CKPTlME
Explanation: Ordinary symbol $CKPTIME specifies the
interval, in seconds, at which certain HASP information will be checkpointed for warm start purposes·.
Default:
$CKPTlME=60
Notes:
1.
The time interval specified is a maximum. Checkpoints are also taken when a job changes its
status in the HASP job queue.
2.
The section of this manual describing the HASP
checkpoint processor describes the checkpoint
information.
HASPGEN Parameters - Page 7.1.11
320
&CLS(n)
HAS P
&CLS(n)
Explanation: Subscripted variable symbols &CLS(n)
specify HASP job classes. The nth HASP logical
partition may select for OS execution a job from
the HASP job queue only if the job's class (specified
by the user in the CLASS=parameter of the JOB card,
or defaulted to A) is one of the characters specified
in the &CLS(n) parameter or specified by the operator
in the set command, $T Imm,list (where &PID(n)=mm).
Each specification must be a 1- to 8-character string
of valid HASP job classes. The same HASP job class
may be specified in two or more specifications.
Default:
&CLS(l)=A
&CLS(2)=BA
&CLS(3)=CBA
&CLS(4)=DCBA
&CLS(S)=EDCBA
&CLS(6)=FEDCBA
&CLS(7)=GFEDCBA
&CLS(8)=HGFEDCBA
&CLS(9)=IHGFEDCB
&CLS(lO)=JIHGFEDC
&CLS(ll)=KJIHGFED
&CLS(12)=LKJIHGFE
&CLS(13)=MLKJIHGF
&CLS(14)=NMLKJIHG
&CLS(15)~ONMLKJIH
Notes:
1.
Only the first &MAXPART specifications, &CLS(l)
through &CLS(&MAXPART), will be used.
2.
If &MAXCLAS is specified less than 8, only the
first &MAXCLAS characters of each specification
&CLS(n) will be used.
HASPGEN Parameters - Page 7.1.12
321
&CONAUTH
HAS P
&CONAUTH
Explanation: Variable symbol &CONAUTH specifies the
HASP command authorization of each of the eight possible
HASP physical consoles when HASP console support is
included in the generated HASP system. The specification must be a string of up to eight numeric digits,
each of which may range from 0 to 7 and is the sum
of the desired authorizations for its respective
console (leftmost digit for CONSOLE 1, next digit
for CONSOLE2, etc.) as follows:
1 - System Control (including OS) Commands
2 - Device Control Commands
4 - Job Control Commands.
Default:
&CONAUTH=77777777
Notes:
1.
Any HASP console's command authorization may be
changed from a console with System Control
Command authority.
2.
If &NUMCONS=O, parameter &CONAUTH is not used.
3.
All HASP consoles are authorized for the issuance
of Display Commands.
HASPGEN Parameters - Page 7.1.13
322
Ii ASP
&DEBUG
&DEBUG.
Explanation: Variable symbol &DEBUG specifies inclusion or exclusion of debugging code in the generated HASP system. The specification must be either
YES or NO.
Default:
&DEBUG=NO
Notes:
1.
The &DEBUG option is independent of the &TRACE
option.
2.
If &DEBUG is specified as YES, HASP includes,
in addition to other debugging code, a core
dump routine.
HASPGEN Parameters - Page 7.1.14
323
$DELAYCT
HAS P
$DELAYCT
I
Explanation: Ordinary symbol $DELAYCT specifies a
delay factor to be applied by the HASP Remote Terminal Access Method when transmitting to a Multi-Leaving
System/360 Model 20 Submodel 2 or 4 Remote Terminal
over a high-speed (19,200 baud or greater) teleprocessing line, to avoid the possibility of certain line
errors. The specification must be an integer greater
than zero. Recommended values for some central CPUs
are:
Model
Model
Model
Model
Model
Model
Model
Model
Model
Model
Model
195
91
85
165
75
65
155
50
145
135
40
-
8000
4000
3000
3000
500
256
256
100
100
50
1
Values for other CPUs may be interpolated based on
CPU speed.
Default:
$DELAYCT=256
HASPGEN Parameters - Page 7.1.15
324
&DMPTAPE
HAS P
&DMPTAPE
Exelanation: Variable symbol &DMPTAPE specifies a
un~t address to be used with the HASP dump program.
The specification must be a valid unit address.
If
the specification is not 000, the address is assumed
to be that ofa tape drive and the generated HASP
system will include a dump-to-tape program for that
tape drive. The tape produced by this program may
be printed using FE Service Aid IMDPRDMP.
Default:
&DMPTAPE=OOO
Notes:
1.
This parameter does not affect inclusion of the
HASP dump-to-printer program, which is always
assembled if &DEBUG=YES. To use the dump-to-tape
program the operator must set location 0 as indicated in an operator message produced by HASP
initialization, make the tape drive ready for
writing, and push PSW RESTART.
2.
This facility is provided as an aid to the
system programmer and may not operate correctly
in all environments or with other than the
IMDPRDMP program provided with Release 19 of
as. No maintenance will be provided for this
facility.
Installations unable to utilize this
support as distributed should utilize the service
aid IMDSADMP to produce dump tapes.
HASPGEN Parameters - Page 7.1.16
325
HAS P
$ESTIME
$ESTIME
Explanation: Ordinary symbol $ESTlME specifies
the default estimated execution time, in minutes,
for a job. The specification must be an integer
greater than zero.
Default:
$ESTlME=2
Notes:
1.
If a user does not specify in the accounting
field of his job card a value for estimated
execution time, the value $ESTIME is used.
2.
All timings performed by HASP are in real
time. The timing for estimated execution
time begins when HASP allows its OS Reader/
Interpreter to start reading the job.
HASPGEN Parameters - Page 7.1.17
326
HAS P
$ESTLNCT
$ESTLNCT
Explanation:
Ordinary symbol $ESTLNCT specifies
the default estimated print line count, in thousands of lines, for a job. The specification must
be an integer greater than zero.
Default:
$ESTLNCT=2
Notes:
1.
If a user does not specify in the accounting
field of his job card a value for estimated
print line count, the value $ESTLNCT is used.
HASPGEN Parameters - Page 7.1.18
327
HAS P
$ESTPUN
$ESTPUN
Explanation: Ordinary symbol $ESTPUN specifies
the default estimated punched card count, in cards,
for a job. The specification must be an integer
greater than zero.
Default:
$ESTPUN=lOO
Notes:
1.
If a user does not specify in the accounting
field of his job card a value for estimated
card count, the value $ESTPUN is used.
HASPGEN Parameters - Page 7.1.19
328
HAS P
&FCBV
&FCBV
Explanation: Variable symbol &FCBV specifies inclusion or exclusion of the 3211 Variable Forms
Control Buffer loading capability. If set to YES,
the "V" specified FCB image is generated and the
code to support the $TF ..• command is included.
The specification must be either YES or NO.
Default:
&FCBV=NO
HASPGEN Parameters - Page 7.1.19.1
328.1
HAS P
(The remainder of this page intentionally left blank.)
328.2
&INITSVC
HAS P
&INITSVC
Explanation: Variable symbol &INITSVC specifies the
SVC number of the HASP SVC. The specification must
·be an integer between 200 and 255, inclusive.
Default:
&INITSVC=255
Notes:
1. The specification for &INITSVC must correspond
to a use at SYSGEN time of the OS SYSGEN macroinstruction SVCTABLE. The HASP SVC is a type-l
SVC and must be included in the OS Nucleus before
HASP can be used. After HASPGEN has completed,
the object deck for the HASP SVC is member
HASPSVC of partitioned data set SYS1.HASPOBJ.
For further discussion, see the section on installing HASP.
HASPGEN Parameters - Page 7.1.20
329
&JITSIZE
HAS P
&JITSIZE
E~anation:
Variable symbol &JITSIZE specifies the
n
er of bytes per entry of the HASP job information
table. The specification must be an integerrgreater
than or equal to 8, or equal to 0, but never so large
that the value
&MAXJOBS*&JITSIZE
is greater than the track size of the device upon
which SPOOLI is mounted.
I
If &JITSIZE=O, the HASP commands with OS job names
as operands will be inoperative.
Default:
&JITSIZE=O
Notes:
1., The recommended specifications for &JITSIZE are
\ 0 and 8. If &JITSIZE is set greater than 8,
the additional space generated in the job information table will not be used by HASP.
2.
If &JITSIZE is specified greater than zero, the
job information table will be checkpointed on
SPOOLI whenever it changes.
HASPGEN Parameters - Page 7.1.21
330
$LINECT
HAS P
$LINECT
Explanation: Ordinary symbol $LINECT specifies the
default maximum number of lines to be printed per
page of a job's printed output.
Default:
$LINECT=61
Notes:
1.
If a user does not specify in the accounting
field of his job card a value for line count,
the value $LINECT is used.
2.
Setting $LINECT=O will cause automatic page
overflow, normally provided by HASP, to be suppressed unless overridden by the job card accounting parameter (see note 1) .
3.
If a print data set 1S generated without any
ejects (no skips to any channel in the carriage
tape), and if $LINECT=O or if the "linect"
parameter on the job card of the job producing
the data set is zero, then that data set will
be treated as one page when forward spaced,
backspaced, interrupted, or warm started while
printing.
HASPGEN Parameters - Page 7.1.22
331
LINEmm
HAS P
LINEmm
Explanation: Ordinary symbols LINEmm specify the
characteristics of teleprocessing lines to be used
by HASP Remote Job Entry. Lines must be defined consecutively, starting with LINEOI. Each specification
must be a 5-character string of the form
LINEmm=aaalc
where the letters represent the following:
Code Letters
nun
Range
01-99
aaa
OOO-FFF
1
0-5
Descript.ion
Line Number
STR or BSC Adapte'r Address (See Note 2)
Line Description as follows:
STR Lines
0 = Interface A
1 = Interface A
2 = Interface A
3 = Interface B
4 = Interface B
5 = Interface B
1
0-5
-
2 wire Half-Duplex
4 wire Half-Duplex
Full-Duplex
2 wire Half-Duplex
4 wire Half-Duplex
Full-Duplex
BSC Lines
0
1
2
3
4
5
= Interface
= Interface
= Interface
= Interface
= Interface
= Interface
A - Half-Duplex
baud) .
A - Full-Duplex
baud)
A - Full Duplex
k-baud)
B - Half-Duplex
baud)
B - Full-Duplex
baud)
B - Full-Duplex
k-baud)
(1200-9600
(1200-9600
(19.2-230.4
(1200-9600
(1200-9600
(19.2-230.4
Clock/Code as follows:
c
0-3
STR Lines
0 = Internal
1 = Internal
2. = Internal
3 = External
Clock X
Clock y
Clock Z
Clock
HASPGEN Parameters - Page 7.1.23
332
HAS P
Code Letters
Range
0-7
DescriEtion
BSC Lines
0
1
2
3
4
5
6
7
Default:
.- Code A - EBCDIC - No Transparency
=
=
=
=
=
=
=
Code
Code
Code
Code
Code
Code
Code
A
A
A
B
B
B
B
-
EBCDIC - Transparency
USASCII - No Transparency
USASCII - Transparency
EBCDIC - No Transparency
EBCDIC - Transparency
USASCII - No Transparency
USASCII - Transparency
LINEmm=***Ol
Notes:
1.
Parameter &NUMLNES must specify the number of
specifications LINEmm to be included in the generated HASP system.
2.
The unit address aaa may be specified as ***.
HASP initialization will assign unit addresses
to lines whose unit addresses are specified as
*** by scanning the OS UCBs. A teleprocessing
UCB whose device type field specifies a 2701
STR adapter, a 2701 BSC adapter, or a 2703 BSC
adapter will be recognized as a UCB defining a
line. If the unit address of such a UCB is not
specified explicitly in' any of the first &NUMLNES
line definitions LINEmm, HASP initialization
will assign the UCB to the first line number
whose unit .address is specified *** and will
change the *** to the EBCDIC address specified
in theUCB, unless no line definition remains whose
unit address is ***, or if (except for M65MP and
a2-CPU multiprocessor) a TIO shows the line riot
operational, or if (for M65MP and a 2-CPU multiprocessor) the UCB is marked off-line: in that
case HASP will not use the line.
3.
If a line specification LINEmm designates USASCII,
that line cannot be used with any but 2770 and
2780 USASCII terminals. HASP will translate each
record it receives into EBCDIC, and each record
it transmits into USASCII before transmission.
HASPGENParameters - Page 7.1.24
333
&LOGOPT
HAS P
&LOGOPT
Explanation: Variable symbol &LOGOPT specifies inclusion or exclusion of code to support the HASP
System Log feature. The specification should be
either YES or NO.
Default:
&LOGOPT=YES
Notes:
1.
The HASP System Log is a listing included in
each user's output of console messages that
were produced during processing of the job and
of replies to WTORs issued during processing
of the job.
2.
If &LOGOPT=YES, the HASP System Log may be
suppressed on an individual job basis through
a parameter in the accounting field of the
job card.
3.
If ·the HASP System Log is suppressed, the HASP
statistics information normally printed with
the job is also suppressed.
HASPGEN Parameters - Page 7.1.25
334
&MAXCLAS
HAS P
&MAXCLAS
Explanation: Variable symbol &MAXCLAS specifies
the maximum number of job classes which may be
specified via the HASP command $T In,list for a
HASP logical partition. The specification must
be an integer from 1 to 64, inclusive.
Default:
&MAXCLAS=8
Notes:
1.
If &MAXCLAS is specified as less than 8, then
no more than &MAXCLAS characters may be specified for each of the parameters &CLS(n).
HASPGEN Parameters - Page 7.1.26
335
HAS P
&MAXJOBS
&MAXJOBS
Explanation: Variable symbol &MAXJOBS specifies the
maximum number of jobs that can be in the HASP System
at any given time., The specification must be an
integer greater than zero.
Default:
&MAXJOBS=lOO
Notes:
1.
This variable does not affect the range of
HASP job numbers, which is 1 to 999.
2.
This variable strongly influences the size of
the HASP checkpoint record(s). The size of
the first checkpoint record is
16* (&MAXJOBS+&NUMPRTS+&NUMTPPR) +
&NUMDA*((&NUMTGV+7)/8)+40.
The size of the second checkpoint record is
&MAXJOBS*&JITSIZE.
If either checkpoint is longer than. the track
size of the device on which SPOOLl is mounted,
HASP will not warm start correctly.
HASPGEN Parameters - Page 7.1.27
336
H
~
S P
&MAXPART
&MAXPART
Explanation: Variable symbol &MAXPART specifies,
for both MFT and MVT, the number of HASP logical
partitions to be defined. The specification must
be an integer between 1 and 15, inclusive.
Default:
&MAXPART=&MAXXEQS
Notes:
1.
The nth logical partition is further defined
by the specifications &PRI(n), &OSC(n), and
&CLS(n) •
HASPGEN Parameters - Page 7.1.28
337
HAS P
&MAXXEOS
&MAXXEQS
Explanation: Variable symbol &MAXXEQS specifies
the maximum number of jobs which may concurrently
be active in the HASP Execution phase. The specification must be an integer greater than zero.
Default:
&MAXXEQS=3
Notes:
1.
See also &MAXPART, the variable which determines the number of HASP logical partitions.
HASPGEN Parameters - Page 7.1.29
338
HAS P
&MINBUF
&MINBUF
Explanation: This variable is provided to allow installations, which depend on the dynamic buffer construction
feature of HASP, to detect the condition where sufficient
buffers for proper operation cannot be obtained. The
specification should be an integer value representing
the minimum number of buffers determined as necessary
for the installation (see &NUMBUF).
Default:
&MINBUF= 3*&MAXXEQS+2*&NUMRDRS
+&NUMINRS+2*&NUMPRTS+&NUMPUNS
+&NUMTPBF
Notes:
1.
HASP wiil automatically attempt to utilize, via a
variable GETMAIN, any free space in its region or
partition (hierarchy indicated by &BUFHICH) as
additional buffers. If .the number of buffers so
obtained when added to the variable &NUMBUF is less
than the value of &MINBUFthe warning message
&MINBUF BUFFERS NOT AVAILABLE
will be issued during HASP initialization and processing will continue.
2.
Since the changing of HASPGEN options, local
modifications and/or OS changes can affect the
number of HASP buffers, proper setting of this
variable can prevent a possible undetected performance degradation.
3.
See the des.cription of HASPGEN parameters &NUMBUF,
&BUFHICH and &RESCORE for related information.
HASPGEN Parameters - Page 7.1.30
339
HAS' P
&MLBFSIZ
&MLBFSIZ
Explanation: Variable symbol &MLBFSIZ specifies the
size in bytes of each HASP Multi-Leaving buffer.
The specification for &MLBFSIZ must be a positive
integer no larger than &TPBFSIZ.
Default:
&MLBFSIZ=400
Notes:
1. The value specified for &MLBFSIZ automatically
becomes the Multi-Leaving buffer size in each
HASP Multi-Leaving Remote Terminal program.
2.
Satisfactory support of one device of each type
(reader, printer, punch, console) on 8K terminal CPUs is based on the assumption that
&MLBFSIZ=400 or less. If the supported terminals include any 8K CPUs, it is recommended
that &MLBFSIZ not be increased above 400, even
if support of a non-programmable terminal requires increasing &TPBFSIZ to 512.
HASPGEN Parameters - Page 7.1.31
340
&MONINTV
HAS P
&MONINTV
Explanation: Variable symbol &MONINTV specifies the
interval in seconds at which the HASP Execution Task
Monitor will examine CPU utilization characteristics
and, if necessary, modify dynamically the order in
the TCB chain, of all HASP-controlled job step tasks
which fit Execution Task Monitor criteria. The specification should be an integer between 0 and 10 inclusive. If &MONINTV is specified as zero, the Execution
Task Monitor is excluded from the generated HASP
system.
Default:
&MONINTV=5
Notes:
1.
See also parameters &XZPRTY (for MVT), &XZMFTL,
and &XZMFTH (for MFT).
2.
as Time Slice Groups must not be assigned to
the priority level or partitions monitored by
the Execution Task Monitor.
3.
Users must not specify TIME=1440 in job or
execute cards. Such specifications will cause
the jobstep TQE not to be created by OS thus
forcing the job HIGH in the dynamic group.
HASPGEN Parameters - Page 7.1.32
341
&NOPRCCW
HAS P
&NOPRCCW
Explanation: Variable symbol &NOPRCCW specifies the
maximum number of channel command words per channel
program for local printers.
Default:
&NOPRCCW=lS
HASPGEN Parameters - Page 7.1.33
342
HAS P
&NOPUCCW
&NOPUCCW
Explanation: Variable symbol &NOPUCCW specifies the
maximum number of channel command words per channel
program for local punches.
Default:
&NOPUCCW=lO
HASPGEN Parameters - Page 7.1.34
343
&NUMBUF
HAS P
&NUMBUF
Explanation: This variable symbol indicates the number
of INPUT/OUTPUT buffers to be included in the HASP
load module and should normally be set by each installation, according to the formulae below, to reflect the
total number of buffers required for proper operation
of HASP. However, since HASP will automatically utilize
free space in its region or partition to dynamically
construct additional buffers, there are circumstances
when &NUMBUF may be set to a value less than the actual
number of buffers required for proper HASP operation.
In this case, it is assumed that sufficient additional
buffers will be dynamically obtained from free storage
in the HASP region/partition to provide an adequate
total number of buffers (see &MINBUF and &RESCORE).
This facility could be used, for example, to allow
additional buffers to reside in a storage hierarchy
different from that of the HASP load module (see &BUFHICH)
or to provide a HASP whose size (and performance and
function) can be controlled by the ~etting of the region
or partition size.
Default:
&NUMBUF=IS
Notes:
1.
In order to utilize all the dynamic storage contained in the" HASP load module for the initialization
process, the value of &NUMBUF must never be less
than the value
1+6000/(80+&BUFSIZE)
2.
Since all HASP .buffers are maintained in a dynamic
pool until required by an active function, installation should determine the appropriate number of
buffers for HASP based on predicted simultaneity
of the various functions required at the installation. The following indicates the number of buffers
required for each logical function.
A defined
function which is inactive requires no buffers.
Each
Each
Each
Each
Each
Each
Each
Each
local input function
internal reader
Remote Input function
local print function
remote print function
local punch function
remote punch function
OS job execution
--2
--1
--1
--2
--1
--1
--1
--2
(I if $PRTBOPT=l)
(2 if $RPRBOPT=2)
(2 if $PUNBOPT=2)
(2 if $RPUBOPT=2)
(minimum value)
HASPGEN Parameters - Page 7.1.35
344
HAS P
For performance reasons, additional buffers must
be available to sustain periods of hiqh SYSIN/
SYSOUT activity by jobs being processed by os.
It is therefore recommended that additional buffers
(beyond the, requirements indicated above) be included corresponding to the value: l+&MAXXEQS.
3.
SEVERE PERFORMANCE AND/OR DEVICE DEGRADATION CAN
OCCUR IN A SYSTEM CONTAINING INSUFFICIENT BUFFERS
TO PERFORM THE REQUIRED FUNCTIONS.
To avoid a complete system failure caused by a
buffer "lock-out" condition, the number of available
buffers must never be less than the value
. &MAXXEQS+&NUMRDRS+&NUMTPES+l
+&NUMPRTS*($PRTBOPT-l)
+&NUMPUNS*($PUNBOPT-l)
+&NUMTPPR*($RPRBOPT-l)
+&NUMTPPU*($RPUBOPT-l)
HASPGEN Parameters - Page 7.1.36
345
HAg. P
&NUMCONS
&NUMCONS
Explanation: Variable symbol &NUMCONS specifies the
type of console support to be provided by HASP. Two
options are available: console support controlled
totally by HASP or a HASP interface to the standard
OS Console processors.
The specification &NUMCONS=n (n an integer between
one and eight) causes HASP to support directly as
many as n consoles. The devices which may be used
as consoles are 1052, 1053, 3210, 3215, 2260 and
1443. The 1053s and 2260s must be attached locally
via a 2848.
The specification &NUMCONS=O causes HASP to interface
with the OS console support, including the MeS option. All devices available with the OS console
routines are supported through this interface.
Default:
&NUMCONS=O
Notes:
1.
If &NUMCONS=O is specified, then all HASP functions with the exception of those listed below
are provided.
2.
a.
Non-HASP Message, e.g., problem program
WTOs, will appear on the console(s) without time tags or HASP Job numbers. A copy
of the message which includes the Job number and time tag is placed in the HASP
System Log.
b.
WTORs issued by the problem program will
be included in the HASP Log without the
OS assigned reply identification number.
c.
Only the first line of multi-line WTOs
isiued by pr6blem programs running under
HASP will be included in the HASP Systems
Log.
If OS Multiple Console Support or M65MP or the
Time Sharing Option have been SYSGENed and are to
be used with HASP, then &NUMCONS should be specified as -zero.
HASPGEN Parameters - Page 7.1.37
346
HAS P
3.
If &NUMCONS greater than zero is specified and if
HASP initialization finds more than &NUMCONS devices of the type supported then the message
MAXIMUM OF &NUMCONS CONSOLE(S) EXCEEDED
is issued and HASP uses as consoles the devices
with the lowest unit addresses starting with the
first 1052, 3210 or 3215 and continuing with the
next &NUMCONS-1 devices.
I
4.
2260 and 1053 support (&NUMCONS greater than
zero) is dependent on additional specifications
via the variables &SIZ2260 and &SPD2260.
5.
If &NUMCONS is specified greater than zero, HASP
will intercept and process all WTOs and WTORs,
ignoring all MCS information. In particular,
HASP will ignore all routing codes. Thus, for
example, a WTO with ROUTCDE=ll will be written
on HASP consoles and on the HASP System Log but
not in an as System Message Block.
6.
See parameter &CONAUTH, &WTLOPT and &LOGOPT for
additional information.
7•
See Chapter 12, Section 12.7.2, for other restrictions on &NUMCONS>O.
HASPGEN Parameters - Page 7.1.38
347
HAS P
&NUMDA
&NUMDA
Explanation: Variable symbol &NUMDA specifies
the maximum number of direct-access volumes which
may be mounted concurrently as SPOOL volumes. The
specification must be an integer greater than zero.
Default:
&NUMDA=2
Notes:
1.
All direct-access devices except 2321s are
eligible for use as SPOOL devices.
2.
Specifying &NUMDA greater than the default may
require increasing the value of &BUFSIZE.
3.
If HASP initialization finds mounted more than
&NUMDA direct-access volumes whose volume
serials begin with the characters SPOOL, it
will write to operator the message
MAXIMUM OF &NUMDA SPOOL VOLUME(S) EXCEEDED
and HASP will quiesce.
4.
This variable influences the size of the HASP
checkpoint record; see Note 2 of variable
&MAXJOBS.
5.
An associated variable is &NUMTGV.
HASPGEN Parameters - Page 7.1.39
348
&NUMDDT
HAS P
&NUMDDT
Explanation: Variable symbol &NUMDDT specifies the
number of Data Definition Tables (DDTs) to be assem-bled into HASP. The specification should be an
integer between 3 and 256, and equal to
2 + &MAXXEQS + A + B + C + D + E
where
A = number of pseudo-2540 readers defined at
SYSGEN time
B = number of pseudo-2540 punches defined at
SYSGEN time
C = number of pseudo-1403 printers defined at
SYSGEN time
D = number of pseudo-1442 punches defined at
SYSGEN time
E = number of pseudo-1443 printers defined at
SYSGEN time
Default:
&NUMDDT=20
Notes:
1.
Pseudo-units for &RDR and &WTR need not be
counted in &NUMDDT.
HASPGEN Parameters - Page 7.1.40
349
\>
&NUMINRS
HAS P
&NUMINRS
Explanation: Variable symbol &NUMINRS specifies
the number of 2520 pseudo-punches to be used by the
generated HASP System as internal readers.
Default:
&NUMINRS=O
Notes:
1.
If &NUMINRS is specified as or defaulted to
zero, code to support the HASP internal reader
feature will be deleted from the generated
system.
2.
If more than &NUMINRS 2520 pseudo-punches have
been specified at SYSGEN time, only the first
&NUMINRS 2520 pseudo-punches can be used.
It
is permissible to specify &NUMINRS greater
than the number of 2520 pseudo-punches specified at SYSGEN time.
3.
The count of 2520 pseudo-punches is not
included in HASPGEN variable &NUMDDT.
HASPGEN Parameters - Page 7.1.41
350
HAS P
&NUMLNES
&NUMLNES
Explanation: Variable symbol &NUMLNES specifies
the largest teleprocessing line identi·fication
number (nun in LINEmm) and thus the number of line
definitions which are to be used by the generated
HASP System.
The specification must be an integer
between Q and 99 inclusive.
The specification for
&NUMLNES automatically becomes the specification
for &NUMRJE, unless &NUMRJE is specified explicitly.
Default:
&NUMLNES=Q
Notes:
1.
See also the HASPGEN variable LINEmm.
2.
If &NUMLNES is set to or left at zero, all
other Remote Job Entry parameters should
be left at their default values.
HASPGEN Parameters - Page 7.1.42
351
HAS P
&NUMOACE
&NUMOACE
Explanation: Variable symbol &NUMOACE specifies the
. number of overlay areas to be provided for the standard
HASP Overlay feature. The specification must be an
integer greater than zero.
Default:
&NUMOACE=l
Notes:
1.
It is judged that more than two overlay areas
will benefit only a system with high performance
orientation (a ~ery fast CPU or a work load consisting of a large number of short jobs).
2.
See also parameter &OLAYLEV.
HASPGEN Parameters - Page 7.1.43
352
HAS P
&Nl1MPRTS
&NUMPRTS
Explanation: Variable symbol &NUMPRTS specifies th~
maximum number of physical printers HASP may use to
print the printed output of jobs. HASP supports 1403
and 3211 printers. Th:e specification must be an
integer greater than zero.
Default:
I
&NUMPRTS=2
Notes:
1.
If HASP initialization finds more than &NUMPRTS
1403 and 3211 printers, it writes to operator
the message
MAXIMUM OF &NUMPRTS PRINTER(S) EXCEEDED
and continues normally, using as printers only
the &NUMPRTS printers with lowest unit
addresses.
•
2.
Regardless of the number specified for &NUMPRTS,
HASP will use only those 1403 and 3211 printers
which are operational (as.shown by a TIO) or
on-line (for M65MP only) when HASP is started.
3.
Handling of special forms by printer, the optional 1403 UCS buffer, and the 3211 UCS and
Forms Control buffers are explained as part of
the $T operator command.
4.
This variable influences the size of the HASP
checkpoint record; see Note 2 of variable
·&MAXJOBS.
5.&BUFSIZE must be 536 or greater if 3211 printers
are used by HASP.
HASPGEN Parameters - Page 7.1.44
353
&N UMP UN S
&NUMPUNS
Explanation: Variable symbol &NUMPUNS specifies
the maximum number of physical punches which will
be used by HASP to punch the punched output of
jobs. HASP s~pports 3525, 2540, 2520, and 1442
card punches. The specification must be an integer
greater than or equal to zero.
Default:
&NUMPUNS=l
Notes:
1.
If HASP initialization finds more than &NUMPUNS
3525, 2540, 2520 and 1442 punches, it writes to
operator the message
MAXIMUM OF &NUMPUNS PUNCH(S) EXCEEDED
and continues normally, using as printers only
the &NUMPUNS punches with lowest unit addresses.
2.
Regardless of the number specified for &NUMPUNS,
HASP will use only those 3525, 2540, 2520 and
1442 punches which are operational (as shown by
a TIO) or on-line (for M65MP only) when HASP is
started.
3.
If &NUMPUNS=O, parameter &ACCTNG should be set
to NO.
HASPGEN Parameters - Page 7.1.45
354
&NUMRDRS'
HAS P
&NUMRDRS
I
Explanation: Variable symbol &NUMRDRS specifies the
maximum number of physical card readers HASP may use
to read OS job streams. HASP supports 3505, 2540
and. 2501 card readers. The specification must be an
integer greater than zero.
Default:
I
I
&NUMRDRS=l
Notes:
1.
If HASP initialization finds more than &NUMRDRS
3505, 2540 and ·2501 card readers, it writes to
operator the message
MAXIMUM OF &NUMRDRS READER(S) EXCEEDED
and continues normally, using as readers only
the &NUMRDRS readers with lowest unit addresses.
2.
Regardless of the number specified for &NUMRDRS,
HASP will use only those 3505, 2540 and 250l
readers which are operational (as shown by a
TIO) . or on -line (for M6 5r~p only) when HASP is
started.
l
HASPGEN Parameters - Page 7.1.46
355
HAS P
&NUMRJE
&NUMRJE
Explanation: Variable symbol &NUMRJE specifies the
largest remote terminal identification number
(nn in RMTnn) and thus the number of remote terminal
definitions which are to be used by the generated
HASP System. The specification must be an integer
bet~een 0 and 99 inclusive.
Default:
&NUMRJE=&NUMLNES
Notes:.
1.
See also the HASPGEN variable RMTnn.
2.
If this variable is not specified and if
&NUMLNES is specified as an integer greater
than zero, the first &NUMLNES remote terminal
definitions RMTnn are used by the generated
HASP System, whether they are specified
explicitly or by default.
HASPGEN Parameters - Page 7.1.47
356
&NUMTGV
HAS P
&NUMTGV
Explanation: Variable symbol &NUMTGV specifies the
number of units (track groups) into which each SPOOL
volume will be divided for HASP allocation purposes.
The specification must be a positive integer no
greater than the number of tracks on the SPOOL device
with the fewest tracks.
Default:
&NUMTGV=400
Notes:
1.
The user should decide upon the number of tracks
he requires in a track group and then divide by
that number the total number of tracks (except
alternate tracks) on a typical SPOOL device type
at the installation. For example, to obtain a
track group size of-five tracks on a 2311, the
division would yield a quotient of 400; the user
would specify &NUNTGV=400.
If the same installation occasionally used a 2314 as a SPOOL
device, the track group size for the 2314 would
automatically become ten tracks.
2.
Specifying a large &NUMTGV may require increasing
the value of &BUFSIZE.
3.
For each SPOOL volume it finds, HASP initialization calculates number of tracks per group by
dividing 'the total number of tracks on the volume
by &NUMTGV.
It then marks unavailable all track
groups which lie partially or wholly outside
the first extent of data set SYSl.HASPACE on
that volume. HASP initialization also computes
the number of HASP buffers of length &BUFSIZE
which will fit on a track of the SPOOL volume
for each SPOOL volume mounted.
HASPGEN Parameters - Page 7.1.48
357
,
(
&NUMTPBF
HAS P
&NUMTPBF
Explanation: Variable symbol &NUMTPBF specifies
the number of HASP Teleprocessing buffers for HASP
Remote Job Entry to be assembled into the generated
HASP system. The specification must be an integer
greater than or equal to zero.
Default:
&NUMTPBF=&NUMLNES
Notes:
1.
Each signed-on HASP Multi-Leaving terminal requires at least two HASP Teleprocessing buffers;
each other signed-on terminal requires at least
one buffer. If &NUMTPBF is specified too small,
HASP RJE may not work correctly.
2.
See also parameters &TPBFSIZ and &MLBFSIZ.
HASPGEN Parameters - Page 7.1.49
358
&NUMTPES
HAS P
&NUMTPES
Explanation: Variable symbol &NUMTPES specifies
the maximum number of tape drives HASP may use
simultaneously to read OS job streams.
The specification must be an integer greater than or equal
to zero.
Default:
&NUMTPES=l
Notes:
1.
If &NUMTPES=O is specified, code required to
support tapes as readers is omitted from the
generated HASP System.
2.
Since the operator specifies a unit address
when issuing the start command to a tape drive
(e.g., $S TPEl,182) , there is rarely a need to
specify for &NUMTPES a number greater than one.
3.
Tapes should be equivalent to the JCL specification LABEL=(1,NL),DCB=(RECFM=FB,LRECL=80 1
BLKSIZE=nnnnn) where nnnnn is not greater than
(lO*&BUFSIZE)/11.
For seven-track tape, use
the additional DCB specification DEN=2,TRTCH=C.
HASPGEN Parameters - Page 7.1.50
359
&NUMTPPR
HAS P
&NUMTPPR
Explanation: Variable symbol &NUMTPPR specifies the
maximum number of HASP Remote Terminal (including MultiLeaving) printed-output streams that can simultaneously
be active. The specification must be an integer greater
than or equal to zero.
Default:
&NUMTPPR=&NUMLNES
Notes:
1.
If any remote terminal is to receive printed
output, &NUMTPPR must not be zero.
HASPGEN Parameters - Page 7.1.51
360
HAS P
&NUMTPPU
&NUMTPPU
Explanation: Variable symbol &NUMTPPU specifies the
maximum number of HASP Remote Terminal (including
Multi-Leaving) punched-output streams that can
simultaneously be active. The specification must
he an integer greater than or equal to zero.
Default:
&NUMTPPU=&NUMLNES
Notes:
1.
If any remote terminal is to receive punched
output, &NUMTPPU must not be zero.
HASPGEN Parameters - Page 7.1.52
361
&NUMTPRD
HAS P
&NUMTPRD
Explanation: Variable symbol &NUMTPRD specifies the
maximum number of HASP Remote Terminal (including
Multi-Leaving) input streams that can simultaneously
be active. The specification must be an integer
greater than or equal to zero.
Default:
&NUMTPRD=&NUMLNES
Notes:
1.
If any remote terminal is to read cards (including
the /*SIGNON and /*SIGNOFF control cards) &NUMTPRD
must not be zero.
HASPGEN Parameters - Page 7.1.53
362
&NUMWTOQ
HAS P
&NUMWTOQ
Explanation: Variable symbol &NUMWTOQ specifies
the number of message buffers to be provided in
HASP. The specification must be an integer greater
than two.
Default:
&NUMWTOQ=15
Notes:
1.
If &NUMCONS is specified greater than zero
additional message buffers are needed.
'
2.
If Remote Job Entry is used, more message
buffers are needed.
This is especially true
with console support for MULTI-LEAVING
terminals.
3.
Serious system degradation can be caused by
specifying too few message buffers.
4.
During periods of high console activity, when
no message buffers are available, certain noncritical HASP messages will be discarded rather
than delaying the associated process. These
include certain RJE oriented messages (such
as communication line error messages), execution
time/line/card excession messages (continued
excession will be noted when a message buffer
becomes available), and certain I/O error messages on HASP-controlled devices. Additionally,
when no message buffers are available in a system in which &NUMCONS is greater than zero,
messages from the OS error task are queued only
to a depth of one which can result in the loss
of some of these messages.
HASPGEN Parameters - Page 7.1.54
363
&OLAYLEV
HAS P
&OLAYLEV
Explanation: Variable symbol &OLAYLEV specifies a
HASP overlay level to be used for assembly of the
various HASP control sections. Any potential overlay
code defined (by the $OVERLAY macro) with a residence
factor greater than &OLAYLEV will be assembled as
resident code rather than overlay code. The specification for &OLAYLEV must be an integer between
and
IS, inclusive.
°
Default:
&OLAYLEV=lS
Notes:
1.
HASP uses only residence factors 4, 8, 12 and (for
HASP initialization only) 0.
2.
If &OLAYLEV=lS, all potential overlay code will
be assembled as overlay code.
3.
If &OLAYLEV=O, all potential overlay code except
that in HASP initialization will be assembled
as resident code. HASP main storage requirements
will be increased by approximately 24K over
the case &OLAYLEV=IS.
4.
Regardless of the setting of &OLAYLEV, the installation systems programmer may use control cards
for the HASP Overlay Builder after the HASPGEN
process is .complete to specify that a particular
section of potential overlay code be made either
resident code or overlay code.
HASPGEN Parameters - Page 7.l.S5
364
&OREPSIZ
HAS P
&OREPSIZ
Explanation: Variable symbol &OREPSIZ specifies the
size in bytes of a table in HASP to be used to hold
REP data for true overlay code. The REPs associated
with a particular section of true overlay .code will
be applied to that code every time it is brought into
main storage from the HASP overlay library. The
specification for &OREPSIZ must be either 0 or an
integer not less than 10.
Default:
&OREPSIZ=O
Notes:
1.
Each entry in the HASP Overlay REP table consists
of 8+n bytes (2:::; n :::; 256) where n is the number
of contiguous bytes to be changed in a section
of overlay code.
2.
The table is used only if the operator specifies
to HASP initialization that REPs are to be used
and if some of the REPs are for sections of true
overlay code.
3.
If the HASP Overlay REP table is too small to
handle all true overlay REPs, HASP initialization
writes to operator the message
OVERLAY REPPING ERROR
and HASP quiesces.
4.
See also Sectio'n 6.4 of this manual.
HASPGEN Parameters - Page 7.1.56
365
&OSC(n)
HAS P
&OSC(n)
Explanation:
Subscripted variable symbols &OSC(n)
specify OS job classes. A job selected by HASP
logical partition n will be submitted to OS with the
job class &OSC(n). Each specification must be a
single unique letter between A and 0, inclusive.
No two specifications may be the same.
Default:
&OSC(l)=A
&OSC(2)=B
&OSC(3)=C
&OSC(4)=D
&OSC(5)=E
&OSC(6)=F
&OSC(7)=G
&OSC(8)=H
&OSC(9)=I
&OSC(lO)=J
&OSC(ll)=K
&OSC(12)=L
&OSC(13)=M
&OSC(14)=N
&OSC(15)=0
Notes:
1.
Only the first· &MAXPART specifications, &OSC (1)
through &OSC(&MAXPART) will be used.
2.
In an MVT system, HASP initialization issues
the &MAXPART commands
S INIT. HOSINIT&OSC (1) , , , &OSC (1)
3.
S INIT.HOSINIT&OSC(&MAXPART) ",&OSC(&MAXPART).
In an MFT system, HASP initialization issues the
single command
S INIT.ALL;
thus the classes of the MFT partitions to be
controlled by HASP must have already been defined.
Each such partition must be defined with only
one job class; that job class must match one and
only one of the &MAXPART job classes &OSC(l),
&OSC (&MAXPART) .
HASPGEN Parameters - Page 7.1.57
366
&OSINOPT
HAS P
&OSINOPT
I
Explanation: Variable symbol &OSINOPT specifies inclusion or exclusion of the HASP OS Input Spooling
option. The specification must be either YES or NO.
If &OSINOPT=YES and a DD * (or DD DATA) statement
specifies the DeB keyword, HASP will pass the DD
statement and the data following it to the OS Reader/
Interpreter; OS will perform input spooling.
If
&OSINOPT=NO, or if &OSINOPT=YES and no DeB parameter
is specified on the DD * (or DD DATA) statement, HASP
will SPOOL the input data as usual.
Default:
I
&OSINOPT=NO
Notes:
1.
If the DLM parameter is specified on a DD * (or
DD DATA) statement, HASP will SPOOL the input
data regardless of the setting of &OSINOPT or
the inclusion of DeB parameters.
HASPGEN Parameters - Page 7.1.58
367
HAS P
&OUTPOPT
&OUTPOPT
Explanation: Variable symbol &OUTPOPT specifies the
action to be taken when a job exceeds its estimated
print lines or punched cards of output. The specification must be one of the integers 0, 1 or 2. For
&OUTPOPT=2, output excession causes the job to be
cancelled with a dump. For &OUTPOPT=l, output excession causes the job to be cancelled without a
dump. For &OUTPOPT=O, output excession does not
cause the job to be cancelled.
Default:
&OUTPOPT=O
Notes:
1.
Regardless of the specification for &OUTPOPT,
output excession causes messages to be written
to the operator. See also Notes 1 and 2 of
$OUTXS.
2.
If &OUTPOPT=2 is specified, users should use
SYSUDUMP or SYSABEND DD cards if a storage dump
is desired on output excession.
3.
For &OUTPOPT=l or 2, the job will not be
cancelled if, at the time of output excession,
the calling task is normally or abnormally terminating. Therefore, if this terminating task
is not the job step task, job termination may
not occur unless provided for by the program
or unless the operator cancels the job.
HASPGEN Parameters - Page 7.1.59
368
$OUTXS
HAS P
$OUTXS
Explanation:
Ordinary symbol $OU'llXS specifies
the interval, in print lines/punched cards, at
which messages will be written to the operator
informing him that a job's print line count or
punch card count has been exceeded.
The specification must be an integer greater than zero.
Default:
$OUTXS=2000
Notes:
1.
The first print line excession message will
be written to the operator when the job's
estimated print line count has been exceeded.
2.
The first punched card excession message
will be written to the operator when the
job's estimated punched card count has been
exceeded.
HASPGEN Parameters - Page 7.1.60
369
&PID(n)
HAS P
&PID (n)
Explanation: Subscripted variable symbols &PID(n)
specify the identifiers to be used with the HASP
logical partitions. Each specification must be
a unique 1- or 2-character string.
Default:
&PID(l)=l
&PID(2)=2
&PID(3)=3
&PID(4)=4
&PID(S)=S
&PID(6)=6
&PID(7)=7
&PID(8)=8
&PID(9)=9
&PID(lO)=lO
&PID(ll)=ll
&PID(l2)=12
&PID(13)=13
&PID(14)=14
&PID(lS)=lS
Notes:
1.
Only the first &MAXPART specifications, &PID(l)
through &PID(&MAXPART), will be used.
2.
The identifiers &PID(n) are used in messages
to and commands from the operator. For example,
when an operator uses the set command $T Imm,list
he is referring not to logical partition rom but
to logical partition n, where &PID(n)=mm.
HASPGEN Parameters - Page 7.1.61
370
HAS P
&PRI(n)
Explanation: Subscripted variable symbols &PRI(n)
specify as job priorities. A job selected by HASP
logical partition n will be submitted to as with the·
job priority &PRI(n). Each specification must be
an integer between 1 and 15, inclusive.
Default:
&PRI(1)=7
&PRI(2)=7
&PRI (3) =7
&PRI(4)=7
&PRI(5)=7
&PRI(6)=7
&PRI (7) =7
&PRI(8)=7
&PRI(9)=7
&PRI(lO)=7
&PRI(II)=7
&PRI(12)=7
&PRI(13)=7
&PRI(14)=7
&PRI(l5)=7
Notes:
1.
The defaults are all the same as &XZPRTY. This
allows the HASP Execution Task Monitor to regulate all job steps under the control of HASP.
See also parameters &XZPRTY and &MONINTV.
2.
These parameters have no effect in MFT.
3.
The priorities defined by &PRI(n) affect only
as execution. The priority of a job in the
HASP Job Queue is determined by parameters
&RPRT(m), &RPRI(m), &XLIN(m), and &XPRI(m).
4.
Only the first &MAXPART specifications, &PRI(I)
through &PRI(&MAXPART), will be used.
HASPGEN Parameters - Page 7.1.62
371
HAS P
$PRICONA
$PRICONA
Ex~lanation:
Ordinary symbol $PRICONA specifies the
un1t address of a 1052, 3210, 3215, 1443, or 1403 to
which HASP will issue a SIO in the event of a catastrophic error. The message HASP writes to this device
is:
HASP CATASTROPHIC ERROR. CODE=xxx.
The specification must be a valid unit address.
Default:
$PRICONA=OlF
Notes:
1.
When HASP is operating with M65MP in a 2-CPU
multiprocessor environment, the device specified
by $PRICONA must be operational to both CPUs
when a HASP catastrophic error occurs.
HASPGEN Parameters - Page 7.1.63
372
HAS P
$PRIDCT
$PRIDCT
Explanation:. Ordinary symbol $PRIDCT specifies the
number of print lines to appear on each HASP job
separator page for local printers. The specification
must be an integer greater than or equal to zero.
If
the specification is zero, no separator page will be
produced on local printers.
Default:
$PRIDCT=6l'
Notes:
1.
The equivalent HASPGEN parameter for remote
terminal printers is $TPIDCT.
HASPGEN Parameters - Page 7.1.64
373
&PRIHIGH
HAS P
&PRIHIGH
Explanation: Variable symbol &PRIHIGH specifies a
HASP priority to be associated with the HASP Priority
Aging feature. A job will not be priority-aged if
its HASP priority is (or becomes) greater than or
equal to &PRIHIGH. The specification must be an
integer between 0 and 15, inclusive.
Default:
&PRIHIGH=lO
Notes:
1.
If &PRIRATE=O, parameter &PRIHIGH is not used.
2.
See also parameters &PRIRATE and &PRILOW.
HASPGEN Parameters - Page 7.1.65
374
HAS P
&PRILOW
&PRILOW
Explanation: Variable symbol &PRILOW specifies a
HASP priority to be associated with the HASP Priority
Aging feature. A job will not be priority-aged by
HASP unless its HASP priority is initially at least
&PRILOW. The specification must be an integer between
o and 15, inclusive.
Default:
&PRILOW=5
Notes:
1.
If &PRlRATE=O, parameter &PRILOW is not used.
2.
See also parameters &PRIRATE and &PRIHIGH.
HASPGEN Parameters - Page 7.1.66
375
&PRIRATE
HAS P
&PRlRATE
Explanation: Variable symbol &PRlRATE specifies the
amount by which a job's HASP priority will be incremented in 24 hours by the HASP Priority Aging feature.
For example if &PRIRATE=3 then a job's priority will
be incremented by one for every eight hours it remains
in the system. But a job's priority will not be incremented unless it is at least &PRILOW; nor will a job's
priority be incremented above &PRIHIGH. The specification must be an integer greater than or equal to
zero.
If zero is specified, Priority Aging is excluded
from the generated HASP system.
Default:
&PRIRATE=O
Notes:
1.
If &PRIRATE=O, parameters &PRILOW and &PRIHIGH
are not used.
2.
See also parameters &RPRT(n), &RPRI(n}, &XLIN(n),
and &XPRI (n) .
3.
If a job's priority is specified on the /*PRIORITY
control card, the job will be priority-aged if
its priority is eligible.
HASPGEN Parameters - Page 7.1.67
376
$PRTBOPT
HAS P
$PRTBOPT
Explanation: Ordinary symbol $PRTOPT specifies the
printer buffering option to be used for local HASP
printers.
The specification must be either 1 (for
single buffering) or 2 (for double buffering) .
Default:
$PRTBOPT=2
HASPGEN Parameters - Page 7.1.68
377
&PRTRANS
HAS P
&PRTRANS
Explanation: Variable symbol &PRTRANS specifies
translation for lines of print. The specification
must be either YES or NO.
Default:
&PRTRANS=YES
Notes:
1.
If &PRTRANS is specified as YES, each line to
be printed by HASP is first translated. Translation changes lower-case letters to upper-case
letters and characters invalid on a PN train to
blanks.
2.
If any print train is to be used on any HASPcontrolled pr-inter which has characters not
equivalent to those on a PN train or a Pll train,
&PRTRANS must be specified as NO.
HASPGEN Parameters - Page 7.1.69
378
&PRTUCS
HAS P
&PRTUeS
Explanation: Variable symbol &PRTUeS specifies the
name of the print chain or print train which HASP
initially assumes is mounted on every local 1403
printer SYSGENed with the ues feature, and on every
local 3211 printer. The ues identifier can be modified by the operator individually by printer. The
specification should be either AN, HN, PN, QN, RN,
UN, All, Hll, Pll, Ull, or O.
Default:
&PRTUeS=O
Notes:
1.
A specification of zero causes HASP to bypass
the ues loading procedure on all local printers
until the ues type of each printer is specified
by the operator.
.
2.
Only the first character of &PRTUeS is interrogated. That is to say, an AN specification is
equivalent to an All specification, an Hll
specification is equivalent to an HN specification, etc.
3.
If a ues specification is encountered which is
not valid for the type of printer being addressed,
the ues loading procedure will be bypassed.
4.
The UN and Ull specifications are provided for
installation use to support other type of print
chains.
HASPGEN Parameters - Page 7.1.70
379
$PUNBOPT
HAS P
$PUNBOPT
Explanation: Ordinary symbol $PUNBOPT ~ecifies the
punch buffering option to be used for local HASP
punches. The specification must be either 1 (for
single buffering) or 2 (for double buffering).
Default:
$PUNBOPT=l
HASPGEN Parameters - Page 7.1.71.
380
&RDR
HAS P
&RDR
Explanation: Variable symbol &RDR specifies the
unit address of a pseudo-2540 reader to be used with
HOSRDR to supply jobs to os.
The specification must
be a valid unit address which has been specified at
SYSGEN time as a pseudo-2540 reader.
Default:
&RDR=OFC
HASPGEN Parameters - Page 7.1.72
381
&RDRPART"
HAS P
&RDRPART
Explanation: Variable symbol &RDRPART specifies for
MFT systems the identifier field of an OS START
command issued by HASP initialization for the OS
reader/interpreter HOSRDR. The complete START command
is
S HOSRDR.&RDRPART,&RDR.
The specification must be a valid identifier field
for an OS START reader command, as described in the
OS Operator's Guide.
Default:
&RDRPART=S
Notes:
1.
If HASP initialization detects an MVT system,
this parameter is not used.
HASPGEN Parameters - Page 7.1.73
382
$REPRDR
HAS P
$REPRDR
Explanation: Ordinary symbol $REPRDR specifies the
unit address of a physical 2540 or 2501 card reader
from which HASP initialization will read REP cards
if requested by the operator. The specification
must be a valid unit address.
Default:
$REPRDR=OOC
Notes:
1.
When REP cards are to be read and HASP is
operating with M65MP in a 2-CPU multiprocessor
environment, the device specified by $REPRDR
must be operational to both CPUs.
HASPGEN Parameters - Page 7.1.74
383
$REPWTR
HAS P
$REPWTR
Exelanation: Ordinary symbol $REPWTR specifies the
un1t address of a physical 1403 or 1443 on which
each REP card read is to be printed, if printing
of REP cards is requested by the operator. The
specification must be a valid unit address.
Default:
$REPWTR=OOE
Notes:
1.
When REP cards are to be printed and HASP is
operating with M65MP in a 2-CPU multiprocessor
environment, the device specified by $REPWTR
must be operational to both CPUs.
HASPGEN Parameters - Page 7.1.75
384
HAS P
&RESCORE
&RESCORE
Explanation: Variable ·symbol &RESCORE specifies a
storage size, in multiples of 1024 bytes. HASP will
always issue a GETMAIN for additional storage for
HASP buffers; all such storage but &RESCORE*1024
bytes will be used for buffers.
The specification must be an integer greater than or
equal to zero.
Default:
&RESCORE=O
Notes:
1.
MFT users should set &RESCORE=l or larger if
80A or 804 abends occur during HASP operation.
This is normally not required for unmodified
HASP with MVT, because of its 2K block storage
management technics.
2.
&RESCORE only prevents HASP from using all
available storage for butfers. It will not
cure abends due to inadequate partition si2e.
HASPGEN Parameters - Page 7.1.76
385
HAS P
&RJOBOPT
&RJOBOPT
Explanation: Variable symbol &RJOBOPT specifies
whether or not an illegal HASP JOB card is to prevent
execution of the associated job. The specification
must be either YES or NO.
Default:
&RJOBOPT=NO
Notes:
1.
If &RJOBOPT=YES and HASP reads a JOB card whose
accounting field does not match the specifications required by HASP, the job 1S flushed by
HASP and an appropriate message is written to
the operator.
HASPGEN Parameters - Page 7.1.77
386
RMTnn
HAS P
RMTnn
Explanation: Ordinary symbols RMTnn specify the
characteristics of remote terminals to be used with
HASP Remote Job Entry. Terminals must be defined
consecutively, starting with RMTOI. Each specification must be a l4-character string of the form
RMTnn=mmooppiillwtdf
where the letters represent the following:
Code Letters
Range
Description
nn
01-99
Remote Number
mm
01-99
Line Number (**indicates /*SIGNON
assignment)
00
00-99
Print Routing (Remote Number)
pp
00-99
Punch Routing (Remote Number)
ii
00-15
Priority Increment for this Remote
11
00-15
Priority Limit for this Remote
w
0-6
Printer Width as follows:
o = 80 characters
1 = 100 characters
2 = 120 characters
3 = 132 characters
4 = 144 characters
5 = 150 characters
6 = 96 characters
t
0-6
Terminal
o =
1 =
2 =
3 =
4 =
Type as follows:
1009, 2770
1978, 2780, 7702
2922, 5360/20 Sub-Model 2, 4
System 360/20 Sub-ModelS, 6
System 360/22, 25, 30, 40,
etc.
5 = 1130
6 = System/3
7 = 3780
HASPGEN Parameters - Page 7.1.78
387
HAS P
d
0-4
Data Format as follows:
o = Unblocked fixed length
1 = Blocked fixed length
2 = Unblocked variable length
(Note ~ use this for basic
2770 terminals.)
3 = Blocked variable length
(Note - use this for all
3780, 2780,· and 1978 terminals, and for 2770 terminals with Buffer Expansion. )
4 = Programmable Interface
(Note - use this for all
STR 20 and BSC MULTILEAVING interfaces.)
Terminal Features as. follows:
f
0-9
3780 Terminal Features
f
Compress
EXEand
Horizontal
Format Control
Trans-
No
No
No
No
Yes
Yes
No
No
Yes
Yes
No
No
No
Yes
No
Yes
No
Yes
0
1
4
5
8
9
Earenc~
2770 Terminal Features
O-@
f
0
1
2
3
4
5
6
7
8
9
#
@
Compress
EX12and
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Horizontal
Format
Control
No
No
No
No
Yes
Yes
Yes
Yes
No
. No
No
No
Additional
Buffer
EX12ansion
Transparencl
No
No
Yes
Yes
No
No
Yes
Yes
No
No
Yes
Yes
HASPGEN Parameters - Page 7.1.79
388
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
HAS P
0-7
2780 Terminal Features
Horizontal
Format
Control
f
No
No
No
No
Yes
Yes
Yes
Yes
0
1
2
3
4
5
6
7
0-3
Default:
Multiple
Record
Feature
TransEarency
No
Yes
No
Yes
No
Yes
No
Yes
No
No
Yes
Yes
No
No
Yes
Yes
MULTI-LEAVING Terminal Features
f
Console
SUEEort
0
1
2
3
No
No
Yes
Yes
TransEarenc~
No
Yes'
No
Yes
RMTnn=**nn0000153131
Notes:
1.
Parameter &NUMRJE must specify the number of
specifications RMTnn to be included in the
generated HASP system.
2.
No two specifications RMTnn may specify the
same line number (rom). If ** is specified instead of a line number for rom, the associated
remote terminal may connect to HASP via any
suitab1~ line.
HASP will logically connect
the terminal with the line when it recognizes
the /*SIGNON control card. If line number is
specified explicitly, the associated terminal
need not use a /*SIGNON card.
3.
The line number specification rom refers to line
specification LINEmm, which in turn specifies
the unit address of the line.
4.
For print and punch routing, a specification of
00 causes output from jobs submitted at the Remote Terminal to be printed/punched locally,
unless re-routed.
HASPGEN Parameters - Page 7.1.80
389
HAS P
5.
6.
7.
8.
9.
10.
Priority increment is the value to be added to
the priority of a job submitted from the Remote
Terminal.
Priority limit is the maximum value of priority
for any job submitted from the Remote Terminal.
If any Multi-Leaving work'station is to utilize
·more than one reader, printer or punch, see
Section 12.16 for additional information.
For a basic 2770 (128 byte buffers), Printer
Width must be specified as 120 characters or
less.
Printed and non-transparent punched output to
a basic 2770 will be variable-blocked up to the
limit of the 128 byte buffers, even though the
Data Format must be specified as variab1eunblocked.
The following table gives minimum values of
&TPBFSIZ required to support various nonprogrammable terminals:
Minimum
&TPBFSIZ
128
256
328
400
512
512
Terminal Type, Features
2770 basic
2770 with Buffer Expansion
1978
2780
2770 with Buffer Expansion
and Additional Buffer
Expansion
3780
See also parameters &TPBFSIZ and &MLBFSIZ.
HASPGEN Parameters - Page 7.1.80.1
389.1
HAS P
(The remainder of this. page intentionally left blank.)
389.2
HAS P
$RPRBOPT
$RPRBOPT
Exelanation: Ordinary symbol $RPRBOPT specifies the
pr1nter buffering option to be used for all printers
at HASP Remote Terminals. The specification must be
either 1 (for single buffering) or 2 (for double
buffering) •
Default:
$RPRBOPT=l
Notes:
1.
The specification refers to HASP regular buffers,
not to HASP Teleprocessing buffers.
HASPGEN Parameters - Page 7.1.81
390
HAS P
&RPRI(n)
&RPRI(n)
Explanation:
Subscripted variable symbols &RPRI(n)
specify tentative job priorities corresponding to
intervals defined by subscripted variable symbols
&RPRT(n).
If a user specifies in the accounting
field of his job card an estimated execution time
of t minutes, the job's tentative priority will
be &RPRI(n) where
&RPRT (n-l).< ts; &RPRT (n) .
Each specification must be an integer between 0 and
15 inclusive.
Default:
&RPRI(1)=9
&RPRI(2)=8
&RPRI(3)=7
&RPRI(4)=6
&RPRI(5)=5
&RPRI(6)=4
&RPRI(7)=3
&RPRI(8)=2
&RPRI(9)=1
Notes:
1.
The values &RPRI(n) will normally be in
opposite order from the subscripts n.
2.
See also Notes 1 and 2 for &RPRT(n).
HASPGEN Parameters - Page 7.1.82
391
HAS P
&RPRT(n)
&RPRT (n)
Explanation: Subscripted variable symbols
&RPRT(n) specify estimated execution times in
minutes.
If a user specifies in the accounting
field of his job card an estimated execution time
of t minutes, and if t satisfies the relation
&RPRT(n-l) lanation: Variable symbol &XZPRTY specifies a
value used by the HASP Execution Task Monitor
for MVT systems.
The Execution Task Monitor periodically analyzes each MVT HASP-controlled job step task,
without subtasks', whose dispatching priority is
&XZPRTY*16+ll.
In order to balance the CPU utilization characteristics of these tasks, the Execution
Task Monitor may re-order these tasks on the TCB
ready chain.
The specification for &XZPRTY must be
an integer between 0 and 15 inclusive, or the expression "0-1". The latter value should be used when the
Execution Task Monitor is to operate for MFT but not
for MVT.
pr~ority
Default:
&XZPRTY=7
Notes:
1.
If &MONINTV=O, the value of &XZPRTY is not used.
2.
If &XZPRTY is specified as 0-1 and &XZMFTH is
specified as 0, then &MONINTV must be set to O.
HASPGEN Parameters"; Page
419
7.1.11Q
$$x
HAS P
$$x
Explanation: Ordinary symbol $$x specifies the
destination for an output data set designated in the
user's JCL as SYSOUT=x. The specification for each
of these ordinary symbols must be one of the characters A, B, 1, 2, or *.
For $$x=A, associated SYSOUT data sets will be
printed with the user's job.
For $$x=B, associated SYSOUT data sets will be
punched with the user's job.
For $$x=l, associated SYSOUT data sets will be
added to the HASP special forms queue, to be printed
with other SYSOUT data sets requiring the same
forms.
For $$x=2, associated SYSOUT data sets will be
added to the HASP special forms queue, to be punched
with other SYSOUT data sets requiring the same
forms.
For $$x=*, associated SYSOUT data sets will be
processed entirely by OS.
In this case, HASP will
add the specification UNIT=SYSDA to the JCL, unless
the user has himself specified UNIT=information.
Default:
$$A=A
$$B=B
$$C=A
$$D=A
$$E=A
$$F=A
$$G=A
$$H=A
$$I=A
$$J=l
$$K=2
$$L=A
$$M=A
$$N=A
$$O=A
$$P=A
$$Q=A
$$R=A
$$S=A
$$T=A
$$U=A
$$V=A
$$W=A
$$X=A
$$Y=A
$$Z=A
$$l=A
$$2=A
$$3=A
$$4=A
$$5=A
$$6=A
$$7=A
$$8=A
$$9=A
$$O=A
HASPGEN Parameters - Page 7.1.111
420
HAS P
Notes:
1.
For any output class x, regardless of the value
specified for $$x, a four-digit special forms
number can be coded as the third positional
parameter of the SYSOUT=keyword.
The specification is converted to a packed number (unless
$$x=*) i that is, forms number 0001 is the same
as forms number 01.
2.
For an output class x for which $$x=*, the
SYSOUT=parameter may be coded as described in
the OS Job Control Language Reference manual.
3.
A user SYSOUT specification which includes the
second positional parameter (program name) will
be processed entirely by OS, regardless of
whether the associated $$ parameter was specified
as *.
4.
If a given output class x is one of the classes
assigned to &WTRCLAS, it must not be used in a
SYSOUT specification to be processed by OS
(caused if $$x=*, or if the second parameter
of SYSOUT is used), unless that class x is
subject to requeueing as described under the
parameter &WCLSREQ.
HASPGEN Parameters - Page 7.1.112
421
HAS P
7.2
RMTGEN PARAMETERS FOR SYSTEM/360 MODEL 20 STR
This section describes the parameters used in assembly
of the System/360 Model 20 STR Remote Terminal Program
for HASP Remote Job Entry. The parameters are used
during RMTGEN to specify hardware configuration and
software options.
For each parameter there is an explanation, the default
value, and frequently notes which expand upon the
explanation.
The parameters are listed in alphabetical order.
STR-20 RMTGEN Parameters - Page 7.2.1
422
&CCT
HAS P
&CCT
Explanation: Variable symbol &CCT specifies the
degree of text compression to be provided in the
program. For text transmission to HASP, the program
will compress strings of &CCT or more identical
characters. The specification must be an integer
between 3 and 80 inclusive.
Default:
&CCT=4
Notes:
1.
Low values of &CCT cause creation of highly
compact records, increasing effective line speed
at the expense of CPU
STR-20 RMTGEN Parameters - Page 7.2.2
423
&CORESIZ
HAS P
&CORESIZ
Explanation: Variable symbol &CORESIZ specifies the
amount of main storage available to the program in
K bytes. The specification must be "an integer greater
than O.
Default:
&CORESIZ=8.
STR-20 RMTGEN Parameters - Page 7.2.3
424
HAS P
&NUMBUFS
&NUMBUFS
Explanation: Variable symbol &NUMBUFS specifies the
maximum number of buffers to be used by the program.
The specification must be an integer greater than or
equal to 2.
Default:
&NUMBUFS=10
Notes:
1.
The length of each buffer is given by HASPGEN
parameter &TPBFSIZ.
STR-20 RMTGEN Parameters - Page 7.2.4
425
&PUNCH
HAS P
&PUNCH
Explanation: Variable symbol &PUNCH specifies inclusion(&PUNCH=l) or exclusion (&PUNCH=O) of support
for a card punch attached to the Model 20. The specification must be either 0 or 1.
Default:
&PUNCH=1
Notes:
1.
The program supports 1442, 2520, and 2560 card
punches interchangeably.
STR-20 RMTGEN Parameters - Page 7.2.5
426
11 ASP
7.3
RMTGEN PARAMETERS FOR SYSTEM/360 MODEL 20 Bse
This section describes the parameters used in assembly
of the System/360 Model 20 BSe Rempte Terminal Program
for HASP MULTI-LEAVING Remote Job Entry. The parameters
are used during RMTGEN to specify hardware configuration
and software options.
For each parameter there is an explanation, the default
value, and frequently notes which expand upon the
explanation.
The parameters are listed in alphabetical order.
BSC-20 RMTGEN Parameters - Page 7.3.1
427
&CCT
HAS P
&CCT
Explanatidn:Variable symbol &CCT specifies for all
text compression but trailing blank compression the
minimum number ox characters to be compressed. A
duplicate character string of fewer than &CCT characters will be treated as a string of non-duplicate
characters for compression purposes. The specification
m:ust be an integer between 3 and 31, inclusive.
Default:
&CCT=4
Notes:
1.
See also &CMPTYPE. The value of &CCT is not
used if &CMPTYPE=l.
2.
A smaller value of &CCT increases efficiency
of communication line usage at the expense of
compute time required for compression.
BSC-20 RMTGEN Parameters - Page 7.3.2
428
&CMPTYPE
HAS P
&CMPTYPE
Explanation: . Variable symbol &CMPTYPE specifies the
type of compression to be applied to all text transmitted from the Model 20 to the central computer.
The specification must be either 1, 2, or 3. The
value 1 specifies trailing blank compression: 2 specifies compression of leading, embedded, and trailing
blanks, and 3 specifies compression of all duplicate
character strings.
Default:
&CMPTYPE=2
Notes:
1.
See also &CCT.
BSC-20 RMTGEN Parameters - Page 7.3.3
429
HAS P
&CORESIZ
&CORESIZ
Explanation:
size of Model
1024 bytes).
between 8 and
Default:
Variable symbol &CORESIZ specifies the
20 main storage ,in Kbytes (1 Kbyte =
The specification must be an integer
32 inclusive.
&CORESIZ=8
BSC-20 RMTGEN Parameters - Page 7.3.4
430
HAS P
&ERRMSGN
&ERRMSGN
Explanation: Variable symbol &ERRMSGN specifies the
number of four-byte entrie,s to be assembled in the
Model 20 ~emote Terminal program as an error message
log table. The specification must be an integer not
less than 8.
Default:
&ERRMSGN=10
BSC-20 RMTGEN Parameters - Page 7.3.5
431
HAS P
&LINESPD
&LINESPD
Explanation: Variable symbol &LINESPD specifies the
speed, in baud, of the communication line to be used
between the Model 20 and the central computer. The
specification must be a positive integer.
Default:
&LINESPD=2000
BSC-20 RMTGEN Parameters - Page 7.3.6
432
&NUMBUFS
HAS P
&NUMBUFS
Explanation: Variable symbol &NUMBUFS specifies number
of teleprocessing buffers to be constructed by the
Model 20 Remote Terminal program. The specification
must be an integer no less than given by the formula
2*X+l
where
X=l if either a 2520 or a 2560 is to be used as
both a reader and a punch, or
o otherwise.
Default:
&NUMBUFS=8
Notes:
1.
The length of each buffer is &MLBFSIZ+5 bytes
(rounded up to the next full word); the value
of HASPGEN parameter &MLBFSIZ is automatically
propagated to RMTGEN.
2.
If &NUMBUFS specifies more buffers than can be
built in available storage, the Remote Terminal
program will build as many buffers as it can.
3.
It is recommended that at least two buffers be
furnished for each output device and for the
communication adapter.
BSC-20 RMTGEN Parameters - Page 7.3.7
433
&NUMTANK
HAS P
&NUMTANK
Explanation: Variable symbol &NUMTANK specifies the
number of decompression buffers ("decompression tanks")
to be assembled in the Model 20 Remote Terminal program.
The specification should be an integer not less than 2.
Default:
&NUMTANK=8
Notes:
1.
The length of each decompression tank is &PRTSIZE+6.
2.
It is recommended that at least two tanks each be
provided for the printer and the punch.
3.
For an 8K Model 20, specification of &NUMTANK
greater than 8 may cause the Remote Terminal
program to assemble larger than X'lFOO' bytes
(8K-256); the resultant program will fail to
load.
BSC-20 RMTGEN Parameters - Page 7.3.8
434
HAS P
&PDEV(l)
&PDEV (1)
Explanation: Subscripted variable symbol &PDEV(l)
specifies device type for the Model 20 printer. The
specification must be either 1403 or 2203.
Default:
&PDEV(1)=2203
BSC-20 RMTGEN Parameters - Page 7.3 .,g
435
HAS P
&PRTCONS
&PRTCONS
Explanation: Variable symbol &PRTCONS specifies the
degree of use of the printer as an output console
and is dependent upon the specifications used in the
generation of the HASP System pertaining to the handling of messages for the remote as follows:
1.
If HASP is told that the remote has a console
via the RMTnn HASPGEN parameter, &PRTCONS has
the following meanings:
&PRTCONS=O - Error logging and display will be
suppressed and operator messages
created while the remote is online to HASP will be discarded.
&PRTCONS=l - The printer will be used as an
output console when sufficient
operator messages from HASP have
been queued for output at the
remote. If the printer is busy
with job stream output, that output will be interrupted for the
printing of operator messages
from HASP and error messages from
the remote error log. When the
console queue is empty, job stream
output will continue.
&PRTCONS=2 - The printer will be used as an
output console but will not interrupt the printing of jobs. Operator messages received from HASP
while jobs are being printed will
be discarded.
2.
If HASP is told that the remote does not have
a console via the RMTnn HASPGEN parameter and
HASP does not have message SPOOLing capability
as determined by the &SPOLMSG HASPGEN parameter
&PRTCONS has the following meanings:
&PRTCONS=O - Error logging and display will be
suppressed and no operator messages
will be displayed.
&PRTCONS=l - Error log messages will be displayed
when the printer is free to print
them (no job interruptions).
&PRTCONS=2 - Same as &PRTCONS=l
BSC-20 RMTGEN Parameter - Page 7.3.10
436
HAS P
3.
If HASP is ·told· that the remote does not have
a console via the RMTnn HASPGEN parameter and
HASP does have message SPOOLing capability as
determined by &SPOLMSG HASPGEN parameter
&PRTCONS takes on the same meanings as 2 above
with the additional capability of printing operator messages queued for the remote by HASP
and transmitted to the remote when the printer
is free and is set to receive messages by the
$TRMr.PRl command.
Settings for &PRTCONS must be 0, 1, or 2.
Default:
&PRTCONS=O
Notes:
1.
If &WDEV(l) is not zero &PRTCONS should be set
to zero.
2.
See HASPGEN parameters RMTnn and &SPOLMSG.
3.
Regardless of the settings of the &WDEV(l) and
&PRTCONS parameters error messages resulting
from loggab1e errors detected by the remote
will be discarded when the errors occur at a
rate faster than the output device can display
them.
BSC-20 RMTGEN Parameter - Page 7.3.10-1
436.1
'H ASP
(The remainder of this page intentionally left blank.)
436.2
a
&PRTSIZE
ASP
&PRTSIZE
Exp.lanation: Variable symbol &PRTSIZE,specifies the
length in bytes of' the' text portion of each decompression tank. Each'tank must be long enough to hold a
maximum-length output record to either the printer,
the punch, or the operator console. The specification
must be an integer that is the largest of 80 (if &UDEV(l)
is not zero), 120 (if &WDEV(l) is not zero), and the
line width of the printer.
Default:
&PRTSIZE=120
BSC-20 RMTGEN Parameters - Page 7.3.11
437
&RADR(1)
HAS P
&RADR(l)
Explanation: Subscripted variable symbol &RADR(l)
specifies, the unit address of the Model 20 card
reader. The specification, must correspond to the
specification for &RDEV (1) as follows,:
&RDEV (1)
2501
2520
2560
Default:
&RADR(l)
1
2
2
&RADR(l)~l
BSC-20 RMTGEN Parameters - Page 7.3.12
438
&RDEV(1)
HAS P
&RDEV (1)
Explanation: Subscrip"ted variabl~ symbol &RDEV (1)
specifies device type for the Model 20 card reader.
The specification must be either 2501, 2520, or 2560.
Default:
&RDEV(1)=2501
Notes:
1.
See also &RADR(l)
BSC-20 RMTGEN Parameters - Page 7.3.13
439
&SUBMOD
HAS P
&SUBMOD
Explanation: Variable symbol &SUBMOD specifies the
Submodel number of the System/360 Model 20 for the
specified Remote Terminal. The specification must
be a valid System/360 Model 20 Submodel number.
Default:
&SUBMOD=2
BSC-20 RMTGEN Parameters - Page 7.3.14
440
HAS P
&UADR(1 )
&UADR (1)
Explanation: Subscripted variable symbol &UADR(l)
specifies· the unit address of the t-1odel 20 card punch.
The specification must correspond to the specification
for &UDEV(l) as follows:
&UDEV (1)
1442
2520
2560
o
Default:
&UADR(l)
3
2
2
not used
&UADR(1)=3
BSC-20 RMTGEN Parameters - Page 7.3.15
441
&UDEV(l)
HAS P
&UDEV(l)
Explanation: Subscripted variable symbol &UDEV(l)
specifies device type for the Model 20 card punch.
The specification must be either 1442, 2520, 2560,
or O. Specification 0 is used when the Model 20
does not include a card punch.
Default:
&UDEV(1)=1442
Notes:
1.
See also &UADR(l), unless &UDEV(l)=O.
BSC-20 RMTGEN Parameters - Page 7.3.16
442
HAS P
&WDEV(l)
&WDEV (1)
Explanation: Subscripted variable symbol &WDEV(l)
specifies device type for the Model 20 console.
The specification must be either 2152 (if a console
is present) or 0 (if no console is present).
Default:
&WDEV(l)=0
Notes:
1.
If &WDEV(1)=1, console support must be indicated
for this Remote Terminal at HASPGEN time. See
HASPGEN parameter RMTnn.
BSC-20 RMTGEN Parameters - Page 7.3.17
443
&WTOSIZE
HAS P
&WTOSIZE'
I
Explanation: Variable symbol &WTOSIZE specifies the
maximum length in bytes ofa HASP operator command
to be transmitted from the Model 20 to the central
computer. The specification must be a positive integer not greater than 120.
Default:
&WTOSIZE=120
Notes:
1.
If &WDEV (1) =0, this parameter ,is not used.
BSC-20 RMTGEN Parameters - Page 7.3.18
444
HAS P
&XPARENT
&XPARENT
Explanation: Variable symbol &XPARENT specifies presence
or absence of the text transparency feature.
If the
Binary Synchronous Communication Adapters at both the
Model 20 and the central computer have the text transparency feature, YES should be specified; otherwise NO
should be specified.
Default:
&XPARENT=YES
BSC-20 RMTGEN Parameters - Page 7.3.19
445
HAS P
7.4
RMTGEN PARAMETERS FOR SYSTEM/360 (EXCEPT MODEL 20) BSC
This section describes the parameters used in assembly
of the System/360 BSC Remote Terminal Program for HASP
MULTI-LEAVING Remote Job Entry. The parameters are
used during RMTGEN to specify hardware configuration
and software options.
For each parameter there is an explanation, the default
-va-l-ue-,-a-n-6.~r-re-(:rt1-e-nt-l-y--no-t-e-s-Vlhi-c-h---expana- upon the
explanation.
The parameters are listed in alphabetical order.
BSC-360 RMTGEN Parameters - Page 7.4.1
446
HAS P
&ADAPT
&ADAPT
Ex~lanation:
Variable symbol &ADAPT specifies the
unl.t address of the Binary Synchronous Communication
Adapter to be used by the System/360 Remote Terminal
to communicate with HASP at the central computer.
The specification must be a valid unit address.
Default:
&ADAPT=020
BSC-360 RMTGEN Parameters - Page 7.4.2
447
HAS P
&CCT
&CCT
Explanation: Variable symbol &CCT specifies for all
text compression but trailing blank compression the
minimum number of characters to be compressed. A
duplicate character string of fewer than &CCT characters will be treated as a string of non-duplicate
characters for compression purposes. The specification
must be an integer between 3 and 31, inclusive.
Default:
&CCT=4
Notes:
1.
See also &CMPTYPE. The value of &CCT is not
used if &CMPTYPE=l.
2.
A smaller value of &CCT increases efficiency
of communication line usage at the expense of
compute time required for compression.
BSC-360 RMTGEN Parameters - Page 7.4.3
448
HAS P
&CMPTYPE
&CMPTYPE
Explanation: Variable symbol &CMPTYPE specifies type
of compression to be applied to all text transmitted
from the System/360 Remote Terminal to the central
computer. The specification must be either 1, 2, or
3. The value 1 specifies trailing blank compression;
2 specifies compression of leading, embedded, and
trailing blanks, and 3 specifies compression of all
duplicate character strings.
Default:
&CMPTYPE=2
Notes:
1.
See also &CCT.
BSC-360 RMTGEN Parameters - Page 7.4.4
449
&CORESIZ
HAS P
&CORESIZ
Explanation: Variable symbol &CORESIZ specifies the
size of main storage for the System/360 Remote Terminal in K bytes (lK byte = 1024 bytes). The specification must be an integer between 8 and 32 inclusive.
Ifthe~SystemI36-0~is largerthan-32K bytes, &CORESIZ
must be specified as 32.
Default:
&CORESIZ=8
BSC-360 RMTGEN Parameters - Page 7.4.5
450
HAS P
&ERRMSGN
&ERRMSGN .
E~anation:
Variable symbol &ERRMSGN specifies the
n
er of four-byte entries to be assembled in the
System/360 Remote Terminal as an error message log
table. The specification must be an integer not less
than 8.
I
Default:
&ERRMSGN=lO
BSC-360 RMTGEN Parameters - Page 7.4.6
451
&LINESPD
HAS P
&LINESPD
Explanation: Variable symbol &LINESPD specifies the
speed, in baud, of the communication line to be used
between the System/360 Remote Terminal and the central
computer •. The specification must be a positive integer.
De£-ault:
&LINESP D= 2 0 00
BSC-360 RMTGEN Parameters - Page 7.4.7
452
HAS P
&MACHINE
&MACHINE
Explanation: Variable symbol &MACHINE specifies the
model number of the System/360to be used as a HASP
Remote Terminal. The specification must be a valid
System/360 model number for a System/360 which includes
the standard instruction set and the decimal instruction
set.
Default:
&MACHINE=30
BSC-360 RMTGEN Parameters - Page 7.4.a
453
11
l~
f:, P
&NUMBUFS
SiNUMI3UFS
Explanation: Variable symbol &NUMBUFS specifies number
of teleprocessing buffers to be constructed by the
System/360 Remote Terminal program. The specification
must be an integer no less than given by the formula
2*X+l
where
X=l if either a 2520 or a 1442 is to be used as
both a reader and a punch, or
o otherwise.
Default:
&NUMBUFS=8
Notes:
1.
The length of each buffer is &MLBFSIZ+5 bytes
(rounded up to a multiple of 4); the value of
HASPGEN parameter &MLBFSIZ is automatically
propagated to RMTGEN.
2.
If &NUMBUFS specifies more buffers than can be
built in available storage, the Remote Terminal
program will build as many buffers as it can.
3.
It is recommended that at least two buffers be
furnished for each output device and for the
communication adapter.
,)3SC-360 RMTGEN Parameters - Page 7.4.9
454
HAS P
&NUMTANK
&NUMTANK
Explanation: Variable symbol &NUMTANK specifies the
number of decompression buffers ("decompression
tanks") program. The specification· should be an integer not less than 2.
I
Default:
&NUMTANK=5
Notes:
1.
The length of each decompression tank is
&PRTSIZE+6.
2.
It is recommended that at least two tanks be
provided for each printer and each punch (3 for
a 2540 punch).
BSC-360 RMTGEN Parameters - Page 7.4;10
455
HAS P
&PADR(n)
. &PADR (n)
Explanation: Subscripted variable symbols &PADR(n)
specify unit addresses for the printe'rs defined by
&PDEV(~).
For each &PDEV(n) not specified as zero,
the corresponding symbol &PADR(n) must specify the
device's 3-character hexadecimal unit address.
Default:
&PADR(l)=OOE
&PADR(2)=OOF
&PADR(3)=FFF
&PADR(4)=FFF
&PADR(5)=FFF
&PADR(6)=FFF
&PADR(7)=FFF
-BSC-;;.-)-o-O---RMTGEN . -Parame-ters-------Page---7--.-4-.-i-l
456
HAS P
&PDEV(n)
&PDEV(n)
Explanation: Subscripted variable symbols &PDEV(n)
specify the existence and device types of the Remote
Terminal printers. Each specification must be either
1403, 1443, or O. A specification of 0 indicates that
the associated printer does not exist.
Default:
&PDEV(1)=1403
&PDEV(2)=0
&PDEV(3)=0
&PDEV(4)=0
&PDEV(5)=0
&PDEV(6)=O
&PDEV(7)=0
Notes:
1.
If &PDEV(n) is specified as a device type, then
&UDEV(8-n) must be specified as zero.
2.
If &PDEV(n+l) is specified as a device type, then
&PDEV(n) must be specified as a device type.
3.
If more than one printer is specified, a Device
Control Table (DCT) for each additional printer
must be added to the HASP System.
BSC-360 RMTGEN Parameters - Page 7.4.12
457
&PRTSIZE
HAS P
&PRTSIZE
Explanation: Variable symbol &PRTSIZE specifies the
length in bytes of the text portion of each decompression tank. Each tank must be long enough to hold a
maximum-length output record to either a printer, a
punch, or the operator console. The specification
must be an integer that is the larger of 120 and the
line width of the widest printer.
Default:
&PRTSIZE=132
BSC-360 RMTGEN Parameters - Page 7.4.13
458
HAS P
&RADR(n)
&RADR(n)
Explanation: Subscripted variable symbols &RADR(n)
specify unit addresses for the readers defined by
&RDEV(n). For each &RDEV(n) not specified as zero,
the corresponding symbol &RADR(n) must specify the
device's 3-character hexadecimal unit address.
Default:
&RADR(l)=OOC
&RADR(2)=FFF
&RADR(3)=FFF
&RADR(4)=FFF
&RADR(5)=FFF
&RADR(6)=FFF
&RADR(7)=FFF
BSC-360 RMTGEN Parameters - Page 7.4.14
459
&RDEV(n)
HAS P
&RDEV(n)
Explanation: Subscripted variable symbols &RDE"V (n)
specify the existence and device types of the Remote
Terminal readers. Each specification must be either
2540, 2501, 2520, 1442, or O. A specification of 0
indicates that the associated reader does not exist.
Default:
&RDEV(1)=2540
&RDEV(2)=0
&RDEV (3) =0
&RDEV(4) =0
&RDEV(5) =0
&RDEV(6)=0
&RDEV(7) =0
Notes:
1.
If &RDEV(n+l) is specified as a device type, then
&RDEV(n) must be specified as a device type.
2.
If more than one reader is specified, a Device
Control Table (DCT) for each additional reader
must be added to the HASP System.
BSC-360 RMTGEN Parameters - Page 7.4.15
460
&UADR(n)
HAS P
&UADR(n)
Explanation: Subscripted varlable symbols &UADR(n)
specify unit addresses for the punches defined by
&UDEV(n).
For each &UDEV(n) not specified as zero,
the corresponding symbol &UADR(n) must specify the
device's 3-character hexadecimal unit address.
Default:
&UADR(l)=OOD
&UADR(2)=FFF
&UADR(3)=FFF
&UARD(4)=FFF
&UARD(5)=FFF
&UARD(6)=FFF
&UARD(7)=FFF
BSC-360 RMTGEN Parameters - Page 7.4.16
461
&UDEV(n)
HAS P
&UDEV(n)
Explanation: Subscripted variable symbols &UDEV(n)
specify the existence and device types of the Remote
Terminal punches. Each specification must be either
2540, 2520, 1442, or O. A specification of 0 indicates
that the associated punch does not exist.
Default:
&UDEV(I)=2540
&UDEV(2)=0
&UDEV(3)=0
&UDEV(4) =0
&UDEV(5) =0
&UDEV(6)=0
&UDEV(7)=0
Notes:
1.
If &UDEV(n) is specified as a device type, then
&PDEV(8-n) must be specified as zero.
2.
If &UDEV(n+l) is specified as a device type, then
&UDEV(n) must be specified as a device type.
3.
If more than one punch is specified, a Device
Control Table (OCT) for each additional punch must
be added to the HASP System.
BSC-360 RMTGEN Parameters - Page 7.4.17
462
HAS P
&WADR(l)
&WADR (1)
Explanation: Subscripted variable symbol &WADR(l) specifies
the unit address of the 1052 operator console on the
System/360 Remote Terminal. The specification must
be a 3-character hexadecimal unit address.
Default:
&WADR(l)=OlF
BSC-360 RMTGEN Parameters - Page 7.4.18
463
&WTOSIZE
HAS P
&WTOSIZE
I
Explanation: Variable symbol &WTOSIZE specifies the
maximum length in bytes of a HASP operator command
to be transmitted from the System/360 Remote Terminal
to the central computer. The specification must be
a positive integer not greater than 120.
Default:
&WTOSIZE=120
BSC-360 RMTGEN Parameters - Page 7.4.19
464
&XPARENT
HAS P
&{(PARENT
Explanation: Variable symbol &XPARENT specifies
presence or absence of the text transparency feature.
If the Binary Synchronous Conununication Adapters at
both the System/360 Remote Terminal and the central
computer have the text trqnsparency feature, YES
.
should be specified: otherwise NO should be specified.
Default:
&XPARENT=YES
BSC-360 RMTGEN Parameters - Page 7.4.20
465
HAS P
7.5
RMTGEN PARAMETERS FOR 1130
This section describes the parameters used in assembly
of the ll30Remote Terminal Program for HASP MULTILEAVING Remote Job Entry. The parameters are used
during RMTGEN to specify hardware configuration and
software options.
For each parameter there is an explanation, the default
value, and frequently notes which expand upon the
explanation.
The parameters are listed in alphabetical order.
RTPll30 RMTGEN Parameters - Page 7.5.1
&CLOCK
II ASP
&CLOCK
Explanation: The varidLlc~IYIL ,. i &CLOCK is used to
specify the type of communication adapter clocking
qvailable on the 1130 to be used by the workstation
program. The specification of &CLOCK~O is interpreted
to mean that data set clocking is being used. The
value &CLOCK=l specifies internal (1130) clocking.
Default:
&CLOCK=O
Notes:
1.
The rate of insertion of the synchronous idle
sequence in the transmitted data is determined
by the variables &CLOCK, &LINESPD and &TRANPRN.
The relationship of these variables to the insertion rate is:
&CLOCK
o
o
1
1
2.
&TRANPRN
o
1
o
1
INSERTION EVERY:
&LINESPD/8
&LINESPD/8
70
&LINESPD/8
characters
characters
characters
characters
The equation used for the insertion rate is:
(&LINESPD/8)*T
where T is 1.00 second which is the nominal 2701
timer value.
RTPl130 RMTGEN Parameters - Page 7.5.2
At:"7
&CMPTYPE
HAS P
&CMPTYPE
Explanation: The variable symbol &CMPTYPE is used to
'specify the compression technique that is to be applied
to the data transmitted to the central HASP system.
The choices for &CMPTYPE are:
&CMPTYPE=Q
for no compression of duplicate characters or truncation of trailing blanks,
&CMPTYPE=l
for trailing blank truncation only.
&CMPTYPE=2
for full compression: trailing blank
truncation and encoding of duplicate
characters.
Default:
&CMPTYPE=2
Notes:
1.
The process of compressing input data offers optimum
performance with respect to efficient line utilization. However, the factors of line speed, CPU
availability, buffer size, line turn-around time,
nature of the data to be compressed, etc., are
variables which contribute to the overall operation
of the workstation program. Since compression and
truncation require considerable CPU time, the user
may decide, on the basis of the other variables,
to respecify the compression technique.
RTPl130 RMTGEN Parameters - Page 7.5.3
468
&DELAY
HAS P
&DELAY
Explanation: The variable symbol &DELJ\Y is used to
define the number of intervals of time that RTPl130
will delay, in transmitting a "handshaking" sequence
(DLE-ACKO) to the central HASP site.
The hardware
program timer ,clock is used to measure the delay and
'is assumed to be set to a nominal value of .35 seconds.
Default:
&DELAY=3
Notes:
1.
&DELAY=3 results in a delay of 1.05 seconds,
assuming a timer interval of .35 seconds.
2.
The purpose of the delay when "handshaking" is
to minimize CPU processing at the central HASP
computer when no dat~ is being transmitted.
3.
The value of &DELAY must not be set to such a
large increment that the delay will be greater
than the timeout period of the central sit~
2701/2703.
RTPl130 RMTGEN Parameters - Page 7.5.4
469
&FULLIST
H A 8 P
&FULLI8T
Explanation: The variable symbol &FULLIST is used
to specify the type of assembly listing which is produced by the 08/360 assembler during the RMTGEN process.
If the value of &FULLI8T is set to 0, then the assembly
listing produced will be according to the PRINT NOGEN
stipulation of the assembler.
If the value of &FULLI8T
is set to 1, the .listing will be produced according to
the PRINT GEN stipulation.
Default:
&FULLIST=l
Notes:
1.
since most of the code in RTPl130 and RTPLOAD
is created by Macro instructions, the specification of &FULLIST=O will essentially produce a
source listing (cross referenced) without the
1130 assembled instructions. Error messages
will not appear on the listing.
RTPl130 RMTGEN Parameters - Page 7.5.5
470
&LINESPD
HAS P
&LINESPD
Explariation: Th~.vari~ble symbol &LINESPD is used
to specify the baud rate for the communication line
interface to the workstation program. The value should
correspond to the selected setting of the baud rate
switch on the 1130 SCA control panel: 1200,2000, ... ,etc.
Default:
&LINESPD=2000
Notes:
~.
The rate"of insertion of the synchronous idle
sequertce (DLE~SYN or SYN-SYN) in the transmitted
data is determined by the variables &CLOCK,
&LINESPD and&TRANPRN. See note 1 of &CLOCK
description.
RTPl130 RMTGEN Parameters - Page 7.5.6
471
&MACHSIZ
HAS P
&MACHSIZ
Explanation: Variable symbol &MACHSIZ specifies the
amount of 1130 core to be ~sed by RTPl130. The value·
of &MACHSIZ is in ~nits of 1130 words.
Default:
&MACHSIZ=8192
Notes:
1.
The value of &MACHSIZ is interpreted to mean that
"&MACHSIZ" number of words, starting at locqtion
0, are available for the workstation program con~
sisting of RTPBOOT, RTPLOAD and RTPll30.
2.
The same variable symbOl must be defined for
RTPLOAD and should have the same value.
3.
The value of &MACH$IZ may be less than the actual
available storage but must not be greater.
RTPl130 RMTGEN Parameters - Page 7.5.7
472
HAS P
&PN1442
&PN1442
Explanation: The variable symbol &PN1442 is used to
define a 1442 pu'nch.
If the variable is set to 1,
thenRTPl130 will include support for punched card
output produced by jobs at the Central HASP site.
If the variable is set to 0, no support for the 1442
punch will be provided.
See &RD1442 for the definition of a reader function on the 1442.
Default:
&PN1442=1
RTPl130 RMTGEN Parameters - Page 7.5.8
473
&PRFOTLW
HAS P
&PRFOTLW
Explanation: The value of the variable symbo1&PRFO'I'LW
is used to define the line width of the 1403 printer
specified by &PR1403. The choices are 120 or 132
character lines.
Default:
&PRFOTLW=120
Notes:
1.
The definition of the line width for all printers
on a particular remote is a HASPGEN requirement.
See HASPGEN parameter RMTnn.
RTPl130 RMTGEN Parameters - Page 7.5.9
474
HAS P
&PRl132
&PRl132
Explanation: The variable symbol &PRl132 is used to
'define an 1132 printer.
If the variable is set to
1, then RTP1l30 will include support for the 1132 to
print job output.
If the variable is set to 0, no
support will be included in RTPl130 for the 1132.
Default:
&PRl132=0
RTPl130 RMTGEN Parameters - Page 7.5.10
475
&PR1403
HAS P
&PR1403
Explanation: The variable symbol &PR1403 is used to
define a 1403 printer for use as an output device.
If the value of &PR1403 is 1, then the 1403 function
will be included in RTPl130.
If the value is 0, the
function is deleted from RTPl130.
Default:
&PR1403=1
Notes:
1.
See &PRFOTLW for specifying the line width of
the 1403.
RTPl130 RMTGEN Parameters - Page 7.5.11
476
1I ASP
&RD1442
&RD1442
Explanation: The variable symbol &RD1442 is used to
define a 1442 as a card reader.
If the variable is
set to 1, then RTPl130 will be assembled with all
necessary control blocks and support routines to provide job input from the 1442.
If the variable is set
to 0, no support for the 1442 reader will be provided
in RTPl130.
See &PN1442 for a definition of the
punch function on the 1442.
Default:
&RD1442=1
Notes:
1.
If the variable &RD1442 is set to 1 and a 1442
reader does not exist then the operation of the
workstation program may be unpredictable.
RTPl130 RMTGEN Parameters - Page 7.5.12
477
&RD2501
HAS P
&RD2501
Explanation: The variable symbol &RD2501 is used to
define a 2501 card reader. If the variable is set
to 1, then RTPl130 will be assembled with all necessary
control block and subroutines to support the 2501 as
a job input device. If the variable is set to 0,
no support for the 2501 will be included in RTPl130.
Default:
&RD2501=0
Notes:
1.
If the variable &RD2501 is set to 1 and a 2501
does not exist then the operation of the workstation program will be unpredictable and usually
unproductive.
RTPll30 RMTGEN Parameters - Page 7.5.13
478
&RTPLORG
HAS P
&RTPLORG
Explanation: The variable symbol &RTPLORGdefines
the origin in 1130 storage of the program loader
RTPLOAD which is used to load RTPl130.
Default:
&RTPLORG=2*(&MACHSIZ-I024)
Notes:
1.
The value of the above expression, assuming
&MACHSIZ=8192, is 14336 (which is twice the
actual 1130 storage address because the value
is used in an ORG operation and must be in terms
of bytes not 1130 words.
2.
The RTPLOAD program must origin ih the storage
available between the end of RTPl130 (beginning
of buffer pool) and the end of defined (&MACHSIZ)
storage MINUS the length of RTPLOADs The default
value of &RTPLORG allows for an RTPLOAD of 1024
words in size.
RTPl130 RMTGEN Parameters - Page 7.5.14
&TRANPRN
HAS P
&TRANPRN
Explanation: The variable symbol &TRANPRN is used to
define the simulation of the Binary Synchronous
Transparency feature.
If the value of &TRANPRN is set
to 1, then RTPl130 will simulate the transparency
feature in the same manner as the 2701 SDA-II adapter
equipped with the transparency feature.
If the
variable is set to 0, no simulation will occur and
therefore data which contains transparent characters
cannot be properly processed by RTPl130.
Default:
&TRANPRN=1
Notes:
1.
If &TRANPRN=O is specified, the conversion of
card code data is monitored and all BSC control
characters are converted to hexadecimal O. This
prevents mispunched data from causing an infinite
error retrytt the central site does not have
transparency.
2.
See &LINESPD and &CLOCK for additional influence
of &TRANPRN.
3.
If &TRANPRN=l, the generated Remote Terminal
program will communicate only with a 2701 or 2703
adapter which has the text transparency feature.
RTPl130 RMTGEN Parameters - Page 7.5.15
·480
HAS P
7.6
RMTGEN PARAMETERS FOR 1130 LOADER
This section describes the parameters used in assembly of
RTPLOAD, the 1130 Loader Program.
RTPLOAD is used to load
the 1130 Remote Terminal Program.
RTPLOAD's three parameters
specify machine size, loader origin, and an assembler list
option.
For each parameter there is an explanation, the default value,
and frequently notes which expand upon the explanation.
The RMTGEN processes produce the object decks for RTPLOAD
and RTPl130. The bootstrap loader (RTPBOOT) cannot be produced on a System 360 and must be punched by keypunch as
indicated in Section 4.14.3.
The parameters are listed in alphabetical order ..
RTPLOAD RMTGEN Parameters - Page 7. 6 ..1
481
&FULLIST
HAS P
&FULLIST
Explanation: The variable symbol &FULLIST is used
to specify the type of assembly listing which is produced by the OS/360 assembler during theRMTGEN process.
If the value of"&FULLIST is set to 0, then the assembly
listing produced will be according to the PRINT NOGEN
stipulation of the assembler.
If the value of &FULLIST
is set to 1, the listing will be produced according to
the PRINT GEN stipulation.
Default:
&FULLIST=l
Notes:
1.
Since most of the code in RTPll30 and RTPLOAD
is created by Macro instructions, the specification of &FULLIST=O will essentially produce a
source listing (cross referenced) without the
1130 assembled instructions. Error messages
will not appear on the listing.
RTPLOAD RMTGEN Parameters - Page 7.6.2
482
&MACHSIZ
HAS P
&MACHSIZ
Explanation: Variable symbol &MACHSIZ specifies the
amount of 1130 core to be used by RTPLOAD. The value
of &MACHSIZ is in units of 1130 words.
Default:
&MACHSIZ=8192
Notes:
1.
The value of &MACHSIZ is interpreted to mean that
"&MACHSIZ" number of words, starting at location
0, are available for the workstation program consisting of RTPBOOT, RTPLOAD and RTP1130.
2.
The same ~ariable symbol must be defined for
RTPll30 and should have the same value.
3.
The value of &MACHSIZ may be less than the actual
available sto~age but must not be greater.
RTPLOAD RMTGEN Parameters - Page 7.6.3
483
HAS P
&RTPLORG
&RTPLORG
Explanation: The variable symbol &RTPLORG defines
the origin in 1130 storage of the program loader
RTPLOAD which is used to load RTPl130.
Default:
&RTPLORG=2*(&MACHSIZ-I024)
Notes:
1.
The value of the above expression, assuming
&MACHSIZ=8192, is 14336 (which is twice the
actual 1130 storage address because the value
is used in an ORG operation and'must be in terms
of bytes not 1130 words.
2.
The RTPLOAD program must origin in the storage
available between the end of RTPl130 (beginning
of buffer pool) and the end of defined (&MACHSIZ)
storage MINUS the length of RTPLOAD. The default
value of &RTPLORG allows for an RTPLOAD of 1024
words in size.
RTPLOAD RMTGEN Parameters - Page 7.6.4
484
HAS P
7.7
RMTGEN PARAMETERS FOR SYSTEM/3
This section describes the parameters used in assembly
of the System/3 Remote Terminal Program for HASP MULTILEAVING Remote Job Entry. The parameters are used
during RMTGEN to specify-hardware configuration and
software options.
For each parameter there is an explanation, the default
value, and frequently notes which expand upon the
explanation.
The parameters are listed in alphabetical order.
System/3 RMTGEN Parameters - Page 7.7.1
485
&COMP
HAS P
&COMP
Explanation: Variable symbol &CO~1P specifies degree
of text compression to be provided for all text transmitted from the System/3 to HASP. The specification
must be either 0, 1, or 2.
For &COMP=O, neither compression nor truncation is
performed.
For &COMP=l, trailing blanks are truncated from each
logical record before it is transmitted.
For &COMP=2, compression takes place after truncation.
Strings of from two to 31 blanks are compressed to a
single byte; strings of from three to 31 duplicate
characters are compressed to two bytes.
Default:
&COMP=2
System/3 RMTGEN Parameters - Page 7.7.2
486
&DEBUG
HAS P
&DEBUG
Explanation: Variable symbol &DEBUG specifies inclusion
or exclusion of certain validity tests and a core dump
program in the System/3 Remote Terminal Program. The
specification must be either 0 or 1.
Default:
&DEBUG=O
System/3 RMTGEN Parameters - Page 7.7.3
487
&DIAL
HAS P
&DIAL, &DIALI
Explanation: Variable symbols &DIAL and &DIALI specify
the telephone number to be used during the initialization process. The values will be included on the
default /*SIGNON card assembled into the System/3
Remote Terminal Program and preceded by the keyword
DIAL (unless the parameters are left at their defaults) .
Each specification is a string of from one to eight
decimal digits. If the telephone number is eight or
fewer digits long, it should be specified by &DIAL.
If the telephone number is longer than eight digits,
its leftmost eight digits should be specified by &DIAL
and the remaining digits by &DIALI.
Default:
&DIAL=[null string]
&DIALl=[null string]
System/3 RMTGEN Parameters - Page 7.7.4
488
HAS P
&MACHSIZ
&MACHSIZ
Explanation: Variable symbol &MACHSIZ specifies the
size of System/3 Core storage. The specification
should be either 8192, 12288, 16384, 24576, or 32768
for core storage sizes of 8K, 12K, 16K, 24K or 32K
respectively.
Default:
&MACHSIZ=8192
System/3 RMTGEN Parameters - Page 7.7.5
489
&PASSWD
HAS P
&PASSWD
Explanation: Variable symbol &PASSWD specifies a
password to be used during the SIGNON process. The
value will be included on the default /*SIGNON card
assembled into the System/3 Remote Terminal Program.
The specification must be a character string of from
one to eight characters.
If blanks are desired, no
specification may be made.
Default:
&PASSWD=[null string]
System/3 RMTGEN Parameters - Page 7.7.6.
490
"r
&PC(n)
HAS P
&PC(n)
Explanation: Subscripted variable symbols -&PC(n)
specify skip information for the 5203 printer. The
value to which &PC(n) is set will be the print line
number to which paper will be skipped when the System/3
Remote Terminal Program simulates the 1403" command
"Skip to Channel n". Each specification must be an
integer between 0 and &S3FORML, inclusive. A specification of 0 causes no forms movement.
Default:
&PC(l)=l
&PC(2)=0
&PC(3)=0
&PC(4)=0
&PC(5)=0
&PC(6)=0
&PC(7)=0
&PC(8)=0
&PC(9)=0
&PC(lO)=O
&PC(ll)=O
&PC(12)=&S3FORML-5
System/3 RMTGEN Parameters - Page 7.7.7
491
HAS P
&PRTCONS
&PRTCONS
Exelanation:
Variable symbol &PRTCONS specifies
ut~lization of the 5203 printer as an operator's
output console.
or 2.
The specification must be 0, 1,
For &PRTCONS=O, the 5203 printer will never be used
as an operator's output console.
For &PRTCONS=l, the System/3 Remote Terminal Program
will attempt to hold operator messages from HASP until a job has completed printing. However, if two
or more MULTI-LEAVING buffers are received containing HASP operator messages, the 5203 will eject a
page (skip to channell), print the HASP operator
messages, eject another page, and resume printing
its job.
For &PRTCONS=2, the System/3 Remote Terminal Program
will throwaway all operator messages while the 5203
is printing a job. While the 5203 is dormant, it
will print any received messages.
Default:
&PRTCONS=2
Notes:
1.
If &S3547l=1, the value of&PRTCONS is ignored
and assumed to be zero.
2.
Regardless of the setting of &PRTCONS, messages
temporarily saved on disk for a remote terminal
will be printed to the terminal as a job. Thus,
they will always appear on the printer, even if
another console exists. See also HASPGEN parameter.&SPOLMSG.
3.
If &PRTCONS is specified greater than zero,
MULTI-LEAVING console support should be specified in HASPGEN parameter RMTnn for this remote.
System/3 RMTGEN Parameters - Page 7.7.8
492
HAS P
&S3CMDS
&S3CMDS
Explanation: Variable symbol &S3CMDS specifies inclusion or exclusion, local to the System/3, of a
command facility and commands to assist the System/3
operator. The specification must be either 0 or 1.
Default:
&S3CMDS=O
Notes:
1.
Commands available with this facility are explained in the System/3 Operator's Guide.
System/3 RMTGEN Parameters - Page 7.7.8.1
492.1
HAS P
(The remainder of this page intentionally left blank.)
492.2
&S3FORML
HAS P
&S3FORML
Explanation: Variable symbol &S3FORML specifies the
number of print lines on a page of the continuous
forms which will be used in the 5203 printer. The
specification must be an integer not less than 6.
Default:
&S3FORML=66
System/3 RMTGEN Parameters - Page 7.7.9
493
HAS P
&S3NPUNS
&S3NPUNS
Explanation: Variable symbol &S3NPUNS specifies the
maximum number of jobs that can be punching simultaneously
at the System/3 Remote Terminal. The. specification must
be 1, 2, or 3.
(A value of 3 allows simultaneous operation of both 5424 hoppers and the 1442 hopper as punches.)
Default:
&S3NPUNS=1
Notes:
1.
If &S3NPUNS is set to 2 or 3, extra device control
tables must be added for the appropriate remote to
the HASP System at HASPGEN time.
System/3 RMTGEN Parameters - Page 7.7.10
494
&S3NRDRS
HAS P
&S3NRDRS
Explanation: Variable symbol &S3NRDRS specifies the
maximum number of job streams that can be reading
simultaneously from the System/3 Remote Terminal.
The specification must be 1, 2, or 3.
(A value of
3 allows simultaneous operation of both 5424 hoppers
and the 1442 hopper as readers.)
Default:
&S3NRDRS=l
Notes:
I.
If &S3NRDRS is set to 2 or 3, extra device control
tables must be added for the appropriate remote to
the HASP System at HASPGEN time.
System/3 RMTGEN Parameters - Page 7.7.11
495
&S30BJDK
HAS P
&S30BJDK
Explanation: Variable symbol &S30BJDK specifies inclusion of a facility to punch Operating System object
decks. Text transparency should be present. The
specification should be 0 or 1.
If &S30BJDK=1, each card of an OS object deck will be
expanded and punched into two 96-column cards. These
cards will be recognized when later read by a System/3
Remote Terminal program for which &S30BJDK=1, and for
each two 96-column cards read an OS object deck card
image will be transmitted.
Default:
&S30BJDK=O
System/3 RMTGEN Parameters - Page 7.7.12
496
&S3SIP
HAS P
&S3SIP
Explanation: Variable symbol &S3SIP specifies usage
of those bytes of System/3 core storage between X'lOO'
and X'IFF', inclusive. The specification must be either
O.or 1. For &S3SIP=l, the System/3 Remote Terminal
Program will not use the bytes; their values will be
preserved for the use of the System/3 Card System
Initialization Program.
Default:
&S3SIP=Q
System/3 RMTGEN Parameters - Page 7.7.13
497
&S3TRACE
HAS P
&S3TRACE
Explanation: Variable symbol &S3TRACE specifies the
number of four-byte entries in the System/3 Remote
Terminal Program's internal error message table. The
specification must be an integer greater than 1.
Default:
&S3TRACE=lO
System/3 RMTGEN Parameters - Page 7.7.14
498
&S3XPAR
HAS P
&S3XPAR
Explanation: Variable symbol &S3XPAR specifies presence
or absence of the EBCDIC text transparency feature.
The
specification should be 1 if both the central computer's
communications adapter and the System/3 BSCA have the
EBCDIC text transparency feature; otherwise the specification should be O.
Default:
&S3XPAR=O
System/3 RMTGEN Parameters - Page 7.7.15
AOO
&S31442
H A 8 P
&831442
Explanation: Variable symbol &831442 specifies inclusion or exclusion of support for the 1442 Card ReaderPunch (RPQ). The specification must be 1 for inclusion
and 0 for exclusion of 1442 support.
Default:
&831442=0
Notes:
1.
If &831442=1, the resultant 8ystem/3 Remote Terminal Program requires that a 1442 be present on
the 8ystem/3.
System/3 RMTGEN Parameters - Page 7.7.16
500
HAS P
&S35424
&S35424
Explanation: Variable symbol &S35424 specifies inclusion or exclusion of support for the' 5424 MultiFunction Card Unit. The specification must be 1
for inclusion or 0 for exclusion of 5424 support.
Default:
&835424=1
Notes:
1.
If &S35424 is specified as 0, then &S31442 must
be specified as 1.
2.
See Chapter 10.3 for RMTGEN considerations for
&S35424=0.
3.
See the System/3 Operator's Guide in Chapter
11.9 for program loading considerations for
&S35424=0.
System/3 RMTGEN Parameters - Page 7.7.16.1
.500.1
HAS P
(The remainder of this page intentionally left blank.)
500.2
&535471
H A 8 P
&835471
Explanation: Variable symbol &835471 specifies
presence or absence of a 5471 Printer-Keyboard on
the 8ystem/3. The 5471 will be used as an operator's
input/output console. The specification must be 1
if a 5471 is present; otherwise it must be O.
Default:
&835471=0
Notes:
1.
If console support is desired, HA8PGEN parameter
RMTnn for this remote must specify MULTI-LEAVING
console support.
2.
Regardless of the setting of &835471, messages
from HA8P can print on the printer. See RMTGEN
parameter &PRTCONS, note 2, and HASPGEN parameter &SPOLMSG.
System/3 RMTGEN Parameters - Page 7.7.17
501
HAS P
&535475
&S35475
Explanation: Variable symbol &S35475 specifies
presence or absence of a 5475 Data Entry Keyboard
on the System/3. The 5475 will be used as an operator's input console. The specification must be 1
if a 5475 is present; otherwise it must be O.
Default:
&S35475=0
Notes:
1.
If &S35471=1, this parameter is ignored.
2.
If console support is desired, HASPGEN parameter RMTnn for this remote must specify MULTILEAVING console support.
3.
For output console specification, see RMTGEN
parameter &PRT.CONS.
System/3 RMTGEN Parameters - Page 7.7.18
5.02
HAS P
&S396COL
&S396COL
Explanation: Variable symbol &S396COL·specifies inclusion or exclusion of the System/3 load-mode punch option.
The specification must be either 0 or 1. If &S396COL
is specified, the resultant System/3 Remote Terminal
Program will be capable of receiving correctly the
punched output of a System/3 RMTGEN.
Default:
&S396COL=O
System/3 RMTGEN Parameters - Page 7.7.19
503
HAS P
7.8
RMTGEN PARAMETERS FOR 2922
To generate a 2922 Remote Terminal Program for HASP MULTI-LEAVING
RJE, the parameters and procedures documented in Sections 7.3 and
10.3 for the System/360 Model 20 BSC should be used, subject to
the following discussion.
Some parameters should be specifically set.
They are:
&PDEV(l) =1403
&PRTSIZE=l32
&UDEV(l) =0
&WDEV(l)=2l52, if the optional typewriter console is installed
&XPARENT=NO, if optional transparency is not installed
&LINESPD=xxxx (the actual line speed used)
Some parameters should not be altered from their default values.
They are:
&CORESIZE
&SUBMOD
&RADR(l)
&UADR(l)
&RDEV(l)
All other Model 20 BSC parameter's may be allowed to default or may
be altered as desired, according to the description in Section 7.3.
2922 RMTGEN Parameters - Page 7.8.1
504
Ii ASP
8.0
HASP CONTROL TABLE FORMATS
Tllis sections contains block diagrams which depict the formats
of the HASP Control Tables which are not described in other
sections of this manual.
HASP Control Table Formats -- Page 8.0-1
505
HAS P
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT
Displacement
Hex.
Dec.
o
o
~-----------------------
4 bytes
------------------------~
$VERSION
-
HASP Version
8
8
SWAIT
Entry to HASP Dispatcher
C
12
SGETBUF
Entry to HASP Buffer "GET" Routine
10
16
$GETPBUF
Entry to HASP RJE Buffer "GET" Routine
14
20
$FREEBUF
Entry to HASP Buffer "FREE" Routine
18
24
$GETUNIT
Entry to HASP Unit "GET" Routine
lC
28
$FREUNIT
Entry to HASP Unit "FREE" Routine
20
32
$QADD
Entry to HASP Job Queue Element "ADD" Routine
24
36
$QGET
Entry to HASP Job Queue Element "GET" Routine
28
40
HASP Communication Table Format
506
-.~
Page 8.1-1
1I ASP
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
28
40
~-----------------------
4 bytes
------------------------~I
$QPUT
Entry to HASP Job Queue Element "PUT" Routine
2C
44
$QREM
Entry to HASP Job Queue Element "REMOVE" Routine
30
48
$QSIZ
Entry to HASP Job Queue "SIZE" Routine
34
52
$QLOC
Entry to HASP Job Queue Element "LOCATE" Routine
38
56
$QJITLOC
Entry to HASP JIT Element "LOCATE" Routine
3C
60
$TRACK
Entry to HASP Track Allocation Routine
40
64
$PURGER
Entry to HASP Track Purge Routine
44
68
$EXCP
Entry to HASP Input/Output Supervisor
48
72
SEXTPOPE
Entry to HASP RTAM Open Routine
4C
76
SEXTPGET
Entry to HASP RTAM Get Routine
50
80
HASP Communication Table Format -- Page 8.1-2
507
HAS P
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
50
80
1-----------------------
4
bytes
-----------------~------1
$EXTPPUT
Entry to HASP RTAM Put Routine
54
84
$EXTPCLO
Entry to HASP RTAM Close Routine
58
88
$RESTORE
Entry to HASP RTAM Restore Routine
5C
92
$ODEL
Entry to HASP Overlay $DELETE Routine
60
96
$ORET
Entry to HASP Overlay $RETURN Routine
64
100
$OLINK
Entry to HASP Overlay $LINK Routine
68
104
$OXCTL
Entry to HASP Overlay $XCTL Routine
6C
108
$OLOAD
Entry to HASP Overlay $LOAD Routine
70
112
$WTO
Entry to HASP Write-to-Operator Routine
74
116
$FREEMSG
Entry to HASP Console Message Buffer Free Routine
78
120
HASP Communication Table Format -- Page 8.1-3
J;()Q
II ASP
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
78
120
~-----------------------
4 bytes
------------------------~
$STIMER
Entry to HASP Set Interval Timer Routine
7C
124
$TTIMER
Entry to HASP Test Interval Timer Routine
80
128
$IOERROR
Entry to HASP Input/Output Error Logging Routine
84
132
$ERROR
Entry to HASP Catastrophic Error Routine
88
136
$DISTERR
Entry to HASP Disastrous Error Routine
BC
140
$SYSTYPE
System Type
MFT or MVT
90
94
98
144
148
152
$HASPECF
156
Initialization
Options
MHASPECB
HASP
Status
$XEQACT
RJE Event
Control Field
O/S Execution
Count
$ENBALL
$DISALL
$DISINT
Enable All
Mask
Disable All
Mask
Disable Int
Timer Mask
$PSRDRCT
$PSPRFCT
$PSPUFCT
Pseudo Printer
Count (1443)
Pseudo Punch
Count (1442)
$EXCPCT
RESERVED
$ACTIVE
Active
Count
RESERVED
RESERVED
$COMMCT
Active Command Count
Active I/O Count
AO
$STATUS
Master Event
Control Field
Pseudo Reader
(2540)
Count
9C
$OPTSTAT
160
HASP Cornmunicatiol1(Table Format -- Page 8.1-4
509
II ASP
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
AD
160
~-----------------------
4 bytes
$CKPTRAK
RES E R V E D
Checkpoint Track
A4
164
------------------------~
$HASPTCB
Address of HASP Task Control Block
A8
168
$PCEORG
Address of First HASP Processor Control Element
AC
172
$BUFPOOL
Address of First Available HASP Buffer
BO
176
$TPBPOOL
Address of First Available HASP RJE Buffer
B4
180
$DCTPOOL
Address of First HASP Device Control Table
B8
184
$JITABLE
Address of HASP Job Information Table
BC
188
$CYLMAP
Address of First HASP Cylinder Module Map
CO
192
$TEDADDR
Address of First Track Extent Data Table
C4
196
$DCBLIST
Address of HASP Direct Access DCB
C8
200
HASP Communication Table Format -- Page 8.1-5
510
HAS P
Fiqurc 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
C8
200
~-----------------------
4 bytes
------------------------~
$FREEQUE
Address of First Free HASP Console Message Buffer
CC
204
$BUSYQUE
Console Message Buffers Queued for I/O
DO
208
$LOGQUE
Console Message Buffers Queued for Log Processor
D4
212
$COMMQUE
HASP Commands Queued for Command Processor
D8
216
$PRCHKPT
Address of HASP Print Checkpoint Table
DC
220
HASP Communication Table Format
511
-~
Page 8.1-6
HAS P
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
DC
220
~-----------------------
4 bytes
------------------------~
$SVCRELT
Address of MFT SVC Relocation Table
EO
224
$SVCTABF
Address of MFT SVC Table
E4
228
$SVCTABV
Address of MVT SVC Table
E8
232
$IOSENT
Entry to O/S Input/Output Supervisor
EC
236
$ATTNENT
Entry to lOS Attention Appendage
FO
240
$XSMFENT
Entry to SMF EXCP Counting Routine
F4
244
$SVRSET
Entry to HASP SVC Reset Routine
F8
248
HASP Communication Table Format -- Page 8.1-7
512
II /\ S P
Figure B.l.l -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement \.. _______________________ 4 bytes ___________________ ~---- . .
Hex.
Dec.
FB
24B
I
$WAITENT
Entry to IGCOOl "(WAIT)
FC
252
$LINKENT
Entry to IGC006 (LINK)
100
256
$XCTLENT
Entry" to IGC007 (XCTL)
104
$TIMENT
260
Entry to IGCOll (TIME)
lOB
$SVCIOS
264
Address of EXCP SVC Table Entry
10C
$SVCLINK
268
Address of LINKSVC Table Entry
110
$SVCWTO
272
WTO/WTOR SVC Table Entry
114
$SVCWTL
276
WTL SVC Table Entry
IlB
$ATTNSAV
2BO
....
......
1~___________
1_2_-_B_y_t_e___A_t_t_e_n_t_1_o_n__A
__
p_p_e_n_d_a_g_e__S_a_v_e__A_r_e_a____________
124
~J __~~
292
HASP Communication Table Format
513
~-
Page 8.1-8
HAS P
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Di~placement
Hex.
Dec.
124
292
r------------------------
4 bytes
------------------------~
--~-
$JOBQPTR
Address of HASP Job Queue
128
296
$JQFREE
Beginning of Free Job Queue Element Chain
12C
300
$JQENT
Beginning of Active Job Queue Element Chain
130
304
$XEQTOTL
Cumulative Estimated Execution Time
134
308
$PRTTOTL
Cumulative Lines to be printed
138
312
$PUNTOTL
Cumulative Cards to be Punched
13C
316
$JOBNO
$MSGRPNO
HASP Job Number
140
320
Last Console Track
$DACKPT
1~_____________
v_a_r_l_a_b_l_e__L_e_n_g__
th
___
DA
___C_h_e_c_k_p_O_l_n_t__A_r_e_a____________
__
~r ~
HASP Communication Table Format -- Page 8.1-9
514
HAS P
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
.
0
0
$VERSION
8
HASP Version (" V v.m
8
8
$WAIT
4
Entry to HASP Dispatcher.
C
12
$GETBUF
4
Entry to HASP Buffer "GET" Routine.
10
16
$GETPBUF
4
Entry to HASP RJE Buffer "GET" Routine.
14
20
$FREEBUF
4
Entry to HASP Buffer "FREE" Routine.
18
24
$GETUNIT
4
Entry to HASP unit "GET" Routine.
lC
28
$FRELNIT
4
Entry to HASP Unit "FREE" Routine.
20
32
$QADD
4
Entry to HASP Job Queue Element "ADD" Routine.
24
36
$QGET
4
Entry to HASP Job Queue Element "GET" Routine.
28
40
$QPUT
4
Entry to HASP Job Queue Element "PUT" Routine.
2C
44
$QREM
4
Entry to HASP Job Queue Element "REMOVE"
Routine.
30
48
$QSIZ
4
Entry to HASP Job Queue "SIZE" Routine.
34
52
$QLOC
4
Entry to HASP Job Queue Element "LOCATE"
Routine.
38
56
$QJITLOC
4
Entry to HASP Job Information Table Element
"LOCATE" Routine.
3C
60
$TRACK
4
Entry to HASP Track Allocation Routine.
40
64
$PURGER
4
Entry to HASP Track Purge Routine.
44
68
$EXCP
4
Entry to HASP Input/Output Supervisor.
48
72
$EXTPOPE
4
Entry to HASP RTAM Open Routine.
4C
76
$EXTPGET
4
Entry to HASP RTAM Get Routine.
50
80
$EXTPPUT
4
Entry to HASP RTAM Put Routine.
54
84
$EXTPOPE
4
Entry to HASP RTAM Close Routine.
58
88
$RESTORE
4
Entry to HASP RTAM Restore Routine.
")
HASP Communication Table Format -- Page 8.1-10
II ASP
Fiqurc 8.1.1 -- HASP COMMUNICATION TABLE FORMArI' (CONTINUED)
Displacement
Hex.
Dec.
Field Name
Bytes
Field Description
SC
92
$oDEL
4
Entry to HASP Overlay $DELE'I'E Routine.
60
96
$oRET
4
Entry to HASP Overlay $RETURN Routine.
64
100
$oLINK
4
Entry to HASP Overlay $LINK Routine.
68
104
$oXCTL
4
Entry to HASP Overlay $XCTL Routine.
6C
108
$0 LOAD
4
Entry to HASP Overlay $ LOAD Routine.
70
112
$WTo
4
Entry to HASP Write-to-Operator Routine.
74
116
$FREEMSG
4
Entry to HASP Console Message Buffer
Free Routine.
78
120
$STIMER
4
Entry to HASP Set Interval Timer Routine.
7C
124
$TTIMER
4
Entry to HASP Test Interval ;rimer Routine.
80
128
$IoERRoR
4
Entry to HASP Input/Output Error Logging
Routine.
84
132
$ERRoR
4
Entry to HASP Catastrophic Error Routine.
88
136
$DISTERR
4
Entry to HASP Disastrous Error Routine.
8C
140
$SYSTYPE
1
System Type -Hex.
Value
10
14
20
8D
141
$oPTSTAT
1
Meaning
MVT
MPS
MFT
Initialization Options -Bit
Name
0
$oPTFMT
$oPTCOLD
$OPTREQ
$OPTREP
$OPTLIST
$OPTRACE
1
2
3
4
S
6-7
Meaning
FORMAT.
COLD.
REQ.
REP.
LIST.
TRACE.
Reserved for Future Use.
HASP Communication Table Format -- Page 8.1-11
516
HAS P
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
8E
142
Field Name
$STATUS
Bytes
1
Field Description
HASP Status -Bit
Name
o
1
$RDRPEND
$ALMSGSW
2
3
4
$DRAINED
$CKPTACT
$JITCKPT
5
$SYSEXIT
6-7
8F
143
90
144
$HASPECF
Reserved for Future Use.
1
Master Event Control Field
Bit
Name
o
2
$EWFPOST
$EWFBUF
$EWFTRAK
3
$EWFJOB
4
6
$EWFUNIT
$EWFCKPT
$EWFCMB
7
$EWF8
5
145
MHASPECF
O/S Reader is Pending.
ALL AVAILABLE FUNCTIONS
COMPLETE Message has been
Issued.
System has been $DRAINed.
Checkpoint is in Progress.
Job Information Table (JIT)
is to be Checkpointed.
HASP System is in termination
process.
Reserved for Future Use.
1
1
91
Meaning
1
Meaning
A PCE has been $POSTed.
A Buffer has been Released.
A Direct-Access Track has
been Released.
A Job Queue Element has
Changed Status.
A HASP Unit has been Released.
A HASP Checkpoint has Completed.
A Console Message Buffer has
been Released.
Reserved for Future Use.
Remote Job Entry Line Manager Event
Control Field
Bit
Name
0-2
3
$EWFJOB
4-7
Meaning
Reserved - Must be Zero.
A Job Queue Element has
Changed Status.
Reserved - Must be Zero.
HASP Communication Table Format -- Page 8.1·-12
517
HAS P
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
92
146
$XEQACT
1
Count of Jobs in O/S Execution Phase.
93
147
$ACTIVE
1
Count of Active Processors.
94
148
$ENBALL
1
$ENABLE ALL Mask (X'FF').
95
149
$DISALL
1
$DISABLE ALL Mask (XIOO').
96
150
$DISINT
1
$DISABLE INT Mask (X'FE').
97
151
1
Reserved for Future Use.
98
152
$PSRDRCT
1
Count of Pseudo 2540 Readers.
99
153
$PSPRFCT
1
Count of Pseudo 1443 Printers.
9A
154
$PSPUFCT
1
Count of Pseudo 1442 Punches.
9B
155
1
Reserved for Future Use.
9C
156
$EXCPCT
2
count of Active I/O Operations.
9E
158
$COMMCT
2
Number of Console Message Buffers which
are not Queued for the HASP Command Processor.
AO
160
$CKPTRAK
2
Checkpoint Track.
A2
162
2
Reserved for Future Use.
A4
164
$HASPTCB
4
Address of HASP Task Control Block.
A8
168
$PCEORG
4
Address of First HASP Processor Control
Element.
AC
172
$BUFPOOL
4
Address of First Available HASP Buffer.
BO
176
$TPBPOOL
4
Address of First Available HASP RJE Buffer.
B4
180
$DCTPOOL
4
Address of First HASP Device Control Table.
B8
184
$JITABLE
4
Address of HASP Job Information Table.
BC
188
$CYLMAP
4
Address of First HASP Track Allocation Map.
co
192
$TEDADDR
4
Address of First Track Extent Data Table.
HASP Communication Table Format -- Page 8.1-13
518
HAS P
Figure S.l.l -- HASP COMMUNICATION TABLE FORMAT ( CONTINUED)
Displacement
Hex.
Dec.
Field Name
Bytes
Field Description
C4
196
$DCBLIST
4
Address of HASP Direct Access DCB.
CS
200
$FREEQUE
4
Address of First Free HASP Console
Message Buffer.
CC
204
$BUSYQUE
4
Address of First Console Message Buffer
which is Queued for I/O.
DO
20S
$LOGQUE
4
Address of First Console Message Buffer
which is Queued for the Log Processor.
D4
212
$COMMQUE
4
Address of First Console Message Buffer
which is Queued for the Command Processor.
DS
216
$PRCHKPT
4
Address of HASP Print Checkpoint Table.
DC
220
$SVCRELT
4
Address of MFT SVC Relocation Table.
EO
224
$SVCTABF
4
Address of MFT SVC Table.
E4
22S
$SVCTABV
4
Address of MVT SVC Table.
ES
232
$IOSENT
4
Address of Entry to O/S Input/Output
Supervisor.
EC
236
$ATTNENT
4
Address of Entry to lOS Attention Appendage.
FO
240
$XSMFEMT
4
Address of Entry to SMF EXCP Counting
Routine.
F4
244
$SVRSET
4
Address of Entry to HASP SVC Reset Routine.
F8
248
$WAITENT
4
Address of Entry to IGCOOI (WAIT) .
FC
252
$LINKENT
4
Address of Entry to IGC006 (LINK) .
100
256
$XCTLENT
4
Address of Entry to IGC007 (XCTL) .
104
260
$TIMENT
4
Address of Entry to IGCOll (TIME) .
108
264
$SVCIOS
4
Address of EXCP SVC Table Entry.
10C
268
$SVCLINK
4
Address of LINK SVC Table Entry.
HASP COITnllunication Table Format --- Page 8.1-14
519
II ASP
Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
110
272
$SVCWTO
4
WTO/WTOR SVC Table Entry.
114
276
$SVCWTL
4
WTL SVC Table Entry.
118
280
$ATTNSAV
12
124
292
$JOBQPTR
4
Address of HASP Job Queue.
128
296
$JQFREE
4
Beginning of Free Job Queue Element Chain.
l2C
300
$JQENT
4
Beginning of Active Job Queue Element Chain.
130
304
$XEQTOTL
4
Cumulative Estimated Execution Time.
134
308
$PRTTOTL
4
Cumulative Lines to be Printed.
138
312
$PLNTOTL
4
Cumulative Cards to be Punched.
l3C
316
$JOBNO
2
HASP Job Number.
13E
318
$MSGRPNO
2
Last Remote Console Message Queueing Track.
140
320
$DACKPT
Attention Appendage Save Area.
. Variable Length Direct Access Checkpoint Area.
HASP Communication Table Format -- Page 8.1-15
520
HAS P
Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT
Displacement
Hex.
o
Dec.
0
~-----------------------
4 bytes
------------------------~
PCESAVEA
RES E R V E D
4
4
PCEPREV
Address of Previous Processor Control Element
8
8
PCENEXT
Address of Next Processor Control Element
C
12
PCELINK
Processor Register 14
10
16
(LINK) Storage
PCER15
Processor Register 15 Storage
14
20
PCERO
Processor Register 0 Storage
18
24
PCER1
Processor Register 1 Storage
lC
28
PCEWA
Processor Register 2 (WA) Storage
20
32
PCEWB
Processor Register 3 (WB) Storage
24
36
PCEWC
Processor Register 4 (WC) Storage
28
40
Processor Control Element Format -- Page 8.2-1
521
HAS P
Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT (CONTINUED)
Displacement
Hex.
Dec.
28
40
~-----------------------
4 bytes
------------------------~
PCEWD
Processor Register 5 (WD) Storage
2C
44
PCEWE
Processor Register 6 (WE) Storage
30
48
PCEWF
Processor Register 7 (WF) Storage
34
52
PCEWG
PCEBASE3
Processor Register 8 (WG or BASE 3 ) Storage
38
56
PCER9
Processor Register 9 Storage
3C
60
PCEJCT
Processor Register 10 (JCT) Storage
40
64
PCEBASEJ.
Processor Register 11 (BASEl) Storage
44
68
PCEBASE2
Processor Register 12 (BASE2 ) Storage
48
72
PCEEWF
PCEID
Event Wait Field
4C
PCEOPRIO
76
RESERVED
50
Overlay
Priority
Processor Type
PCEOCON
Overlay Routine OCON
80
Processor Control Element Format -- Page 8.2-2
II ASP
Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT (CONTINUED)
Displacement
Hex.
Dec.
50
80
~-----------------------
4 bytes
------------------------~
PCEORTRN
Overlay Supervisor Register ,14
54
(LINK)
Storage
PCEOPCE
84
Chain of PCEs Using Same Overlay Routine
58
88
PCEWORK
,
Variable Length Processor Work Area
'
1________----'1
Processor Control Element Format -- Page 8.2-3
523
II ASP
Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT ( CONTINUED)
Dis12lacement
Hex.
Dec.
Field Name
Bytes
Field Description
0
0
PCESAVEA
4
Reserved.
4
4
PCEPREV
4
Address of Previous Processor Control
Element.
8
8
PCENEXT
4
Address of Next Processor Control Element.
C
12
PCELINK
4
Processor Register 14 (LINK) Storage.
10
16
PCER15
4
Processor Register 15 Storage.
14
20
PCERO
4
Processor Register 0 Storage.
18
24
PCERl
4
Processor Register 1 Storage.
1C
28
PCEWA
4
Processor Register 2 (WA) Storage.
20
32
PCEWB
4
Processor Register 3 (WB) Storage.
24
36
PCEWC
4
Processor Register 4 (We) storage.
28
40
PCEWD
4
Processor Register 5 (WD) Storage.
2C
44
PCEWE
4
Processor Register 6 (WE) Storage.
30
48
PCEWF
4
Processor Register 7 (WF) Storage.
34
52
PCEWG
PCEBASE3
4
Processor Register 8 (WG or BASE3)
Storage.
38
56
PCER9
4
Processor Register 9 Storage.
3C
60
PCEJCT
4
Processor Register 10 (JCT) Storage.
40
64
PCEBASEl
4
Processor Register 11 (BASEl) Storage.
44
68
PCEBASE2
4
Processor Register 12 (BASE2) Storage.
Processor Control Element Format -- Page 8.2-4
HAS P
Figure S.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT (CONTINUED)
Displacement
Hex.
Dec.
4S
72
Field Name
PCEEWF
Bytes
2
Field Description
Event Wait Field -Hex.
Value
Byte 1
Byte 2
4A
74
PCEID
2
Byte 1
Name
40
20
$EWFPOST
$EWFBUF
$EWFTRAK
10
OS
04
$EWFJOB
$EWFUNIT
$EWFCKPT
02
$EWFCMB
01
$EWF8
SO
$EWFOPER
40
$EWFIO
20
10
OS
04
02
01
$EWFWORK
$EWFHOLD
$EWFDDB
$EWFOLAY
$EWF15
$EWFOROL
so
Meaning
Reserved.
Waiting for a Buffer.
Waiting for HASP
Direct-Access Space.
Waiting for a Job.
Waiting for a Unit.
Waiting for the completion
of a HASP Checkpoint.
Waiting for a Console
Message Buffer.
Reserved for Future Use.
Waiting for Operator
Response.
Waiting for the Completion
of I/O.
Waiting to be Re-directed.
Waiting for a $S Command.
Waiting for a DDT or UCB.
Waiting for an Overlay Area.
Reserved for Future Use.
Relinquished Overlay Area.
Processor Type
Bit
Name
0
1
2-4
PCEPRSID
PCEPUSID
S
PCEINRID
PCERJEID
PCELCLID
6
7
Meaning
Print Processor.
Punch Processor.
Reserved for Future Use.
Internal Reader Processor.
Remote Terminal Processor.
Local Processor.
Processor Control Element Format -- Page 8.2-5
525
HAS P
Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT (CONTINUED)
Displacement
Hex.
Dec.
Field Name
Bytes
Field Description
Processor Type (continued) -Hex.
Value
Byte 2
4C
76
4D
77
4E
00
01
03
04
05
07
08
09
OA
OB
OC
OD
OE
OF
Name
PCEASYID
PCERDRID
PCEXEQID
PCETHWID
PCEXZMID
PCEPRTID
PCEPUNID
PCEPRGID
PCECONID
PCEMLMID
PCETIMID
PCECKPID
PCEGPRID
PCEOROID
Meaning
ASYNCH Processor.
Input Service Processor.
Execution Service Processor.
Execution Thaw Processor.
Execution Task Monitor.
Print Processor.
Punch Processor.
Purge Processor.
Console Processor.
Line Manager Processor.
Timer Processor.
Checkpoint Processor.
Priority Aging Processor.
Overlay Roll Processor.
1
Reserved for Future Use.
PCEOPRIO
1
Priority of Current Overlay Routine.
78
PCEOCON
2
Overlay Constant (OCON) of Current Overlay
Routine.
50
80
PCEORTRN
4
Overlay Supervisor Register 14 (LINK) Storage.
54
84
PCEOPCE
4
Chain of PCEs Using Same Overlay Routine.
58
88
PCEWORK
Variable Length Processor Work Area.
Processor Control Element Format
526
--~
Page 8.2-6
HAS P
Figure 8.3.1 -- BUFFER FORMAT
Displacement
Hex.
Dec.
o
o
4
4
r----------------------10BFLAG:L
10BFLAG2
I/O Flags
I/O Flags
8
---------------------:.--1
IOBSENSO
10BSENSl
First
Sense Byte
Second
Sense Byte
10BECBPT
IOBECBCC
8
4 bytes
IOBFLAG3
Address of HASP Event Control Block
IOBCSW
I/O Flags
Channel Status Word
10
16
10BSTART
10BSI0CC
14
20
-
Address of Channel Program
10BDCBPT
Address of Data Control Block
18
24
IOBRESTR
IOBREPM
lC
28
Restart Address of Channel Program
10DINCAM
10BERRCT
Block Count Increment
20
32
10BXTENT
Error Count
10BSEEK
Extent Index
Seek Address {Direct-Access Only}
28
-
40
Buffer Format -- Page 8.3-1
527
HAS P
Figure 8.3.1 -- BUFFER FORMAT (CONTINUED)
Displacement
Hex.
Dec.
28
40
~-----------------------
44
Buffer Chain Field
I
BUFDCT
BUFTYPE
30
------------------------~
BUFCHAIN
BUFECBCC
2C
4 bytes
Address of Device Control Table
I
BUFEWF
48
Event Wait Field or Post Address
34
52
RES E R V E D
38
IOBCCWl.
56
f-
40
Channel Command Word 2
-
Channel Command Word 3
-
IOBCCW3
72
-
50
-
IOBCCW2
64
-
48
Channel Command Word 1
80
Buffer Format -- Page 8.3-2
528
HAS P
Figure 8.3.1 -- BUFFER FORMAT (CONTINUED)
Displacement
Hex.
Dec.
50
80
~-----------------------
4 bytes ------------------------ . .
1
~UFSTART
1
Variable Length Buffer
1L-.-_ _---'J
Buffer Format -- Page 8.3-3
529
11 ASP
Figure 8.3.1 -- BUFFER FORMAT (CONTINUED)
Displacement
Hex.
Dec.
Field Name
Bytes
Field Description
o
o
IOBFLAGl
1
standard OS/360 lOB Flag Byte.
1
1
IOBFLAG2
1
standard OS/360 lOB Flag Byte.
2
2
IOBSENSO
1
First Sense Byte (Device Dependent) .
3
3
IOBSENSl
1
Second Sense Byte (Device Dependent) .
4
4
IOBECBCC
1
Completion Code for I/O Event.
4
4
IOBECBPT
4
Address of HASP Event Control Block:
$HASPECB.
8
8
IOBFLAG3
1
I/O Supervisor Error Routine Flag Byte
(Device Dependent) .
9
9
IOBCSW
7
Low-Order Seven Bytes of the Last CSW
that Reflects the Status of the
Last Request.
10
16
IOBSIOCC
1
Condition Code Returned after Execution
of SIO Instruction for Last Request.
10
16
IOBSTART
4
Address of Channel Program to be
Executed.
14
20
IOBDCBPT
4
Address of Data Control Block Associated
with this lOB.
18
24
IOBREPM
1
Operation Code Used by I/O Supervisor
Error Routines for Repositioning
Procedures.
18
24
IOBRESTR
4
Restart Address of Channel Program Used
by I/O Supervisor Error Routines During
Error Correction.
lC
28
IOBINCAM
2
Value used to Increment Block Count
Field in DCB for Magnetic Tape.
IE
30
IOBERRCT
2
Used by r/o Supervisor Error Routines
to Count Temporary Errors during Retry.
20
32
IOBXTENT
1
The Number of the DEB Extent to be
Used for this Request.
Buffer Format -- Page 8.3-4
530
Figure 8.3.1 -- BUFFER FORMAT (CONTINUED)
Displacement
Hex.
Dec.
Field Name
Bytes
Field Description
21
33
IOBSEEK
7
Seek Address Required for this I/O
Request (Direct-Access Only).
28
40
BUFECBCC
1
Completion Code for I/O Event -Hex.
Value
00
7F
other
Meaning
The I/O Event has not Completed.
The I/O Event has Completed
Successfully.
The I/O Event has Completed
Unsuccessfully.
28
40
BUFCHAIN
4
Buffer Chain Field.
2C
44
BUFTYPE
1
Buffer Type -Hex.
Value
00
Name
HASPBUF
Meaning
HASP Buffer
2C
44
BUFDCT
4
Address of Device Control Table Associated
with this I/O Request.
30
48
BUFEWF
4
Event wait Field or Post Address.
34
52
4
Reserved for Future Use.
38
56
IOBCCWl
8
Channel Command Wo.rd 1.
40
64
IOBCCW2
8
Channel Command Word 2.
48
72
IOBCCW3
8
Channel Command Word 3.
50
80
BUFSTART
Variable Length Buffer.
Buffer Format -- Page 8.3-5
HAS P
Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT
Displacement
Hox.
o
4
Dec.
0
4
~----------------------IOBFLAG1
IOBFLAG2
I/O Flags
I/O Flags
------------------------~
IOBSENSO
IOESENS1
First
Sense Byte
Second
Sense Byte
IOBECBPT
IOBECBCC
8
4 bytes
Address of HASP Event Control Block
IOBCSW
8
RESERVED
Channel Status Word
10
16
IOBSTART
IOBSIOCC
14
20
Address of Channel Program
IOBDCBPT
Address of Data Control Block
18
24
IOBRESTR
Address of First
lC
28
32
36
Address of Last Remote Carriage Control
TPBFDATA
TPBRECNT
28
RES E R V E D
TBPLCCAD
TPBLCCC
24
in Channel Program
TPBMXREC
Maximum
Record Count
20
ccw
Remote nata Pointer
40
Buffer Formqt -- Page 8.3-6
HAS P
Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED)
Displacement
Hex.
Dec.
28
40
~-----------------------
4 bytes
BUFCHAIN
Buffer Chain Field
BUFECBCC
2C
44
BUFDCT
Address of Line DCT
BUFTYPE
30
------------------------~
BUFEWF
48
Address of Event Wait Field
34
38
52
56
LCBMCB
LCBACK
Mode Byte
Next
Acknowledge
LCBRCB
Response Control Block
IOBCCWl
Channel Command Word 1
"-
-
MSEQTYPE
40
64
IOBCCW2
I-
48
-
Channel Command Word 3
-
IOBCCW3
72
r-
50
Channel Command Word 2
80
Buffer Format -- Page 8.3-7
533
HAS P
Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED)
Displacement
Hex.
Dec.
50
80
~-----------------------
88
104
-
Channel Command Word 6
-
Channel Command Word 7
-
Channel Command Word 8
-
IOBCCW8
112
~
78
Channel Command Word 5
IOBCCW7
r-
70
-
IOBCCW6
96
-
68
Channel Command Word 4
IOBCCW5
r-
60
------------------------~
IOBCCW4
r-
58
4 bytes
120
Buffer Format -- Page 8.3-8
534
HAS P
Figure
8.3.2 -- REMOTE J"OB ENTRY BUFFER FORMAT
Displacement
Hex.
Dec.
78
120
~-----------------------
I
1
4 bytes
(CONTINUED)
-------------------------1
TPBUFST
Variable Length Buffer
J
Buffer Format -- Page 8.3-9
535
II ASP
Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
o
o
IOBFLAGl
1
Standard OS/360 lOB Flag Byte.
1
1
IOBFLAG2
1
Standard OS/360 lOB Flag Byte.
2
2
IOBSENSO
1
First Sense Byte (Device Dependent).
3
3
IOBSENSl
1
Second Sense Byte (Device Dependent) .
4
4
IOBECBCC
1
Completion Code for I/O Event.
4
4
IOBECBPT
4
Address of HASP Event Control Block:
$HASPECB.
8
8
1
Reserv'ed.
9
9
IOBCSW
7
Low Order Seven Bytes of the Last CSW
that Reflects the Status of the Last
Request.
10
16
IOBSIOCC
1
Condition Code Returned after Execution
of SIO Instruction for Last Request
10
16
IOBSTART
4
Address of Channel Program to be Executed.
14
20
IOBDCBPT
4
Address of Data Control Block Associated
with this lOB.
18
24
IOBRESTR
4
Address of Normal Channel Program to be
Executed.
lC
28
TPBMXREC
1
Maximum Output Record Count.
lD
29
3
Reserved for Future Use.
20
32
TPBLCCC
1
Last Output Channel Command Operation.
20
32
TPBLCCAD
4
Address of Last Remote Carriage Control.
24
36
TPBRECNT
1
Current Output Record Count.
24
36
TPBFDATA
4
Address of Next Data in Buffer.
28
40
BUFECBCC
1
Completion Code for I/O Event.
28
40
BUFCHAIN
4
Buffer Chain Field.
Buffer Format -- Page 8.3-10
HAS P
Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED)
Displacement
Hex.
Dec.
2C
44
Field Name
BUFTYPE
Bytes
I
Field DescriEtion
Buffer Type -Hex.
Value
80
Name
TPBUF
Meaning
Remote Job Entry Buffer
2C
44
BUFDCT
4
Address of Line Device Control Table
Associated with this I/O Request.
30
48
BUFEWF
4
Address of Event Wait Field.
34
52
LCBMCB
I
Mode Byte Used to Set SDA Mode.
35
53
LCBACK
I
BSC:
STR:
Next Acknowledgement Character
(Expected or to be Sent).
Second Mode Byte.
Response Control Block.
Unused.
36
54
LCBRCB
2
BSC:
STR:
38
56
IOBCC\~l
8
Channel Command Word 1.
3D
61
MSEQTYPE
1
Sequence and Command Type,,--
Bits 0-3
Sequence Type
Bit
Name
0
MBSCSEQ
Value
0
1
1
MPREPSEQ
2
MWRITSEQ
0
1
0
1
3
MCPUSEQ
0
1
Meaning
STR Sequence.
BSC Sequence.
Text Sequence.
Prepare Sequence.
Read Sequence.
write Sequence.
Hardware Sequence.
CPU Sequence.
Buffer Format ._- Page 8.3-11
537
HAS P
Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED)
Displacement
Hex.
Dec.
Field Name
Bytes
Fi~ld
Description
Sequence and Command Type (continued)
Bits 4-7
--
Command Type
Hex.
Value
0
1
2
3
4
5
6
7
8
9
A
B
Name
MDISCMD
MSETMCMD
MENBCMD
MTSYNCMD
MREADCMD
MRRSPCMD
MRREQCMD
MPREPCMD
MWRITCMD
MWRSPCMD
MWENQCMD
MSEOTCMD
Meaning
Disable Command.
Set Mode Command.
Enable Command.
Test Synch Command.
Read Text Command.
Read Response (Normal) .
Read Response (To ENQ) .
Prepare Command.
write Text Command.
write Response Command.
Send Inquiry Command.
Send EOT Command.
40
64
IOBCCW2
8
Channel Command Word 2.
48
72
IOBCCW3
8
Channel Command Word 3.
50
80
IOBCCW4
8
Channel Command Word 4.
58
88
IOBCCW5
8
Channel Command Word 5.
60
96
IOBCCW6
8
Channel Command Word 6.
68
104
IOBCCW7
8
Channel Command Word 7.
70
112
IOBCCW8
8
Channel Command Word 8.
78
120
TPBUFST
Variable Length Buffer.
Buffer Format -- Page 8.3-12
538
HAS P
Figure 8.3.3 -- OVERLAY AREA FORMAT
Displacement
Hex.
Dec.
o
o
4
4
~----------------------IOBFLAGl
IOBFLAG2
I/O Flags
I/O Flags
8
------------------------1
IOBSENSO
IOBSENSl
First
Sense Byte
Second
Sense Byte
10BECBPT
Address of HASP Event Control Block
10BECBCC
8
4 bytes
IOBFLAG3
IOBCSW
I/O Flags
Channel Status Word
10
16
10BSTART
Address of Channel Program
10BSI0CC
14
20
-
10BDCBPT
Address of Data Control Block
18
24
10BRESTR
IOBREPM
lC
Restart Address of Channel Program
I
IOBERRCT
28
RE S E R V E D
20
32
IOBXTENT
Error Count
IOBSEEK
Extent Index
Seek Address
28
-
40
Buffer Format -- Page 8.3-13
539
HAS P
Figure 8.3.3 -- OVERLAY AREA FORMAT (CONTINUED)
Displacement
Hex.
Dec.
28
40
~-----------------~----- 4 bytes ------------------------~
BUFCHAIN
Buffer Chain Field
BUFECBCC
2C
BUFDCT
44
Address of OLAY OCT
BUFTYPE
30
BUFEWF
48
Address of Overlay Service Asynchronous Exit
34
OACECHN
52
Overlay Area Chain Word
38
IOBCCWl
56
-
40
Channel Command Word I
-
IO:aCCW2
64
Channel Command Word 2
44
OACEPRIO
68
RESERVED
48
Overlay Call Constant
IOBCCW3
72
I-
50
Overlay
Priority
OACEOCON
Channel Command Word 3
-
80
Buffer Format -- Page 8.3-14
540
HAS P
Figure 8.3.3 -- OVERLAY AREA FORMAT (CONTINUED)
Displacement
Hex.
Dec.
50
80
r-----------------------
4 bytes
------------------------1
OACENAME
Name of Overlay Routine
54
84
OACEASMO
Assembly Origin of Overlay Routine
58
OACEPROG
88
Entry Point of Overlay Routine
5C
92
'"
Var1able Length Overlay Area
OACEPCE
Chain of peEs Using Overlay Area
Buffer Format -- Page 8.3-15
541
HAS P
Figure 8.3.3 -- OVERLAY AREA FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
o
o
IOBFLAGl
1
standard OS/360 lOB Flag Byte.
1
1
IOBFLAG2
1
standard OS/360 lOB Flag Byte.
2
2
IOBSENSO
1
First Sense Byte (Device Dependent) .
3
3
IOBSENSl
1
Second Sense Byte (Device Dependent) .
4
4
IOBECBCC
1
Completion Code for Overlay Read.
4
4
IOBECBPT
4
Address of HASP Event Control Block:
$HASPECB .
8
8
IOBFLAG3
1
I/O Supervisor Error Routine Flag Byte
(Device Dependent).
9
9
IOBCSW
7
Low Order Seven Bytes of the Last CSW
that Reflects the Status of the Last Read.
10
16
IOBSIOCC
1
Condition Code Returned After the Execution
of the SIO Instruction for the Last Read.
10
16
IOBSTART
4
Address of the Channel Program to be
Executed.
14
2Q
IOBDCBPT
4
Address of the Data Control Block Associated
with this lOB.
18
24
IOBREPM
1
Operation Code Used by I/O Supervisor
Error Routines for Repositioning Procedures.
18
24
IOBRESTR
4
Restart Address of Channel Program Used by
I/O Supervisor Error Routines During Error
Correction.
lC
28
2
Reserved.
IE
30
IOBERRCT
2
Used by I/O Supervisor Error Routines
to Count Temporary Errors During Retry.
20
32
IOBXTENT
1
The Number of the DEB Extent to be Used
for this Read.
21
33
IOBSEEK
7
The Seek Address for the Requested Overlay
Routine.
Buffer Format -- Page B.3-16
542
H l\ S P
Fiqure 8.3.3 -- OVERLAY AREA FORMAT (CONTINllliD)
Displacement
Hex.
Dec.
28
40
Field Name
Bytes
BUFECBCC
1
Field Description
Completion Code for Overlay Read --,
Hex.
Value
Meaning
00
7F
other
The Read,has not Completed.
The Read has Completed Successfully.
The Read has Completed Unsuccessfully.
28
40
BUFCHAIN
4
Buffer Chain Field.
2C
44
BUFTYPE
1
Buffer Type -Hex.
Value
40
,Name
OLAYBUF
Meaning.
Overlay Area.
2C
44
BUFDCT
4
Address of Overlay Device Control Table.
30
48
BUFEWF
4
Address of Overlay Service Asynchronous Exit.
34
52
OACECHN
4
Overlay Area Chain Word.
38
56
IOBCCWl
8
Channel Command Word 1.
40
64
IOBCCW2
8
Channel Command Word 2.
44
68
1
Reserved for Future Use.
45
69
OACEPRIO
1
Priority of Current Overlay Routine.
46
70
OACEOCQ\J
2
Overlay Constant (OeON)
Routine.
48
72
IOBCCW3
8
Channel Command Word 3.
50
80
OACENAME
4
Name of Overlay Routine.
54
84
OACEASMO
4
Assembly Origin of Overlay Routine.
58
88
OACEPROG
of Current Overlay
Entry Point of Overlay Routine.
Variable Length Overlay Area
OACEPCE
4
Chain of PCEs Using Overlay Area.
Buffer Format -- Page 8.3-17
543
HAS P
Figure 8.4.1 -- CONSOLE MESSAGE BUFFER FORMAT
Displacement
Hex.
o
Dec.
~-----------------------
0
4 bytes
------------------------~
CMBCHAIN
Address of Next Console Message Buffer
4
8
4
8
CMBFLAGS
CMBCONS
CMBMSGL
CMBPRIO
CMBCLASS
Flags
Consoles
Specified
Message
Length
Prio & Class
CMBMSG
CMBMARK
CMBTIME
Attention
Indicator
Start of
Message
C
-
12
Time of Day
f.-
10
16
14
20
CMBJOBNO
Job Number
I-
18
24
lC
28
CMBTEXT
......
1~
8C
_________________
-
......
l~
1_1_2__B_y_t_e__M_e_s_s_a_g_e___
T-ex--t--A-r-e_a_________________
140
Console Message Buffer Format -- Page 8.4-1
544
HAS P
Figure 8.4.1 -- CONSOLE MESSAGE BUFFER FORMAT (CONTINUED)
Displacement
Hex.
Dec.
Field Name
Bytes
Field Description
o
o
CMBCHAIN
4
Address of Next Console Message;Buffer.
4
4
CMBFLAGS
1
Console Buffer Flags -Bit
Name
o
WCMBFD
1
2
WCMBFH
WCMBFE
WCMBFF
WCMBFG
WCMBFA
WCMBFB
WCMBFC
3
4
5
6
7
Meaning
CMBCONS Contains
Consoles.
Operation Type.
Message for HASP
CMBCONS Contains
CMBCONSContains
Reserved for
Command
Processor.
Physical
Log Only.
UCMID.
Remote No.
5
5
CMBCONS
1
Console Specifications or Remote Number.
6
6
CMBMSGL
1
Message Length.
7
7
CMBCLASS
1
Message Class
Bits 0-3
Value
5
$TRIVIA
$NORMAL
$ACTI(J\J
7
$ALWAYS
1
3
CMBPRIO
Name
Meaning
Non-Essential Messages.
Normal Messages.
Messages Requiring
Operator Action.
Essential Messages.
Message Priority
Bits 4-7
Value
1
4
7
Name
$LO
$ST
$HI
Meaning
Low Priority.
Standard Priority.
High Priority.
8
8
CMBMSG
9
9
CMBMARK
1
Asterisk (*) if Message Class is 5 or More.
A
10
CMBTIME
9
Time of Day (HH.MM.SS ).
13
19
CMBJOBNO
8
Job Number (If Applicable) .
lB
27
CMBTEXT
132
112
Message Area.
Message Text Area.
Console Message Buffer Format -- Page 8.4-2
545
HAS P
Figure 8.5.1 -- DIRECT-ACCESS DEVICE CONTROL TABLE FORMAT
Displacement
Hex.
o
Dec.
0
~----------------------DCTPCE
Address of Processor Control Element
DCTSTAT
4
4
.J
4 bytes ------------------------- I
DCTBUFAD
Current Buffer Address
8
8
DCTSEEK
Current Track Address
C
12
DCTEWF
Event Wait Field or Post Address
10
16
DCTBUFCT
Active
Buffer Count
14
20
RESERVED
DCTDEVTP
DCTIOTYP
Device
Type
Input/Output
Request Type
DCTCHAIN
Address of Next Device Control Table
18
24
Device Control Table Format -- Page 8.5-1
546
1i i\ S P
Figure 8.5.1 -- DIRECT-ACCESS DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
o
o
Field Name
DCTSTAT
Bytes
1
Field Description
DCT Status -Bit
Name
o
DCTINUSE
1-7
o
Meaning
DCT is In Use.
Reserved.
DCTPCE
4
Address of Processor Control Element.
DCTBUFAD
4
Address of Current Buffer.
·DCTSEEK
4
Current Track Address.
4
4
8
8
C
12
DCTEWF
4
Event Wait Field or Post Address.
10
16
DCTBUFCT
1
Number of I/O Requests Outstanding.
11
17
1
Reserved for Future Use.
12
18
1
Device Type --
DCTDEVTP
Hex.
Value
00
13
19
DCTIOTYP
1
Bit
Name
o
DCTREAD
DCTWRITE
2-7
20
DCTCHAIN
4
DCTDA
Device Type
Direct~Access
Device.
Input/Output Request Type
1
14
Na:me
Meaning
Read Request.
Write Request.
Reserved for Future Use.
Address of Next Device Control Table.
Device Control Table Format -- Page 8.5-2
547
HAS P
Figure 8.5.2 -~ OVERLAY DEVICE CO~TROL TABLE FORMAT
Displacement
Hex.
o
Dec.
0
r-----------------------
4
------------------------1
DCTPCE
Address of Overlay Roll PCE
DCTSTAT
4
4 bytes
DCTBUFAD
Address of Current Overlay Area
8
8
DCTSEEK
Overlay Track Address
C
12
DCTEWF
Address of Overlay Service Asynchronous Exit
10
16
DCTBUFCT
Active
Buffer Count
14
20
RESERVED
DCTDEVTP
DCTIOTYP
Device
Type
Input
Request Type
DCTCHAIN
Address of Next Device Control Table
18
24
DCTDEVN
EBCDIC Device Name -- "OLAY"
lC
28
DCTOTC
DCTOTT
Number of Tracks/Cylinder
20
Overlay Extent Origin
32
Device Control Table Format -- Page 8.5-3
548
HAS P
Figure 8.5.2 -- OVERLAY DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
o
o
Field Name
DCTSTAT
Bytes
1
Field Description
DCT Status -Bit
Name
o
DCTINUSE
1-7
Meaning
DCT is In Use.
Reserved.
o
o
DCTPCE
4
Address of Overlay Roll PCE.
4
4
DCTBUFAD
4
Address of Current Overlay Area.
8
8
DCTSEEK
4
Overlay Track Address.
C
12
DCTEl.JF
4
Address of Overlay Service Asynchronous
Exit.
10
16
DCTBUFCT
1
Number of I/O Requests Outstanding.
11
17
1
Reserved for Future Use.
12
18
1
Device Type --
DCTDEVTP
Hex.
Value
13
19
DCTIOTYP
1
Name
00
DCTDA
01
DCTOLAY
Meaning
Overlay Data Set Resides
on SPOOL Disk.
Overlay Data Set does not
Reside on SPOOL Disk.
Input Request Type -Bit
o
1-7
Name
DCTREAD
Meaning
Read Request.
Reserved for Future Use.
14
20
DCTCHAIN
4
Address of Next Device Control Table.
18
24
DCTDEVN
4
EBCDIC Device Name -- "OLAY".
lC
28
DCTOTC
2
Number of Tracks per Cylinder on Overlay
Direct-Access Device.
lE
30
DCTOTT
2
Overlay Extent Origin.
Device Control Table Format -- Page 8.5-4
549
H A' S P
Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT
Displacement
Hex.
Dec.
o
o
~-----------------------
------------------------~
DCTPCE
Address of Processor Control Element
DCTSTAT
4
4 bytes
D.CTBUFAD
4
Current Buffer Address
8
DCTDCB
8
Address of Data Control Block
C
DCTEWF
12
Event Wait Field or Post Address
10
DCTNO
DCTBUFCT
16
Active
Buffer Count
14
Device
Type
Device
Type
Address of Next Device COllt::,Q.,l Table
DCTDEVN
24
-
20
DCTIOTYP
DCTCHAIN
20
DCTFLAGS
18
OCT
Number
DCTDEVTP
-
EBCDIC Device Name
32
DEVICES OTHER THAN PRINTERS AND PUNCHES
20
32
DCTPRINT
Print
Destination
24
DCTPUNCH
DCTPRINC
DCTPRLIM
Punch
Destination
Priority
Increment
Priority
Limit
36
Device Control Table Format -- Page 8.5-5
HAS P
Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
-- --
r-----------------------
4 bytes
------------------------1
PRINTERS AND PUNCHES
20
DCTFORMS
32
Current Forms Type (Packed)
Carriage Tape
UCS Type
I
24
36
INTERNAL READERS
24
RIDUC:B
36
Address of Internal Reader UCB
28
RIDFLAGS
40
RIDTJID
Synchronization Flags
2C
RESERVED
RIDEC:B
44
Address of Internal Reader ECB
30
RIDTC:B
48
Address of Internal Reader TCB
34
RIDDATA
52
80-Byte Internal Reader Data Area
84
L32
I
]
Device Control Table Format -- Page 8.5-6
551
HAS P
Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED)
P
Di.S 1acement
Hex. Dec.
-
-
r----------~------------
4 bytes ------------------------,. .
PUNCHES
24
74
36
116
DCTWORK
1
I
SO-Byte Error Recovery Save Area
1
r
Device Control Table Format -- Page 8.5-7
552
HAS P
Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
o
o
Field Name
DCTSTAT
Bytes
1
Field Description
DCT Status -Bit
o
1
2
Meaning
Nam~
DCTINUSE DCT is In Use~
DCTDRAIN DCT is Drained.
DCTHOLD DCT is Held.
Reserved.
3-7
o
o
DCTPCE
4
Address of Processor Control Element.
4
4
DCTBUFAD
4
Current Buffer
8
8
DCTDCB
4
Address of Data Control Block
for this Unit.
C
12
DCTEWF
4
Event Wait Field or Post Address.
10
16
DCTBUFCT
1
Number of I/O Requests Outstanding.
11
17
DCTNO
1
Device Number.
12
18
DCTDEVTP
1
Device Type -Hex.
Value
10
11
14
20
30
40
13
19
DCTIOTYP
1
Address~
Name
DCTRDR
DCTTPE
DCTINR
DCTPRT
DCTPUN
DeTCON
Device Type
Card Reader.
Input Tape.
Internal Reader.
Printer.
Punch.
Console.
Device Type and Console Restrictions
Bit
Name
0-1
2
3
4
5
6
7
DCT1053
DCT2260
DCTREJRM
DCTREJJB
DCTREJDV
DCTREJSY
Meaning
Reserved.
1053 Console.
2260 Console.
Reserved.
Job Command Restriction.
Device Command Restriction.
System Command Restriction.
Device Control Table Format -- Page 8.5-8
553
HAS P
Figure 8. 5 . 3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
14
20
Field Name
Bytes
DCTFLAGS
1
Field Description
Operator Command Flags -Bit
o
1
2
3
4
Name
Command
DCTSTOP $Z ($STOP)
DCTDELET $C ($DELETE)
DCTRSTRT $E ($RESTART)
$N ($REPEAT)
DCTRPT
DCTBKSP $B ($BACKSPACE)
$F
5
DCTHOLDJ $T ••• ,H
DCTSPACE $T ••. ,C=l
$1
2+4
6-7
Reserved for Future Use.
14
20
DCTCHAIN
4
Address of Next Device Control Table.
18
24
DCTDEVN
8
EBCDIC Device Name.
20
32
DCTPRINT
1
Print Destination.
21
33
DCTPLNCH
1
Punch Destination.
22
34
DCTPRINC
1
Priority Increment.
23
35
OCTPRLIM
1
Priority Limit.
20
32
DCTFORMS
2
Current Forms Type (Packed).
22
34
1
Carriage Tape
Bit
o
1
2-7
23
35
1
Name
Meaning
DCTFSPEC Special Forms Routing.
DCTFOPER. Operator Controlled Forms.
Carriage Tape Type.
Universal Character Set -Bit
o
1
2-7
Name
Meaning
DCTIDSEP Generate Separator Page/Card.
DCTOPACT Operator Action Allowed.
UCS Type.
Device Control Table Format -- Page 8.5-9
554
HAS P
Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Field Name
Bytes
Dec.
24
36
RIDUCB
4
Address of Internal Reader UCB.
28
40
RIDFLAGS
2
Synchronization Flags --
Byte 1
I
I
Field Description
Hex.
Bit
Name
o
RIDPOST
RIDBUSY
1
2-7
Meaning
User Waiting for POST.
I/O Simulation in Progress.
Reserved for Future Use.
Byte 2
Reserved for Future Use.
2A
42
RIDTJID
2
Reserved for Future Use.
2C
44
RIDECB
4
AddresS of Internal Reader ECB.
30
48
RIDTCB
4
Address of Internal Reader TCB.
34
52
RIDDATA
80
Internal Reader Data Area.
24
36
DCTWORK
80
~unch
Error Recovery Save Area.
Device Control Table Format -- Page 8.5-10
555
HAS P
Figure 8.5.4 -- LINE DEVICE CONTROL TABLE FORMAT
Displacement
Hex.
o
Dec.
r-----------------------
0
------------------------~
DCTPCE
Address of Line Manager PCE
DCTSTAT
4
4 bytes
4
DCTBUFAD
Address of Line RJE Buffer
8
DCTDCB
8
Address of Line Data Control Block
DCTPSTAT
C
12
MDCTOBUF
RJE Output ·Buffer Chain Field
MDCTOPCT
10
14
16
DCTBUFCT
MDCTATTN
DCTDEVTP
DCTPCODE
Active
Buffer Count
Attention
Indicator
Device
Type
Line
Type
DCTCHAIN
20
DCTFLAGS
18
DCTDEVN
24
32
-
EBCDIC Device Name
I-
20
Address of Next Device Control Table
MDCTCODE
Address of RJE Code Table
24
36
MDCTFCS
Function Control Sequence
28
MDCTERCT
DCTPLINE
Error Count
Mode Byte
40
Device Control Table Format -- Page 8.5-11
556
HAS P
Figure 8.5.4 -- LINE DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
28
40
~-----------------------
4 bytes
------------------------~
MDCTDCT
Address of First Remote DCT Attached to this Line
2C
30
44
48
MDCTRSEQ
MDCTTSEQ
Receive
Sequence
Transmit
Sequence
MDCTPSWD
Line Password
38
RES E R V E D
-
56
Device Control Table Format -- Page 8.5-12
557
II ASP
Figure 8.5.4
Displacement
Hex. Dec.
0
0
~-
LINE DEVICE CONTROL TABLE FORMAT (CONTINUED)
Field Name
B:ltes
DCTSTAT
1
Field Descri}2tion
DCT Status -Bit
0
1
2-7
Name
Meaning
DCTINUSE DCT is In Use.
DCTDRAIN DCT is Drained.
Reserved.
0
0
DCTPCE
4
Address of Line Manager PCE.
4
4
DCTBUFAD
4
Address of Line RJE Buffer.
8
8
DCTPSTAT
1
Line Flags
Bit
Name
0
1
2
DCTLOGAL
DCTLEASE
DCTETX
DCTSOFF
3
4-7
Meaning
Log Every Channel End.
Leased Line.
An ETX has been Received.
A /*SIGNOFF Card has been
Processed.
Reserved for Future Use.
DCTDCB
4
Address of Line Data Control Block.
12
MDCTOPCT
1
MULTI-LEAVING Terminal Open Count.
C
12
MDCTOBUF
4
RJE Output Buffer Chain Field.
10
16
DCTBUFCT
1
Number of I/O Requests Outstanding.
11
17
MDCTATTN
1
Line Attention Requests --
8
8
C
Bit
Name
0
1
2
MDCTIMER
MDCTPAWS
MDCT JOBl
MDCTJOB2
MDCTJOB
3
2+3
4-7
Meaning
Timed Action Requested.
Line Pause Requested.
Job Post Indicator 1.
Job Post Indicator 2.
Job Post Indication.
Reserved for Future Use.
Device Control Table Format -- Page 8.5-13
558
II ASP
Figure 8.5.4 -- LINE DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
12
18
Field Name
Bytes
DCTDEVTP
1
Field Description
Device Type -Hex.
Value
02
13
19
DCTPCODE
1
Name
DCTLNE
Device Type
Line.
Line Type -Bit
o
Name
Value
o
DCTPBSC
1
1
o
DCTPTRSP
1
2
DCTPASCI
3
4-5
6
DCTPHASP
o
1
o
DCTPWIDE
1
7
14
20
DCTFLAGS
1
o
DCTPHALF
DCTPFULL
1
Meaning
STR Line.
BSC Line.
No Transparency.
Transparency.
EBCDIC Code.
USASCII Code.
Reserved.
Reserved.
Low-Speed Line.
Wide-Band Line.
Half-Duplex Line.
Full-Duplex Line.
Operator Command Flags
Bit
Name
0-1
2
3-7
DCTRSTRT
Command
Reserved.
$E ($RESTART) -- Abort.
Reserved.
14
20
DCTCHAIN
4
Address of Next Device Control Table.
18
24
DCTDEVN
8
EBCDIC Device Name.
20
32
MDCTCODE
4
Address of RJE Code Table.
24
36
MDCTFCS
2
Last Function Control Sequence Received.
26
38
MDCTERCT
1
Line Error Count/Indicator.
27
39
DCTPLINE
1
SDA Mode Byte.
28
40
MDCTDCT
4
Address of First Remote DCT Attached to
this Line.
Device Control Table Format -- Page 8.5-14
559
HAS P
Figure 8.5.4 -- LINE DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
Field Name
B~tes
Field Description
2C
44
MDCTRSEQ
I
Receive Block Sequence Count.
2D
45
MDCTTSEQ
I
Transmit Block Sequence Count.
2E
46
2
Reserved for Future Use.
30
48
8
Line Password.
MDCTPSWD
Device Control Table Format -- Page 8.5-15
560
HAS P
Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT
-----------------------~~
Displacement
Hex.
o
Dec.
r-----------------------DCTPCE
0
Address of Processor Control Element
DCTSTAT
4
4 bytes
4
DCTBUFAD
Address of Current RJE Buffer
8
DCTDCB
8
Address of Line Device Control Table
DCTPSTAT
C
DCTEWF
12
Address of Event Wait Field
10
16
DCTNO
RESERVED
14
Remote
Number
Device
Type
Remote
Code
Address of Next Device Control Table
DCTDEVN
24
20
DCTPCODE
DCTCHAIN
20
DCTFLAGS
18
DCTDEVTP
-
EBCDIC Device Name
32
REMOTE READERS AND REMOTE CONSOLES
20
24
32
DCTPRINT
DCTPUNCH
DCTPRINC
DCTPRLIM
Print
Destination
Punch
Destination
Priority
Increment
Priority
Limit
36
Device Control Table Format -- Page 8.5-16
561
HAS P
Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
~-----------------------
4 bytes
------------------------~
REMOTE PRINTERS AND REMOTE PUNCHES
20
32
DCTFORMS
Current Forms Type (Packed)
24
Flags
36
ALL REMOTE DEVICES
24
36
MDCTFCS
DCTPRLEN
Function Control Sequence
28
40
44
Remote
Remote
Printer Width Characteristics
MDCTDCT
MDCTRCB
2C
DCTPLINE
I
Address of Next DCT for this Remote
Device Control Table Format -- Page 8.5-17
562
HAS P
Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
o
o
Field Name
Bytes
DCTSTAT
1
Field Description
OCT Status -Bit
Name·
o
Meaning
DCTINUSE OCT is In Use.
DCTDRAIN OCT is Drained.
DCTHOLD OCT is Held.
1
2
3-7
Reserved.
o
o
DCTPCE
4
Address of Processor Control Element.
4
4
DCTBUFAD
4
Address of Current RJE Buffer.
8
8
DCTPSTAT
I
Remote Flags -Bit
I
Name
0-2
3
4
DCTEOF
DCTSIN(]'tJ
DCTPOST
DCTABORT
DCTPBUF
5
6
7
Meaning
Reserved for Future Use.
An EOF has been Detected.
OCT is Attached to Line OCT.
I/O Complete Flag.
Transmission was Aborted.
Remote has Output Buffer.
8
8
DCTDCB
4
Address of Line Device Control Table.
C
, 12
DCTEWF
4
Address of Event Wait Field.
10
16
1
Reserved -- Must be zero.
11
17
DCTNO
1
Remote Number.
12
18
DCTDEVTP
1
Device Type -.Hex.
Value
12
22
32
42
Name
Meaning
DCTRJR
DCTRPR
DCTRPU
DCTRC(]\J
Remote
Remote
Remote
Remote
Reader.
Printer.
Punch.
Console.
Device Control Table Format -- Page 8.5-18
563
HAS P
Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
13
19
Field Name
Bytes
DCTPCODE
1
Field Description
Remote Code -Bit
Name
o
1
2
I
3
4
5
6
7
14
20
DCTFLAGS
1
DCTPTRSP
DCTPPRES
DCTPCON
DCTPMRF
DCTPTAB
DCTPROG
DCTPVAR
DCTPBLK
Meaning
Reserved.
Terminal Transparency.
Hardware Compress Feature.
Terminal Console.
Multiple Record Feature.
Buffer Expansion, Additional.
Horizontal Format Control.
Programmable Interface.
Variable Length Records.
Blocked Records.
Buffer Expansion Feature.
Operator Command Flags -Bit
o
1
2
3
4
5
Name
DCTSTOP
DCTDELET·
DCTRSTRT
DCTRPT
DCTBKSP
DCTHOLDJ
DCTSPACE
2+4
6-7
Command
$Z ($STOP)
$C ($DELETE)
$E ($RESTART)
$N ($REPEAT)
$B ($BACKSPACE)
$F
$T ••• ,H
$T ••• ,C=l
$I
Reserved for Future Use.
14
20
DCTCHAIN
4
Address of Next Device Control Table.
18
24
DCTDEVN
8
EBCDIC Device Name.
20
32
DCTPRINT
1
Print Destination.
21
33
DCTPLNCH
1
punch Destination.
22
34
DCTPRINC
1
Priority Increment.
23
35
DCTPRLIM
1
Priority Limit.
Device Control Table Format -- Page 8.5-19
564
HAS P
Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex •. Dec.
20
32
22
34
Field Name
Bytes
DCTFORMS
2
Current Forms Type (Packed).
2
Flags
Byte 1
Field Description
Bit
Name
o
DCTFSPEC Special Forms Routing.
DCTFOPER Operator Controlled Forms.
1
2-7
Byte 2
Reserved for Future Use.
Bit
Name
o
2-7
36
MDCTFCS
2
Meaning
DCTtDSEP Generate Separator Page/Card.
DCTOPACT Operator Action Allowed.
1
24
Meaning
Reserved for Future Use.
Function Control Sequence Mask -Bit
Meaning
Byte 1
0-3
4
5
6
7
Reserved.
Reader 1 or Printer 1.
Reader 2, Printer 2, or Punch 7.
Reader 3, Printer 3, or Punch 6.
Reader 4, Printer 4, or Punch 5.
Byte 2
o
Reserved.
Remote Console.
Reserved.
Reader 5, Printer 5, or Punch 4.
Reader 6, Printer 6, or Punch 3.
Reader 7, Printer 7, or Punch 2.
Punch 1.
1
2- 3
4
5
6
7
26
38
OCTPRLEN
1
Remote Printer width and Remote Input Size.
27
39
OCTPLINE
1
Remote Characteristics --
Bits 0-3
Adapter/Terminal Characteristics
Bit
Name
Value
o
DCTPBSC
1
DCTPTRSP
2
DCTPASCI
0
1
0
1
0
1
3
Meaning
STR Adapter.
BSC Adapter.
No Transparency.
Transparency.
EBCDIC Code.
USASCI I Code.
Reserved.
Device Control Table Format -- Page 8.5-20
565
HAS P
Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
Remote Characteristics (continued) --
Bits 4-7
Terminal Type
Hex.
Value
6
8
A
40
MDCTRCB
1
o
1-3
4-7
Meaning
Always One.
Device Number.
Device Type -Value
1
2
3
4
5
40
MDCTDCT
4
2770, 3780, 1009.
2780, 1978.
360/20 Sub-ModelS, 6.
360/22, 25, 30, 40, etc.
360/20 Sub-Model 2, 4.
1130.
System/3.
Record Control Byte
Bits
28
Terminal Type
DCTP2770
DCTPHARD
DCTP20
DCTP360
DCTP20S2
DCTP:L:L30
DCTPSYS3
0
1
2
4
28
Name
Device Type
Output Console.
Input Console.
Reader.
Printer.
Punch.
Address of Next DCT for this Remote.
Device Control Table Format
566
~-
Page 8.5-21
HAS P
Figure 8.6.1 -- JOB QUEUE ELEMENT FORMAT
Displacement
Hex.
o
Dec.
0
r---- ---- ----------QUEPRIO
Priority
4
4
8
QUE TYPE
Queue Type
-~ --.--------- -- - - ,
QUEJOBNO
Job Number (Binary)
,
QUECHAIN
QUEFLAGS
8
-4 bytes -- --- --
Address of Next Job Queue Element
QUETRAK
Disk Address of Job Control Table
C
12
QUEPRTRT
Print Route
10
QUEPUNRT
Punch Route
QUECLASS
QUE FORMS
I
QUEREGSZ
16
Job Queue Element Format -- Page 8.6-1
567
HAS P
Figure 8.6.1 -- JOB QUEUE ELEMENT FORMAT (CONTINUED)
Displacement
Hex.
Pee.
o
o
Field Name
Bytes
Field Description
QUEPRIO
1
Queueing Priority
Bits 0-3
Bits 4-7
1
QUETYPE
1
Priority (O-lS).
Reserved.
Queue Type
Binary
Value
Name
1xxxxxxx
xlcccccc
QENTBY
$XEQ
xOlOOOOO
x0000100
xOOOOOlO
xOOOOOOO
$INPUT
$PRINT
$Pl,.NCH
$PURGE
Meaning
Queue Entry is In Use.
-cccccc = Job Class - X'CO'.
Input Queue.
Print Queue.
Punch Queue.
Purge Queue.
Ex~cution
2
2
QUEJOBNO
2
Job Number (Binary)
4
4
QUE FLAGS
1
Queue Flags -Bit
Name
o
QUEHOLDA
QUEHOLDl
QUEHOLD2
QUEPURGE
QUEUSECT
1
2
3
4-7
Meaning
Job Held ($H A)
Job Held (Single Job)
Job Held (Duplicate Job Name) .
Job Deleted.
Entry Use Count.
4
4
QUECHAIN
4
Address of Next Job Queue Element.
8
8
QUETRAK
4
Track Address of Job Control Table.
C
12
QUEPRTRT
1
Print Routing:
D
13
QUEPUNRT
1
Punch Routing:
0
n
0
n
= Local.
=
Remote n.
=
Local.
Remote n.
E
14
QUECLASS
1
Sub-Class -- Unused.
E
14
QUE FORMS
2
Forms Code (Packed).
F
15
QUEREGSZ
1
Region Size -- Unused.
Job Queue Element Format -- Page 8.6-2
568
HAS P
Figure 8.7.1
Displacement
Hex.
Dec.
o
o
~OB
INFORMATION TABLE ELEMENT FORMAT
I~~-----.----------------' ,
4 byte.s
.
-
8
Displacement
Hex. Dec.
o
.
JITJNAME
Job Name
8
,. '1
------------------------
o
Field Name
Bytes
JITJNAME
8
)
Field Description
Job Name.
Job Information Table Element Format .... - Page 8.7-1
569
HAS P
Fi9ure8~8~1
-~
JOB CONTROL TABLE FORMAT
Displac;:ement
Hex.
Dec.
50
80
r------------------------
84
JCTJOBNO
I
AdQress of Processor Control Element
Job Number (Binary)
58
------------------------~
JCTPCE
JCTID
54
4 bytes
88
JCTPRIO
JCTROUTE
Priority
Input
Route Code
JCTPNAML
JCTJOBEB
Job Number (EBCDIC)
5C
Programmer's
Name Length
JCTPNAME
92
-
-
-
Programmer's Name from Job Card
70
-
-
-
-
JCTJNAME
112
r-
78
Job Name from Job Card
-
120
Job Control Table Format -- Page 8.8-1
570
HAS P
Figure 8.8.l -- JOB CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
78
120
~--------------------~--
4 bytes
-----~------------------1·
JCTACCTN
Job A9counting Number
7C
124
JCTROOMN
,.
Programmer's Room Number
80
128
JCTETIME
Estimated Execution Time
84
132
JCtCARDS
Number of Input Cards
88
136
JCTESTLN
Estimated Lines of Output
8C
140
JCTlINES
Current Lines of Output
90
144
JCTESTPU
Estimated Number. of Cards to be Punched
94
148
JCTPUNc'H
Current Output Card Count
98
9C
152
156
JCTlINCT
JCTCPYCT
Lines
Per PQge
Print
Copy Count
JCTlOG
Log Option
Switch
JCTFlAGS
Miscellaneous
Flags
..
JCTFORMS
Job Print Forms
AO
160·
Job Control Table Format -- Page 8.8-2
571
HAS P
Figure 8.8.1
Displacement
Hex.
Dec.
AO
160
JOB CONTROL TABLE FORMAT (CONTINUED)
~-----------------------
4 bytes
------------------------~
Job Punch Forms
A4
164
JCTPRTCT
Current Number of Lines Printed
A8
168
JCTPAGCT
Current Number of
AC
172
P~ges
Printed
JCTPUNCT
Current Number of Cards Punched
BO
176
JCTRDRON
Reader Sign-On Time
B4
180
JCTRDROF
Reader Sign-Off Time
B8
184
JCTXEQON
Execution Sign-On Time
BC
188
JCTXEQOF
Execution Sign-Off Time
CO
192
JCTPRTON
Printer Sign-On Time
C4
196
JCTPRTOF
Printer Sign-Off Time
C8
200
Job Control Table Format -- Page 8.e-3
572
HAS P
Figure 8.8.1 -- JOB CONTROL TABLE )~'ORMAT (CONT.I:NUED)
Displacement
Hex.' Dec.
C8
_I.----------_-~-----------
4 bytes ________________,___-_____
I"
200
..~".
.
J,
-I
. JCTPUNON
Punch Sign-On Time
CC
204
JCTPUNOF
Punch Sign-Off Time
DO
208
JCTPRC
Checkpoint
Copy Count
Checkpoint PDDB Displacement
Checkpoint PDDB Page Count
Checkpoint Total Line Count
Checkpoint Total Line Count
(continued)
Checkpoint Total Page Count
Checkpoint
Flags
D4
D8
212
216
"
DC
220
Checkpoint Total Page COunt
.,
(continued)
First Reader Track
JCTRDRTR
EO
224
' ....
.,
,
JCTCYSAV
I n p ut File T rae k Allo c a tion Bit Map S ave Area
' ...
JCTCYMXM'
Maximum MTTR for Current Track Group
. JCTMTTR
Last MTTR Allocated
Job Control
573
~~ble
Format -- Page 8.8-4
BAS P
Figure
8.8.~
Displacement
Hex.
Dec.
-- JOB CONTROL TABLE FORMAT (CONT1NUED)
~-----------------------
4 bytes
----------------~-------~
JCTCYMAP
1
1
Variable Length Track Allocation Bit Map
JCTACCT
l32-Byte Job Accounting Information Area
'r-
"~
JCTPDDB .
JCTLPDDB
HASP System Log PDOB
~
JCTSPDDB
System Message Block (SMB) PDDB
' ....
pe.-r_._l.p_h_e_r_a_l-. .D_a_t_a~D-e-f-1.-n-1.-t-1.-o-n_B_l_O_C_k
11...____
"
--'J
__
(P_D_D_B_)_A_r_e_a_ _ _
Job Control Table Format -- Page 8.8-5
574
l~
ASP
Figure 8.8.1 -- JOB CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
50
80
JCTID
1
JCT Identification -- XfFF'.
5-0
80
JCTPCE
4
Address of Processor Control Element.
54
84
JCTJOBNO
2
Job Number (Binary).
56
86
JCTPRIO
1
Priority from /*PRIORITY Card.
57
87
JCTROUTE
1
Route Code of Input Device:
0
n
Local.
= Remote n.
58
88
JCTJOBEB
3
Job Number (EBCDIC).
5B
91
JCTPNAMl
1
Length of Programmer's Name.
5C
92
JCTPNAME
20
70
112
JCTJNAME
8
Job Name from Job Card.
78
120
JCTACCTN
4
Job Accounting Number.
7C
124
JCTROOMN
4
Programmer's Room Number.
80
128
JCTETIME
4
Estimated Execution Time.
84
132
JCTCARDS
4
Number of Input Cards.··
88
136
JCTESTLN
4
Estimated Lines of Output.
8C
140
JCTlINES
4
Generated Lines of Output.
90
144
JCTESTPU
4
Estimated Number of Cards to be Punched.
94
148
JCTPUNCH
4
Number of Output Cards Generated.
98
152
JCTlINCT
1
Lines per Page.
99
153
JCTCPYCT
1
Number of Copies of Print.
9A
154
JCTlOG
i
Log Option Switch --
Programmer's Name from Job Card.
EBCDIC
Va1~e
L
N
Meaning
Produce HASP SYSTEM LOG.
Do not Produce HASP SYSTEM LOG.
Job Control Table Format -- Page 8.8-6
,575
HAS P
Figure 8.8.1 -- JOB CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
9B
155
Field Name
Bytes
JCTFLAGS
1
Field Description
Miscellaneous Flags --
Bit
Name
o
JCTDSRT
1-7
9C
156
AO
160
A4
164
A8
JCTFORMS
Meaning
Processing Special Forms.
Count of Input Data Set$
SPOOLed by HASP.
4
Job Print Forms.
4
Job Punch Forms.
JCTPRTCT
4
Number of Lines Printed.
168
JCTPAGCT
4
Number of Pages Printed.
AC
172
JCTPUNCT
4
Number of Cards Punched.
BO
176
JCTRDRON
4
Reader Sign-On Time.
B4
180
JCTRDROF
4
Reader Sign-Off Time.
B8
184
JCTXEQON
4
Execution Sign-On Time.
BC
188
JCTXEQOF
4
Execution Sign-Off Time.
co
192
JCTPRTON
4
Print Sign-On Time.
C4
196
JCTPRTOF
4
Print Sign-Off Time.
C8
200
JCTPUNON
4
Punch Sign-On Time.
CC
204
JCTPUNOF
4
Punch Sign-Off Time.
DO
208
JCTPRC
DC
220
JCTRDRTR
EO
224
JCTCYSAV
14
4
Print Checkpoint Element.
First Reader Track.
Variable Length Input File
Track Allocation Bit Map Save Area.
JCTCYMXM
4
Maximum MTTR for Current Track Group.
JCTMTTR
4
Last MTTR Allocated.
JCTCYMAP
Variable Length Track Allocation Bit Map.
Job Control Table Format -- Page 8.8-7
576
HAS P
Figure 8.8.1 -- JOB CONTROL TABLE FORMAT (CONTINUED)
Displacement
Hex. Dec.
Field Name
JCTACCT
Bytes
Field Description
132
Job Accounting Information Area.
JCTPDDB
Peripheral Data Definition Block (PDDB) Area.
JCTLPDDB
5
HASP System Log PDDB.
JtTSPDDB
5
System Message Block (SMB) PDDB.
Job Control Table Format -- Page 8.8-8
577
HAS P
Figure 8.9.1 -- TRACK EXTENT DATA TABLE FORMAT
Displacement
Hex.
o
Dec.
0
~-----------------------
4 bytes
------------------------~
TNCH
MTTR For Most Recent $EXCP on this Module
4
4
TNTC
Number of Tracks per Cylinder on this Device
8
8
TNMD
TNRT
DEB Extent Number
(times 256)
C
10
12
16
Number of HASP
Buffers per Track
TNGE
TNTG
Number of Groups/Extent
Number of Tracks/Group
TNMO
TNMB
Offset of this Map
from First Map
14
Number of Bytes
in this Map
20
Displacement
Hex. Dec.
Field Name
Bytes
Field DescriEtion
0
0
TNCH
4
MTTR for Most Recent $EXCP on this Module.
4
4
TNTC
4
Number of Tracks per Cylinder on this Device.
8
8
TNMD
2
DEB Extent Number (times 256).
A
10
TNRT
2
Number of HASP Buffers per Track.
C
12
TNGE
2
Number of Track Groups per Extent.
E
14
TNTG
2
Number of Tracks per Track Group.
10
16
TNMO
2
Offset of This Map from First Map.
12
18
TNMB
2
Number of Bytes in This Map.
Track Extent Data Table Format -- Page 8.9-1
578
HAS P
Figure 8.10.1 -- TIMER QUEUE ELEMENT
DisPlacement~ _______________________
Hex.
o
Dec.
0
4
bytes
I
",.,
,
--~--~~-------------~--~
ICHAIN
Address of Next HASP Timer Queue Element
4
4
ITIME
Specified Interval
8
8
IPOST
Address of Event Wait Field to be Posted
C
12
Displacement
Hex. Dec.
Field Name
Bytes
Field Description
o
o
ICHAIN
4
Address of Next HASP Timer Queue Element.
4
4
ITIME
4
Timer Interval.
8
8
I POST
4
Byte 1
Flag Byte --
o
0
1
1-7
Bytes 2-4
Timer Interval has not Expired.
Timer Interval has Expired.
Reserved.
Address' of Event wait Field to be Posted.
Timer" Queue Element Format -- Page 8.10-1
579
HAS P
Figure 8.11.1 -- OVERLAY TABLE FORMAT
Displacement
Hex.
Dec.
~----------------------&DEBUG
o
o
OTBPRIO
o
0
------------------------~
= NO
OTBADDR
&DEBUG
4 bytes
Address of Resident Overlay Module
I
RESERVED
I
OTBTRAK
Relative TTR
YES
OTBNAME
Overlay Module Name (Last Four Characters)
4
4
OTBADDR
OTBPRIO
8
8
Address of Resident Overlay Module
I
RESERVED
Relative TTR
OTBLODS
OTBCALLS
Count of PCE Requests
C
OTBTRAK
Count of Times Loaded
12
Overlay Table Format -- Page 8.11-1
580
HAS P
Figure 8.11.1 -- OVERLAY TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
o
o
Field Name
Bytes
OTBADDR
4
Byte 1
Bytes 2-4
o
o
1
1
2
2
0
OTBPRIO
Field Description
Address of Resident Overlay Module'.
X'FF' .
Addressability Address of Resident
Overlay Module -- Assembly Origin - X'50'.
1
Priority of Overlay Module.
1
Reserved for Future Use.
OTBTRAK
2
Relati ve Track and Record Address o,f
Overlay Module.
a
OTBNAME
4
Last Four Characters of Overlay Module Name.
8
8
OTBCALLS
2
Number of Times This Overlay Module
was Requested.
A
la,
OTBLODS
2
Number of Times This Overlay Module
was Loaded.
Overlay Table Format -- Page 8.11-2
,581
HAS P
r
Figure 8.12.1 -- DATA DEFINITION TABLE FORMAT
Dise1acernent
Hex.
Dec.
.
--
--
o
0
4 bytes ------------------------~
.
DDBCHAIN
Address of Next Data Definition Table
4
DDBUNIT
DDBTYPE
4
unit Address
Data Set Type
8
DDBSTAT2
DDBSTATl
(XS)
8
Status Byte 1
C
Status Byte 2
(EBCDIC)
DDBUFPTR
Current Buffer Pointer
DDBPBUF
12
Address of Primary Buffer or TTR
10
DDBSBUF
16
Address of Secondary Buffer ( Input)
DDBFORMS
r-
Special Forms Type
18
24
28
32
(Input Data Sets)
(Output Data Sets)
DDBCOUNT
Output Record Count
20
-
DDBTTR
Next Track Address
First Track Address
1C
(Output)
RES E R V E D
DDBPCE
Address of Processor Control Element
24
36
Data Definition Table Format -- Page 8.12-1
582
HAS P
Figure 8.12.1 -- DATA DEFINITION TABLE .FORMAT.
Displacement
Hex.
Dec.
Field Name
Bytes
(CONTI~UED)
Field Definition
o
o
DDBCHAIN
4
Address of Next Data Definition Table.
4
4
DDBTYPE
1
Data Set Type -Hex.
Value
01
02
04
08
10
40
80
Name
XSPROUTE
XPRTDDB
XPUNDDB
XPLOTDDB
XLOGDDB
XNULLDDB
XINDDB
Data Set Type
Special Route SYSOUT.
Print.
Punch.
Plot.
Log.
Dummy (Null).
Input.
5
5
DDBLl'JIT
3
unit Address (EBCDIC).
8
8
DDBSTATl
(XS)
I
Status Byte 1
Bit
o
I
2
3
4
5
6
7
9
9
DDBSTAT2
I
Name
XSEOD
XSIOA
XSIO
XNSB
XPEOD
XPIOA
XPIO
XNPB
Meaning
End of Data on Secondary.
I/O Active on Secondary.
I/O Required on Secondary.
No Secondary Buffer.
End of Data on Primary.
I/O Active on Primary.
I/O Required on Primary.
No Primary Buffer.
Status Byte 2
Bit
o
I
2
3
4
5
6
7
Name
XACT
XLOGHEAD
XOPEN
XUCB
XIOC
XROLL
XTERM
Data Definition
583
Tab1~
Meaning
Action Required on This DDT.
Reserved for Future Use.
Log Title Switch.
DDT has been Used.
Allocatable UCB Exists.
I/O Error on Read.
Roll Output Buffer.
Terminate DDT.
For~at
-- Page 8.12-2
HAS P
Figure
8~12.1
Displacement
Hex.' Dec.
-- DATA DEFINITION TABLE FORMAT (CONTINUED)
Field Name
Bytes
Field Description
A
10
DDBUFPTR
2
Current Displacement of Data in
Primary Buffer.
e
12
DDBPBUF
4
Address of Primary Buffer -- Or TTR
if No Primary Buffer.
lO
16
DDBSBUF
4
Address of Secondary Buffer (Input Only) .
10
16
DDBFORMS
8
Special Forms Type (Output Only) .
18
24
DDBTTR
4
Input: Next Track Address.
Output: First Track Ad~ress.
Ie
28
DDBCOLI'JT
2
Output Record Count.
lE
30
2
Reserved for Future Use.
20
32
4
Add~ess
DDBPCE
of Processor
Cont~ol
Element.
Data Definition Table Format -- Page 8.12-3
584
HAS P
Figure 8.13.1 -- PARTITION· INFORMATION T.ABLE.' FORMAT
D:::~ac:::~t ~--"'---~--~--------~---~_4bYteS.--------------------"~--:
o
PITSTAT
0
PITICLAS
Status Byte
,
4
4
Ini tiator .'
Class
PITPATID
Logical' Parti tiort
Identification
, :> "
PITSIZE
PITPRIO
Logical Partition Size
Logical Partition PRTY
.
;
,
WITH EXECUTION JOB BATCHING
8
PITBECB
8
Batching Program Frozen ECB Chain
C
PITBJST
12
Address of Batching Program TCB
10
16
PITBCLAS
~ctive
Batching
Class
14
PITBUNIT
Batching Program Input Unit
PITBUCBA
20
PITCLASS
Batching Input UCB Address
-
"-
Var1able Number of Log1cal Part1t10n Classes
1
"
J
Parti tio.n Informati,on Table Format
5'85
-~
Page 8.13-1
Ii ASP
Fig~re
8.13.1 -- PARTITION INFORMATION TABLE FORMAT (CONTINUED)
. Rex.
Dec.
r----------------".-----WITHOU~
8
8j
EXECU~ION
4 l1ytes
---------,..--------------1
JOB BATCHING
PITCLASS
Vari~ble
Number of Logic?l Partition Classes
1
I
J
Pa~tition
Information Table Format -- Page 8.13-2
586
HAS P
Figure 8.13.1 -- PARTITION INFORMATION TABLE FORMAT (CONTINUED)
Displacement
Hex.
Dec.
o
o
Field Name
Bytes
PITSTAT
1
Field Description
Status Byte -Bit
Name
o
PITHOLDA
PITHOLDl
PITBUSY
PITIDLE
1
2
3
4-6
7
PITLAST
Meaning
PIT is Drained ($p I).
PIT is Drained ($p In).
Partition Busy Indicator.
PIT Idle Message Switch.
Reserved for Future Use.
Last PIT Indicator.
1
1
PITICLAS
1
O/S Initiator Class.
2
2
PITPATID
2
Logical Partition Identification.
4
4
PITSIZE
2
Logical Partition Size (Unused).
6
6
PITPRIO
2
Logical Partition PRTY.
8
8
PITBECB
4
Batching Program Frozen ECB Chain.
c
.12
PITBJST
4
Address of Batching Program TCB.
10
16
PITBCLAS
1
Active Batching Class.
11
17
PITBUNIT
3
Batching Program Input Unit.
14
20
PITBUCBA
2
Batching Input unit Control Block (UeB)
Address.
PITCLASS
variable Number of Logical Partition
Classes.
Partition Information Table Format -- Page 8.13-3
587
H 'A S P
Figure 8.14.1 -- MESSAGE ALLOCATION CONTROL BLOCK
Displacement
Hex.
Dec.
o
o
~-----------------------
4 bytes
------------------------~
MSAMTTR
Base SPOOL Record Pointer
4
MSARPTRK
4
MSABITS
Number of Records/Track
-
...
I
Dis}2lacement
Hex. Dec.
Variable Length Allocation Bit Map
J
Field Name
B:i tes
Field
De~criEtion
0
0
MSAMTTR
4
Base SPOOL Record Pointer.
4
4
MSAPTRK
2
Number of Records/Track.
6
6
MSABITS
Variable Length Allocation Bit Map.
Message Allocation Control Block Format -- Page 8.14-1
588
HAS P
Figure 8.15.1 -- DATA BLOCK FORMAT
Displacement
Hex.
Dec.
50
80
~-----------~-----------
4, bytes ---------.:..---"-----------.
HDBNXTRK
'Track Address of Next Data Block
54
HDBSTART
84
Record
Length
Control
Byte
,
...
Variable Length Data Area
"'"
'!'-
f-
Record
Length
Control
Byte
....
Var~able
Record
Length
Length Data Area
"
Control
Byte
....
....
Variable Length Data Area
. Block
Terminator
)
Unused
t
1L--,-_ _ _ _ _------lJ
Data Block Format -- ,Page 8.15-1
589
Ii
ASP
Figure 8.15.1 -- DATA BLOCK FORMAT (CONTINUED)
Displacement
Hex.
Dec.
Field Name
Bytes
'4
50
80
HDBNXTRK
.54
84
HDBSTART
Field Description
Track Address of Next Data Block.
Start of Data Block .
Record
Length
1
Length of Data Area (0-254).
Control
Byte
1
.Control Byte -Input Data Sets
Hex.
Value
00
03
04
13
19
73
Data
Area
Block
Terminator
Meaning
Normal Record.
Internally Generated Card.
HASP Control Card.
Illegal HASP Control Card.
Last JCL Card.
Dummy Track Address Record.
Print Data Sets
Carriage Control.
Punch Data Sets
Stacker Select.
Variable Length Data Area.
Record Length of 255 (X'FF').
Data Block Format -- Page 8.15-2
590
HAS P
9.0
HASP EXECUTOR SERVICES
The HASP Control Service Programs provide a comprehensive set of
services which aid the HASP Processors in performing their respective tasks in an efficient manner without burdening the processor
programmer down with endless detail.
These services are requested
by the processor through the use of HASP macro instructions.
The
services are subdivided in this publication, as follows:
•
Buffer Services, which provide for the acquisition and release
of HASP buffers.
•
Unit Services, which provide for the acquisition and release
of HASP Input/Output units.
•
Jqb Queue Servides, which provide the.processors. with an
interface with the HASP JobQueue~
•
Direct Access Space Services, which provide for the allocation
and de-allocation of HASP direct-access s·tor-age space.
•
Input/Output Services, which provide all communication with
the Operating System Input/Output Supervisor .
...
•
Time Services, which provide for the setting and interrogation
of the interval timer.
•
Overlay Services, which provide the capability to define and
utilize sections of HASP that may optionally be made resident
on direct-access storage and fetched into a dynamic area
within HASP whenever required.
•
Synchronization Services, which provide synchronization and
communication between HASP processors,the HASP dispatcher,
and the Operating System.
•
Debug Services, which provide' facilities for aid in debugging
HASP.
•
Error Services, which provide a uniform way of processing
detected errors.
•
Coding Aid Services, which provide the HA.SP progranuner with
coding aids not usually available in the Operating System,
but useful in coding HASP routines.
Some of the above services are provided by "in-line" code expansion
wherever the macro instruction is used.
The remainder of the services are provided by routines which are integral parts of the
Control Service Programs.
For more information about these routines refer to Section 5. These routines are "linked to" by code
generated wherever the macro instruction is used.
HASP Executor Services - Page 9.0-1
591
HAS P
At execution time, the macro-expansion passes information to the
control program ~outine to specify the exact nature of the service
to be performed., This information is broken down into parameters
and, in general, is passed to the routine through general purpose
registers called parameter registers.
The macro-expansion can contain load instructions (LA,L,LH,etc.)
that form parameters in parameter registers, and/or it can contain
instructions which load parameter registers from registers loaded
by the processor.
The processor can also load parameters directly.
Registers "RI" and "RO" are generally used as parameter registers.
Each parameter resulting from the expansion of a macro-instruction
is either an address or a value.
ADDRESS PARAMETER: An address parameter is a standard 24-bit
address.
It is always located in the three low-order bytes of a
parameter register.
The high-order byte in the parameter register
should ~ontain all zeros. Any exception to this rule will be stated
in the individual macro-instruction description.
An address parameter is always an effective ~ddress.
The Control
Service Programs is never given a 16-bit or 20-bit explicit address
of the form D(B) or D(B,X) and then required to form an effective
address. Whe·n an effective address is to be resolved, it is formed
either by the macro-expansion or before the macro-instruction is
issued.
VALUE PARAMETER:
A value parameter is a field of data other than
an address.
It is of variable length, and is usually in the loworder bits of a parameter register.
The value parameter will always
have a binary format.
The high-order unused bits in the parameter
register should contain all zeros. Any exception to this rule will
be stated in the individual macro-instruction description.
Certain value parameters can be placed in a register along with
another parameter, which can either be an address or a value
parameter.
In this case, a value parameter will be in other than
the low-order bits. Two or more parameters in the same register
are called packed parameters.
OPERANDS:
Parameters are specified by operands in the
macro-instruction. An address parameter can result from a relocatable expression or, in certain macro-instructions, from an
implied or explicit address. A value parameter can result from an
absolute expression or a specific character string. Address and
value parameters can both be specified by operands written as an
absolute expression enclosed in parentheses. This operand form is
called register notation.
The value of the expression designates
a register into which the specified parameter must be loaded by the
processor before macro-instruction is issued. The contents of this
register are then placed in a parameter register by the macro-expansion.
HASP Executor Services 592
Page 9.0-2
HAS P
Types of Macro-Instruction Operands
The processor programmer writes operands in a HASP macro-,instruction
to specify the exact nature of the service to be performed.
Operands
are of two types:
positional and keyword.
POSITIONAL OPERANDS:
A positional operand is written as a string
of characters. This character string can be an expression, an implied or explicit address, or some special operand form allowed in
a particular macro-instruction.
positional operands must be written in a specific order.
If a positional operand is omitted and another positional operand is written
to the right of it, the comma that would normally have preceded the
omitted operand must be written. This comma should be written only
if followed by a positional operand; it need not be written if it .
would be followed by a keyword operand or a blank.
In the following examples, EXI has three positional operands.
In
EX2, the second of three positional operands is omitted, but must
still be delimited by commas.
In EX3, the first and third operands
are omitted; n9 comma need be written to the right of the second
operand.
EXI
$ EXAMP
A,B,C
EX2
$EXAMP
A, ,C
EX3
$EXAMP
,B
KEYWORD OPERANDS:
A keyword operand is written as a keyword
immediately followed by an equal sign and an optional value.
A keyword consists of one through seven letters and digits, the.
first of which must be a letter.
It must be written exactly as
shown in the macro-instruciton description.
An optional value is written as a character string in the same way
as a positional operand.
Keyword operands can be written in any order, but they.must be
written to the right of any positional operands in the macro-instruction.
In the following examples, EXI shows two keyword operands.
EX2 shows
the keyword operands written in a different order and to the right
of any positional operands.
In EX3, the second and third positional
operands are omitted; they need not be delimited by commas, because
they are not followed by any positional operands.
HASP Executor Services -
Page 9·.0-3
HAS P
EXl,
$EXAMP
KWl=X,KW2=Y
EX2
$ EXAMP
A,B,C,KW2=Y,KWl=X
EX3
$ EXAMP
A,KWl=X,KW2=Y
REQUIRED AND OPTIONAL OPERANDS: Certain operands are required in
a macro-instruction, if the macro-instruction is to make a meaningful request for a HASP executor service. Other operands are optional,
and can be omitted. Whether an operand is required or optional is
indicated in 'the macro-instruction descriptions.
9.0.1
BASIC NOTATION USED TO DESCRIBE MACRO-INSTRUCTIONS
HASP macro-instructions are presented in this section by means of
macro-instruction descriptions, each of which contains an illustration of the macro-instruction format.
This illustration is called
,a format description. An example of a format description is as
follows:
[symbol]
$ EXAMP
namel-value mnemonic,name2-CODED VALUE,
KEYWDl=value
mnemonic,KEYW~2=CODED
VALUE
Operand representations in format descriptions contain the following
elements:
•
An operand name, which is a single mnemonic word used to
refer to the operand.
In the case of a keyword operand, the
keyword is the name.
In the case of a positional operand,
the name is merely a reference.
In the above format description, namel, name2, KEYWDl, and KEYWD2 are operand names.
•
A value mnemonic, which is a mnemonic used to indicate how
the operand should be written, if it is not written as a coded
value. For example, addr is a value mnemonic that specified
that an operand or optional value is to be 'written as either
a relocatable expression or register notation.
•
A coded value, which is a character string that is to be
written exactly as it is shown.
For example, RDR is a coded
value.
The format description also specifies when single operands and
combinations of operands should be written. This information is
indicated by notational elements called metasymbols.
For example,
in the preceding format description, the brackets around "symbol"
indicate that a symbol in this field is optional.
HASP Executor Services - Page 9.0-4
594
HAS P
Operand Representation
Positional operands are represented in format descriptions in one
of two ways:
•
By a three-part structure consisting of an operand name,
a hyphen, and a value mnemonic.
For example:
namel-addr.
•
By a three-part structure consisting of an operand name,
a hyphen, and a coded value.
For example: namel-RDR.
Keyword operands are represented in format descriptions in one of
two ways:
•
By a three-part structure consisting of a keyword, an equal
sign, and a value mnemonic.
For example: KEYWDl=addr.
•
By a three-part structure consisting of a keyword, an equal
sign, and a coded value.
For example: KEYWDl=RDR.
The most significant characteristic of an operand representation
is whether a value mnemonic or coded value is used; these two
cases are discussed below.
Operands with Value Mnemonics
When a keyword operand is represented by:
KEYWORD=value mnemonic
the programmer first writes the keyword and the equal sign, and
then a value of one of the forms specified by the value mnemonic.
When a positional operand is represented by:
name-value mnemonic
the programmer writes only a value of one of. the forms specified
by the value mnemonic.
The operand name is merely a means of
referring to the operand in the format description; the hyphen
simply separates the name from the value mnemonic.
Neither is
written.
The following general rule applies to the interpretation of operand
representations in a format description; anything shown in upper~
case letters must be written exactly as shown; anything shown in
lower-case letters is to be replaced with a value provided by the
programmer.
Thus, in the case of a keyword operand, the keyword
and equal sign are written as shown, and the value mnemonic is
replaced.
In the case of a positional operand, the entire
representation is replaced.
HASP Executor Services 595
Page 9.0-5
HAS P
VALUE MNEMONICS:
,The value mnemonics listed ,below specify most
of the ,allowable operand forms that can be written in HASP macroinstructions. Other value mnemonics, which are rarely used, are
defined in individual macro-instruction descriptions.
•
symbol
•
relexp
the operand can be written as a relocatable
expression.
•
addr
-- the operand can be written as (1) a relocatable
expression, or (2) register notation designating a register
that contains an address in its three low order bytes.
The
designated register must be one of the registers 2 through
12, unless special, register notation is used.
(Refer to
Section 9.0.2: Special Register Notation.)
•
addrx -- the operand can be written as (1) an indexed or
nonindexed implied or explicit address, or (2) register
notation designating a register that contains an address in
its three low-order bytes. An explicit address must be
written as in the RX form of an assembler language instruction.
•
adval -- the operand can be written as (1) an indexed or
nonindexed impl~ed or explicit address, or (2) register
notation designating a register that contains a value. An
explicit address must be written as in the RX form of an
assembler language instruction.
•
•
absex}2
the operand can be written as a symbol.
the operand can be written as an absolute expression.
the operand can be written as (1) an absolute expresor (2) register notation designating a register that contains a value in its three low-order bytes.
value
i
s~on,
•
text
-- the operand can be 'written as a character constant
as in a DC data definition instruction.
The format description
shows explicitly if the character constant is to be enclosed
in single quotation marks.
•
code
-- the operand can be written as one 'of a large set of
coded values; these values are defined in the macro-instruction
description.
Coded Value Operands
Some operands are' not represented in format descriptions by value
mnemonics.
Instead, they are represented by one or more upper-case
character strings that show exactly how the operand should be written.
These character strings are called coded values, and the operands
for which they are written are called coded value operands.
HASP Executor Services -- Page 9.0-6
596
HAS P
A coded value operand results in either a specific value pa.
or a specific sequence of executable instructions.
If a positional operand can be written as anyone of two or
coded values, all possible coded values are listed and are set
by vertical stroke indicating -that only one of the values is , address, and length of the record to'be
written.
If register notation is used, the appropriate address must
have been loaded into the designated register before the
execution of this macro-instruction.
Input/Output Services - Page 9.5-2
616
HAS P
OLAY~YES
must be specified if the $EXTP macro-instruction is coded
physically within an overlay segment.
Input/Output Services - Page 9.5-3
617
HAS P
9.5.3
$WTO - HASP Write to·Operator
The$WTO macro-instruction inifiates·output activlty on one or
more of the devices de.·signated as operator consoles.
Format Description - Standard Form:
[symbol]
$WTO
message-addrx}
{ (Rl)
{le.ngth-value}
'(RO)
YES] [ ' WA~T=NO.
YES] [ ' CONVERT=NO
YES]
[ . ' JOB=NO
. [,ROUTE=code] [,CLASS=code] [,PRI=code]
Format Description - Execute Form:
[symbol]
.
$WTO
{7~~)~ge-ad~rx}
[
len.
(RO)gth-value]
~.,1F-~ (E ,name )
,!
Formatqescription - List Form:
$WTO
[name]
[ , length-value,] HF=L
['JOB=~~S] [WAIT=~~S] [CONVERT=~~SJ
[ , ROUTE=code]
[, CLASS=code]
[, PRI=code]
message
specifies the address of a message which is to be written
on the designated console(s).
If register notation is used, the address must have been
loaded into the designated register before the execution
of this macro-instruction.
length.
specifies the length of the above message.
If register notation is used, the value must have been
load~d in~o the low-order byte of the designated register
before the execution of the macro-instruction. ·The rest
of the register must be zero unless the message is being
sent to·,a·
remote r terminal (see below) .
-'
~'
NOTE:. When using the Execute and List forms of the macroinstruction, the length can be specified on either form
but mus't not be specified on both.
Il1put/Output Services - Page 9.5-4
618
HAS P
JOB
specifies whether the characters "lJOB nnn" will be appended
to the start of the message as follows:
YES - The job number will be appended to the start of
the message.
NO -- The job number will not b~ appended to the
message.
If this operand is omitted, JOa=YES will be assumed.
CAUTION:
Unless JOB=NO is specified, the JCT register must
be loaded with the address of the Job Control Table before
the execution of this macro-instruction or the job number
printed will be unpredictable.
WAIT
specifies the action to be taken in the event no Console
Message Buffers are available as follows:
YES - Return will not be made until a Console Message
Buffer has become available and the message has
been queued.
NO - An immediate return will always be made with the
condition code set as follows:
CC=O - No Console Message Buffers were available. The message was not accepted
and the macro-instruction must be
re-issued.
CC~O - The message was accepted.
If this operand is omitted, WAIT=YES will be assumed.
NOTE:
Unless WAIT=NO is specified, the message to be issued
must be constructed in a re-e"nterable area of storage.
CAUTION: WAIT=NO must be specified if the $WTO macroinstruction is coded physically within an overlay s~gment.
CONVERT
specifies the type of consoles indicated as follows:
.
YES - Logical Consoles have been specified (e.g., $LOG)
and these must be converted to physical consoles
by the Control Service Program.
NO - Physical Consoles have been specified and no
conversion is necessary.
If this operand is omitted, CONVERT=YES will be assumed.
Input/Output Services - Page 9.5-5
619
HAS P
ROUTE
specifies the console or consoles on which the above
message is to be written.
The code consists of the
absolute sum of one or more of the Logical Console
designations in the' following list:
Designation
Console Specified
$LOG
System Log Console(s)
$ERR
Error Console(s)
SUR
unit Record operations area
$TP
Teleprocessing operations area
$TAPE
Tape operations area
$MAIN
Chief Operator's area
$OS
OS Message Console(s)
$ALL
All of the above Consoles
$ REMOTE
Remote Terminal Console
NOTE:
If "$REMOTE" is specified, no other consoles should
be specified, the register form of "length" must be
specified, and the remote terminal number must be loaded
into bits 16-23 of the register used to specify the length
before the execution of the macro-instruction.
Bits 0-15
of this register must be zero.
If no ROUTE is specified, the "$LOG" console will be assumed.
CAUTION:
The designation "$ALL" should not be used in
conjunction with any other console but should be specified
alone.
Failure to observe this rule will give unpredict~
able results.
CLASS
specifies the class of the message as one of £he following:
$ALWAYS- The message should always be written.
$ACTION - The message requires operator action.
$NORMAL - The message is considered essential to
normal computer operations.
$TRIVIA - The message is considered non-essential
to normal computer operations.
If no CLASS is specified, $NORMAL will be assumed.
Input/Output Services - Page 9.5-6
620
HAS P
PRI
specifies the priority of the message as one of
following:
,
$HI - High Priority.
SST - standard Priority.
$LO - Low Priority.
t~e
If no PRI is specified, $S1 priority will be assumed.
Input/Output Services - Page 9.5-7
621 .
HAS P
9.6
9.
6.~
TIME SERVICES
$TIME- Request Time
of~,
The $TIME macro-instruction obtains the time bf day and returns
this time in register "RO".
The time is returned as an unsigned
32-bi t binary number in' which the least significant bi t has :'a
value of 0.01 second.
Format Description:
[symbol]
$TIME
[OLAY=YES]
OLAY=YES
must be specified if the $TIME macro-instruction is coded
physically within an overlay segment.
The time returned is the time of day based on a 24-hour clock.
Time Services - Page 9.6-1
622 , ' ,
HAS P
9.6.2
$STIMER - Set Interval Timer
The $STIMER macro-instruction 'sets an interval into a pr'ogramrned
interval timer.
Format Description:'
[symbol]
$STIMER
loc-add rx
{ (Rl)
j-
[,OLAY=YES]
loc
specifies the address of a HASP Timer Queue Element.
Before this macro-instruction is executed, t~e Timer
Queue Element must be initialized as follows:
ITIME must be initialized with the interval to be
set in the following manner:
If "x" seconds are desired, then ITIME should
be set to "x"; OR
If "y" hundredth-seconds (0.01 seconds) are
desired, then ITIt-1E should beset to the
two's complement of "y".
IPOST must be initialized with the address of the
Event Wait Field to be posted.
If register notation is used, the address must have been
loaded into the designated register before the execution
of this macro-instruction.
For more information, refer to section 8.10: HASP Timer
Queue Element Format.
QLAY=YES
must be specified if the $STIMER macro-instruction is coded
phy~ically within an overlay segment.
PROGRAMMING NOTE: An unlimited number of independent $STIMER
time intervals can be active at any time provided that each
has been furnished with a unique HASP Timer Queue Element.
Time Services - Page 9.6-2
623
HAS P
9.6.3
$TTIMER - Test
.
-Interval Timer
The $TTIMER macro-instruction obtains the time remainipg in the
assoclated time interval that was previously set with a $STIMER
macro-instruction.
The value of the time interval ,remainder is
returned in register "RO" in seconds (rounded to the nearest
second).
The $TTIMER macro-instruction can also be used to cancel the associated time interval.
Format Description:
[symbol]
loc
$TTIMER
!
loc-addrx-}
(Rl)
[ ,CANCEL]
[, OLAY=YES]
specifies the address of the timer queue element.
If register notation is to be used, the address must have
been loaded into the designated register before the execution of this macro-instruction.
CANCEL
specifies that the interval in effect should be cancelled.
If this operand is omitted, processing continues with the
unexpired portion of the interval still in effect.
If the interval expired before the $TTIMER macro-instruction
was executed, the CANCEL operand has no effect.
OLAY=YES
must be specified· if the $TTIMER macro-instruction is coded
physically within an overlay segment.
Time Services - Page 9.6-3
624
HAS P
9.7
9.7.1
OVERLAY SERVICES
$OVERLAY·- Define ·Overlay Segment'
The $OVERLAY macro-instruction defines the. instructions which
follow it as an overlay segment and defines the name, priority,
and residence susceptibility factor of this' overlay segment'.
Format Description:
HASPname-symbol
$ OVERLAY
prio-value [,resfact-value]
HASP name
specifies the name to be assigned to the 'overlay segment.
The first four characters must be the characters "HASP".
The last four characters can be any unique combination of
alphameric characters.
prio
specifies the priority of the overlay segment as follows:
o
- Lowest P~iority
&LOW - Low Priority
&MED - Medium Priority
&HIGH - High Priority
res fact
specifies the residence susceptibility factor of the
overlay segment as follows:
o
- Never Resident
&LOW - Resident only if &OLAYLEV<4
&MED - Resident only if &OLAYLEV<8
&HIGH - Resident only if &OLAYLEV<12
If this parameter is omitted, a residence factor of 0 will
be used.
NOTE:
This parameter may be overridden at the time that
the overlay library is built.
Overlay Services - Page 9.7-1
625
HAS P
9 .7. 2
$OCON - Define Overlay Constant
The $OCON macro-instruction defines an overlay constant (aCON)
for use in conjunction with other overlay mqcro-instruct~ons.
Format Description:
[symbol]
$OCON
HASPname-symbol
HASP name
specifies the name of an overlay
segment~
Overlay Services - Page 9.7-2
626
HAS P
9.7.3
$L~NK-
Link to an Overlay Segment
The $LINK macro·-instruction is used to link to an overlay segment
from a non-overlay segment.
Format Description:
[symbol]
$LINK
HAspname-symbol}
{ (register)
HASPname
specifies the name of the overlay segment to which control
is to be transferred.
If register notation is used, the register specified must
be loaded with the qddress of an overlay constant (OeON)
which represents the overlay segment to which control is
to be transferred.
Overlay Services - Page 9.7-3
h?7
HAS P
9 .7. 4
$XCTL - Transfer Control to
A~other Ov~rlay
Segment
The $XCTL macro-instruction is used to transfer control from
one overlay segment to another.
Format Description:
[symbol]
$XCTL
!
HAspname-symbolj
(register)
HASPname
specifies the name of the overlay segment to which control
is to be transferred.
If register notation is used, the register specified must
be loaded with the address of an overlay constant (OCON)
which represents the overlay segment to which control is
to be transferred.
Overlay Services - Page 9.7-4
628
HA S P
9.7.5
$R~TURN
. . . Return from an.Overlay
Se
9.7.7
$DEL~TE
- De~ete a Loaded Over.~ Segment
The $PEL$TE ma~ro . . instruction is used to d~lete an ov~rlay
segment Which has been loaded with a $I..OADmacro-instruction.
Format Desqription:
[symbol]
$DELETE
Overlay Services - Page 9.7-7
631
HAS P
9.8
9.8.1
SYNCHRONIZATION SERVICES
$ACTIVE - Specify Processor is Active
The $ACTIVE macro-instiuction indicates to the' HASP Disp~tcher
that the associated processor is processing a job or task.
Format Description:
[symbol]
$ACTIVE
[R=register]
R
specifies the register which is to be used by the $ACTIVE
macro-instruction.
if R is omitted, register "Rl" will be used.
Synchronization Services - Page 9.8-1
632
HAS P
9.8.2
$DORMANT - Specify Processor is Inactive
The $DORMANT macro-instruction indicates to the HASP Dispatcher
that the associated processor has completed the processing of a
job or task and is now going into a "dormant" state.
Format Description:
[symbol]
$ DORMANT
IR=register]
R
specifies the register which is to be used by the $DORMANT
macro-instruction.
If R is omitted, register "RI" will be used.
CAUTION: The $DORMANT macro-instruction should never be executed
unless a corresponding $ACTIVE has been executed for the same
processor.
Synchronization Services - Page 9.8-2
633
HA S P
9.8.3
$WAIT - wait for a HASP Event
J
The $~AIT macro-instruction places the associated processor in
a HASP wait condition and specifies the event upon which the
processor is waiting in the Processor Control Element Event
Wait Field.
Format Description:
[symbol]
$WAIT
event-code [,ENABLE]
[,OLAY=YES]
event
specifies
as one of
BUF
TRAK
JOB
UNIT
CKPT
CMB
OPER
the event upon which the processor is waiting
the following:
- waiting for a HASP Buffer.
waiting for a direct-access track address.
waiting for a job.
waiting for a Device Control Table.
waiting for the completion of a HASP checkpoint.
waiting for a Console Message Buffer.
- waiting for an operator response.
10
waiting for the completion of an Input/Output
operation.
WORK
waiting to be re-directed.
HOLD
waiting for a $S operator command.
DDB
waiting for a Device Definition Table or Unit
Control Block.
ABIT - waiting for the next HASP dispatch.
ENABLE
specifies that the system mask in the PSW should be set to
all ones prior to returning to the HASP Dispatcher.
OLAY=YES
must be specified if the $WAIT macro-instruction is coded
physically within an overlay segment.
Synchronization Services - Page 9.8-3
634
HAS P
9.8.4
$POST - Post a HASP Event Complete
The $POST macro-instruction indicates a HASP event is complete
by turning off the specified bit in the indicated Event Wait
Field.
Format Description:
[symbol]
$POST
ewf-relexp,event-code
ewf
specifies the address of the event wait field which is to
be posted.
This operand can also be written in the form
D (B) •
event
specifies the event which is to be posted as one of the
following:
BUF - a HASP Buffer has been returned.
TRAK - direct-access space has been released.
JOB - a HASP Job Queue Element has changed status.
UNIT - a Device Control Table has been released.
CKPT - a HASP checkpoint has completed.
CMB - a Console Message Buffer has been returned.
OPER - an operator has responded.
10
- an Input/Output operation has completed.
WORK - a processor has been re-directed.
HOLD - an operator has entered a $S command.
DDB - a Device Definition Table or a Unit Control
Block has been released.
CAUTION:
The $POST macro-instruction should not be executed
unless addressability to the HASP Communication Table (HCT) has
been established.
Synchronization Services - Page 9.8-4
635
HAS P
9.8.5
$ENABLE - Enable Interrupts
The $ENABLE macro-instruction causes the specified interrupts
to be enabled.
Format Description:
[symbol]
$ ENABLE
mask-code [,OLAY=YES]
mask
specifies the interrupts to be enabled as follows:
ALL - Enable all interrupts.
JCL - Enable the interrupts which were enabled when
the Reader/Interpreter appendage was entered.
NOTE: This code can be specified only in the
Reader/Interpreter appendage.
OLAY=YES
must be specified if the $ENABLE macro-instruction is coded
physically within an overlay segment.
Synchronization Services - Page 9.8-5
636
HAS P
9.8.6
$D~SABLE
- Disable Interrupts
The $DISABLE macro-instruction causes the specified interrupts
to be disabled.
Format Description:
[symbol]
$DISABLE
mask-code [,OLAY=YES]
mask
specifies the interrupts to be disabled as follow~:
ALL - Disable all interrupts.
INT - Disable Interval Timer Interrupt.
OLAY=YES
must be specified if the $DISABLE" macro-instruction is 'coded
physically within an overlay segment.
Synchronization Services - Page 9.8-6
HAS P
9.9
9.9.1
DEBUG SERVICES
$TRACE - Make Entry in the HASP Trace Table
IThe $TRACE macro-instruction makes an entry in the HASP trace
table if the &TRACE option is set non-zero.
If the &TRACE
option is set to zero, this macro-instruction does not gerierate
any code.
Format Description:
[symbol]
$TRACE
P.ROGRAMMING NOTE:
The $TRACE macro-expansion and associated
Control Service Program preserve all registers and the condition
code. For more information concerning the HASP trace table,
refer to Section 5.11.
Debug Services - Page 9.9-1
638
HAS P
9.9.2
$'COUNT - Count Selected Occurrences
The $COUNT macro-instruction increments a counter every time
the macro-instruction is executed and can be used to determine
the number of times a particular event occurs or a particular
section of code is entered. The counter is a half-word counter
(modulo 65,536) which is located fourteen bytes deep in the macro
expansion (symbol+14).
Format Description:
[symbol]
$COUNT
[R=register]
R
specifies a register to be used in performing the counting
operation.
If this parameter is omitted, register "RI" will be used.
Debug Services - Page 9.9-2
639
HAS P
9.10
ERROR SERVICES
9.10.1
$ERROR - Indicate Catastrorhic
Er~or
The $ERROR macro-instruction is used to indicate that a catastrophic error has occurred, one that prevents any further processing
by HASP.
The macro-instruction causes the following message to
be printed out on the console specified by HASPGEN parameter
$PRICONA:
$ HASP SYSTEM CATASTROPHIC ERROR.
CODE
=
symbol
Format Description:
symbol
$ERROR
symbol
consists of a four-character symbol indicating the type
of error which occurred.
This operand usually consists of a letter, two digits; and
trailing blanks, and will be printed as the error code in
the message which is printed.
NOTE:
This operand must be present.
Error Services - Page 9.10-1
640
HAS P
9.10.2
$DISTERR - Indicate Disastrous Error
The $DISTERR macro-instruction is used to indicate that a
disastrous error has occurred.
The macro-instruction causes
the following message to be printed out on the $ERR and $LOG
consoles:
DISASTROUS ERROR - COLD START SYSTEM ASAP
Format Description:
[symbol]
$DISTERR
[OLAY=YES]
OLAY=YES
must be specified if the $DISTERR macro-instruction is coded
physically within an overlay segment.
Error Services - Page 9.10-2
641
HAS P
9.10.3
$IOERROR -Log Input/Output Error
The $IOERROR macro-instruction is used to log an Input/Output
Error on the operator's console.
Format Description:
[symbol]
$ IOERROR
!
buffer-addrx}
(Rl)
[,OLAY=YES]
buffer
specifies either a pointer to a HASP buffer or the address
of a buffer which has been associated with a HASP Input/
Output. error.
If "buffer" is written as an address then it represents the
address of a full-word which contains the address of the
buffer in error in its three low order bytes.
This word
must be located on a full-word boundary in core.
If "buffer" is written using register notation (either
regular or special register notation), then it represents
the address of the buffer in error.
If register notation is used, the address must have been
loaded into the designated register before the execution
of the macro-instruction.
OLAY=YES
must be specified if the $IOERROR macro-instruction is
coded physically within an overlay segment.
Error Services - Page 9.10-3
642
HAS P
9.11
9.11.1
CODING AID SERVICES
$GLOBAL - Define GLOBAL Symbols
The $GLOBAL argument on a COpy instruction causes all HASP
GLOBAL 'Symbols to be defined. This COpy instruction must be
the first instruction in an assembly (except for TITLE, EJECT,
and SPACE operations) to function correctly.
Format Description:
COpy
$ GLOBAL
Coding Aid Services - Page 9.11-1
643
HAS P
9.11.2
$HASPGEN - Define HASPGEN Parameters
The $HASPGEN argument on a COpy instruction causes all general
HASPGEN parameter values to be defined. This COpy instruction
may be placed anywhere in an assembly but must follow the
COpy $GLOBAL instruction.
Format Description:
COpy
$HASPGEN
Coding Aid Services - Page 9.11-2
644
HAS P
9.11.3
NULL - Define a Symbol
The NULL macro-instruction defines the symbol in the name field,
if any, as haVing the eurrent value of the lOcation counter
rounded ~p, if necessary, to a half-word boundary.
Format Description:
[symbol]
NULL
Coding Aid Services - Page 9.11-3
HAS P
9.11.4
$HASPCB - Generate HASP Control Blo
Jobs being processed (active):
JOB j
[name] {EXECUTING ClaSS} PRIO priority~OLDl
IS PURGING
~URGEJ
ON device name
HASP Operator's Guide - Page 12
705
HAS P
Where:
j
=
the HASP assigned job number
name
=
the OS job name assigned by the programmer
(displayed only if requested by the installation
at HASPGEN time)
class
=
the job class specified on the job card or set by
the operator with the $T JOB command
r
=
the remote terminal to receive the output for
which the job is queued (if r=O the job is queued
for local printing)
=
the device that is ready, printing or punching
data associated with the job.
If the operator has
repeated the output of a job, the lowest numbered
device will be listed.
priority
=
the HASP queueing priority
HOLD
=
the job is in HOLD status and must be released to
continue to flow through the system
PURGE
=
the job has been flagged for purge and will be
deleted from the system
DUPLICATE
=
the job is waiting for OS execution and another
job is currently executing with the same as job
name
device
na~e
HASP
706
Operator~s
Guide - Page 13
HAS P
Examples:
JOB
JOB
JOB
JOB
JOB
JOB
12
13
14
13
15
16
JOHNSJB
JOHNSJB
PUNCHJOB'
TESTOUT
ASMJOB
UNIQUE
EXECUTING A PRIO 9
AWAITING EXEC B PRIO 8 DUPLICATE
ON RMl.PUl PRIO 7
ON PRINTERI PRIO 8
AWAITING PRINT 1 PRIO 6'
AWAITING PUNCH 0 PRIO 6
HASP Operator's Guide - Page 14
707
· HAS P
STANDARD ERROR RESPONSES
The following standard messages will be returned in response to
invalid SYNTAX in command entry:
1.
xxxxxxxx
INVALID COMMAND - The command identified by the
eight characters displayed was not found in the
HASP command verb table.
No action has been taken.
2.
xxxxxxxx
INVALID OPERAND - The input stream identified by
the eight characters displayed was not recognized
as a valid operand. With exception of device list
commands no action has been taken.
In the case of
device list commands action has been taken on
operands preceding the INVALID OPERAND.
HASP Operator's
708
G~ide
- Page 15
HAS P
1.4
JOB QUEUE COMMANDS
Definition:
$A Ax •.•
Action:
Any jobs in the system held by the $HA command
will be released and processing allowed
Responses:
OK
- one or more jobs have been
released
QUElJE. No.T HELD
- no jobs have been released
RELEASE ALL JOBS
Examples:
1.
user
system
-
$A ALL
OK
2.
user
,system
-
$A A
3.
user
- $A.A
system -,; QUEUE· NOT. HELD ..
-.0:«
HASP Operator's Guide - Page 16
709
U
.M.
u
r
DISPLAY ACTIVE JOBS
Definition:
$D Ax ...
Action:
Job infor~ation for each active job in the
system will be displayed.
Responses:
Job information messages -
(see section
1.3)
NO ACTIVE JOBS
- no active jobs were
found
LIST INCOMPLETE
- the last job listed
was removed from the
HASP job queue while all
HASP WTO buffers were in
use.
Examples:
Comments:
1.
user
- $D A
system - JOB 3 ASSEMBLY EXECUTING A PRIO 5
2.
user
- $D ACTIVE
system - JOB 20 LISTALL ON PRINTER 2 PRIO 6
The LIST INCOMPLETE response shoul¢ be extremely
rare when s-q,fficient WTO buffers have been
generated to handle the message traffic.
HASP Operator's Guide - Page 17
710
HAS P
Definition:
$D, Fx ... [ , r-rr]
DISPLAY NUMBER OF JOBS QUEUED ON FORMS
Action:
The number of jobs queued for special forms printers
and special forms pu~ches will be summarized and
displayed for the local or remote workstations
specified by the route codes (r~rr).
If the route
code ranges are not specified, only the local queues
are displayed.
Responses:
jjj FORM ffff PRT rrr
,jjj FORM f f f f PUN rrr
- one response for each
form/route code combination
with jobs queued for special
f6rms printer output meaning:
jjj j6bs are queued for form
ffff at a printer located
at the local or remote station as indicated by rrr.
- one response for each
form/route code combination
with jobs queued for special
forms punch output.
Examples:
1.
user
- $D F
system - 4 FORM 0030 PRT 0
3 FORM 0132 PRT 0
1 FORM 0011 PUN 0
2.
user
$D F, 3-'4
system - 2 FORM 6431
1 FORM 7346
3 FORM 0563
1 FORM 7346
PRT
PRT
PRT
PRT
3
3
4
4
HASP Operator's Guide - Page 18
711
HAS P
Definition:
$D Nx ... f,{r-rr} [,queue]]
lqueue
DISPLAY JOB INFORMATION ON QUEUED JOBS·
Where:
queue = XEQ
- only jobs waiting for execution are
to be displayed in order by class
(A I B, C, etc.)
= XEQ class -
Ac~ion:
only jobs waiting for execution in
the designated class are to be
displayed
= PRT
- only jobs waiting for print are to
be displayed in order by route
code ( 0, I, 2, etc.)
= PUN
- only jobs waiting for punch are to
be displayed in order by route
code ( 0, I, 2, etc.)
=
- only jobs waiting for any activity
and in hold status are to be
displayed
HOLD
If routing and/or queue type restriqtions are not
specified, job information will be displayed for-all
jobs queued for execution (XEQ), print (PRT), and
punch (PUN); destined for output at local and all
remote terminal printer-punch unit record groups.
If the routing restriction is specified in operand 2,
only the jobs with output destined to the terminals
designated will be displayed.
If the queue type is
specified in operand 2 or 3, only jobs in the
selected queue with the appropriate routings will be
displayed.
In addition to displaying job information, the percentage of spool disk utilization will be displayed
following the search for queued jobs.
HASP Operatorts Guide - Page 19
712
HAS P
Responses:
Job information message
- , (see section 1. 3)
xx PERCENT SPOOL UTILIZAT.ION
- the last response
LIST
INCOMPLET~,
- the last job listed
prior to this message was removed from
the HASP job queue
while all HASP WTO
buffer~ere in use
Examples:
.1.
Comments:
user
- $D N,4 ,PRT
system - JOB 6 PRINTJOB AWAITING PRINT 4 PRIO 6
JOB 8 ASSEMBLY AWAITING PRINT 4 PRIO 5
25 PERCENT SPOOL UTILIZATION
2.
- $D N, 0-2, XEQ
1J.se1='
system - JOB 3 UNIQUE AWAITING EXEC A PRIO 9 DUPLICATE
,J.QB 6 JOHNSJB AWAITING EXEC A PRIO 9
JOB 2 BILLSJB AWAITING EXEC A PRIO 8
30 PERCENT SPOOL UTILIZATION
3.
user
- $D N,PUN
system - JOB 6 XYZJOB AWAIT:rNG PUNCH
JOB. 7 XYZJOB AWAITING PUNCH
JOB 12 JOBXYZ AWAITING PUNCH
JOB 15 JOBXYZ AWAITING PUNCH
JOB '5 JOBJOB AWAITING PUNCH
.35 PERCENT SPOOL UTILIZATION
9 PRIO 9
9 PRIO 8
1 PRIO 13
1 PRIO 8
3 PRIO 10
In exampl'e 1 the operator has requested that only jobs
with output to remote 4 and wait,ing for print to be
displayed.
.
In example 2 the operator has requested information
on jobs waiting for execution with output to local,
remote 1, or~rem6te 2 device~.
HASP Operator's Guide - Page 20
713
HAS P
Definition:
$D
QX •••
[{r-rr} [,queue]l
,queue
J
DISPLAY NUMBER OF JOBS QUEUED
Where:
queue
=
XEQ
=
XEQ class - only jobs waiting for execution
in the designated class are to
be counted and summarized
=
PRT
- only jobs wqiting for print are
to be counted and summarized in
order by route code (0, 1, 2, etc.)
=
PUN
only jobs waiting for punch are
to be counted and summarized in
order by route code (0, 1, 2, etc.)
== HOLD
Action:
- only jobs waiting for execution
are to be counted and summarized
in ordeT of class (A, B, C, etc.)
- only jobs waiting for any acti vi ty
and in ~old status are to be
displayed
If routing and/or queue type restrictions are not
specified, the number of jo.bs queued for execution
. (XEQ) , print (PRT) , and punch (PUN); destined for
output at local and all remote terminal printer~
punch unit record groups will be displayed.
If
the routing restriction ts specified in operand 2,
only the count of jobs with output destined to the
terminals designated will be displayed.
If the
queue type is specified in operand 2 or 3, only the
count of jobs in the selected queue with the appro~
priate routings will be displa¥ed.
In addition to displaying number of jobs queued,
the percentage of spool disk utilization will be
displayed following the search for queued jobs.
HASP Operator's Guide - Page 21
714
HAS P
Responses:
- number of jobs in
designated queue type-one line for each queue
type
nn queue type
xx
P~RCENT
SPOOL UTILIZATION - the last response
Examples:
Comments:
1.
user
- $D Q,4,PRT
system - 2 PRT 4
25 PERCENT SPOOL UTILIZATION
2.
user
- $D Q,O-2,XEQ A
system - 3 XEQ A
30 PERCENT SPOOL UTILIZATION
3.
user
- $D Q,PUN
system - 2 PUN 0
2 PUN 1
1 PUN 3
35 PERCENT SPOOL UTILIZATION
In example 1 the operator has requested that the
number of jobs with output to remote 4 and waiting
for print to be displayed.
In example 2 the operator has requested that the
number of jobs waiting for execution class A with output
to local, remote 1, or remote 2 devices
In example 3 the operator has requested that the
number of jobs waiting for punch be displayed. The
response shows two jobs waiting for punch at remote
1 (route code 1) ~ ~nd one job wa~ting for punch at
remote 3 (route code 3).
HASP Operator's Guide - Page 22
71S
HAS P
Definition:
$H Ax ...
HOLD ALL JOBS CURRENTLY IN THE SYSTEM
Action:
All jobs currently in the system will be placed in
the HOLD status and" further processing will be
prevented. Any new jobs entering the system subsequent to $HA command will not be held.
The
$A ALL command may be used to negate the effect
of the $HA command or the $A JOB command may be
used to negate the effects for specific jobs.
Response:
OK - all jobs currently in the system have been
placed in the hold status
Examples:
-
$H ALL
OK
-
$H A
OK
1.
user
system
-
2.
user
system
-
HASP Operator's Guide - Page 23
716
HAS P
1.5
JOB LIST COMMANDS
JOB LISTS
All job list commands accept requests for action for one or
moie jobs. The following format i~ used for entry of job list
commands:
Each operand requests action upon a range of job numbers;
i.e., if "1-300" were specified for an operand, action
would be attempted on jobs 1, 2, 3, ... 300.
If a single
job is desired, the "-jj" may be omitted or entered with
a value equal to the first value of the range.
If the
second value of the range is not greater than the first,
only the job corresponding to the second value will be
operated upon.
Limitations:
The maximum of five (5) range groups may be entered; any
entries beyond operand five will be ignored.
HASP Operator's Guide - Page 24
717
HAS P
Definition:
$A job list
RELEASE SPECIFIED JOB(S)
Action:
Specified jobs will be released from the HOLD
status if held by $H ALL, $H JOB, or JCL
TYPRUN=HOLD.
Response:
- one response for each job released
JOBj RELEASED
JOB(S) NOT FOUND - none of the specified job(s) were
found
JOBj NOT HELD
- one re$ponse for each job indicated
but not in the hold status
Examples:
Comments:
1.
user
- $A JOB 3
system - JOB 3 RELEASED
2.
user
- $A JOBS 4-6
system - JOB 4 RELEASED
JOB 6 NOT HELD
In example 2 job 5 was not found.
HASP Operator's Guide - Page 25
718
HAS P
Definition:
$C job list
Action:
Specified jobs will be flagged for PURGE, if NOT
in OS--execution will have its activity deleted
and be queued for purging. If the job is queued
for execution, or being read into the system it
will have its JCL queued for print prior to purging.
Limitations:
If the job is on an output device which has been repeated, multiple $C commands may be necessary to purge
the job.
Response:
Job information response - one response for each
job cancelled
JOB(S) NOT FOUND
- none of the specified
jobs were found
CANCEL SPECIFIED JOB(S)
Examples:
1.
user
- $C'JOB 7
system - JOB 7 YOURJOB AWAITING PUNCH 0
PRIO 7 PURGE
HASP Operator's Guide - Page 26
719
HAS P
Definition:
$D job list
DISPLAY JOB INFORMATION ON SPECIFIED JOB(S)
Response:
Job information response·
JOB(S) NOT FOUND
- one response for each
specified job found in
the system
- none of the specified jobs
were found
Examples:
1.
Comments:
user
- $D JOBS 1-10
system - JOB 2 YOURJOB
JOB 3 YOURJOB
JOB 6 ANOTHER
JOB 7 JOHNSJB
EXECUTING A PRIO 13
AWAITING EXEC A PRIO 13 DUPLICATE
ON PRINTERl PRIO 12
AWAITING PRINT 0 PRIO 12 HOLD
In example 1 jobs 1, 4, 5, 8, 9 and 10 were not found.
If the $D job list conunand is entered fre/m a remote
terminal, only those jobs belonging to the remote will
be displayed.
HASP Operator's Guide - Page 27
720
HAS P
Definition:
$E job list
Action:
Each specified job found in the system and currently
in OS execution will have its HASP execution controller flagged to restart the job. Upon completion
of OS execution (normal or abnormal) the controller
will place the job back on the HASP execution queue.
Note:
This command requires job and system command authority and is not available to HASP remote operators.
Response:
Job information response - one response for each
specified job in execution
which has been flagged for
re-execution
JOBj NOT RESTARTABLE
- one response for each
specified job found in the
system which cannot currently be restarted
JOB(S) NOT FOUND
-'none of the specified jobs
were found
RESTART EXECUTION OF SPECIFIED JOB(S)
Examples:
Comments:
1.
user
- $E J6
system - JOB 6 ANY EXECUTING A PRIO 8
2.
user
system
user
OS
-
$E J3
JOB 3 MYJOB EXECUTING A PRIO 6
C MYJOB
accepted message
In example 1 the operator desires to let job 6 run
to completion before requeueing for execution.
In example 2 the operator desires to abort current
execution of job 3 and requeue for execution.
HASP Operator's Guide - Page 27.1
720.1
HAS P
(The remainder of this page intentionally left blank.)
720.2
HAS P
Definition:
$H job list
Action:
Each specified job found in the system will
be placed in the HOLD status.
Response:
Job information response - one response for each job
held
JOB(S) NOT FOUND
- none of the specified jobs
were found
HOLD SPECIFIED JOB(S)
Examples:
1.
user
- $H J4
system - JOB 4 YOURJOB AWAITING PRINT 0
PRIO 4 HOLD
HASP Operator's Guide - Page 28
721
HAS P
Definition:
$p job list
STOP SPECIFIED JOB(S) AFTER CURRENT
ACTIVITY
Action:
Specified jobs will be flagged for PURGE and, if
not active, will be queued for purging.
Jobs
which are active will be queued for purging upon
completion of current activity. Jobs awaiting
execution will be queued for printing of JCL prior
to purging.
Response:
Job information response - one response for each
job which will be stopped
JOB(S) NOT FOUND
- none of the specified jobs
were found
Examples:
1.
user
- $p J7
system - JOB 7 JOHNSJB ON PRINTER2
PRIO 4 PURGE
HASP Operator's Guide - Page 29
722
HAS P
1. 6
MISCELLANEOUS JOB COMMANDS
Definition:
$A'jobname' RELEASE JOB SPECIFIED BY OS JOBNAME
Where:
'jobname'
Limitations:
This command is valid only if requested by the installation at HASPGEN time.
Action:
The HASP job queue is searched for the single job
with the specified job name and the action of the
$A job list command is performed as though that
command had been entered for the job. If the job
is not found or if more than one job with the specified name is encountered, no action is taken and
an appropriate diagnostic is displayed.
Response:
JOBj RELEASED
=
the OS job name appearing on the user's
job card enclosed by apostrophes. The
name may be upper or lower case alphameric characters, but must not contain
blanks.
- the job specified has
been released
jobname NOT FOUND
- the job named is not
in the system
JOBj NOT HELD
- the specified job was
not in hold status
MULTIPLE JOBS WITH jobname - more than one job with
the specified name is
in the system
- messages compatible
with $D 'jobname' will
follow
Examples:
1.
user
- $A'MYJOB'
system - JOB 4 RELEASED
HASP Operator's Guide - Page 30
723
HAS P
Definition:
$C'jobname' CANCEL JOB SPECIFIED BY OS JOBNAME
Where:
'jobname'
= the OS job name appearing.on the user's
job card enclosed by apostrophes. The
name may be upper or lower case alphameric characters, but must not contain
blanks.
Limitations:
This command is valid only if requested by the installation at HASPGEN time.
Action:
The HASP job queue is searched for the single job
with the specified job name and the action of the
$C job list command is performed as though that
command had been entered for that job. If the job
is not found or if more than one job with the specified name is encountered, no action is taken and
an appropriate diagnostic is displayed.
Responses:
Job information response
- response listing the
current status of the
job after command action
jobname NOT FOUND- the job named is not in
the system
MULTIPLE JOBS WITH jobname - more than one job with
the specified name is in
the system
- messages compatible with
$D'jobname' will follow
Example:
1.
user
- $C'YOURJOB'
system - JOB 82 YOURJOB AWAITING PRINT 0
HASP Operator's Guide - Page 30.1
723.1
HAS P
Definition:
$D'jobname' DISPLAY JOB INFORMATION ON JOB SPECIFIED
BY OS JOBNAME
Where:
'jobname' = the OS job name appearing on the 'user's
job card enclosed by apostrophes. The
name may be upper or lower case alphameric characters, but must not contain
blanks.
Limitations:
This command is valid only if requested by the installation at HASPGEN time.
Response:
Job information response - one response for each job
in the system with the OS
job name specified
LIST INCOMPLETE
- the last job listed was
removed from the HASP job
queue while all HASP WTO
buffers were-rn use
jobname NOT FOUND
- the job named is not in
the system
Examples:
user
- $0 'my job ,
system - JOB 4 MYJOB
JOB 5 MYJOB
JOB 6 MYJOB
JOB 7 MYJOB
ON PRINTER 1 PRIO 13
AWAITING PRINT 0 PRIO 13
EXECUTING A PRIO 13
AWAITING EXEC A PRIO 13 DUPLICATE
HASP Operator's Guide - Page 30.2
723.2
HAS P
Definition:
$E'jobname' RESTART EXECUTION OF JOB SPECIFIED BY
OS JOBNAME
Where:
'jobname' = the OS job name appearing on the user's
job card enclosed by apostrophes. The
name may be upper or lower case alphameric characters, but must not contain
·blanks.
Limitations:
This command is valid only if requested by the installation at HASPGEN time.
Action:
The HASP job queue is searched for the single job
with the specified job name and the action of the
$E job list command is performed as though that
command had\been entered for that job. If the job
is not found or if more than one job with the specified name is encountered, no action is taken and
an appropriate diagnostic is displayed.
Note:
This command requires job and system command authority and is not available to HASP remote operators.
Responses:
Job information response
Examples:
1.
- response listing the
current status of the
job (the job's execution
controller has been
flagged to restart the
job)
JOBj NOT RESTARTABLE
- the specified job is not
currently in execution
jobname NOT FOUND
- the job·named is not in
the system
MULTIPLE JOBS WITH jobname - more than one job with
the specified name is in
the system
- messages compatible with
$D'jobname' will follow
2.
Comments:
user
system
user
system
user
OS
-
$E 'ANY'
- JOB 6 ANY EXECUTING A PRIO 8
- $E 'MYJOB'
- JOB 3 MYJOB EXECUTING A PRIO 6
- C MYJOB
- accepted message
In example 1 the operator desires to let job "ANY"
run to completion before requeueing for execution.
In example 2 the operator desires to abort current
execution of job "MYJOB" and requeue for execution.
HASP Operator's Guide - Page 30.3
723.3
HAS P
Definition:
$H'jobname' HOLD JOB SPECIFIED BY OS JOBNAME
Where:
'jobname' = the OS job name appearing on the user's
job card enclosed by apostrophes. The
name may be upper or lower case alpha-meric characters, but must not contain
blanks.
Limitations:
This command is valid only if requested by the installation at HASPGEN time.
Action:
The HASP job queue is searched for the single job
with the specified job name and the action of the
$H job list command is performed as though that
command had been entered for the job. If the job
is not found or if more than one job with the specified name is encountered, no action is taken and
an appropriate diagnostic is displayed.
Responses:
Job information response
- response listing the
current status of the
job after command action
jobname NOT FOUND
- the job named is not in
the system
MULTIPLE JOBS WITH jobname - more than one job with
the specified name is in
the system
- messages compatible with
$D'jobname ' will follow
Example:
1.
user
- $H 'ANYJOB'
system - JOB 302 ANYJOB AWAITING EXEC A PRIO 4
HOLD
HASP Operator's. Guide - Page 30.4
723.4
HAS P
Definition:
$P'jobname' STOP JOB SPECIFIED BY OS JOBNAME
Where:
'jobname'
Limitations:
This command is valid only if requested by the installation at HAS~GEN time.
Action:
The HASP job queue is searched for the single job
with the specified job name and the action of the
$P job list command is performed as though that
command had been entered for the job. If the job
is not found or if more than one job with the specified name is encountered, no action,is taken and
an appropriate diagnostic is displayed.
Responses:
Job information response
=
the OS job name appearing on the user's
job card enclosed by apostrophes. The
name may be upper or lower case alphameric characters, but must not contain
blanks.
- the job specified has
been stopped
jobname NOT FOUND
- the job named is not
in the system
MULTIPLE JOBS WITH jobname - more than one job with
the specified name is
in the system
- messages compatible with
$D'jobname' will follow
Example:
1.
user
- $P 'UNIQUE'
system - JOB 31 UNIQUE ON PRINTER 2 PRIO 6 PURGE
HASP Operator's Guide - Page 30.5
723.5
HAS P
(The remainder of this page intentionally left blank.)
723.6
HAS P
~Tx ... j
Definition:
$T
.
Where:
priority = a numeric value 0 through 15 which indicates the HASP queuing priority desired
for the specified job.
, {p=priori ty } SE'T JOB CLASS OR PRIORITY
P=+priority
.
P=-priority
C=clas's
+priority = a numeric value which is to be added to
the present HASP queuing priority of the
specified job.
-priority
class
Action:
Limitation:
=
a numeric value which is to be subtracted
from the present HASP queuing priority of
the specified job.
=
a single character (A,B,C---Z,O,1---9)
representing the new execution class of
the specified job.
(Lower case characters
will be made upper case.)
1.
PRIORITY SETTING
The specified job's priority will be adjusted
as indicated; however, if the resulting priority
is outside the range 0-15, the final priority is
adjusted to 0 or 15 as appropriate.
2.
CLASS SETTING
The specified job's execution class will be set
to the indicated plass.
No action will be taken on a job that is currently
active.
If a job's class is execution batching (one of the
classes specified by HASPGEN parameter &XBATCHC) it
should not be changed to a non-batching class. Similarly,-a-non-batching class should not be changed
to a batching class. Such actions will cause the
job to execute incorrectly.
Responses:
Job information response--response for the job being
set.
Examples:
1.
user
- $TJ4,P=14
system - JOB 4 ANYJOB AWAITING EXEC A PRIO 14
2.
user
- $TJ6,C=Z
system - JOB 6 YOURS AWAITING EXEC Z PRIO 3
HASP Operator's Guide- Page 31
724
HAS P
Definition:
$T Jx ... n
Where:
n = the new base number for automatic job number
assignments.
Action:
The new base number will be set causing the next
job number assignment to be "JOB n" or the first
number beyond n that is not currently held by a job.
Responses:
OK - indicates that the.new job number base has
been set.
SET HASP INTERNAL JOB NUMBER
Examples:
Comments:
1.
user
- $TJl
system - OK
2.
user
- $TJOBIOO
system - OK
In example 1 assume that jobs 1, 3 and 4 are
currently in the system when the input service
processors read the next job. An attempt to
assign the value of "1" to the new job will fail;
however, the job will be assigned the value of "2".
Subsequent jobs will be assigned the value of 5, 6, 7 ...
If, however, the jobs 1, 3 and 4 are not in the
system, new jobs entering the system will receive
job number 1, 2, 3, 4 ...
HASP Operator's Guide - Page 32
725
HAS P
1.7
DEVICE LIST COMMANDS
Unless the format of the acceptable device list required by a command is explicitely specified, all device list commands accept entries of the following form:
$verb device ,device , ... ,device
l
2
n
Each operand specifies a single device that is to be acted upon by
the HASP System. The device may be specified by its full name or
abbreviated name as "follows:
CONSOLEn
INTRDRn
LINEn
PRINTERn
PRINTRn
PUNCHn
READERn
RMr .PRn·
RMr.PUn
RMr.RDn
TAPEn
-
CONn (abbreviation must be used)
RDIn (abbreviation must be used)
LNEn
PRTn
PRTn (used when more than 9 printers· are on the
system)
- PUNn (abbreviation must be used)
- RDRn
(no abbreviation)
(no abbreviation)
(no abbreviation)
- TPEn
Limitations:
A maximum of five (5) operands may be specified in a single
device list command. Operands which are in excess of the
maximum allowed will be considered part of the fifth operand.
HASP Operator's Guide - Page 33
726
HAS P
NOTES:
1.
Device list commands generally perform operations which occur
after the response to the command entered; i.e., the OK
response to a device list command signifies that the command
has been a~cepted and an attempt to perform the requested
action will be made for all devices listed.
Additional messages will be displayed on the operator's console when the action requested is either in process or has
been completed as appropriate.
See Messages and Codes
section of this manual for the format and meanings of these
messages.
2.
An error response to a device list command indicates that the
action requested by the previous operands will be attempted
but the operand in error and all following operands will be
ignored.
3.
Many commands will accept operands as being valid even though
the devices specified are unable to perform the function
requested.
Table 1.7~l identifies the devices affected by
each device list command.
HASP Operator's Guide - Page 34
727
HAS P
TABLE 1.7.1
DEVICES AFFECTED BY DEVICE LIST COMMANDS
$B
$C
$E
$F
$I
$N
y
LINE
$P
$S
$T
$Z
y·4
y
y7
y7
LOCAL READER
y2
Y
Y
y
Y
INPUT TAPE
y2
Y
Y
Y
Y
REMOTE READER
y2
y5
Y
Y
y
y2,3
y6
Y
y
y7
INTERNAL READER
LOCAL PRINTER
y
Y
Y
Y
Y
Y
Y
y
y
y
REMOTE PRINTER
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
LOCAL PUNCH
yl
Y
Y
yl
yl
y
y
y
y
Y
REMOTE PUNCH
yl
y
y
yl
yl
y
y
y
y
Y
Y
Y
Y
LOCAL CONSOLE
lRESTARTS FUNCTION
2DELETES CURRENT JOB
3SIMULATES EOF IF NO CURRENT EXCP
4DRAIN AFTER SIGNOFF OR $E IF REMOTE ACTIVE
5 DRAIN AT EOF AS OPPOSED TO END OF FUNCTION FOR CURRENT JOB
6AUTOMATICALLY STARTED BY USER PROGRAM
7COMMAND ACCEPTED BUT WILL HAVE NO EFFECT
HASP Operator's Guide - Page 35
728
HAS P
I
[
page~
Definition:
$B device
Where:
device = HASP printer device desired to perform the
backspace
pages = the number of pages (up to 9999) to backspace (optional for the last device of the
list, mandatory for the other devices)
DX ••• = backspace to beginning of data set
Action:
The designated printer will, if ACTIVE, back up the
designated number of pages in the current data set
and resume printing.
If the beginning of the data
set is encountered during the backspace process, the
printer will resume printing at the beginning of the
data set.
If the number of pages is not specified,
the count of one (1) will be assumed for the last
device in the list.
Note:
A $B directed to a punch will have the effect of restarting the current function.
Responses:
OK - the specified printer(s) will be backspaced
Examples:
1.
user
- $B PRT1,lO
system - OK
2.
user
- $B PRTl
system - OK
3.
user
Comments:
Dx ••
aACKSPACE DEVICE(S)
j
- $B PRTl,5,PRT2
In example 1 printer 1 is to be backspaced ten pages.
In example 2 printer 1 is to be backspaced one page.
In example 3 printer 1 is to be backspaced five
pages (the count for printer 1 must be specified),
and printer 2 is to be backspaced one page.
HASP Operator's Guide - Page 36
729
HAS P
Definition:
$C device list
Where:
device
Action:
The current activity on the designated devices will
be terminated.
In the case of printer and punch
devices, the highest priority job eligible for output on the device will be selected and printing or
punching will resume for the new job. In case of
input reader devices, the current job will be queued
for print and reading will continue.
In case of internal reader devices an end of file maybe simulated
based upon the instantaneous status of the device.
Note:
A $C directed to an internal reader should only be
used when the reader has been left active by a submitting task that has terminated (ie., the job that
submitted the input stream terminated without freeing
the internal reader).
Responses:
OK - the activity on the specified device(s) will
be cancelled.
Examples:
1.
=
CANCEL CURRENT ACTIVITY ON DEVICE(S)
HASP reader, printer, and punch devices
user
- $C PRTI
system - OK
HASP Operator's Guide - Page 37
730
HAS P
. Definition:
$E device list
=
RESTART CURRENT ACTIVITY ON DEVICE(S)
Where:
device
Action:
The current activity on the designated devices will
be terminated.
In case of printer/punch devices the
job will be returned to the appropriate print or punch
queue in order of priority and made eligible for
selection.
In case of remote job entry lines, the
HASP System will, upon completion of the current
line I/O, abort all activities on the line.
Response:
OK
Examples:
1.
user
$E PRTl,PRT2
system - OK
2.
user
- $E LNE2
system - OK
HASP line, printer, and punch devices
- the specified device will be restarted
-
HASP Operator's Guide - Page 38
731
HAS P
Definition:
$F device [pages]
DX .•.
Where:
device
pages
DX ...
I
FORWARD-SPACE PRINTER DEVICE (S)
=
HASP printer device desired to perform
the forward-space
= the number of pages (up to 9999) to
forward-space (optional for last device
of list, mandatory for the other devices)
= forward-space to end of data set
Action:
The designated printer will, if ACTIVE, skip forward
the designated number of pages and resume printing.
If the end of the data set is encountered during the
forward-space, printing will resume on the next data
set if present.
If the number of pages is not specified for the last device in the list, the count of
one (1) will be assumed.
Note:
A $F directed to a punch device will have the effect
of restarting the current function.
Responses:
OK - the specified printer(s) will be forward-spaced
Examples:
1.
user
- $F PRT1,999
system - OK
2.
user
$F PRT1,DS
HASP Operator's Guide - Page 39
732
HAS P
I
Definition:
$1 device list
-Where:
device
Action:
The current-activity on the designated printer(s)
will, if ACTIVE, be checkpointed and terminated.
The job will be returned to the HASP SYSTEM job
queue and made available for selection. Any printer
selecting the job for output will resume printing
the job after the backspacing of one (1) page.
Note:
A $Idirected to a punch device will have the effect
of restarting the current function.
Responses:
OK - the specified printer(s) will be interrupted
Examples:
1.
INTERRUPT CURRENT ACTIVITY ON
PRINTER DEVICE(S)
= HASP printer devices
user
= $I PRTl
system = OK
HASP Operator's Guide - Page 40
HAS P
Definition:
$N device list
Where:
device
Action:
The current activity on the designated printer and/or
punch devices will be repeated. This operation will
not terminate the activity in process but will place
the job back on the HASP job queue and make it available for otner devices to output. Once a device has
been repeated additional commands to repeat or interrupt the device will be ignored until the device has
completed operation on the ,current copy of the output. A restart,$E directed to a repeated device will
have the effect of cancelling the output.
Responses:
OK - the specified printer and/or punch device(s) will
be repeated if the device(s) are eligible
Examples:
1.
I
= HASP
REPEAT CURRENT ACTIVITY ON DEVICE(S)
printer and punch devices
user
- $N PRTI
system - OK
HASP Operator's Guide - Page 41
734
HAS P
DEVICE STATUS
A device controlled by the HASP System will be in one of four
status conditions as follows:
ACTIVE
- The device is actively performing a function.
INACTIVE
- The device is available to perform a function,
however, no jobs are available for the device.
DRAINING
- The device is actively performing a function,
but upon completion of that function will not
begin a new activity.
DRAINED
- The device is not performing a function and will
not do so until the operator starts the device.
The operator controls the ability of a HASP device to select jobs
for processing via the following commands:
$p
$S
- stop the device
- Start the device
HASP Operator's Guide - Page 42
735
HAS P
Definition:
$Pdevice list
STOP (DRAIN) DEVICE(S)
Action:
The specified devices will be prevented from
starting any new activity.
If a device is INACTIVE,
the device will be immediately stopped (DRAINED).
If a device is ACTIVE, the device status will be
DRAINING and will revert to the DRAINED status upon
completion of the current activity.
Responses:
OK
- the device(s) have been placed in the DRAINED
OR DRAINING status
1.
user
- $P PRTl,PRT2,PUNl
system - OK
Examples:
Comments:
When the device enters the DRAINED status, the HASP
message
"device IS DRAINED"
will be displayed on the operator's console.
If a VARY CPUx,OFFLINE command is to be issued to
stop a CPU in the Model 65 Multiprocessor configuration, the operator must first insure that ~ll
devices accessible only from the CPU to be varied
offline are in the HASP DRAINED status.
HASP Operator's Guide - Page 43
71f,;
HAS P
I
[,additional deVices] START DEVICE (S)
Definition:
$S
Note:
The explanation of this command is complex and is
separated into the definitions which follow.
device
line ,password
input tape,address
console
HASP Operator's Guide - Page 44
737
HAS P
Definition:
$S device list
Where:
device
Action:
The devices listed will be placed in the ACTIVE
or INACTIVE status.
If the device is INACTIVE,
an attempt to select and process a job will be
made. Each device started will be placed into
the OS off-line status to prevent inadvertent
OS alloGation of an active device.
Responses:
OK
=
START DEVICE(S)
HASP card reader, printer, and punch
devices
- the device(s) listed have been started
Examples:
1.
user
- $S PRTl,PRT2,PUNl,RDRl
system - OK
2.
user
- $S PRTI
system - OK
HASP Operator's Guide - Page 45
738
HAS P
Definition:
$S line,password
Where:
line
password
START DEVICE(S)
= HASP remote job entry line device
=
0 to 8 character security password
required for remote workstation SIGNON
Action:
The specified line(s) will be started unless
allocated by OS to another activity or the designated adapter is off-line. The password will be
set for the line and be used to reject unauthorized
terminals attempting to use the line without permission from the central installation.
If the line
is ACTIVE, the command has the effect of setting a
new password to be used for future terminal SIGNON.
Responses:
OK
- the specified line(s)
will be started
device name IN USE
- the line listed is
assigned by OS
device name INVALID OPERAND - the line listed, if
spelled correctly,
has not been assigned
a hardware address
Examples:
1.
user
- $S LNEl"LNE2
system - OK
2.
user
- $S LNEl,XZQ,LNE2,XZZ
system - OK
HASP Operator's Guide - Pagei 46
739
HAS P
Definition:
$S input tape, address
Where:
input
= HASP input tape device
address = three digit hardware address for the
device
Action:
The specified HASP input tape device will be made
ACTIVE and will read the input stream data from
the assigned tape unit.
Note:
The unit address is used for the purpose of assigning a physical device to the HASP logical device.
Once this assignment has been made succeeding $S
commands directed to the device should be made
omitting the unit specification and associated
comma.
Responses:
OK
Examples :.
1.
user
- $S TPEl,182
system - OK
2.
user
- $S TAPEl,TAPE2
system - OK
Comments:
START DEVICE(S)
- the designated tape(s) have
been started
device name IN USE - the device is currently ACTIVE
or the unit has been assigned
by OS
In example 2 the operator has previously set tapes 1 .
and 2 to place all jobs in the hold status and now
wishes to reverse that action.
HASP Operator's Guide - Page 47
740
H A 5 P
Definition:
$5 console
Where:
device
Action:
The specified HASP consoles will be started for
all logical console classes of messages with all
levels of importance (see CONSOLE SUPPORT for
classes and levels of messages) .
Responses:
OK
START DEVICE(S)
= HASP console device(s)
- the HASP console(s) have been started
Examples:
1.
user
- $5 CONl,CON2
system - OK
HASP
741
Operator'~
Guide - Page 48
HAS P
Definition:
$T
reader, /A=authorit y
Hx ...
printerl
/ punch
,C=
,F=
I
SET DEVICE
I~arriagel
! I
Rx ••.
Sx .••
Ax .••
n
,T=
{ train
}
,S=
/Yx •••
I
Nx ...
console
,level
,class [,class, •.. ]
!
, Rx. • •
I
.
,A=authority
CON,level,class[,class, ... ]
Note:
The explanation of this command is complex and is
separated into the definitions which follow.
HASP Operator's Guide - Page 49
742
HAS P
Hx. • ·
{ A=authority
l
Definition:
$T reader,
Where:
reader = HASP reader device
Action:
If Hx •.• is specified the designated reader will
be set to place all jobs subsequently read by the
reader into the execution HOLD queue. Jobs placed
into the HOLD queue may be released for execution
by use of the $AJOB command. A successful $S command directed to the reader will negate the effects
of the "$T reader,H" command causing the reader to
revert to normal reading and queueing of jobs~
J
SET DEVICE
If A~authority is specified the HASP command authority of the designated local, tape, or internal
reader is set to allow HASP command entry as follows:
o-
display only
1 - system control
2 - device control
4 - job control
Notes:
1.
2.
3.
4.
5.
6.
A reader may not be used to set the command
authority of a reader device.
See CONSOLE SUPPORT section of this manual.
See $TCON and $TCONn commands.
The $S command does not negate the effects of
the "$T reader, A=authority" command.
A=authority operand requires device and system
authority.
If a specification is in error, that specification and all succeeding specifications in the
command are rejected. Previous specifications
will be acted upon.
Responses:
OK - The specified reader has been set to HOLD subsequent jobs and/or its HASP command authority
has been set.
Examples:
1.
2.
3.
user
- $T RDRl,HOLD
system - OK
$T RDRl,H
user
system - OK
user
- $T RDRl,A=O
system - OK
-
HASP Operator's Guide - Page 50
743
HAS P
Definition:
$T
l
printer} ,C=
punch
;arriagel
,F= Rx ...
Sx ...
Ax ...
n
,T= train
,s=lyx ...
lNx .. ·
Where:
SET DEVICE
I
I
1
=
space the printer one line after each
print line; i.e., single space the printer
ignoring problem program carriage control
Rx ...
=
set the printer or punch to output jobs
using standard forms (STD.) allowing
changing of forms on a DEMAND basis
Sx ....
=
set the printer to print special forms
data sets using standard (STD.) forms
which the operator has loaded into the
device
Ax...
=
set the printer or punch to output jobs
using special forms under HASP AUTOMATIC
forms assignment
n
=
a one to four digit number specifying the
forms which the operator has loaded into
the device
train
=
the two character train or chain identification (AN, HN, PN, QN, RN, or UN).
carriage
=
the single character 3211 carriage tape
identification (6, 8, or U)
yx...
=
set the printer or punch to provide
HASP separator pages or cards between
data sets of different jobs.
Nx...
=
set the printer or punch not to provide
HASP separators and (in case of a nonconsole remote workstation) not to
provide operator messages on the printer.
HASP Operator's Guide - Page 51
744
HAS P
Action:
·The specified printer will be set to handle the
carriage control (C=), forms (F=), and train/chain
(T=) as specified or the specified eunch will be
set to handle the forms (F=) specif~ed.
If the
specified printer has the UCS feature installed,
the UCS buffer will be loaded with the print train/
chain image prior to the printing of each job.
Notes:
1.
The effect of C=l will be negated by entry of
a successful $S command directed to the printer.
2.
Multiple settings directed to the same device
using the same command entry are permitted.
3.
The specification F=R will cause the printer
to print the normal batch stream jobs using the
installation's standard forms. However, a job
requesting special forms in a data set to be
printed with the rest of the job will cause a
forms mount before printing the data set and a
forms mount to STD upon completion of printing this data set.
4.
The specification C=V should be used in conjunction with the $TF command discussed in the
SYSTEM COMMANDS section of this manual.
1.
The setting of forms, train/chain, or carriage
is valid only when the appropriate device is
not being used.
It is recommended that the operator enter "$P device name" and wait for it
to enter the DRAINED status. When HASP has issued a forms load and is waiting for the operator to enter $S for the device, the device may
be considered inactive for the purpose of setting train/chain or carriage for local printers.
2.
Train/chain settings directed to remote printers
or local printers without DCS will be ignored.
3.
The (T=) operand is defined only for local
printers. The remote CPU workstation operator
must load DCS buffers via means other than
through the HASP central system.
4.
The (C=carriage) operand is defined only for local printers. The remote CPU workstation operator must load the carriage buffers via means
other than through the HASP central system.
Limitations:
HASP Operator's Guide - Page 52
745
HAS P
Responses:
OK - the settings requested have been made
Examples:
1.
user
- $T PRTl,C=l
system - OK
2.
user
system
3.
user
- $T PUNl,F=4732
system - OK
4.
user
system
Comments:
-
-
$T PRTI,F=AUTO,T=PN
OK
$T PRT2,F=R,T=HN
OK
In example 1 the operator discovers the problem program is skipping to carriage tape channels which
violate the installation procedures. The entry of
$T PRTl,C=l causes the printer to single space after
each line printed to the end of the data set.
In example 2 the operator desires to use the printer
to print all jobs queued for special forms allowing
HASP to select the special forms to be mounted. The
printer has been loaded with a PNtrain to be used
with the special forms.
In example 3 the operator desires to use the punch
to punch only those data sets in the system which
have specified forms type '4732'.
In example 4 the operator desires to use the printer
to print the normal batch output using standard forms
and the HN print train.
HASP Operator's Guide - Page 53
746
HAS P
Definition:
$T console
!
,level
,class[,class, •.• ]
, Rx •••
SET DEVICE
,A=authority
Where:
console
level
class
Comments:
= HASP console device
= a number, 0-15, which specifies the
highest operator message level to
eliminate for the designated console.
A value of a will allow all messages for
the designated console to be displayed.
A value of 15 will eliminate all messages. The following list indicates the
general levels of messages displayed by
the HASP system:
1 - non-essential messages
3 - normal messages
4 - messages requiring operator action
7 - essential messages
= the logical console class of messages
the specified console is to display in
addition to current classes ..
Specify class as follows:
LOG
- log console messages
ERROR - error messages
UR
- unit record messages
TP
- HASP RJE line messages
TAPE - tape console messages
MAIN - main operator console messages
OS
- OS WTO messages
When using the VARY CPUx,OFFLINE command in a Model
65 Multiprocessor system with HASP Console Support,
the operator must first issue the HASP command
$T console,R
for the console on the CPU to be varied offline, and
wait until the console stops printing messages.
HASP Operator's Guide - Page 54
747
HAS P
Notes:
Rx •••
=
RESET--indicating the level value is to
be set to 15 to eliminate all output
based upon importance and the class
settings are to be reset to eliminate
all output based upon logical console
class.
Authority
=
a number, 0-7, representing one or more
command authority groups as follows:
o - display only console
1 - system control console
2 - device control console
4 - job control console
Under HASP mUltiple console support,
console authority may be set to allow
controlling commands to be entered from
consoles which have the authority to
control the designated function. Multiple
settings are accomplished by the operator
adding the authority group numbers together
and entering the result; i.e., 7 indicates
authority 1+2+4 (zero is assumed).
1.
2.
See CONSOLE SUPPORT section of this manual.
The entry console for A=authority operands
must be authorized for system control (authority
1, 3, 5 or 7)and the device specified must not
be the entry console.
HASP Operator's Guide - Page 55
748
HAS P
Action:
The specified console is set to the appropriate list
"level" logical console "class" and "authority" indicated by the operands. Each operand is handled individually and completely starting with the second
operand. If an operand is determined to be in error,
previous operands will take effect and the operand
in error, along with succeeding operands will be ignored. If the RESET operand is used, it is assumed
to be the last of the list.
Responses:
OK - the settings requested have been made
Examples:
1.
user
- $T CON1,15
system - OK
2.
$T CON1,4
user
OK
system -
3.
user
- $T CON1,RESET
system - OK
user
- $T CON1,O,MAIN
system - OK
4.
user
- $T CON 3 ,A=O
system - OK
f
Comments:
In example 3 all output to console 1 is turned off
(console level set to 15 and class set for no logical classes). Then the console is set to display all
messages for the MAIN console.
HASP Operator's Guide - Page 56
749
HAS P
Definition:
$T CON,level,class [,class, ... ]
Where:
CON
CON--indicating that HASP is to set the
level of message output for the logical
console classes passed to OS consoles.
level = a number, 0-15, which specifies the highest
operator message level to eliminate for the
designated logical console class specified
in the succeeding operands. A value of 0
will allow all H~SP messages for the designated logical console class to be displayed
on the OS console(s) assigned to display
the message class. A value of 15 will
eliminate all HASP messages of the specified
class. The following list indicates the
general levels of messages displayed by
the HASP system:
1 - non-essential messages
3 - normal messages
4 - messages requiring operator action
7 - essential messages
class = the logical console class of the messages
given to OS for display purposes.
Specify as follows:
LOG
- log console messages
ERROR - error messages
UR
- unit record messages
TP
- HASP RJE line messages
TAPE - tape console messages
MAIN - main operator console messages
Notes:
1.
See CONSOLE SUPPORT section of this manual.
2.
Responses to HASP commands will always be
displayed at the console of entry regardless
of the logical console class or level settings.
SET DEVICE
=
HASP Operator's Guide - Page 57
750
HAS P
Action:
The display "level" of the logical console classes
will be set to the level specified.
Each logical
console class is set independently from the others
starting with the first listed, operand 3.
If
an error is detected in the list, the operands
pre~eding
the operand in error will be acted
upon and the operand in error and all succeeding
operands will be ignored.
Responses:
OK
- the logical console classes have been
set to the display level specified.
Examples:
1.
user
- $T CON,4,MAIN,LOG
system - OK
HASP Operator's Guide - Page 58
751
HAS P
HALT (STOP) DEVICE
Definition:
$Z device list
Where:
device
Action:
The specified devices will be HALTED after the
current scheduled operations complete.
In case
of HASP consoles, all logical console classes and
levels of importance will be RESET so that, except
for direct responses to commands entered from
the console, no new messages will be directed to
the device. The effects of the $Z command may
be negated by use of the $S command.
Responses:
OK
= HASP reader,
printer, punch, and
console devices
- the device(s) has been set to HALT
operations
Examples:
1.
user
- $Z PRTl,PRT2,RDRl,PUNl
system - OK
HASP Operator1s Guide - Page 59
752
HAS P
1.8
SYSTEM COMMANDS
Syst,(~m commands control the abili ty of the HASP System to
process jobs through OS and may be broken down into two groups:
INITIATOR COMMANDS
HASP SYSTE.M COMMANDS
- those cornmandswhich control
the actual selection and submission of jobs from HASP to OS
for processing.
Those commands which control
the ability of the HASP System
to process jobs for 'any function.
In the following descriptions, a parameter lin" is referred to as
the initiator identification.
This identification is assigned
by the systems programmer during the HASPGEN process.
However,
it is assumed in this manual that the initiator identifications
are one or two character numeric digits 1, 2, 3, eo.; in MFT the
values correspond to the partition numbers.
HASP Operator's Guide - Page 60
753
HAS P
INITIATOR STATUS CONDITIONS
An initiator's ability to process jobs depends upon the availability
of jobs in the input queue of corresponding classes and t~e status
of the initiator.
These status conditions are as follows~~
I
ACTIVE
- the initiator is currently processing a job and ha$ the
ability to continue processing.
INACTIVE
- the initiator has the ability to process jobs but no
job of the initiator's current classes is ready for
execution.
DRAINING
DRAINED
the initiator is currently processing a job but will not
select another upon completion of the current job.
- the initiator is not processing a job and will not
attempt to select any job.
HASP Operator's Guide - Page 61
754
HAS P
JOB SELECTION FOR
as
EXECUTION
'~vhen the HASP Sys'tem completes reading card' images ctssociated wi th
an OS job, the job is placed into one of the HASP logical execution
queues.
The appropriate execution queue is selected based ~ppn the
job class as specified by:
CLASS=class
parameter on tti~ as job card submitted by
the prog-r amrner
$
$T ~JOBn,C=class HASP command entered by the' operator after
previous queueing based upon the job card.
"
:J "
CLASS=A
default specification in lieu of other
specifications~
Each job is placed in the appropriate execution queue in order by
priority so that higher priority jobs within the queue will be
selected for execution before jobs of lower priority and that jobs
of the same priority will be selected in order first in - first out.
J"on selection priority is determined from the following sources:
1"
The time and line estimate in the HASP accounting field of
the as job card:
Although the correlation of time
estimate with priority is determined
at HASPGEN time, it is normally set
to give the shortest running jobs
highest priority.
ca.rd "vhich may appear preceding the
job card.
This card overrides the
time and line estimate priority setting.
$T ,JOBn p
J.ority
HASP command entered by the operator
after previous queueing.
HASP Operator's Guide - Page 62
755
HAS P
When an initiator enters the INACTIVE status, it will attempt
to select ready jobs from the HASP job queue in a manner
directly controllable by the operator. An initiator will search
the logical ex~cution queues for jobs in order by class.
If
the operator has set the initiator to execute classes "ABX" in
that order, the initiator will initiate only Class A jobs
so long as there are Class A jobs ready for execution. When
there ar~ no Class A jobs ready, the initiator will initiate
only Class B jobs or, if no Class B jobs, Class X jobs. The
operator, therefore, by altering the initiation classes controls
the selection of jobs based upon the job class.
By appropriate
job classing and setting of initiator class selection lists,
jobs with complementary characteristics will tend to be in execution concurrently.
\
HASP Operator's Guide - Page 63
756
HAS P
Definition:
$D I[n]
Where:
n = the identification of the initiator to be
displayed
Action:
The status and eligible classes for the initiator(s)
indicated will be displayed. If n is not specified,
all initiators will be assumed. If an Execution
Batch Processing Program is in main storage under
control of a logical initiator, its as jobname will
also be displayed.
Responses:
INIT n
Examples:
1.
user
- $DIl
system - INIT 1 (ACTIVE)=ABCD
2.
user
- $OI
system - INIT
INIT
INIT
INIT
DISPLAY INITIATOR(S)
(I.
DRAINING
DRAINED
ACTIVE
INACTIVE
I)
1
2
3
4
= classes - one response for
each initiator requested
(ACTIVE)=ABCD
(ORAINING)=BCDA
( INACT lVE) =WDAB
(ORAINED)=DABC
$$$$$W3
HASP Operator's Guide - Page 64
757
HAS P
Definition:
$p I[n]
Where:
n
Action:
The designated initiator will be prevented from
selecting additional jobs for processing.
If a
specified initiator is actively processing a job
(ACTIVE), its status will be changed to (DRAINING)
until the current job terminates.
If a specified
initiator is not actively processing a job
(INACTIVE) or upon completion of processing, the
status of the initiator will be (DRAINED).
STOP (DRAIN) INITIATOR{S)
=
the identification of the initiator
to be stopped
If the optional identification is not specified,
all initiators will be stopped.
--If the system contains the Execution Batch Scheduling
feature (see section 12.13 of HASP Systems Manual),
this command will cause a batch program(s) under
control of the designated initiator(s) to be cancelled
when the initiator(s) becomes DRAINED, thereby releasing memory for other processing.
Responses:
OK
- the specified initiator(s) are or
will be stopped
Examples:
1.
user
- $PI3
system - OK
2.
user
- $PI
system - OK
"HASP Operator I s Guide - Page 65
758
HAS P
Def$n,ti..iQiJ;
.:f&<···.·.:t [n]
·Where:
n
Action:
:Response:S'l
STARTINITIATOR(S)
= the identification of the iriitiator
to be star1:~d
The designated initiator, will be allowed to select
jobs of :the appropriate job classes acceptable to
the initiator. It the identification "n" is
omitted, all initiators which were not stopped by
a $'PI command with the initiator specified will
be started. If the initiator is DRAINING, its
. status will become ACTIVE; if DRAINED, its status
will become INACTIVE and. an immediate attempt
to select a job will be made.
OK
- the specified· initiator(s) are started
Examples:
1>.
'u;se~
- $513
.ystem-.OK
~~
user
- $SI
s'yate. - OX
HAS P
Definition:
$T In,list
Where:
n
list
Action:
SET INITIATOR
C~ASSES
~
the identification of the initiator
to be set
= li~~ of acceptable job classes for
the ~pec~fie~ i~itiator.
Each class
is ,listed in order o£ selection
pr{oritydesi~ed~or. the initiator.
The maximuni length of the list is
specified by the system programmer
atHASPGEN time,.,
. The new clas~ list is".ins~rte(i' without inspection
into the sp~cified i1)i tiator'"s cl'ass selection
list. All future job ~election for the initiator
will be done based upon the new l+st.
~'. _"
Examples:
1.
user
- $TI1,ABC
system - OK
2.
user
- $TI2,~~A
system - OK
3.
user
- $TI3,CAB
system - OK
HASP Operator's Guide - Page 67
760
HAS P
Definition:
$p
Action:
All HASP job processing will be stopped. The
HASP initiators, printers, and punches will not
begin any new functions. The effects of $P
under normal conditions may be negated by the
$S command.
.
Responses:
OK
STOP SYSTEM
- current functions will be allowed to
complete and the system will become
dormant
Examples:
1.
user
- $p
system - OK
HASP Operator's Guide - Page 68
761
·H ASP
Definition:
$P HASP
STOP HASP
Action:
The $P command will be simulated and, if HASP is in
a dormant status (no job processing is in process,
and all HASP devices are DRAINED or INACTIVE), the
HASP SYSTEM will withdraw from control of the Operating System.
Note:
If the system contains the Execution Batch Scheduling
feature (see section 12.13 of HASP Systems Manual),
it is recommended (but not required) th~t the $F I
operator command be issued and system activity be
allowed to quiesce prior to issuing the $P HASP command. This will allow any batch programs to be
cleared from the OS Job Queue prior to withdrawal of
HASP.
Responses:
HASP NOT DORMANT - response when HASP is unable to
withdraw.
Note:
Since HASP loses control of the system during withdrawal, a response is not issued by HASP. However,
reader closed and initiator waiting for work may be
issued by OS as an indication of HASP job completion.
Examples:
1.
user - $P HASP
OS
- reader closed/initiator waiting for work
HASP Operator's Guide - Page 69
762 .
HAS P
. Definition:
$S
START SYSTEM
Action:
All HASP job processing functions which are
otherwise ready for activity will become ACTIVE.
If the system is already processing jobs, it will
continue to do so.
Responses:
OK
- the HASP System functions will begin
or continue.
Examples:
1.
user
- $S
system - OK
HASP Operator's Guide - Page 70
763
HAS P
Definition:
$TF .•. [ 6J
8 [,L=n
,c=list J
SET FCB IMAGE FOR 3211 CARRIAGE CONTROL C=V
Where:
6 = Indicator for six lines/inch (default if
six or eight omitted)
8 = Indicator for eight lines/inch
L=n = Number of lines per page (may be specified
only once per command)
Acceptable numeric values for n range from
2 to 180 (default settings L=66-for 6 lines/
inch and L=88 for 8 lines/inch)
c=list = Specifications for one or more printer
carriage control channels. The "c" specification may take values 1 through 12 representing the channel number. List items
identify the line(s) to which a corresponding printer skip command is to position
the page. List items are separated by
commas. No two list items within the commandmay designate the same line number.
Acceptable values for list items range from
2 to 180.
Notes:
Action:
1) The normal operand limit specified for
HASP commands does not apply with this
command.
2) List items are not inspected to insure
specified lines are within the L=n specification or the default if L is not
specified.
3) This command is defined only when selected by the installation at HASPGEN
time by &FCBV parameter.
The FCB image used for setting carriage control via
$T printer,C=V is reset and created in accordance
with the operands of the command. If the last character of the first operand is not "8", the image is
set for six lines/inch. If the L=n operand is omitted,
a default of 66 lines/page is assumed for six lines/
inch forms and" 88 lines/page is assumed for eight
lines/inch forms.
For each channel "c=list" specified, the carriage
channel is set so that a "skip to channel" command
addressed to the printer will cause the page to be
HASP Operator's Guide - Page 70.1
763.1
II ASP
positioned at the line indicated in the list items
(see 3211 component description manuals for hardware
details). If invalid characters, invalid lines· or
channel values, or mutually exclusive parameters are
specified, the image is reset and six or eight lines
per inch null parameters are as·sumed.· Carriage
channel 1 is always set for line 1 representing the
first print line on the page. This setting must not
appear as a list item for channell.
Starting at the bottom of the page for as many lines
as possible, channels which are omitted from the
specifications are assigned automatically.
Responses:
OK - the settings requested have been made.
Examples:
1.
2.
Comments:
user
system
user
system
-
$T FCB
OK
$T FCB8,L=40,2=20,4=10,30
OK
In example 1, the user desires the default six
lines/inch carriage control image of channel i at
line 1 with 66 lines/page.
In example 2, the user desires eight lines/inch with
40 lines/page. Channel 2·is to allow skipping to
line 20 while channel 4 is to allow skipping to line
10 and 30 on the page.
Notes:
1.
2.
This command requires console authority for
both device and system commands.
The null FCB image settings are as follows:
6 lines/inch
line channel
8 lines/inch
line channel
1
1
1
1
56
57
58
59
60
61
62
63
64
65
66
2
3
4
5
6
7
8
10
11
9
12
78
79
80
81
82
83
84
85
86
87
88
2
3
4
5
6
7
8
10
11
9
12
HASP Operator's Guide - Page 70.2
763.2
HAS P
1.9
MISCELLANEOUS DISPLAY COMMANDS
Definition:
$D Dx ...
Action:
The device addresses and volume serials of all online direct access storage devices will be
displayed.
Limitations:
The 2321 cell is not included.
Responses:
aaa serial - one message for each device found
Examples:
1.
user
- $D DISKS
system - 190 IPLRES
- 191 LNKRES
- 192 NO ID
- 193 SPOOLI
2.
user
- $DD
system - 190 IPLRES
- 191 LNKRES
193 SPOOLI
DISPLAY DIRECT ACCESS DEVICES
I
HASP Operator's Guide
764
~
Page 71
HAS P
Definition:
$D line
Where:
line
Action:
The status of the s~ecified line along with the
device address assignment will be
displayed.
If no address is assigned, the address
will be filled with n***".
If·the line is
ACTIVE and associated wi th a HASP .remote workstation, the HASP status of each device on the
remote terminal will be displayed.
See device
list commands for status definitions.
DISPLAY DEVICES ON RJE LINE
=
HASP RJE line devices (see device
list commands for specification)
hardwa~e
Responses:
LINEn
aaa status - status of the specified line
RMr.devn aaa status - one response for each device
associated with the line (aaa
is the address of the line}
LINEn
NOT FOUND - HASP has no record of the
line specified
Note:
Remote console devices will not be displayed.
Examples:
1.
2~
user
- $D LINEl
system - LINEl
031
- RM3.RDl 031
- RM3.PRl 031
- RM3.PUl 031
user
- $DLNE2
system - LINE2
ACTIVE
INACTIVE
ACTIVE
DRAINED
032 DRAINED
HASP Op.era.tor's Guide
765
""!'
Page 72
HAS P
Definition:
$D R
Action:
All outstanding WTOR reply identification numbers
will be displayed.
Note:
This command is not defined if OS
is being used-.- ---
Responses:
REPLY IDS: id,id, ..• id
DISPLAY OUTSTANDING REPLY IDS
con~ole
support
- one line for each 10
reply ids
- no reply ids were
found
NO OUTSTANDING REPLY IDS
Examples:
1.
user
- $0 R
system - REPLY IDS:
0,
1, 14, 11
HASP Operator's Guide - Page 73
766
HAS P
I
Definition:
$D RMx ... [r]
vJhere:
r = the number of the remote.
all remotes will be assumed.
Action:
If the designated remote is currently associated
with a HASP RJE line, the HASP status of the line
and devices attached to the remote will be displayed.
If the remote is not associated with a
line, only the HASP status of the devices attached
to the remote are displayed.
If the remote number
is not specified in the command, the HASP status.
of. all remote devices will be displayed.
Note:
If there are no HASP remote devices $DR command
will be assumed.
Responses:
LINEn
aaa status - status of the associated line
RMr.devn aaa status - status of each device on the
remote (aaa is the address of
the line)
Note:
Remote console devices will not be displayed.
Examples:
1.
2•
DISPLAY REMOTE(S)
user
system -
$D RM3
LINE 1
RM3.RDl
RM3.PRI
RM3.PUI
-
$D RMTS
RMl.RDl
RMl.PRl
RMl.PUl
RM2.RDI
RM2.PRI
RM2.PUl
RM3.RDl
RM3. PRI
RM3.PUl
user
-
031
031
031
031
If r is omitted,
ACTIVE
INACTIVE
ACTIVE
DRAINED
*** DRAINED
*** DRAINED
*** DRAINED
021
021
021
031
031
031
DRAINED
ACTIVE
INACTIVE
ACTIVE
ACTIVE
INACTIVE
HASP Operator's Guide - Page 74
767
HAS P
Definition:
$D Ux •••
Action:
The status of all HASP controlled, non-direct
access devices attached to the local system will
be displayed along with the corresponding hardware address of the device.
Note:
If HASP multiple consoles are present, the ACTIVE
'status message will also display console authority.
Responses:
device aaa status - one line for each HASP device
DISPLAY UNITS
Examples:
1.
user
- $D UNITS
system - READERI
- PRINTERI
- PRINTER2
- PUNCHI
- TAPEl
- CONSOLE
DOC
ODE
OOF
000
INACTIVE
ACTIVE
DRAINED
INACTIVE
*** DRAINED
OlF ACTIVE
HASP Operatorts Guide - Page 75
768
HAS P
1.10
REMOTE JOB ENTRY COMMANDS
Definition:
$D Mr-rr,message
Where:
r-rr
=
=
Notes:
(1)
(2)
DISPLAY MESSAGE AT REMOTE
TERMINAL(S)
range of remote terminals--all remote
terminals from r through rr are to
receive the message.
single remote number--the remote
specified by r is to receive the·message.
A remote specification of zero (0) indicates
that the message is to be displayed at the central
operator's console.
If a range of remote terminals is specified by
a remote terminal operator only the last remote
specified will receive the message.
message
=
the text of the message desired to be
displayed at the designated remote
terminals.
If the message is enclosed
by apostrophes, the message will be
upper cased and transmitted along with
the apostrophes to the remote terminals
indicated; otherwise, the text will be
made upper case and blanks removed.
Action:
The message will be transmitted to the indicated
remote terminal if the terminal is capable of
receiving the message.
Responses:
OK
- the message has been queued for
transmission to eligible remote
terminals.
HASP Operator's Guide - Page 76
769
HAS P
Examples:
1.
user
- $D M4,Jobs rema~n~ng after 5PM will be purged
at remote -0,JOBSREMAININGAFTER5PMWILLBEPURGED
2.
user
- $D M4,'Jobs remaining after 5PM will be purged'
at remote -0, 'JOBS REMAINING AFTER 5PM WILL BE PURGED'
Note:
The value zero (0) at the beginning of the message indicates
that the message originated at the central site.
If the
message originated from a remote the value would be the
remote number.
HASP Operator's Guide - Page 77
770
HAS P
Definition:
$R type,for-id,to-id
Where:
type
for-id
to-id
Notes:
ROUTE JOB(S) OUTPUT
=
ALL--all output for the specified
job(s) is to be routed
= PRT--print output for the specified
job(s) is to be routed
= PUN--punch output for the specified
job(s) is to be routed
= JOBj--the designated output for job j
is to be routed
--= LOCAL--the designated output for all
jobs currently in the system and routed
for LOCAL devices is to be routed
= device--the designated output for all
jobs currently in the system and routed
for this device is to be routed
= RMx ... r--the designated output for all
jobs currently in the system and routed
for remote r is to be routed
= LOCAL--job(s) are to be routed to local
devices
-= device--job(s) are to be routed to this
device
-= RMx ... r--job(s) are to be routed to
remote r
1 •.
It is possible to route a job to a remote that
does not exist.
2.
In an unmodified HASP System device routing has no
meaning and will be equivalent to specifying LOCAL
or RMTr as appropriate.
3.
RMTO is equivalent to specifying LOCAL.
HASP Operator's Guide - Page 78
771
HAS P
Action:
The routing for print and punch data sets will be
altered for the job specified or for all jobs
currently in the system and routed for the output
device group specified by the second operand to
the routing as specified by the third operand.
Responses:
OK
- the job output specified has been
routed
Examples:
1.
user
- $R ALL,J4,RMT6
system - OK
2.
user
- $R PUN,RM3,LOCAL
system - OK
HASP Operator t $
772
Guid~ -P~ge
79
HAS P
2.0
STARTING THE HASP SYSTEM
HASP runs as a job under OS 360 in the MVT or MFT environment.
Although jobs in the installation may be submitted to OS independently of HASP, it is assumed that all production jobs run
by OS
will be under the control of HASP
and that HASP and OS have been tailored during the generation
processes to minimize operator action required to start the system.
2.1
PREPARATION
The Operating System must be started and running correctly prior
to any attempt to start HASP. AlIOS readers, writers and initiators should be stopped.
If an OS "warm start" is performed,
messages which indicate that the HASP System has abnormally terminated should be ignored; these messag~s result from the cleaning
out of the OS queues from the last IPL of the system.
HASP requires that direct access volumes be mounted for the purpose of
queueing JCL cards along with input data awaiting OS execution and
for saving the job output for later output to the various printer
and punch devices.
One of these volumes will be labeled "SPOOLI".
The additional volumes, if present, will be labeled "SPOOLx" where
the last character "x" is an alphabetic character or numeric digit
(other than 1); no two volumes may have the same volume serial.
The maximum number of volumes to mount is determined by the installation during the generation of HASP.
If the volumes are on-line
and ready at OS IPL time and OS has not requested that they be
removed, the SPOOL volumes are ready for the starting of HASP.
However, if the above is not true, the operator should use the OS
mount command to insure all SPOOL volumes are known to OS.
If HASP is to be "warm started", the exact physical volumes which
we're used during the last running of the system should be mounted.
It is not necessary that the volumes be mounted on the same drives;
the criteria is that all of the volumes be present and that the
data set SYSl.HASPACE has not been altered. Additional SPOOL
volumes may be added if desired.
All unit record and console devices which are to be used by HASP
must be on-line to the CPU and should be in the ready status.
If
the unit record devices are not on-line at the time HASP is started,
they will be unusable for any purpose until the next starting of
HASP.
If HASP Remote Job Entry is to be used, the line adapters
should be on-line and ready with dial data sets on AUTO and non-dial
HASP Operator's Guide - Page 80
773
1! ~ -~ the ready condition.
(I f HASP has been generated wi th
the hardware addresses of,the line adapters, the adapt, ,..::led not be on-line until an attempt is made to use them.)
if
,~Lof
2.2
STARTING THE HASP JOB
With the operating system otherwise dormant and ready for job processing, the direct access SPOOL volumes mounted and known to the
operating system, the unit record, console, and line devices online, the operator starts the HASP job by' entering the OS command:
S .HASP
- MVT start command
S HASP.Pn - MFT start command where n is the partition number
of the HASP partition (normally 0)
S HASP.S - MFT start command if HASP partition is not large
enough to contain the MFT RDR.
The start command causes OS to read the procedure "HASP" from
SYSl.PROCLIB. The "HASP" procedure is an OS reader procedure which
reads the HASP job from a direct access data set and starts an initiator to class H. The initiator will load the HASP executable module into storage and pass control to HASP.
HASP will issue an initial WTOR requesting directions from the operator. The WTOR message will appear as follows:
fInn $ SPECIFY HASP OPTIONS -- HASP-id VERSION x.x"
The operator should respond to this message using the standard OS
reply format with the corresponding reply number "nn". The text
portion of the reply must be one or more options selected from
table 2.2.1. Each option may be entered in either upper or lower
case. A comma must be used to separate.the options. Blanks are
not permitted.
If two options are entered which are considered
opposite, the latter option overrides the former. The FORMAT option, when used, has the effect of COLD starting regardless of the
WARM/COLD specification.
WARM STARTING HASP
When HASP is "warm started", it will require that all SPOOL volumes
which were up during the last execution of HASP be present and
available. HASP will assume that the volumes are intact and that
no FORMATTING will be required to run with the volumes. If a new
HASP Operator's Guide - Page 81
774
HAS P
volume with a "SPOOLx" label is present, HASP will make a few.
basic checks to determine if it has been pre-formatted, and format
the volume if necessary.
It is recommended, however, that only
pre-formatted volumes be added at HASP warm start time.
Jobs which were in execution at the time the CPU was stopped will,
on a HASP "warm start", be scheduled for execution again .. For
this reason, the operator should enter as a reply to the HASP mOR:
ROO, ' WARM, REQ '
(assuming'OO is the current reply number)
HASP will list the activity in process at the time the CPU was
stopped and wait for the operatoi to enter requests. The wait for
HASP REQUESTS serves the following purposes:
1.
It allows OS to flush the interrupted jobs from the
OS queues.
2.
It allows the operator to examine each job listed to
determine whether or not:
A.
to allow the job to be automatically
re-executed by HASP
B.
to hold the job for further investigation
C.
to cancel the job allowing it to be purged
from the system
3.
It allows the operator to examine the activity on the
output devices to determine what action to take prior
to starting normal job processing.
4.
It allows the operator to change tqe default status of
HASP initiators and devices as well as modify the status
of jobs in the HASP queue.
HASP Operator's Guide - Page 82
775
H A 8 P
When the operator has determined that the system is ready for
job processing, he should enter "$8" on the console~
The following examples list the console messages and reply
sequence expected during HA8P initialization~
1.
2.
user
system
user
system
system
user
-
S HASP
00 $SPECIFY HASP OPTIONS -- HASP id VERSION
R 00, 'COLD ,FORMAT ,
SPOOL! IS BEING FORMATTED
ENTER HASP REQUESTS
$S
user
system
user
system
user
-
S HASP.PO
00 $SPECIFY HASP OPTIONS -- HASP id VERSION x.x
R OO,'U'
ENTER HASP REQUESTS
$S
x~x
HASP Operatorts Guide - Page 83
776
HAS P
TABLE 2.2.1
HASP INITIALIZATION OPTIONS
OPTION
OPPOSITE
FORMAT
NOFMT
NOFMT
FORMAT
COLD
WARM
WARM
COLD
REP
NOREP
NQREP
REQ
REP
NOREQ
NOREQ
REQ
LIST
NOLIST
NOLIST
TRACE
LIST
NOTRACE
NOTRACE
TRACE
NONE
U
Note:
MEANING
All SPOOL volumes are to be formatted.
No SPOOL volume is to be formatted
unless HASP determines necessary.
Any job data contained on the SPOOL
volumes is to be ignored.
HASP is to continue processing where
it left off during the previous IPL.
Replacement cards are to be used for
temporary modifications to HASP for
this IPL.
This option should be
specified only under the direct supervision of the system programmer
responsible for the replacement cards.
No replacement cards are to be used.
HASP is to stop and wait for a $S
command before beginning job processing
HASP is to begin job processing when
ready to do so.
HASP is to list on a designated printer
any replacement cards read.
HASP is not to list replacement cards.
Allow tracing of HASP internal execution; this option is not active ori a
system generated for production.
Cut off the tracing of HASP internal
execution.
Take all default options.
Take all default options.
The options underlined are the normal default options.
HASP Operator's Guide - Page 84
777
HAS P
3.0
ABBREVIATED WTOR
REP~¥
nn ,.' text'
..
,.
'oJ.•'.";,
"
.,':.
'";
2.
3.
nntext
nn,text
4.
"
.
The
a.
b.
nteJ[t!:.,t:::.:::;::·~;/:.;
n Itel(~ . . •. . ':'
n'text." . . ':.
n··,·t~~;"<:
·ij~SP Opex:a~pr;!,·Sli:";·G~i.;~"\~ ··~~.g:~;,··;85
778
HAS P
4.0
HASP MESSAGES AND CODES
The following sections list those messages originating from HASP
which are not direct responses to HASP operator commands.
4.1
HASP INITIALIZATION MESSAGES
All HASP Initialization Messages are displayed by OS WTO or WTOR
requests and are listed as follows:
CORRECT THE ABOVE PROBLEMS AND RESTART HASP
Explanation: This message occurs following one or
more messages which describe why HASP direct-access
initialization could not complete normally.
System action:
The HASP job will terminate.
Operator response:
Self-explanatory.
EXTENT ERROR ON SPOOLx
Explanation: The operator did a HASP warm start.
HASP has found that the first extent of data set
SYSl.HASPACE on SPOOLx is different from what it
was previous to the warm start. This could be due
to the wrong SPOOLx volume having been mounted, a
different HASP system havin~ been started, or
SYSl.HASPACE having been scratched and reallocated.
System action: After attempting to verify the remaining required SPOOL volumes, the HASP job
terminates.
I
HASP MFT SUPPORT REQUIRES RESIDENT SVC OPTION (TRSVC)
SPECIFICATION AT SYSGEN TIME - HASP TERMINATED
Explanation: The MFT System does not contain the
proper format SVC table (four byte entries) for
use with HASP. See HASP manual section 10.1.
System action:
The HASP job will terminate.
Operator response:
Notify System Programmer.
HASP Operator's Guide - Page 86
779
HAS P
HASP module ATTACH ERROR - code
Explanation: HASP has attempted to attach a
sub-task which is required for the running of the
system. The module name indicates the ECaDIC name
of the sub-task entry module and code is the as
completion code returned.
If the system is
allowed to continue processing, the results will
be unpredictable but will cause general malfunction
as follows:
Module HASPWTR
Jobs upon completion of as execution will remain on the as job queue arid HASP will
not become aware of the user job termination.
Module HASPBRl - HASP WTO message facility will be
inactive eventually causing HASP to become interlocked attempting to use the as console interface.
System action:
HASP will attempt to process jobs.
Operator response:
Probable user error.
Stop HASP,
refer to· the OS messages and completion codes manual,
and correct the problem as indicated.
INVALID UNIT RECORD DEVICE CONTROL TABLES
Explanation: An inconsistency has been detected in
the HASP control section HASPINIT. Unit record
device control tables have been improperly generated.
System action:
The HASP job will terminate.
System programmer response: Check the assembly of
HASPINIT for improperly applied modifications and
insure the correct HASP overlay data set corresponds
with the current HASP resident module.
Reassemble
HASPINIT, recreate the HASP overlay data set, and
LINKEDIT the HASP module as required.
HASP Operator's Guide - Page 87
780
HAS P
JOB j WAS
I
READING
EXECUTING
PRINTING
PUNCHING
!
Explanation: The operator did a HASP warm start.
At the time of system stop, the job numbered j
was in the process of reading, executing, printing,
or punching.
System action:
If the job was reading, it is now
purged.
If the job was executing, HASP will restart
its execution at the first job step.
If the job was
printing, HASP will restart its print phase back a
few pages. If the job was punching, HASP will restart its punching from the beginning.
Operator response:
If the job was reading, it
should be read in again. If the job was executing,
printing, or punching, no operator response is
necessary if the default HASP action is desired.
MAXIMUM OF n SPOOL VOLUME(S) EXCEEDED
Explanation: More direct-access volumes with labels
SPOOLx have been found ·on-line than HASP has been
generated to handle (x is any alphameric character).
System action:
The HASP job will terminate.
Operator response: Probable user error. Check the
volume labels of all direct-access volumes and
remove all but "n" volumes.. Restart HASP.
HASP Operator's Guide - Page 88
781
rI
ASP
MAXIMUM OF n device type EXCEEDED
Explanation:
HASP found more reader, printer, punch,
or console devices physically on-line to the CPU than
the installation indicated for HASP to support.
System action:
The first n devices of the specified
type will be used by HASP: the additional devices
of the specified type will be ignored.
System programmer actio~:
Check the OS generation
to insure that the hardware devices correctly reflect
the system configuration and that the additional
pseudo devices generated in as for HASP do not
address a HARDWARE device or control unit on the
system.
DUNT SPOOLx ON A yyyy
Explanation:
The operator did a HASP warm start.
HASP has found that not all SPOOL volumes are mounted
which were mounted prior to the warm start.
In the
message, x completes the SPOOL volume serial number
and yyyy is the device type upon which the volume
had been mounted.
System action: After attempting to verify the
remaining required SPOOL volumes, the HASP job
will terminate.
Operator response:
Probable user error. Mount the
required volume(s) on the required devices and do a
HASP warm start, or merely a HASP cold start.
This message could also mean that the wrong SPOOLl
volume was mounted.
HASP Operator's Guide - Page 89
782
HAS P
OBTAIN FAILED ON SPOOLx WITH CC nn
Explanation:
The operator did a HASP warm, cold,
or format start.
HASP used the OBTAIN supervisor
service to get information about data set
SYS1.HASPACE on volume SPOOLx, but OBTAIN did not
work as expected.
OBTAIN returned condition code
nn to indicate the problem.
•
nn =
4 - SPOOLx was not mounted.
should not occur.
This error
•
nn
=
8 - SYS1.HASPACE was not allocated on
SPOOLx.
•
nn
=
12 - A permanent input/output error was
found during OBTAIN processing.
•
nn
=
16 - This error should not occur.
•
nn
=
20 - This error should not occur.
System action: After attempting to verify the
remaining SPOOL volumes, the HASP job will
terminate.
Operator response:
Probable user error.
If nn = 8,
allocate a data set named SYS1.HASPACE on SPQOLx and
do a HASP warm start.
If nn = 12, use the IBM
utility program IEHDASDR or IBCDASDI to re-initialize
the SPOOLx volume and then follow the procedure for
nn = 8.
HASP Operator's Guide - Page 90
783
HAS P
OLAYLIB DOES NOT MATCH RESIDENT HASP
Explanation: The job used to start HASP (normally
in SYSl.PROCLIB when HASP is started by usual
method) referenced a load module (from SYSl.LINKLIB
or a JOBLIB or STEPLIB) which was not created from
the output of the same execution of HASPOBLD which
created the referenced OLAYLIB.
System action:
The HASP job will terminate.
Operator response: Probable user error. Verify that
the correct start command and direct-access volumes
which contain parts of the HASP System are being used.
Restart HASP.
If unsuccessful, notify system
programmer.
System programmer resEonse: Verify that procedures
HASP and STRTHASP (or their equivalents, see Section
10.1.4.2 of the HASP Manual) are correctly installed
in SYS1.PROCLIB and that data sets they reference
are cataloged and mounted, etc.
If difficulty persists, re-do the install HASP program actions (sample
job HASPHASP) as described in Section 10.1.4.3.
OPERATOR MESSAGE SPACE NOT AVAILABLE
EXElanation: HASP has attempted to reserve tracks
from SPOOLI volume for remote operator message
queuing and found:
1.
The first extent of SYSl.HASPACE was not large
enough for the requested number of spool records.
2.
During HASP "warm start" the SPOOLl volume was
found incompatible with the loaded copy of HASP.
System action:
The HASP job will terminate.
Operator response:
If HASP "warm start", match the
SPOOLl volume with the HASP load module used during
the "cold start". If "cold start" consult the system
programmer.
System programmer response:
Insure the HASP generation
parameter &SPOLMSG has been correctly applied to the
system and check the extents of SYSl.HASPACE on SPOOLl
for requested space.
HASP Operator's Guide - Page 91
784
HAS P
OVERLAY REPPING ERROR
Explanation:
REP card intended for resident CSECT
may be mispunched or REP card intended for overlay
CSECT cannot be processed because no space exists to
save it.
HASPGEN parameter &OREPSIZ was not set
large enough to hold amount of overlay REP information
currently being processed or &OREPSIZ was set to zero
which eliminates capability of applying REP cards to
overlay CSECTs.
System action:
The HASP job will terminate.
Operator response:
Probable user error.
Verify that
REP cards are those intended for the HASP System which
was started.
Restart HASP and attempt to use correct
REP cards.
If unsuccessful, notify system programmer.
System programmer response: Verify that REP cards
are punched correctly according to format described
in Section 6.4.1 of the HASP Manual and/or re-HASPGEN
with parameter &OREPSIZ set larger to reserve more
space for overlay REPs.
P~RM
I/O ERR ON SPOOLx WHILE FORMATTING
Explanation:
HASP was unable to complete formatting
the first extent of SYSl.HASPACE on SPOOLx.
This may
be because a hardware error occurred or because the
SPOOL volume is not properly initialized.
System action: After attempting to process the
remaining SPOOL volumes, the HASP job will terminate.
Operator response:
If the message was caused by a
hardware malfunction, have it corrected.
If not,
the SPOOL volume may need to be reinitialized;
reinitialize it using the IBM utility program
IEHDASDR or IBCDASDI.
HASP Operator's Guide - Page 92
785
HAS P
PERM I/O ERR READING HASP CKPT
Explanation: The operator did a HASP warm start.
HASP was unable to read the checkpoint record on
SPOOLI. This may be because the wrong SPOOLI was
mounted, a different HASP System was started, or
the checkpoint record had been destroyed.
System action:
The HASP job will terminate.
Operator response: Probable user error. Mount the
correct SPOOLI volume and do a HASP warm start using
a HASP System compatible with the old HASP checkpoint.
If this fails, do a HASP cold start.
PERM I/O ERR WRITING HASP CKPT
Explanation: HASP failed to format-write correctly
the HASP checkpoint record on SPOOLI. This could
be because of a hardware malfunction or because the
HASPGEN variables used to generate HASP created a
checkpoint record too long to be written on the type
of device upon which SPOOLI is mounted.
System action:
The HASP job will terminate.
Operator response:
If the message was caused by a
hardware malfunction, have it corrected.
If the
message was caused by too long a checkpoint record,
and if the installation has devices which can support
longer records, prepare a SPOOLI volume for one of
these devices. Otherwise it is necessary to do
another HASPGEN, specifying parameters which will
create a smaller checkpoint record.
HASP Operator's Guide - Page 93
786
HAS P
SET RESTART PSW TO 0004000000aaaaaa FOR TAPE DUMP
Explanation: The special tape dump feature
has been generated by the system programmer.
The entry point to the dump routine is indicated
by the hexadecimal address aaaaaa.
Operator Response: In the event a STAND ALONE
DUMP is necessary, the operator may use the HASP
tape dump feature by using the following procedures:
1.
Ready the designated tape drive with a scratch
tape at load point with ring in.
(The device
address is determined by the system programmer,
but may be altered by over storing the halfword aaaaaa-4 with the new tape address.)
2.
Stop the CPU and press system reset (this
sets the tape mode) .
3.
Store the displayed PSW in location 0-7.
4.
Press PSW RESTART
~.
IPL arunable system and execute IMDPRDMP as
prescribed by 08/360 SERVICE AIDS manual or
equivalent post processor.
HASP Operator's Guide - Page 94
787
HAS P
PREVIOUSLY-MOUNTED VOL SPOOLx IS UNFORMATTED
Explanation: The operator did a HASP warm start.
HASP has found that the length of the first record
of the last track of the first extent of
SYSI.HASPACE on SPOOLx is incorrect. This could be
due to its having been overwritten, a different
HASP system having been started, or the wrong
SPOOLx volume having been mounted.
System action: After attempting to verify the
remaining required SPOOL volumes, the HASP job
will terminate.
Operator response; Probable user error.
If the
wrong SPOOLx volume was mounted, mount the correct
volume and do a HASP warm start. Otherwise do a
HASP cold start; any SPOOL volumes that are not
correctly formatted . will automatically be re-formatted
on a HASP cold start.
SPOOL VOLUMES HAVE DUPLICATE LABELS
Explanation: Multiple direct-access volumes have
been found with identical SPOOLx labels (x is any
alphameric character).
System action:
The HASP job will terminate.
Operator response: Probable user error. Check the
volume labels of all direct-access volumes on the
system and remove the required volumes. Restart
HASP.
SPOOLx IS BEING FORMATTED
Explanation: The operator did a HASP warm, cold,
or format start. HASP detected an unformatted SPOOL
volume which it could format and is now formatting
the volume.
S¥stem action: H~.SP will format unformatted new SPOOL
volumes on a warm start, all unformatted SPOOL
volumes on a cold start, and all SPOOL volumes on a
format start.
HASP Operator's Guide - Page 95
788
HAS P
SPOOLI IS NOT MOUNTED
Explanation: The operator did a HASP warm, cold, or
format start, and HASP could not find a non-232l
direct-access UCB with" volume serial SPOOL. The
SPOOLI volume is required to be mounted and on-line
when HASP is started~
System action:
The HASP job will terminate.
Operator response: Probable user error. Make sure
that SPOOLI is mounted, ready, and on-line. Then
restart HASP.
I
n BUFFERS AVAILABLE
Explanation: HASP has
enough dynamic storage
of buffers required to
by the HASP generation
not been able to allocate
to build the minimum number
run the system as specified
parameter &MINBUF.
System action: An attempt will be made to run with
the available buffers.
Operator response: Probable user error. Take one
of the following actions depending upon installation
procedure:
1.
Stop enough HASP functions to allow running with
less than &MINBUF buffers.
2.
Stop the HASP System, change the HASP region or
partition size, and restart HASP.
nn $SPECIFY HASP OPTIONS--HASP-id, VERSION x.x
Explanation: HASP has been given control and is requesting instructions from the operator.
System action:
Wait for REPLY.
Operator response:" Read the section STARTING THE
HASP JOB and enter the desired options using the OS
reply format.
HASP Operator's Guide - Page 96
789
HAS P
nn $SYNTAX ERROR -- RESPECIFY OPTIONS
Explanation: HASP does not recognize one or more
of the initialization options entered by the
operator.
System action:
for REPLY.
Reset to default responses and wait
Operator response:
Probable user error.
Read the
section STARTING THE HASP JOB and carefully enter
the desired options.
HASP Operator's Guide - Page 97
HAS P
4.2
HASP SYSTEM CATASTROPHIC ERROR CODES
All HASP System catastrophic errors are considered so extremely
serious in nature that HASP is unable to continue processing.
The message will be displayed on a single 1052 console, designated
by the HASP generation parameter $PRICONA, using a hardware START
I/O instruction. HASP will then go into a single instruction loop.
SYSTEM PROGRAMMER RESPONSE
A storage dump should be taken by STAND-ALONE utility and saved
for later analysis. A careful check of the HASP generation process should be made to insure that HASP modules·are assembled
properly (modifications are correctly entered and no errors
occurred during assembly), that the overlay library has been
properly created, that the linkage editor created a correct HASP
resident module, and that the HASP execution JCL corresponds to
the data sets designated by the generation JCL.
If any doubt
exists that the HASP generation process is other than perfect, a
new complete HASP generation should be undertaken.
AOI
Explanation:
HASP has detected more channel end
indications for a device than expected.
Only one
channel end indication· should be received from lOS
for each Input/Output operation which HASP has
initiated.
System action:
Continuous Loop.
Operator response:
Take a STAND-ALONE DUMP and
notify system programmer.
BOI
Explanation:
Probable user error. Either (1) an
attempt has been maqe to return an invalid HASP
buffer to the buffer pool, or (2) the free buffer
chain has been destroyed.
System action:
Continuous Loop.
Operator response:
Take a STAND-ALONE DUMP and
notify system programmer.
HASP ope~ator's Guide - Page 98
791
HAS P
EOl
Explanation:
The total number of channel end
indications from lOS has exceeded the total number
of Input/Output operations which HASP has initiated
(i.e., the total number of outstanding Input/Output
operations has gone negative).
System action:
Continuous Loop.
Operator response:
Probable user error.
Take a
STAND-ALONE DUMP and notify system programmer.
KOl
Explanation:
The Checkpoint Processor has discovered that some track groups are both free and
allocated.
System action:
Continuous Loop.
Operator action: Take a STAND-ALONE DUMP and
notify system programmer.
MOl
Explanation:
HASP has detected more channel end
indications for an RJE line than expected.
Only
one channel end indication should be received from
lOS for each Input/Output operation which HASP has
initiated.
System action:
Continuous Loop.
Operator response:
Take a STAND-ALONE DUMP
notify system programmer.
M02
Explanation: An attempt has been made to initiate
an Input/Output operation on an RJE line before the
previous operation has completed.
System action:
Continuous Loop.
Operator response:
Take a STAND-ALONE DUMP and
notify system programmer.
HASP Operator's Guide - Page 99
792
HAS P
001
Explanation: A HASP Processor already logically
executing under overlay control has issued another
call ($LINK or $LOAD) to Overlay Service without
exiting from overlay control ($RETURN and $DELETE).
Test for this condition is performed only if the
HASPGEN parameter &DEBUG is set to YES.
System action:
Continuous Loop.
Operator response: Take STAND-ALONE DUMP and
notify system programmer.
System programmer response:
Probable user error.
Check any local modifications to HASP for the errors
described above. Consult IBM Customer Engineer if
problem remains undetermined.
VOl
Explanation: The Purge Processor has discovered
that some track groups to be freed were already
free.
System action:
Continuous Loop.
Operator response: Take a STAND-ALONE DUMP and
notify system programmer.
X03
Explanation: The Execution Processor routine
XTERMIN8 which deallocates DDBs discovered a
non-existent UCB entry in the DDB being deallocated.
System action:
Continuous Loop.
Operator response: Take a STAND-ALONE DUMP and
notify system programmer.
X04
Explanation: T~e Execution Processor DDB Service
routine (XDDBCONT) which maintains the DDB frequency
table was unable to match the action DDB with the
frequency table entry.
System action:
Continuous Loop.
Operator response: Take a STAND-ALONE DUMP and
notify system programmer.
HASP Operator's Guide - Page 100
793
HAS P
xos
Explanation:
The HASP Reader/Interpreter appendage
initialization routine (XJCLTEST) could not identify
the JCL keyword value provided on the first entry
to the appendage.
The first entry is presumed to
be a JOB statement and the keyword value must be
X'65' (Release 18 and prior releases) or X'B4'
(Release 19 and subsequent releases).
System action:
Continuous Loop.
Operator response:
Take a STAND-ALONE DUMP and
notify system programmer.
HOI
,Exelanation: A HASP Control Service Program function
WhlCh was not generated was requested by a HASP
processor.
System action:
Continuous Loop.
Operator response: Take a STAND-ALONE DUMP and
notify system programmer.
System programmer response: Probable user error.
Validate HASPGEN parameters for consistency across all
modules.
Verify local modification dependency on
HASPGEN parameters.
ABND
Explanation: The HASP abnormal exit (STAE) routine
has been entered, indicating that the HASP SYSTEM
has been abnormally terminated.
The OS code indicating
the reason for the ABEND may be found in the HASP
TCB completion code field.
System action:
Continuous Loop.
Operator response: Take a STAND-ALONE DUMP ,and
notify system programmer.
HASP Operator's Guide - Page 101
794
HAS P
4.3
HASP JOB PROCESSING MESSAGES
Messages displayed during HASP job processing 'reflect conditions
which range from informational to serious errors .and are listed
as follows:
ALL AVAILABLE FUNCTIONS COMPLETE
Explanation: All HASP job processors have become
dormant and no HASP RJE lines are active.
device BACKSPACED
Explanation: Output processing on the indicated
printer is being backspaced.
System Action: The requested number of pages are
backspaced. Then processing continues.
If the
start of the data set is encountered while backspacing, processing continues at the start of that
data set.
device command
Explanation: The displayed command has been entered
from the device indicated.
System Action: The command is passed to the command
processor for further action.
device DELETED
Explanation: Output processing on the indicated
device has been deleted.
System Action: 'The job being processed on the indicated device will be queued for the next processing
phase. Output processing will be terminated.
HASP Operator's Guide - Page 102
795
HAS P
device FWD-SPACED
Explanation: Output processing on the indicated
printer is being forward-spaced.
System Action: The requested number of pages are
skipped without printing. Then processing continues.
If the end of a data set is encountered while skipping, processing continues with the beginning of the
next data set.
device IS DRAINED
Explanation:
The operator has entered a $p device
command directed to the named device and the device
has entered the DRAINED status.
fdeVice) message
lJOB j
Explanation: The Input Service Processor has
detected a /*MESSAGE control card in the input stream.
System Action:
None
Operator Response: Observe the message and take any
action which may be appropriate.
device REPEATED
Explanation: Output processing on the indicated
device has been repeated.
System Action: Thejob being processed on the
indicated device will be re-queued.
Output processing will continue.
HASP Operator's Guide - Page 103
796
HAS P
device RESTARTED
Explanation: Output processing on the indicated
device has been restarted.
System Action: The job being processed on the
indicated device will be re-queued. Output processing for the job will be terminated.
device SKIPPING FOR JOB CARD
Explanation: The Input Service Processor is now
scanning the input stream for a Job Card.
System Action: The Input Service Processor will
continue to read the input stream until a Job Card
is encountered or until an end-of-data condition
is recognized.
device SUSPENDED
Explanation: Output processing on the indicated
printer is being interrupted.
System Action: The job. being processed on the indicated printer will be re-queued in suc~ a way that
when it is processed again, printing will begin one
page before the current point or at the beginning
of the data set, whichever is less. Output processing will be terminated.
HASP Operator's Guide - Page 104
797
HAS
r
DISASTROUS ERROR - COLD START SYSTEM ASAP
Explanation: A critical I/O error has occurred
on the SYSI.HASPACE data set. A corresponding I/O
error message will accompany this message giving
details of the error.
System Action: HASP will continue processing jobs
using unaffected facilities~
Operator Response: Prevent new jobs from entering
the system, prepare all jobs in the HASP execution
queue for resubmission when HASP is restarted, allow
HASP to complete all current jobs in execution and
all output activity depleting the output queues,
and stop HASP.
The cause of the error should be
determined before COLD starting HASP.
DISASTROUS ERROR DURING CHECKPOINT - RESTART ASAP
Explanation: An I/O error has occurred while
attempting to write checkpoint information, thus
preventing any possibility of performing a future
HASP WARM start. An associated I/O error message
will accompany this message.
System Action: HASP will discontinue the checkpointing
of critical information on direct access.
Operator Response: Prevent new jobs from entering the
system, prepare all jobs in the HASP execution queue
for resubmission when HASP is restarted, allow HASP
to complete all current jobs in execution and all
output activity depleting the output queues, and stop
HASP.
The cause of the error should be determined
before COLD starting HASP.
HASP Operator's Guide - Page 105
798
HAS P
HASPWTR - PERM I/O ERR OS JOBQ
Explanation: The separate l'oad module HASPWTR,
which retrieves OS System Messages for HASP before
the end of job execution, has received a permanent
error indication while attempting I/O on the data
set SYSI.SYSJOBQE, after all standard OS direct
access error recovery actions have been attempted.
System Action:
If the operation is a write, processing continues but later attempts to read the
record may fail or read incorrect information.
If
the operation is a read, HASPWTR does not use the
incorrect information. Processing of the single
job, whole sysout MSGCLASS, or re-queue action is
terminated (depending upon when the I/O error
occurred) and other processing continues.
Operator Response: Use the $p command to prevent
any new functions from starting. When all current
functions have completed (except perhaps one or
more jobs which may not finish execution if HASPWTR
has stopped processing a MSGCLASS), re-IPL the
system, cold start OS (this re-formats SYS1.SYSJOBQE
by writing every record on it), and if no errors are
indicated, warm start HASP to continue processing.
If unsuccessful, notify system programmer.
System Programmer Response: The direct access volume
containing SYS1.SYSJOBQE should be analyzed with an
appropriate utility and/or the direct access device
changed to localize possible machine malfunction.
The IBM customer engineer should be notified if
difficulties persist.
HASP Operator's Guide - Page 106
799
HAS P
I/O ERROR ON device uuu,cc,ssss,iiii,bbcchhr
Explanation: An INPUT/OUTPUT error has occurred
on the indicated HASP device where:
device = HASP device name or volume serial if
DIRECT ACCESS
uuu
= hardware address
= CCW op-code used at the time of error
cc
ssss
= CSW status code
iiii
= sense information
bb
= bin as appropriate
cc
= cylinder as appropriate
hh
= head as appropriate
r
= record as appropriate
Associated error messages may be displayed as a
result of the error. For direct access the following
could be causes of the error:
1.
The channel, control unit, or device is
malfunctioning. This may be determinable
by moving the volume (if movable) to a new
drive, control unit, or channel and restarting
HASP.
2.
The recording surface is bad. This may be
indicated by the nature of the error and
distribution of the bbcchhr information
(A reinitialization with assignment of
alternate tracks followed by HASP FORMAT
start may be desirable).
3.
The data set SYSl.HASPACE may have been overwritten by improper data set assignment and
protection procedures. This may be indicated
by wrong length record indications.
(A
HASP FORMAT start is required).
System action: HASP will continue job processing
and submit additional error messages indicating the
severity of the error to the system.
Operator response: Determine the cause of the error
and take appropriate action.
HASP Operator's Guide - Page 107
800
HAS P
I/O ERROR ON LINEn uuu,cc,ssss,iirr,xyee
Explanation: An error has been detected on the
indicated HASP RJE line or on a device attached
to that line wnere:
n = HASP RJE line number
uuu = line adapter address
cc = CCW op-code used at the time of error
ssss = CSW status code if no Block Sequence Check
= 0000 - Indicator for normal channel end
with a Block Sequence Check at the
central CPU
= FFFF - Indicator for normal channel end
with a Block Sequence Check at
the remote site
ii = sense information if ssss=OEOO
= last character received if ssss=OCOO
and xy=94 or B4
rr = additional sense information (if STR
and ssss=OEOO)
= remote device first response character
if BSC
x = HASP CCW internal sequence identification
y = HASP CCW internal sequence command type
ee = expected response if BSC
= blank if STR
Notes:
1.
This message may also occur as an informational
message when maintenance personnel have set
HASP internal flags to log all channel ends on
the line device.
2.
The appropriate IBM Component Description System
Reference Library manual describes the status
and sense information in detail.
HASP Operator's Guide - Page 108
801
HAS P
System Action: HASP will for most line errors attempt to recover and continue processing usin~ the
line.
Operator Responses: The console log should be saved
for maintenance personnel (even if recovery is successful). Additional responses depend upon the
nature of the problem.
Specific Messages and Explanations: For STR terminals, the "IBM 2701 Data Adapter unit Component Description" (GA22-6864) should be consulted for a
complete discussion of status and sense bit meanings.
For BSC terminals that employ the USASCII transmission code, the following substitutions should be
made in response fields:
Res}2onse
EBCDIC
EOT
NAK
ACKI
ACKO
37
3D
61
70
USASCII
04
15
31
30
In the following messages, conventions observed are
as follows:
UPPER CASE LETTERS AND NUMBERS--indicate fields
which will appear on the error log exactly as
described.
LOWER CASE LETTERS--indicate fields which have
not been described in any previous example exactly the way that they appear in the error
log.
ASTERISKS (**)--indicate fields which should be
ignored as they do not contribute to the meaning
of the message.
HASP Operator's Guide - Page 109
802
HAS P
I/O ERROR ON LINEn
uuu ,02 ,0000 ,00rr, {
~!
}ee.
Explanation: A block sequence error has been detected by HASP while communicating with a MULTILEAVING terminal. This indicates that one or more
transmission blocks have been lost.
"rr" indicates
the count received and "ee" indicates the count
expected.
System Action: Any job reading in will be deleted
and must be resubmitted.
Operator Action: This represents a very serious
error. Control records may have been lost which
could cause partial loss of terminal function.
The line should be drained ($P) and restarted ($S)
as soon as practical.
I/O ERROR ON LINEn
UUU
,02 ,oeoo ,0001 , {
~~
}**
Explanation: A 2770 or 2780 terminal has disconnected without signing off and a MULTI-LEAVING terminal has subsequently connected to the same line
and is attempting to sign on.
System Action: The previous terminal will be signed
off and the line disconnected.
Operator Action: The remote terminal operator must
re-dial and attempt to sign "on again.
HASP Operator's Guide -Page 110
803
HAS P
I/O ERROR ON LINEn
uuu ,02 ,oeoo ,003D.5
t
H\l. .
**
B4 '
Explanation: A NAK has been received from the remote terminal indicating an error was detected at
the terminal.
System Action:
.are invoked.
Normal error recovery procedures
I/O ERROR ON LINEn
UUU
,02 ,oeoo ,0061 , {
~~
} 70
I/O ERROR ON LINEn
UUU
,02 ,oeoo ,0070, {
~~
} 61
Explanation: HASP has received an incorrect acknowledgementfrom a 2770 or 2780 terminal. This may indicate that an output device (printer or punch) at
the remote terminal has become not ready. It may
also indicate that an output block has been lost.
System Action:
The last block is retransmitted.
Operator Action: The remote terminal operator should
check (to any extent possible) for missing or duplicate output and request a backspace or restart if the
output looks questionable.
I/O ERROR ON LINEn
uuu,02,OCOO,OOrr,84**
Explanation: Invalid data has been received from a
"rr" indicates the first significant
2770 or 2780.
byte received.
System Action:
invoked.
Normal error recovery procedures are
HASP Operator's Guide - Page I I I
804
HAS P
I/O ERROR ON LINEn
uuu,02,OCOG,OOrr,****
Explanation: An invalid response has been received
from the remote terminal.
"rr" indicates the first
significant byte of the response.
System Action:
invoked.
I/O ERROR ON LINEn
Normal error recovery procedures are
uuu,02,OCOO,;;
{~~}, {~!} **
Explanation: An invalid termination character was
received from a MULTI-LEAVING terminal. "ii" indicates the termination character received.
System Action:
invoked.
I/O ERROR ON LINEn
Normal error recovery procedures are
uuu,02,ODOO,0037,84**
Explanation: The card reader on a 2770 or 2780 has
become not ready. This may be caused by a card feed
error or by the failure of the remote operator to
activate the END-OF-FILE switch or button.
System Action: The system waits for the reader to
be made ready and transmission to continue.
Operator Action: The remote terminal operator should
correct the problem and ready the card reader (insuring that the END-OF-FILE switch or button is
activated) .
HASP Operator's Guide - Pagelll.l
804.1
HAS P
I/O ERROR ON LINEn
UUU
,02,0000 ,0037 ,{
.
Explanation:'
System Action:
invoked.
I/O ERROR ON LINEn
~:} **
. C6
HASP has received an unexpected EOT.
Normal error recovery procedures are
uuu,**,OEOO,ii**,****
Explanation: A Unit Check has been detected by HASP
on the Communications Adapter.
For more detailed
information concerning the exact nature of the error,
the "IBM 2701 Data Adapter Unit Component Description" (GA22 .... 6864) and/or the "System/360 Component
Description--2703 Transmission Control" (GA27-2703)
publications should be consulted. Table 4.3.1 gives
an explanation of the sense bits.
HASP Operator's Guide - Page 111.2
804.2
HAS P
I/O ERROR ON LINEn
UUU
,02 ,FFFF ,OOrr, {
~4
}ee
Explanation: A block sequence error has been detected by a MULTI-LEAVING terminal. This indicates
that one or more transmission blocks have been lost.
"rr" indicates the count that was received at the
remote terminal and "ee" indicates the count that
was expected.
System Action: Any job printing on the terminal will
be interrupted, and any job punching on the terminal
will be restarted.
Operator Action: This represents a very serious error. Control records may have been lost which could
cause partial loss of terminal function. The line
should be drained ($P) and restarted ($S) as soon as
practical.
I/O ERROR ON LINEn
uuu,cc,ssss,ii**,****
Explanation: ·An unusual channel end condi tion has
been detected by HASP on the Communications Adapter.
For more detailed information concerning the exact
nature of the error, the appropriate hardware component description manuals should be consulted.
System Action:
The line is automatically restarted.
HASP Operator's Guide - Page 111.3
804.3
HAS P
Table 4.3.1
HASP RJE Typical Sense Information on 2701
ii
Meaning
80
Command Reject--"Abortive Disconnect" option of the
2701/2703 has been selected and the remote terminal
has disconnected without signing off.
40
Intervention Required--Remote terminal has disconnected without signing off and abortive disconnect
is not selected.
20
Bus Out Check--Hardware error.
10
Equipment Check--Hardware error.
08
Data Check--Line error or hardware error.
04
Overrun--Hardware error or deficiency.
02
Lost Data--Synchronization error.
01
Timeout--Expected terminal response not received
by HASP.
Table 4.3.2
HASP BSC MULTI-LEAVING Data Stream Control Sequences
rr
sequence
comments
01
02
2D
3D
SOH-STX-data-ETB
DLE-STX-data-DLE-ETB
SOH;""ENQ
NAK
70
DLE-ACKO
non-transparent data transfer
transparent data transfer
initial sequence (prior to SIGN ON)
remote did not receive last transmission correctly
last transmission received correctly
but remote has no data to transmit
Note:
The display of control sequences has meaning only when
(ssss=OCOO) •
HASP Operator's Guide - Page 111.4
804.4
HAS P
Table 4.3.3
Command Codes utilized by HASP RJE
cc
command
01
02
03
06
07
08
17
23
27
2F
33
37
3B
WRITE
READ
NOP
PREPARE (STR only)
STEP COUNT (STR only)
TRANSFER IN CHANNEL
ERROR (STR only)
SET MODE
ENABLE
DISABLE
TEST SYNCH (STR only)
SEND EOT (STR only)
SEND INQUIRY (STR only)
Table 4.3.4
HASP RJE CCW Internal Sequence Identifiers
x
sequence identification
o
STR
STR
STR
STR
STR
STR
BSC
BSC
BSC
BSC
BSC
1
2
3
4
5
8
9
A
B
C
Table 4.3.5
Hardware Remote Read Sequence
CPU Remote Read Sequence
Hardware Remote Write Sequence
CPU Remote Write Sequence
Hardware Remote Prepare Sequence
CPU Remote Prepare Sequence
Hardware Remote Read Sequenc,e
CPU MULTI-LEAVING Remote Write-Read Sequence
Hardware Remote Write Sequence
CPU MULTI-LEAVING Remote Write-Read Sequence
Prepare Sequence
HASP RJE CCW Internal Sequence Command Types
~
command type
o
Disable
Set Mode
Enable
Test Synch
Read Text
Read Response (normal)
Read Response (to ENQ)
Prepare
Write Text
Write Response
Send Inquiry (Write ENQ)
Send EOT
HASP Operator's Guide - Page 112
1
2
3
4
5
6
7
8
9
A
B
805
HAS P
Explanation:
INIT/PART "i" is idle because the
Execution Processor discovered that no jobs of the
class (es) identified by "c ... " were available in the
HASP job queue.
System Action: The execution processor will activate
the INIT/PART when jobs of the class(es) become
available.
JOB DELETED BY HASP OR CANCELLED BY OPERATOR BEFORE EXECUTION
Explanation: The job was either deleted by the
Input Service Processor of HASP or cancelled by an
operator before OS Execution Processing.
System Action:
purged.
The JCL is printed and the job is
Note: This message appears only in the printed
output stream for the job.
JOB j
EXCESSIVE INPUT STREAM DATA SETS
Explanation: The Input Service Processor has detected
an excessive number of "DD *" or "DD DATA" JCL statements
for a single job. Either the total number of Pseudo 2540
Units or the number of HASP Data Definition Tables was
exceeded.
System Action: The job will be deleted.
Pro~rammer Response:
Divide the job into a number
of Jobs such that no one job contains too many input
stream data sets.
System Programmer Response:
Increase the number of
Pseu~o 2540 Units generated and/or increase the
number of HASP Data Definition Tables generated
(see HASPGEN Parameter
&NUMDDT).
HASP Operator's Guide - Page 113
806
HAS P
JOB j -- ILLEGAL JOB CARD
Explanation: The Job Card for the indicated job
was found to be invalid by the Input Service"
Processor.
System Action:
Input Service Proce?sing is
terminated for this job.
Programmer Response:
resubmit the job.
Correct the Job Card and
System Programmer Response: The HASPGEN Parameter
&RJOBOPT, if set to "NO", will allow jobs with
illegal job cards to be processed.
JOB j
ILLEGAL /*ROUTE CARD
Explanation: The Input Service Processor has
encountered an invalid /*ROUTE control card.
System Action:
Input Service Processing for the
job is terminated.
Programmer Response:
re-submit the job.
JOB j
jobname -- BEGINNING EXEC -
Correct the /*ROUTE card and
{;~~}
i-CLASS c
Explanation: Job" j ", named "j obname ", is
beginning the execution phase in the INIT/PART
"i" as a Class "e" job.
HASP Operator's Guide - Page 114
807
HAS P
JOB j AWAITING HASP ALLOCATION
Xx-lTafia-fic'-fi-:-rns-ufficfr-e-nrliASP~re-sfo,rrce-sfefre~avaTI
able to process the specified job (j). The Execution Processor is unable to find an available DDB or
UCB needed to service the indicated job's I/O
request.•
System Action: Processing of the specified job will
continue when a DDB or UCB becomes available. Note:
If insufficient DDBs or UCBs (pseudo devices) have
been defined for the system, a permanent lockout
condition can occur.
Operator Response: If a single job is being proc-.
essed by HASP, then a permanent lockout caused by
insufficient DDBs has occurred. Notify system programmer.
If multiple jobs are being processed under control
of HASP, then DDBs or UCBs can be made available by
OS cancelling a job which did not cause the
condition.
Sfistem Programmer Resaonse: Frequent occurrence of
t is message is an in ication of insufficient resources (ODBs or UeBs) for proper system performance.
See the HASP Manual, Sections 7.1 and 10.2 for guidelines on DDB and UCB definitions.
.
HASP Operator's Guide - Page 115
808
HAS P
JOB j
BUFFER ROLL UNSUCCESSFUL ••• VERIFY NUMBER OF BUFFERS
Explanation: An insufficient number of HASP buffers
is available to process the specified job.
The Execution Processor BUFFER GET/ROLL routine was
unable to find a DDB with a HASP buffer eligible
for the buffer roll process.
System Action: Processing of the specified job
will continue when a buffer becomes available from
another HASP processor.
Operator Response:
Notify system programmer.
System Programmer Response:
If this message appears
frequently, the number of buffers defined for HASP
is insufficient for proper performance.
Note: This message is eligible for output only if the
HASPGEN variable &DEBUG was selected at HASPGEN time.
JOB j DELETED
Explanation: The Input Service Processor has deleted
the indicated job.
System Action: Thejob is routed to the Print phase
for appropriate action~ then the job is purged.
JOB j DUPLICATE JOB NAME - JOB DELAYED
Explanation: The specified job was delayed for
execution because a job of the same name was already
executing.
System Action: The indicated job Tllill be executed
when the job with the same name terminate? execution.
JOB j END EXECUTION
Explanation: The specified
execution processing.
job has completed
System Action: The specified
by the Print/Punch Processor.
job is queued for action
HASP Operator's Guide - Page 116
809
HAS P
I JOB
j ESTIMATED
f
LINES
~ CARDS
lf EXCEEDED
BY xxxxxx
Explanation: The indicated job has exceeded its
estimated number of lines/cards by xxxxxx lines/
cards.
System Action: The action taken by the system is
dependent upon the HASPGEN variable &OUTPOPT. See
Section 7.2. Either the job will be cancelled (with
or without a dump) or no further action "will be
taken.
JOB j ESTIMATED TIME EXCEEDED BY xx MINUTES
Explanation: The indicated job has exceeded its
estimated real time in the HASP Execution Phase· by
xx minutes.
System Action: The action taken by the system is
dependent upon the HASPGEN variable &TIMEOPT. See
Section 7.2. The job will either be cancelld (with
or without a dump) or no further action will be
taken.
JOB j HELD
Explanation: The lndicated job has been placed in
HASP Hold Status for one of the following reasons:
1.
The Job Card specified "TYPRUN=HOLD".
2.
The device from which the job was read was
set to hold all jobs.
System Action:
None.
Operator Response: The reason why the job was placed
in HASP Hold Status should be determined and the job
should be released when appropriate for further
processing.
HASP Operator's Guide - Page 117
810
HAS P
JOB j HELD FOR THE FOLLOWING VOLUMES -text
Explanation: The job indicated has been placed in
HASP Hold Status pending availability of the volumes
indicated by "text".
System Action: The job is placed in HASP Hold
Status and input processing continues.
Operator Response:
Insure that the requested volumes
are available to be mounted and release the job.
JOB j IS PURGED
Explanation: HASP has completely finished
processing the designated job and all HASP facilities
belonging to the job are made available for reuse.
JOB j JCT OVERFLOW - OUTPUT LOST
Explanation: The indicated job generated more output
data sets than were provided for by HASPGEN.
See
Section 7.2. The Execution Processor discovered
that the JCT for the indicated job could not hold
another PDDB representing additional SYSOUT data.
System Action: The job will continue to process
nQrmally except those data sets in excess of the
maximum will not be printed or punched.
Operator Response:
condition.
Notify system programmer of
HASP Operatorts Guide - Page 118
811
HAS P
JOB j LOAD 'xxxx' FORMS IN device
1::'.. J.ana-t'lOn:
---L.IAp
meh 'J n d'
. 1"
~ \..
"
"
:.1.:_
lCa..J.-ed ~)-oS.J---re-q-U1res~w-!-a-t--'.'.-x-x-x-x
type forms be mounted in the indicated device before
output processing can continue.
I ... , , - ,
System Action: Output processing is halted on the
specified device until an appropriate operator
response is received.
Operator Response: The operator should load the
requested forms (or verify that the requested forms
are loaded) and enter a start ($S) command for the
indicated device.
If the operator does not wish to
continue processing at this time, either the restart
($E) command, the interrupt ($I) command, or the
delete ($C) command will be accepted at this time
and the output processor will assume that the requested forms have not been mounted.
JOB j ON device -- jobname programmername
Explanation: A Job Card has been detected in the
input stream from the indicated device and the
associated job has been assigned a HASP Job Number
of "j". The jobname and programmername displayed
are the job name and programmer name from the Job
Card.
System Action:
The previous job (if any) is queued
for the execution phase and input service processing
is initiated for the new job.
JOB j
PRINTINGj
,
{PUNCHING ON devlce
Explanation: The indicated job is now being processed by the Output Service Processor.
HASP Operator's Guide - Page 119
812
HAS P
JOB j TERMINATED
Explanation: A permanent I/O error, while reading
input from a SPOOL volume for the specified job,
was encountered. The nature of the error was displayed by a previous "I/O ERROR ... " message.
System Action:
automatically.
The indicated job is cancelled
Operator Response:
Notify system programmer.
LINEn -- INVALID PASSWORD
Explanation: A Remote attempted to sign-on the
specified line with an invalid password.
s!stem Action: The attempted sign-on is not
a lowed and the line is left in an inactive
status.
Operator Action: The remote operator should
determine the valid password and correct the
sign-on card to reflect this information.
LINEn -- INVALID SIGNON
Explanation: A Remote attempted to sign-on the
specified line with an invalid sign-on card. A
sign-on card may be invalid if:
1.
The Remote name is spelled incorrectly.
2.
The Remote specified has not been
generated.
3.
The Remote specified is attached to
another line.
4.
The remote name aoes not begin in column 16
System Action: The attempted sign-on is not
allowed and the line is left in an inactive
status.
Operator Action: The remote operator should verify
the spelling of the Remote.
If the Remote is
attached to another line, steps should be taken
to correct this conflict in Remote assignments.
System Programmer Action:
If the required Remote
has not been generated another HASPGEN will be
required to correct this situation.
HASP Operator's Guide - Page 120
813
HAS P
r, . message from operator
Explanation: The operator at a central console
(r=O) or at a remote terminal identified by the
value r has entered the displayed message via the
$DM (display message) command.
UNREADABLE OVERLAY--REBUILD OLAYLIB AND WARM START
Explanation: The HASP Overlay Service Routines have
received a permanent error indication while attempting to read from the data set whose ddname is
OLAYLIB, after all standard OS direct-access error
recovery actions have been performed.
System Action: The HASP Processor which requested
the overlay module is placed on a permanent $WAIT
state. Other processors continue to function.
Operator Response: Notify the systems programmer.
Enter $p to prevent new functions from starting.
System Programmer Response: Re-install HASP as described in section 10.2.2.3. Ask the operator to
warm start HASP to continue. processing.
HASP Operator's Guide - Page 121
814
HAS P
5. 0
CONSOLE SUPPORT
HASP provides the installation the option of allowing either HASP
or OS to control the local operator console devices.
Although the
format of the entry of OS and HASP commands is the same regardless
of the option selected by the installation, the physical control of
the devices differs. The section HASP CONSOLE SUPPORT provides sufficient information for the operator to control HASP console devices,
and the section OS CONSOLE SUPPORT provides sufficient supplementary
information to the OS Operator's Guide for control of OS consoles.
5.1
HASP CONSOLE SUPPORT
Up to eight locally attached devices may be used as HASP consoles.
The following devices may be used as consoles for the type of
input-output listed:
1052
1053
1443
2260
printer keyboard
printer (on local 2848)
printer
display (on local 2848)
-
input and output
output
output
input and output
Each console device will be assigned a HASP physical device identification which is used to reference the device via HASP commands;
the identifications are: CONI, CON2, •••.
The $DU (DISPLAY UNITS) command may be used to determine the HASP
physical device with the hardware address
assigned to the device.
HASP Operator-s Guide - Page 122
815
HAS P
CONTROLLING CONSOLE MESSAGE OUTPUT
When HASP is started, all local consoles will be set to display
all messages generated by OS, including problem program WTO and
WTOR messages, as well as those generated from within HASP.
Depending upon the system, it is possible for a large volume of
messages to be displayed upon the console devices. A large message
volume not only makes it difficult for an operator handling a part
of the operator work load to quickly identify messages intended for
his use, but it tends to tie up the system waiting on the speed of
the slowest console device.
HASP provides a means of classifying
messages so that each operator can cause only desired messages to
be displayed at his console. Each message has one or more logical
console classifications:
LOG
ERROR
UR
TP
TAPE""'
log console messages
error messages
unit record messages
HASP RJE line messages
tape console messages
MAINmain operator's console messages
OS
OS WTO messages
Each message will also have an associated level of importance:
1
3
4
7
non-essential messages
normal messages
messages requiring action
essential messages
HASP Operator's Guide - Page 123
816
HAS P
By appropriate setting of the output classifications of a given
HASP console, the operator is able to select only those messages
he desires to see. As an example, CONI is a 1052 and CON2
is a 1443. Because the 1443 is a high speed device, it is allowed
to display all ,messages generated within the system.
However, the
1052 is set to display only messages to the main operator, MAIN,
at a level of importance above 3.
The setting for the 1052 would
be accomplished using the following commands:
$T CONl,RESET
$T CONl,3,MAIN
- turn off all output
~
set level of importance and
logical console class
If it is desired to assign a console to more than one logical
console class, the following command sequences could be used:
1.
$TCONl,RESET
$T CONl,3,MAIN
$T CONI, ERROR
- turn off all output
- set level and logical class
- add an additional logical class
2.
$T CONl,RESET
$T CONl,3,MAIN,ERROR
- turn off all output
- set level and both logical classes
Setting the HASP console output characteristics applies equally well
with multiple or single console options. The only difference is the
flexibility achievable in
mUltiple console configurations.
Resetting a console although preventing console message output will
not, however, prevent responses to HASP commands from being displayed;
HASP command responses will always be displayed on the console upon
which the command was entered.
TABLE 5 .1.1 lists the classifications
for each message originating from HASP.
In addition to the $T command, the following commands may be used
to control console output:
$Z CONn
$S CONn
- turn off all output to console (same as RESET)
- turn on all output to console (same as level 0
and specifying all of the logical console
classes)
HASP Operator's Guide - Page 124
817
HAS P
TABLE 5.1.1
HASP MESSAGE CLASSIFICATIONS
LEVEL
MESSAGE
"ERROR" CONSOLE MESSAGES
ALL AVAILABLE FUNCTIONS COMPLETE
DISASTROUS ERROR - COLD START SYSTEM ASAP
DISASTROUS ERROR DURING CHECKPOINT - RESTART ASAP
I/O ERROR ON device uuu,cc,ssss,iiii,bbcchhr
I/O ERROR ON LINEn uuu,cc,ssss,iirr,xyee
7
7
7
7
7
"UR" CONSOLE MESSAGES
ALL AVAILABLE FUNCTIONS COMPLETE
SPOOL VOLUMES A~E FULL
JOB j LOAD 'xxxx' FORMS IN device
JOB j ON device -- jobname programmername
device BACKSPACED
device command (excluding remote console devices)
device DELETED
device FWD-SPACED
device REPEATED
device RESTARTED
device SKIPPING FOR JOB CARD
device SUSPENDED
JOB j HELD
device IS DRAINED
JOB j -- ILLEGAL JOB CARD
JOB j -- ILLEGAL /*ROUTE CARD
JOB j DELETED
JOB jlPRINTINGjON device
PUNCHING
JOB j PURGED
7
7
5
5
3
3
3
3
3
3
3
3
3
1
1
1
1
1
1
"TP" CONSOLE MESSAGES
ALL AVAILABLE FUNCTIONS COMPLETE
I/O ERROR ON device uuu,cc,ssss,iiii,bbcchhr
I/O ERROR ON LINEn uuu,cc,ssss,iirr,xyee
r, message from operator (at remote r)
device command
LINEn ~- INVALID PASSWORD
LINEn -- INVALID SIGNON
REMOTEr DISCONNECTED
REMOTEr STARTED ON LINEn
device IS DRAINED
7
7
7
7
3
3
3
3
3
1
HASP Operator's Guide - Page 125
818
HAS P
"TAPE" CONSOLE MESSAGES
ALL AVAILABLE FUNCTIONS COMPLETE
device} message
{ JOB j
JOB j HELD FOR THE FOLLOWING VOLUMES--
7
5
5
"MAIN" CONSOLE MESSAGES
ALL AVAILABLE FUNCTIONS COMPLETE
JOB j BUFFER ROLL UNSUCCESSFUL--VERIFY NUMBER OF BUFFERS
JOB j JCT OVERFLOW - OUTPUT LOST
JOB j TERMINATED
SPOOL VOLUMES ARE FULL
device} message
{ JOB j
INIT} i IDLE - CLASS = classes
{ PART
JOB j DUPLICATE JOB NAME - JOB DELAYED
JOB j ESTIMATED LINES} EXCEEDED BY xxxxxx
{ CARDS
JOB j ESTIMATED TIME EXCEEDED BY xx MINUTES
JOB j HELD FOR THE FOLLOWING VOLUMES-JOB j -- jobname -- BEGINNING EXEC - {INIT} i-class c
JOB j AWAITING HASP ALLOCATION
PART
JOB j HELD
JOB j -- EXCESSIVE INPUT STREAM DATA SETS
JOB j END EXECUTION
7
7
7
7
7
5
5
5
5
5
5
3
3
3
1
1
"OS" CONSOLE MESSAGES
ALL AVAILABLE FUNCTIONS COMPLETE
(alIOS and problem program WTO and WTOR requests)
HASPWTR - PERM I/O ERR OS JOBQ
UNREADABLE OVERLAY - REBUILD OLAYLIB AND WARM START
7
5
5
5
"REMOTE" CONSOLE MESSAGES
JOB j ON device--jobname programmer name
device SKIPPING FOR JOB CARD
JOB j LOAD 'xxxx' FORMS IN device
r, message from operator (at remote r)
"LOG" CONSOLE MESSAGES
(All messages routed to any other console)
HASP Operator's Guide - Page 126
HAS P
CONTROLLING COMMAND ENTRY
All correctly entered commands will be accepted for action when entered upon the central console of a single console system. However,
when multiple local input consoles are available, some of which are
accessible to large numbers or inexperienced personnel, it is desirable to limit the authority of one or more of the consoles to
control the various functions of the system. HASP consoles may,
therefore, be assigned one or more authority groups as follows:
o
1
2
4
display only
system control
device control
job control
Any console may be used to enter HASP display commands; these commands are not deemed to be harmful to the system. However, to control the system from a given console, that console must be authorized for entry of the command; if not, the entry will be rejected
with an INVALID COMMAND response or INVALID OPERAND if the command
is generally acceptable but use of the operand is unauthorized.
"System Control" authorization is required for the entry of any OS
command or any command which attempts to alter the authorization
of a console.
At HASP initialization each console is given 'a default authorization:
by use of the $DU (DISPLAY UNITS) command each console will be listed
and if ACTIVE the sum of the authorizations will be displayed (applicable only for multiple consoles).
If a console is eligible for full
control, the authorization value is 7 (1+2+4).
If a console is eligible for control of jobs and devices, the authorization value is
6 (2+4).,
I
Because HASP local readers (card, tape, and internal) may be used
for command entry, these devices have an associated command authority
with the default setting of 7 (full authority).
CHANGING CONSOLE AUTHORIZATION
I
An operator via a HASP local console or reader device authorized
for system control may alter the authority of any other local HASP ·
console in the system via the "$T CONn,A=value" command (value is
the sum of the desired authority group numbers). As long as authorization changes are made from HASP consoles, no combination of commands can be entered which will cause all consoles to be unauthorized
as a "system control" console.
HASP Operator's Guide - Page 127
820
HAS P
CHANGING READER AUTHORIZATION
An operator via an OS console or HASP local console with System and
Device authority may change the command authority of any local HASP
reader in the system via the "$T reader device, A=value" command.
The operator must not use an authorized reader to turn off the System authority of a HASP console while that console has sufficient
commands pending which will turn off the System authority of all
HASP readers and other consoles on the system. This sequence of
events will result in loss of operational control of the system.
HASP Operator's Guide - Page 127.1
820.1
HAS P
(The remainder of this page intentionally left blank.)
820.2
HAS P
HASP 2260 OPERATION
HASP 2260 consoles operate in "roll mode" such that available
messages replace displayed messages at a specified predetermined
rate.
In order to enter commands through 22605, the following
procedure must be used:
1.
Press SHIFT and ENTER
2.
When MI (Manual Input Symbol) appears at the beginning of
one of the display lines, the system is ready to accept
commands. The console is interlocked such that no
further display messages will be processed until the
command is entered.
3.
Enter the desired command through the 2260 keyboard.
4.
To send the command to the system, press SHIFT and ENTER.
The command will be read by HASP, the screen made available for display messages.
If mistakes are made during command entry, use the BKSP key and
re-type over the incorrect portions, space the cursor beyond the
last command character if necessary, then do step 4. To cancel
a command without entering it, backspace the cursor until it is
immediately to the right of the MI symbol, then do step 4.
The screen should not be cleared by use of the keyboard ERASE when
the MI symbol is on the screen. If this is done, the usual symptom
will be that the system will not respond with MI when ENTER is
pressed. The following special recovery procedure should be used:
1.
Re-clear the screen by pressing SHIFT and ERASE.
2.
Press SHIFT and START to manually produce the MI symbol.
3.
Continue as above from step 3 to enter a command.
HASP Operator's Guide - Page 128
821
HAS P
HASP 1052 OPERATION
HASP 1052 consoles normally operate in the output mode. The system
is free to print messages to the operator whenever a message is
ready. In order to enter commands through 1052s, the following
procedure must be used:
1.
Press the REQUEST key at the right end of the keyboard.
2.
When the PROCEED light located above the keyboard glows, enter
the desired command using the 1052 keyboard.
3.
Upon completion of command entry, enter EOB to indicate completion of entry.
(Press top row keys ALTN CODING and numeric
5 simultaneously for EOB)
If mistakes are made during entry, enter CANCEL and do steps 2 and
3 again.
(Press top row keys ALTN CODING and numeric 0 simultaneously for CANCEL). To cancel a command after one or more characters have been entered, enter CANCEL and then enter EOB when the
proceed light glows.
HASP Operator's Guide - Page 129
822
H'A S P
"5.2
OS CONSOLE SUPPORT
HASP utilizes standard OS facilities for displaying information on
the. OS controlled consoles and accepts HASP commands from OS by
monitoring the console inputs. All devices supported by OS continue
to. be supported when HASP is running in the system.
CONTROLLING CONSOLE MESSAGE OUTPUT
In the process of controlling devices and jobs, HASP originates
messages to be displayed on one or more OS consoles. Depending upon
the system, it is possible for a large volume of messages to be displayed upon the console devices. A large message volume not only
makes it" difficult for an operator handling
part of the operator
work load to quickly identify messages intended for his use, but
tends to tie up the system waiting on the speed of the slowest device.
HASP utilizes the OS Multiple Console Support and provides
to OS message group routing codes for each HASP originated message
(see OS Operator's Guide).
TABLE 5.1.1 lists all HASP originated
messages with the appropriate HASP logical console classifications.
The equivalent OS routing codes are as follows:
a
LOG
ERROR
UR
TP
TAPE
MAIN
-
MASTER CONSOLE INFORMATION
SYSTEM ERROR MAINTENANCE
UNIT RECORD POOL
TELEPROCESSING CONTROL
TAPE LIBRARY, DISK LIBRARY, TAPE POOL, DIRECT
ACCESS POOL
- MASTER CONSOLE ACTION, MASTER CONSOLE INFORMATION
Each HASP message will also have an associated level of importance:
1
3
5
7
-
non-essential messages
normal messages
messages requiring action
essential messages
By appropriate setting of the output routings of the console device,
the operator is able to select only the OS messages as well as HASP
messages desired.
The operator should refer to the OS 360 Operator's
Guide for correct use of the OS "VARY unit,CONSOLE" command.
The
HASP "$T" CON" command may be used to set the desired level of importance for HASP originated messages.
HASP Operator's Guide - Page 130
823
HAS P
CONTROLLING COMMAND ENTRY
In a system running with OS Multiple Console Support, consoles
may be physically available to unauthorized personnel. OS provides a facility by which each console is given authorization to
enter selected groups of commands.
HASP will, when accepting a
command from OS, examine the entry console authorization and
reject unauthorized entry as an INVALID COMMAND or INVALID OPERAND
as appropriate.
The OS command authority groups and the HASP
equivalents are as follows:
OS GROUP
HASP
o
DISPLAY ONLY
JOB CONTROL
DEVICE CONTROL
SYSTEM
1
2
3
INFO
SYS
IO
CONS
The OS "VARY unit,CONSOLE,AUTH" conunand may be used for the control
of the command entry authorization of the OS controlled consoles.
HASP Operator's Guide - Page 131
824
HAS P
6.0
READER SUPPORT
HASP supports numerous types of devices for entry of Operating
System commands, HASP commands, control cards, and user
jobs to be executed under control of the HASP/OS environment. Via
local attachment to the central CPU the following device types
are supported:
IBM 2501 Card Reader
IBM 2540 Card Reader
IBM 24xx Tape Drive (using non-labeled tape with maximum
block size set at HASP generation time--if seven
track tape written with 800 BPI, odd parity, data
convert on)
HASP provides an additional local reader interface enabling programs and system routines to submit commands, control cards, and
jobs to HASP as though submitted through a physical reader device.
This device-like interface is known as an internal reader (INTRDR)
and is controllable through OS and HASP commands in a manner
similar to 2540 reader devices. Devices which are connected
to HASP remote work stations and supported as readers allow
for entry of as commands, user jobs, and a subset of the HASP
commands.
HASP Operator's Guide - Page 132
825
HAS P
6.1
CONTROLLING HASP READERS
-'Ph~r-ough----t-h-e-us-e------o-f--HA-S-P-op-erator-command~s------t1re-op-e~rator-c-o~n-e-ro-Ts-trlE~
HASP reader devices. Operators at remote work stations may control
only those HASP readers which are attached to the remote work station.
Commands which control HASP readers are as follows:
Command
General Use
$C reader
Cancel the current job being read on the
reader thus causing the reader to skip for
the next job or HASP control card.
Stop HASP from using the reader device for
future job streams.
Start HASP use of the reader device for
future job stream input.
Set the reader device to place input jobs
in the HOLD status--reset by $S reader
Set the command authority for the local
reader device
Halt the reader device until $S reader is
entered
$P reader
$S reader
$T reader,HOLD $T reader,A=a
$Z reader
The formal definitions of these commands may be found in the HASP
OPERATOR COMMANDS section of this manual.
The following paragraphs discuss special methods of controlling local readers. The remote operator should refer to the operator's .
guide provided for the supported work station.
HASP LOCAL CARD READERS
Each 2540 or 2501 Card Reader on the system is assigned a HASP name
at HASP initialziation time; responses to the $DU command display
the HASP reader names along with the corresponding hardware addresses.
STARTING HASP LOCAL CARD READERS - There are three methods of causing
HASP to begin using a HASP card reader device:
1.
Enter the $S reader command when the device is halted,
drained, or inactive.
2.
Ready the reader with cards prior to replying to the initialization WTOR. This is equivalent to entering a $S
reader command.
3.
If the Automatic Starting Reader feature is selected by
the installation, ready the reader with cards at any time
unless the $P reader command has been entered.
HASP Operator's Guide - Page 133
826
HAS P
If OS has allocated the card reader for other functions when HASP
is initialized, there will be no attempt to use the reader for
reading jobs unless a $S reader command is entered.
To prevent
inadvertent OS allocation of the reader to other jobs, HASP simulates an OS vary off-line command prior to its initial use of the
device and when each $S reader command is entered.
SHARING HASP LOCAL CARD READERS WITH OS JOBS - Because HASP is a
long running job it is desirable for HASP not to prevent OS from
allocating the card reader devices to other jobs within the system.
The operator is then able to start OS readers to a HASP card reader
or enter jobs which require direct reading from a card reader.
The
operator should observe the following precautionary rules when
other jobs are to use HASP reader devices:
1)
Enter a HASP $P command for the device and allow the
device to become drained before varying the device
on-line or replying to OS allocation requests.
2)
Insure that the job has finished reading cards and will
not attempt to read more cards prior to entering a HASP
$S command for the device.
HASP INTERNAL READER
Although the HASP internal readers are not real devices on the
system, they may be controlled by the operator in much the same
way as real devices.
If the operator desires to prevent problem
program submission of jobs to HASP, he should enter the as command:
VARY
unit,OFFLINE
once for each internal reader.
Each unit specified is the
three digit address for an internal reader obtainable from HASP
when $DU command is entered. as will issue an allocation request
when a user job desires the unit. The operator then has the option
of cancelling the job or allowing the device to be assigned.
In addition to the control of as allocation, the operator can cause
all jobs submitted via the internal reader to be placed in the HOLD
status via the command:
$Tinternal reader,HOLD
This allows problem programs to submit jobs to HASP but prevents
the submitted jobs from executing until the operator specifically
releases them.
HASP Operator's Guide - Page 134
827
HAS P
To prevent the problem program from entering HASP commands via an
internal reader, the operator may restrict the command authority
of the device by entering:
$T internal reader,A=O
In order to prevent as commands from taking effect the system programmer must have properly restricted the as reader procedure used
by HASP to pass jobs to as.
HASP LOCAL TAPE READERS
HASP support of local tape readers differs from that of the card
reader devices in that the tape drive address assignment to a HASP
TAPE is specified by the operator by the command:
$S tape reader,unit
Because of speed and characteristics of tape drives HASP does not
allow sharing of the tape device with problem programs; therefore,
HASP will not start a tape that is allocated to another function
and will prevent as allocation while in use by HASP.
HASP Operator's Guide - Page 135
828
HAS P
6.2
HASP INPUT STREAM
The input job streams submitted to the Operating System via HASP
follow the conventions and format described in the OS/360 Job
Control Language manual. Within these conventions HASP requires
that some cards be specified in a particular manner and provides
for optional control cards which would appear as comments to the Operating System in systems without HASP.
This section discusses
the use, format, and placement of these cards.
HASP JOB CARD
The JOB card is a variable-field control card which defines the
beginning of a job (and, of course, the end of the previous job if
there is one) within the input stream.
In addition, certain parameters are passed to HASP and to the Operating System via fields
and subfields punched into the JOB card.
The format of the JOB card is basically as defined in the Job
Control Language Manual.
In particular, HASP requires that the
accounting information field be punched in the following format:
(pano,room,time,lines,cards,forms,copies,log,linect)
where:
pano
=
Programmer's accounting number. This subfield
MUST BE PRESENT and must consist of one to four
alphameric characters. (Example:
"4301 ,,-)- - - -
room
=
Programmer's room number. This subfield MUST BE
PRESENT and must consist of from one to four
alphameric characters.
(Example:---",E30~
time
=
Estimated execution time in minutes. This subfield
is optional and may consist of ~ to four numeric
digits.
If omitted, a standard value will be
assumed.
(Example:
" ,30" for 30 minutes)
lines
=
Estimated line count in thousands of lines.
This
subfield is optional and may consist of ~. to four
numeric digits.
If omitted, a standard number of
lines will be assumed.
(Example:
",5" for 5000 lines)
. cards
=
Estimated number of cards to be punched. This subfield is optional and may consist of up to four
numeric digits.
If omitted, a standard number of
cards will be assumed.
(Example:
",200" for 200
cards to be punched)
.
HASP Operator's Guide - Page 136
829
HAS P
forms
=
Special forms for printing entire job. This subfield is optional and may consist of ~ to four ~
meric characters. If omitted, standard forms "STD."
will be assumed.
(Example:
",5" for 5-part forms)
copies
=
Number of times the print output is to be printed.
This subfield is optional and may consist of ~ to
two numeric digits.
If omitted, one copy will be assumed.
(Example:
",2" for two copies) This count
applies only to data sets printed on job forms and
demand forms. Only one copy of data sets indicated
as specially routed data sets will be produced.
log
=
HASP System Log option. This subfield is optional
and may consist of one character. If this character
is an "N", the HASP System Log will not be produced.
If any other character, or if omitted, the log will
be produced.
linect =
Lines to be printed per page. This subfield is optional and may consist of ~ to two numeric digits.
If coded as "0" (zero) no automatic overflow will be
produced. If omitted, a standard value will be assumed.
(Example:
",34" for 34 lines per page)
I
The other fields on the JOB card are also interpreted for accounting
purposes and Job control.
The job card may be continued in accordance with the Operating System Job Control Language specifications.
To omit a specific subfield, the comma normally punched following
the subfield should be punched in the first column of the subfield.
To omit the remainder of the subfields, the closing right parenthesis should be punched following the last subfield entered.
The following would be a typical JOB card:
IIORBIT
II
JOB (7808,E305,,2,200),
CONTINUED
'J. Jackson' ,MSGLEVEL=l,CLASS=B
In this case:
pano
= 7808
room
= E305
time
= 2 minutes
(assumed value)
lines = 2000 lines
cards = 200 cards
HASP Operator's Guide - Page 137
830
HAS P
forms
=
standard forms
copies
=
1 copy (assumed value)
log
=
yes (assumed value)
linect
=
standard value (assumed)
(assumed)
HASP PRIORITY CARD
The PRIORITY card is a fixed-field control card used to aqsign
a set priority to a job. The format of the card is as follows:
Columns
1 - 10
11 - 15
16 - 17
18 - 80
/*PRIORITY
blank
p(left justified)
ignored
where "p" is either a number (between 0-15) or the character "*".
If "p" is a number, the value of "p" will be assigned as the priority
of the job following the PRIORITY card.
If "p" is the character
"*", or if the PRIORITY card is not present, the priority of the
job will then be determined by the estimated execution time and the
estimated lines on the JOB card.
The PRIORITY card must immediately precede the JOB card.
If it
does not, the PRIORITY card will be ignored and the input stream
will be flushed until a job card (or another PRIORITY card) is
found.
HASP ROUTE CARD
The ROUTE card is a fixed-field control card which allows the user to
specify the location to which his output is to be printed or punched.
The format of the card is as follows:
Columns
1 -
7
8 -
9
10 - 14
15
/*ROUTE
blank
PRINT or PUNCH
blank
HASP Operator's Guide - Page 138
831
HAS P
16 - 23
24 - 80
one of the following device
specifications:
LOCAL
Any local device
REMOTEn
Remote Terminal "n"
PRINTERn
Printer "n"*
PUNCHn
Punch "n"*
ignored
A single ROUTE card can be used to direct either the print or punch
routing but not both. If both print and punch are to be routed,
two cards must be used.
The ROUTE cards should be placed immediately after the JOB card.
*
NOTE:
The PRINTERn and PUNCHn specifications are the same
as LOCAL unless the specified printer or punch is
subject to local print/punch routing.
.
HASP MESSAGE CARD
The MESSAGE card is a fixed-field control card which permits the
user to send messages to the operator via the operator console at
HASP job input time. ·The format of the card is as follows:
Columns
1
10
12
72
- 9
- 11
- 71
- 80
/*MESSAGE
blank
message to be written
ignored
All leading and trailing blanks are removed from the message before
writing it on the console.
If MESSAGE cards are included as part of a job they should be
placed immediately following the JOB card (or after any ROUTE
cards). In such cases the· job number is appended on the front
,of the message(s).
If a MESSAGE card is not included within the boundaries of a job,
the input device name is appended on the front of the message.
HASP Operator's Guide - Page 139
832
HAS P
HASP SETUP CARD
The SETUP card is a variable-field control card which p_ermi ts the
. user to indicate the need for certain volumes during the execution
phase of his job. The format of the card is as follows:
Columns:
I
1 7
8 - 15
16 - 71
72 - 80
/*SETUP
blank
volume identifiers separated by commas
(i.e., vvvvvv, wwwwww, xxxxxx, .•. )
ignored
The volumes required are listed on the console at the time that the
job enters the system. The job is then placed in "hold" status
pending subsequent release by the operator when the required volumes
are available.
The SETUP card should be continued with MESSAGE cards and placed
with the ROUTE and other MESSAGE cards after the JOB card.
HASP COMMAND CARD
The COMMAND card is a "variable-field" control card used to enter
HASP operator commands into the system. The format of the card is
as follows:
Columns:
1 3
4 - 71
72
73 - 80
/*$
operator command verb and operands
If "N" the command will not be repeated
on the operator's console.
ignored
Restrictions concerning commands which can be entered from remote
terminals are listed under the HASP OPERATOR COMMANDS section of
this manual.
All COMMAND cards must be placed in the input stream prior to any
JOB card. COMMAND cards within jobs will be ignored.
HASP Operator's Guide - Page 140
833
HAS P
OS COMMAND CARD
The OS command card is a variable-field control card, the format
of which is described in the 05/360 Operator's Guide. This card,
if submitted through the HASP input stream, must fall within a job
of the input stream and is passed to OS at the time the job is submitted for OS execution. The acceptability of the OS COM}~ND CARD
is determined by the system programmer when creating the HASP
reader procedure on the SYSI.PROCLIB data set.
HASP Operator's Guide - Page 141
834
HAS P
6.3
LOCAL READER ERROR PROCEDURES
Unrecoverable ~rrors encountered. while. reading jobs and SPOOLING
the data to direct access de~ices Will result in an error message
to the operator and the deletion of the job being read.
The
operator should re-submit any job so deleted in its entirety to
HASP.
Errors on local readers such as read checks, feed stops, etc.
will be processed by the Operating System.
The operator should
follow the procedures described in the appropriate component description manual for the device as supplemented by the 08/360
Operator's Guide.
Since HASP selects cards read by the IBM 2540
in pocket 2, cards which are non-processed run out (NPRO) will
be separated from those read, the last card in pocket 2 being the
card in error on data and validity checks.
HASP Operator's Guide - Page 142
HAS P
7.0
PRINT AND PUNCH SUPPORT
HASP supports numerous printer and punch devices for the output
of HASP System Log messages, Operating System messages and
problem program SYSOUT data sets. Via local attachment to the
central CPU the following devices are supported as printer or
punch devices as appropriate:
IBM
IBM
IBM
IBM
IBM
1403
3211
2540
1442
2520
PRINTER
PRINTER
PUNCH
PUNCH
PUNCH
HASP Operator's Guide - Page 143
836
HAS P
7.1
CONTROLLING HASP PRINTER AND PUNCH DEVICES
Through the use of HASP operator commands the operator controls
the HASP printer/punch devices.
Operators at remote work stations
may control only those HASP printer/punch devices which are attached
to the remote work station.
Commands which are defined for direct
control of HASP printer/punch devices are as follows:
command
general use
$B printer
Backspace the printer the designated number of
pages or to the beginning of the current data
set.
$C device
Cancel the current job output on the indicated
printer or punch.
$E device
Restart the job output currently printing or
punching on the indicated device, placing the
job back on the corresponding queue for selection by the indicated device or other printer
or punch, as appropriate.
$F printer
Forward-space the indicated printer the designated number of pages or to the end of the
current' data set.
$I printer
Interrupt the current job output on the indicated
printer, allowing the output to be continued by
the indicated or other printer as appropriate.
$N device
Repeat the job output currently printing or
punching on the indicated device, placing the
job back on the corresponding queue for selection by the indicated device or other printer
or punch as appropriate while allowing the
current job output to continue.
$p device
Stop the printer or punch after completion of
the current job output.
$S device
Start the printer or punch device.
$T device
Set device characteristics.
$Z device
Halt the printer or punch device until $5
device is entered.
HASP Operator's Guide - Page 144
837
HAS P
The formal defin'i tions of these commands may be found in the HASP
OPERATOR COMMANDS section of this manual.
STR as well as non-MULTI-LEAVING BSC remote workstation operators
will find that for practical purposes only the $P, $S, and $T commands are available for direct control of printer or punch devices
from the workstation. Commands entered from these workstations can
only be entered when the printer and punch devices are not ACTIVE.
This is true even when the non-MULTI-LEAVING BSC workstation printer
is manually interrupted simulating the $I device command.
CONTROLLING HASP LOCAL PRINTER AND PUNCH DEVICES
Each printer and punch on the system is assigned a HASP name at
HASP initialization time; responses to the $DU command display the
HASP printer and punch device names along with the corresponding
hardware addresses.
STARTING HASP LOCAL PRINTER AND PUNCH DEVICES - There are two methods of causing HASP to begin using a HASP printer or punch device:
1.
Enter the $S device command when the device is halted or
drained.
2.
Ready the printer or punch device prior to replying to
the HASP initialization WTOR. This is equivalent to
entering a $S device.
If OS has allocated the device for other functions when HASP is
initialized, there will be no attempt to use the device for job
output unless a $S device command is entered. To prevent inadvertent OS allocation of the printer or punch to other jobs, HASP
simulates an OS vary off-line command prior to its initial use of
the device and when each $S device command is entered for the
printer or punch.
I
The operator should align printer forms setting printer FCB images,
non-standard UCB images, and non-standard forms via the $T command
prior to allowing HASP to begin job processing on printer devices.
SHARING HASP LOCAL PRINTER AND PUNCH DEVICES - Because HASP is a
long running job, it is desirable for HASP not to prevent OS from
allocating the printer or punch to other jobs within the system.
The operator is then able to start OS writers to a HASP printer '
or punch device or enter jobs which require direct output. The
operator should observe the following precautionary rules when
other jobs are to use HASP printer or punch devices:
HASP Operator's Guide - Page 145
838
HAS P
1.
Enter a HASP $P command for the device and allow the device to become drained before varying the device on-line
or replying to the as allocation requests. This may be
supplemented by the $I printer or $E device command to
insure rapid termination of the current job activity.
2.
Insure that the job has finished with the device and will
not attempt to output more data prior to entering a HASP
$S command for the device.
SETTING THE 3211 PRINTER FCB IMAGES - The 3211 printer carriage
control tape--Forms Control Block (FCB)--is internally set by HASP.
The installation system programmer creates several FCB images at
HASP generation time and will inform the operator which image should
be used on the various printers. The operator sets the FCB image by
entering the following command:
$T printer,C=x - where x is the installation defined image id
character.
Image char~cter "V" may be designated by the installation as a variable image and, if so designated, may be changed by the operator.
This single image may· then be used by operators to set desired
printer FCB images by the command:
$T printer,C=V
An operator may create the "V" image by entering the $TF command
from an as console, HASP local console, or reader with device and
system HASP command authority.
HASP Operator·'s Guide - Page 146
839
HAS P
7.2
HASP OUTPUT ROUTING
Under the standard HASP System, output routing has meaning only
when the HASP remote job entry feature is being used.
Under this
environment each group of printer or punch devices is considered
a pool of output devices identifiable by routing codes.
All local
printer and punch devices are assigned route code zero (0), all
printer and punch devices at work station REMOTEI (RMI.PRn,RMI.PUn)
are assigned route code one (1), etc.
A job which has its print
output destined to local printers will be printed on any of the
local printers.
Likewise, a job which has its print output destined
to remote 4 will be printed on any of the printers assigned to
REMOTE4 (RM4.PRI,RM4.PR2,etc.)
HASP will automatically assign print and punch output routings to
each job as it enters the system.
This assignment is determined
by the system programmer at HASP generation time.
Normally all
output for jobs entering local devices will be routed to the local
"device pool and all output for jobs" entering a remote reader will
be routed to the corresponding remote output devices.
This may be
altered so that, for example, remotes without~punch devices will
have punch data routed to the local punch pool or to a remote
convenient to the submitting work station.
Routing of print and punch output may be directly assigned by the
programmer via /*ROUTE control cards (see READER SUPPORT) or by
the operator after the job has entered the system via the $R
(ROUTE) command. Although the central operator has complete routing
control over jobs, the remote work station operator may only route
jobs which belong to the remote, i.e., jobs which have the print or
punch routings destined for Qutput at the remote.
The following
sample command sequence allows the operator to redirect the print
output for a job after printing of the data sets is in progress:
1.
$R PRT,JOB25,LOCAL
- Sets the print routing for job 25
to the central printer pool.
2.
One of the following (assume job 25 is printing on
remote 3 printer 1):
A.
$I RM3.PRI
- Interrupt print output and requeue
for continuing the print by a LOCAL
printer.
B.
$E RM3.PRI
- Restart print output and requeue
for printing by a LOCAL printer.
c.
$N RM3.PRI
- Repeat the print allowing a LOCAL
printer to print a copy.
HASP Operator's Guide - Page 147
840
HAS P
7.3
HASP SPECIAL FORMS ROUTING
At HASP initialization HASP assumes that the printer and punch devices are loaded with the standard forms paper or cards as appropriate. Normal operation of the devices calls for each printer or
punch device to select the highest priority job in the appropriate
print or punch queue and begin outputting. Assuming that the installation selects SYSOUT Class A to be standard print output and
SYSOUT Class B to be standard punch output, all "SYSOUT=A" data sets
will be printed on the standard forms paper and "SYSOUT=B" data sets
will be punched on the standard forms cards (see OS JOB CONTROL LANGUAGE manual for the meanings of SYSOUT=A or SYSOUT=B). Occasionally
the programmer will desire to have a data set printed or punched
using special forms and submits a "SYSOUT=(A"form#)" or "SYSOUT=
(B"form#)" parameters for the Data Definition (DD) card describing
the data set. When the data set is encountered during output HASP
will stop the printer or punch and display a forms load message on
the operator's console. This allows the operator to load the forms
desired and enter a $S device command to signify that the device is
ready. When output of the data set is complete, HASP will request
that standard forms be loaded and wait for the operator as before.
The normal mode of operation is therefore the loading of forms on a
DEMAND basis.
Occasionally the programmer will decide that all print data ~s to be
printed on special forms and instead of specifying the forms on ·the
"SYSOUT=A" parameter of the DD card, he specifies the forms in the
HASP accounting field of the JOB card (see HASP INPUT STREAM section
of this manual). This causes the forms designated to be made stand~
ard for the printing of the job.
SUBMISSION OF SPECIAL FORMS DATA SE.TS
Processing special forms on a DEMAND basis, while convenient when
occasional need for special forms exists, will cause poor printer
or punch utilization when a large number of data sets require special forms. Assuming that the installation selects SYSOUT Class J
to be special forms print and SYSOUT Class K to be special forms
punch, all "SYSOUT=(J"form#)" and "SYSOUT=(K"form#)" data sets
will not be printed or punched with the standard output for the
job. The programmer therefore designates special forms on theappropriate DD cards in the job input stream. HASP will print the
normal print data sets and queue the job for the printing of the
first special forms data set. When this data set has been printed
the job will be queued for the printing of the next special forms
data set (if any). This process will continue until all special
forms data sets have been processed. The data sets will be queued
in the order of the collating sequence of the special forms designations. After the special forms printer(s) complete all special forms
printing, the job will proceed to special forms data set punching
(again in collating sequence), and then, if appropriate,.to standard
job punching.
HASP Operator's Guide - Page 148
841
HAS P
ASSIGNING SPECIAL FORMS TO A PRINTER OR PUNCH
The operator may determine the number of jobs with output for
special forms by entering the command:
Display Number of Jobs Queued
on Forms
$0 F
When sufficient output is awaiting special forms, the operator
may choose to activate one of two types of special forms control
by command as follows:
$T device,F=AUTO
Activate printer or punch special
forms allowing HASP to determine
which special forms should be
loaded
Activate printer or punch special
forms using the forms indicated and
loaded by the operator (operatorcontrolled)
If the device is a printer, special forms jobs (forms indicated
in the JOB card) along with data sets which have been disassociated
from other jobs will be selected for printing. If a normal SYSOUT
class (SYSOUT=A as described previously) with a special forms
specification is encountered a DEMAND load for the forms is
requested, requiring the operator to cancel the print or load the
forms and enter $8 device.
Printing and punching of output will proceed until the queue for
the forms indicated by the operator or asked for by HASP is empty.
If AUTO was indicated by the operator HASP will select jobs awaiting another special forms for the device, ask for the loading of
the new forms, and attempt to exhaust the queue of the new forms
upon receiving the appropriate $S device command.
The operator may cause the device to revert to standard output
by entering:
$T device,F=RESET
NOTES:
1.
The command $T device,S=YES or $T device,8=NO
may be used to indicate separator pages or cards
between job output on the device.
HASP Operator's Guide - Page 149
842
HAS P
2.
The non-MULTI-LEAVING remote workstation operator
will find that the $S command may not be entered
from the remote to signal that forms have been loaded
and that no messages to the operator will be printed
on a printer set to output special forms. Therefore
the following rules are recommended:
a.
Use only operator-controlled special forms.
b.
Prevent users from requesting DEMAND loading
of forms.
c.
After exhausting a special forms queue enter $T
device, S=Y (if required), enter a $DF command
and, after receiving all messages, set to the
next forms type desired.
3.
For safe forms changing operations when using operator controlled forms, the operator should stop the
device ($P device), load the new forms, tell HASP
($T device), and then start the device ($S device).
4.
The operator is permitted to change carriage tapes
and print trains/chains while HASP is waiting for
the $S command following a request for forms load.
This change may be activated by entering $T device
operands C=carriage or T=train as appropriate.
HASP Operator's Guide - Page 150
843
HAS P
7.4
HASP PRINT AND PUNCH OUTPUT FORMATS
HASP PRINT FORMAT
The format for standard print output for each job stream is as
follows:
1.
2.
3.
4.
5.
6.
HASP START JOB SEPARATOR PAGE
HASP SYSTEM LOG (OPTIONAL)
HASP STATISTICS
OPERATING SYSTEM MESSAGES
DATA SETS CREATED BY T.HE JOB
HASP END JOB SEPARATOR PAGE
HASP START JOB and END JOB separator pages consist of a single
line of information duplicated a number of lines as specified
by each installation.
The format of the information line is as
follows:
columns
contents
1 - 17
18 - 22
23 - 31
HASP identification
periods (.)
START JOB
.CONT JOB
.. END JOB
job number assigned by HASP
periods (.)
32 - 35
36 - 40
41 - 51
52
62
66
70
75
79
87
91
116
61
65
69
74
'78
- 86
- 90
-115
-132
-
time of printing the page in form: hh.mm.ss AM
PM
date of printing the page in form: day month year
periods ( )
ROOM
room number
periods (.)
as jobname
periods (.)
programmers name padded with trailing periods (.)
HASP identification
.
The HASP statistics is a single printed line which contains the
following information:
1.
2.
3.
4.
cards read
lines printed
cards punched
execution time (real time)
HASP Operator's Guide - page 151
844
HAS P
ijASP PUNCH FORMAT
The format for standard local IBM 2540 punch output for each
job stream is as follows:
1.
2.
3.
4.
HASP PUNCH ID CARD - in pocket 2
DATA SETS CREATED BY JOB - in pocket 2
HASP JOB ACCOUNTING CARD - in pocket 3
BLANK CARD - in pocket 1 (also will contain error cards)
HASP JOB ACCOUNTING CARD FORMAT
Columns
Mode
Contents
Programmer's name
EBCDIC
21 - 24
Room number
EBCDIC
25 -
Spares
N/A
28 - 31
P. A. number
EBCDIC
32
Job priority number
BINARY
33 - 35
Job input time in hundredths of a second
BINARY
36 - 38
Job output time in hundredths of a second
BINARY
39 -
40
Number of cards read in
BINARY
41 -
43
Number of output lines
BINARY
44 - 45
Number of output cards
BINARY
46 -
Total reader time in hundredths of a second
BINARY
1 - 20
27
48
49 - 51
52
54
Total execution time in hundredths of a second BINARY
Total print time in hundredths of a second
BINARY
55 - 57
Total punch time in hundredths of a second
BINARY
58 - 65
Job name
EBCDIC
66 - 71
Sp~res
N/A
72
Identifier (X'FF')
BINARY
73 - 74
Year
EBCDIC
75 - 77
Days
EBCDIC
78 -
Job number
EBCDIC
80
HASP Operator's Guide - Page 152
845
HAS P
HASP PUNCH 10 CARD FORMAT
Each job's punch output will be preceded by an identification card
containing the programmer room number Clnd interIlal job nUlJlPer.
To make the card easy to identify, it has an ll-pun~hand a
l2-punch punched in all 80 columns. To make the room nu.~ber
and job number easy to read, each digit is ext$ndedoverten
columns. Alphabetic characters are converted to digits as
follows:
AlEhabetic Characters
A or J
B, K, or S
C, L, or T
0, M, or U
E, N, or V
F, 0, or W
G, P, or X
H, Q, or y
I, R, or Z
Numeric Punch
1
2
3
4
5
6
7
8
9
Below is an example of the punch ide.ntification card which would
precede a deck punched, for eXClmple, for a programmer residing in
Room E305, and having an internal job number of 129.
111111111111111111111111111111111111111'1111111111111111"1111111111111111111111
1111111111111111111111111111111111111I111111I11111111II1I1I11I11I1I111I111111111
DOD 0 0 0 III 0 a DII 0 0 II II 111111111'11' I • II • III '1 80 I • II'" I. 811 .1•• , 11118 I t I.• I ••• 8 •• III
2 J4S.' ••
••
• • • UU_ • • U •••
• • p ••••• UN • • p ••
I , I ; 1 1 I Itt I Itt I 1 1 11 I 1 I 1 11 I I 11 1 I I • 11 I III 1 I II 1 I 1 I. ','111:1111111 • 11 1 11 I I I 1 , .. I I , I I I
, 7 2 1 1 2 2 2 2 7 2 2 2 Z 2 2 2 2 2 2 2 I , 22 2 2 2 2 2 , 2 2' '2 2 22 2 2 22 2 2 2 2 2 , 2t' 22 2 2 2 2 2 , '1111'1111 2 J 2 22 2 7 2 7 2
13333333333111111113333333333333333333333333333333J33333333333333133333333333333
I
~"nQ"qq"qq.ftftft~a.Daa.~.»~
P~
fl.N~
_nn~H~~n~~.
t
•• , 4 , •• 4 4 •• 4 4 •• 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 • 4 44. 4 4 4 44 4 4 4 4 4 4 4 4 4 4
.4 . 4 4•• 4. 4 4 4 4 ••••••
t'.
~ •••••••••••
5111111115 55 5 5 5 55 5 5 5 5 5 5 5 55 5 55 $ 5'111"11" ~ 5 5 5 5 5 5 5 5 5 5 5 5 55 51'"' $,i5 ~5.J 5 $ t~ 5 5 5 5 5·5 •
& I I 6 I I I • • I I &. I I I I I & I 6 I • • &• It • I •• • , II • ,'1 • • 6 • II • • && I • II II .: •• I'>'fll' " II'
I .1 II • I
'1 •
, 1 1 1 I 1 I , , 1 1 1 , , 7 7 J 7 J 7 J J 7 7 J J 1 J J .1 , JI 11 J r J1J J J 7 7 17 J 77 J " J J lJ J J 1 JJ fJ 7 J r J r J , J 1J J J J 1 J } 7
I I II I • II • I ••• 1,11, ••••• I I. I" •• '1 ., "" ••••• , • I.
"11," •,••• ,,1'1',"
9 ~ ! 9 I I I I I ! It' I 9 ! I t 99 9 9 9 I • , It I '9' II I 9 8 •• I, 9 9 9 9 9 t 9 ttl • ttt It J
, J ,
4 5 1 ~D'- :0:'" II II 14 15
tI" "192'&2122
n24
,t
I •• "I •• , I 8 •••
1*, .••. . .ft'
•• , 9 t 111111119
.,.4\t ...IJlU':4.$...:, ......
. . . ••• JI'ln U
111111.
.2I17I1",JUt. M• • 3J . . . . . a414441 ••
~
141$11
HASP Operator'sGu.i4e....Page 153
846
HAS P
7.5
LOCAL PRINTER AND PUNCH ERROR PROCEDURES
All job printing and punching for local devices is accomplished
through Operating System facilities. OS will attempt to recover
from printer and punch errors and provide appropriate error messages to the operator. In the case of permanent errors the followi~g procedures apply:
PRINTER - Permanent errors will be ignored and output will
continue. Since the accuracy of the output is determined by the presence or lack of error messages,
the operator should react in accordance with the
severity of the problem.
PUNCH
- Error cards are dropped in pocket 1 and punching
continues starting with the record detected to be
in error.
The appropriate hardware SRL (e.g., GA21-9033 for
the 2540, GA21-9124 for the 3525) should be consulted for correct operator procedures in response
to indicator lights and sense bits displayed when
the punch stops and requires intervention.
HASP Operator's Guide - Page 154
847
HAS P
(The remainder of this page intentionally left blank.)
848
HASP
11.2
HASP REMOTE TERMINAL PROCESSOR (MODEL 20/STR)
OPERATOR'S GUIDE
The following section contains detailed instructions for operating a
360/20, equipped with a Synchronous Transmit-Receive (STR) communication
adapter, as a remote terminal system under HASP. Although intended for
use as a separate operational manual, it has been included into the HASP
SYSTEMS Manual to achieve completeness.
HASP Remote Terminal Operator's Guide (Model 20) - Page 11.2-1
849
HAS P
(The remainder of this page intentionally left blank.)
850
HASP
HAS P
REMOTE TERMINAL PROCESSOR
FOR
STR·COMMUNICATIONS
MODEL 20 OPERATOR1S GUIDE
851
HASP
Page
Section
1.0
Introduction
1. 0-1
Section
2.0
Operating Procedure s
2. 0-1
2. 1
Initial Program Load
20 1-1
2.2
Establishment of Communications Line
2.2-1
20 3
Initiating Proce s sing
2. 3-1
3.0
Error Recovery
3. 0-1
3. 1
Communications Adapter Errors
3. 1-1
3.2
Unit Record Device Errors
3.2-1
3. 3
Model 20 Restart
3. 3 - 1
Section
4.0
Dynamic Configuration Specifications
4.0-1
Section
5.0
Central Computer Control
5. 0-1
Section
6.0
Operational Hints
6. 0-1
Section
Table of Contents -
852
Page i
HASP
1. 0 INTRODUCTION
The HASP System· is an automatic
spooling, priority scheduling system which, while operating in conjunction with OS/360, operates an unlimited number of peripheral
device s simultaneously with normal job execution, to perform the
functions normally associated with off line support computers.
function of HASP has been extended to operate,
v~a
The
several classes
of telephone lines, peripheral devices located remotely from the
central computer complex.
Through the use of the HASP Remote Job Entry feature, a user,
located perhaps thousands of miles from a particular System/360
installation, can utilize the capabilitie s of that installation much as if
it were in the local computer room.
The unit record devices at a
remote station are logically operated by HASP as if they were local
readers, printers and punchers, so that HASP can simultaneously,
while operating all local unit record devices, read jobs from several
remote readers into the queue of jobs awaiting processing and upon
completion of the processing, can print and punch the results at the
remote site.
Although a variety of devices may be utilized as remote terminals,
this document discusses only the use of a System/360 model 20 as a
remote statioh.
HASP Remote Terminal Operator's Guide (Model 20) - Page 1.0-1
853
HASP
A special program has been written tor the model 20 which can
be considered as a logical extension of the HASP SYSTEM.
This
program, called the HASP Remote Terminal Processor (HASP /RTP)
performs the following functions:
A.
INPUT
1.
Reads cards from the card reader attached to the
model 20.
2.
Compresses, blocks and encodes the card images
for transmission, over telephone lines, to the
central computer facility.
3.
Maintains synchronization and communication with
HASP for transmission.
B.
PRINT AND/OR PUNCH
1.
E stablishe s and maintains synchronization and
communication with HASP to receive transmissions
of job output.
2.
Decodes and decompresses print and/or punch records
received.
3,.
Interprets and executes carriage control information in
the case of print.
4.
Prints and / or punche s the received data.
HASP Remote Terminal Operator's Guide (Model 20) - Page 1.0-2
854
HASP
HASP /RTP may either Read, Print orPut;lc,hbut may notperf:o~m
any two operations simultaneously.
Due to the use of blocking and character compre s sion to minimize
line transmission time, the speed at which the model 20'c;tevices are
operated is dependent on the data being transmitted.
Certain jobs,
because of their data characteristics, will enable HASP /RTP;.to
operate the model 20 devices at full rated speed.
Other jobs, with
less advantageous data characteristics, may cause the devices to
operate at Ie s s than full speed.
HASP Remote Terminal Operator's Guide (Model 20) - Page 1.0-3
855
HASP
2.0 OPERATING PROCEDURES
The following pages provide
s~fficient
information for initiating
and operating the HASP/Remote Terminal Program.
HASP Remote Terminal Operator's Guide (Model 20) - Page 2 . 0-1
856
HASP
2.1 INITIAL PROGRAM LOAD
1.
Ready the HASP/RTP deck in a reader on the m.odel 20.
The deck should include as the last card an appropriate
"configuration" card as described in Section 4. O.
2.
If the model 20 has multiple readers, the reader select
switch on the console should be set to indicate the reader
containing the RTP deck.
3.
Ready the system printer and punch (if present).
4.
Set the TIME SHARING key to the on (down) position.
5.
Set the BINARY /BCD switch on the comm.unications
adapter to the BINARY position.
6.
Set. the LINE SPEED key to the appropriate speed.
7.
Set the AUTO-CALL key to the OFF position.
8.
Verify the setting of the full duplex (FD) - half duplex
(HD) switch inside the CE console.
9.
Turn the communications adapter switch to the NORMAL
positiono
10.
Set the DATA KEYS to 009C.
11.
Set the MODE switch to PROCESS.
12.
Press the I/O CHECK RESET,' SYSTEM RESET and LOAD
key on the m.odel 20 consoleo
HASP Rem.ote Terminal Operator's Guide (Model 20) - Page 2.1-1
857
HAS P
13.
If the Model 20 has less than 16,000 bytes of
memor~
a program stop will occur after the loading of the
first card.
When this occurs, press only the LOAD
key again to initiate loading.
14.
Press the START key on the communications adapter
while the HASP/RTP deck is being loaded into memory.
15.
Establish the communications line (see Section 2.2).
16.
The program should now begin processing in accordance
with the algorithm given in Section 2.3.
HASP Remote Terminal Operator's Guide (Model 20) - Page 2.1-2
858
HASP
2. 2 EST ABLISHMENT OF COMMUNICATIONS LINE
1.
Advise the ope rator of the central computer location
that job transmis sion is to be initiated.
(The central
computer operator must authorize HASP to proces s
jobs from a given remote terminal.
This authorization
must be given only once per terminal. )
2a.
Leased (or private transmission lines) - place the data
set in the DATA mode.
2b. Dial-up transmis sion line s - Pre s s the TALK button
on the data switch and dial, exactly as in a normal call,
the number of the appropriate data set at the central
computer.
After the "ringing" sound, a shrill sound
indicates that the phone has been answered.
Immediately
upon hearing this sound, press the DATA button on the
data set and hang the telephone up.
3.
The CHARACTER PHASE light on the communications
adapter should appear to indicate synchronization of the
two computers.
NOTES on communication line establishment:
a.
A "busy" signal indicates that the called data set is in use.
HASP Remote Terminal Operator's Guide (Model 20) - Page 2.2-1
859
HASP
b.
A line may be established by a call from the central
to the remote site.
(~om-p-uj;_e_r
To receive such a call, normal initializa-
tion procedures should be followed but rather than dialing,
the AUTO button should be pre s sed and the phone hung up to
await the call.
c.
On a two-wire half-duplex telephone line, a period of
several seconds may be registered to synchronize the
two computer s.
d.
On the establishment of a connection other than the first,
a period of several seconds may be required to begin
transmis sion of print and/ or punch data.
HASP Remote Terminal Operator's Guide (Model 20) - Page 2.2-2
860
HASP
2.3 INITIATING PROCESSING
In order to allow the remote computer operator to select the
function the Model 20 is to perform (i. e., input or output), the
transmission of jobs to the central computer site is given priority.
At the end of the print and punch for a job,HASP /RTP te sts the system
card reader for ready status and, upon finding it ready, immediately
begins the transmission of all jobs in the reader to the HASP job
queue in the central computer.
If no print or punch jobs are
available to be processed, the program maintains communications
with HASP in the central computer to await a job.
During this
dormant period, the reader is tested every several seconds for
the availability of a job to transmit.
Thus, the Model 20 operator
by merely placing a job (or jobs) in the card reader can cause transmission to the central cOITlputer at the next "end of job" (or within
several seconds if no processing is active).
The lack of jobs in the
reader will therefore cause all print and punch output froITl the central
computer to be processed as it becoITles available.
HASP Remote TerITlinal Operator's Guide (Model 20) - Page 2.3-1
861
HASP
3.0 ERROR RECOVERY
The following sections list some of the more common error
•
conditions that may arise and indicate a solution to each.
HASP Remote Te rminal Ope rator I s Guide (Model 20) - Page 3. 0 - 1
862
HASP
3.1 COMMUNICATION
ADAPTER ERRORS
Any errors concerned with data transmission are indicated by
the communications adapter on the Model 20 by halting (stop light on),
sounding the audible alarm, and displaying a combination of error
indicators.
Normally, an error stop indicates a line transmission
failure (after three retries).
By pressing start, the transmission will
be retried thre e additional time s.
If a failure still re suIt s afte r
several retries, the computing system and the telephone line should
be checked.
A detailed description of the meaning of various error
indicators is given in the IBM Reference manual A26-5847.
NOTE: occasionally certain error lights on the communications
adapter will flash on for brief periods of time.
No action should be
taken until the CA stop key is lighted.
HASP Remote Terminal Operator's Guide (Model 20) - Page 3. 1-1
863
HASP
3.2 UNIT RECORD DEVICE ERRORS
All error conditions on unit record devices will be indicated by
the illumination of the appropriate ATTENTION light on the Model 20
console and a program stop in the Model 20 with an indicative number
displayed in the ESTR Register.
When the error condition has been
cleared (as described subsequently), the START key on the console
should be pressed to resume operation.
The following sections
de scribe the error identification halt codes and the specific actions
neces sary to correct an error condition on all supported devices.
HASP Rem.ote Terminal Operator's Guide (Model 20) - Page 3.2-1
864
HASP
3. 2. I
1403/2203 Printer
SYNC CHECK/PRINT CHECK/FORMS CHECK- All printer checks
will be effectively ignored by HASP /RTP.
The error co'nditi.on should be
reset and the printer put into READY status to continue printing.
If
the malfunction caused the loss of print lines, the central computer
operator should be contacted and advised to BACKSPACE* or RESTART*
the print to recover the lost line s.
*
See the HASP SYSTEM Operator's Guide
HASP Rem.ote Terminal Operator's Guide (Model 20) - Page 3.2-2
865
HASP
,3.2.2
2501, 2560, 1442, 2520 CARD READERS
All card reader checks are indicated by a program halt code of
0001.
To retry the faulty read, the cards should be run out of the
reader and the last two cards in the receiving stacker should be placed
back into the reader.* Frace s sing may then be re sumed by depre ssing
the START keys on both the card reader and the model 20 CPU.
If
the read check condition persists after several retries, the validity
of the card should be checked.
Feed Stops and other mechanical problems on card readers are
indicated by the illumination of an error light on the reader console
(along with the appropriate ATTENTION indicator on the Model 20
CPU).
This condition may be corrected by running out the reader,
correcting the cause of the stop, and replacing the cards into the
reader.
Note that no cards are removed from the receiving
stacker.
Pressing the START key,on the card reader will cause
processing to resume.
The occurrence of both type s of error, conditions simultaneously
should be corrected by following the procedure for reader checks.
*
In the case of the 2560 (primary stacker) the last THREE cards should be
placed back in the read hopper.
HASP Remote Terminal Operator's Guide (Model 20) - Page 3.2-3
866
HASP
3.2.3 2560, 1"442, 2520 CARD PUNCHES
All punch checks will be indicated by a program halt code of 0002.
To repunch the card in error, the cards in the punch should be run out
and the last two cards in the receiving stacker discarded.
Blank cards
should be placed into the punch and START depressed on the punch console.
The pre s sing of the START key on the CPU will cause proce s sing to
resume.
Punch STOPS and other mechanical problems will be indicated by
an indicator light on the punch {and by the appropriate ATTENTION
indicator on the CPU console}.
These conditions sho.uld be corrected
by clearing the punch and discarding all non-processed cards.
will re sume when the punch is re-readied.
Processing
The occurrence of both type s
of the above errors simultaneously should be corrected by following the
punch check correction procedure.
HASP Remote Terminal Operator's Guide (Model 20) - Page 3.2-4
867
HASP
3.3
MODEL 20 RESTART
In the event of an untimely interruption of Model 20 operation such
as a machine, program, communication line, or environmental failure,
the following procedures should be utilized to resume processing:
A.
Model 20 transmitting at failure -
HASP/RTP should be
reloaded with the complete job which was being sent at
the time of the failure immediately behind the HASP /RTP
. deck.
Due to the sometimes extensive buffering of cards
by the Model 20, doubts concerning which job was being
transmitted at the time of the failure should be resolved
by contacting the operator at the Central site.
The central
operator should also be advised to enter the HASP RESTART
RMT n command to delete this partially complete job from
the HASP job queue. After normal initialization procedures
I
processing should resume.
B.
Model 20 RECEIVING AT FAILURE -
HASP/RTP should be
reloaded with NO input jobs in the card reader to force it
into the receive mode again.
Since a system failure will
normally result in the loss of some amount of data, the
central computer operator should be advised to BACKSPACE or
RESTART the function in progress as required by the amount
of data lost.
HASP Remote Terminal Operator's Guide (Model 20) - Page 3.3-1
868
HASP
4.0
DYNAMIC CONFIGURATION SPECIFICATION
The HASP/Remote Terminal Processor can utilize any of the types
of peripheral I/O equipment that can normally be ordered with the
Model 20. At program load
I
HASP/RTP either determines or is
instructed by the operator what devices to use.
I
Either the 2203 or
1403 printer will automatically be used and need not be indicated.
The card reader utilized will be the one from which the RTP deck is
loaded.
The punch to be used must be indicated by the following card
which must follow the program deck:
_ _ _ _ CARD COLUMNSu--_ _ _ _ _ _ _ _ _ __
o
1
1
2
1
6
8
o
/ /SYSPUNCH DD
UNIT=XXXX
DUMMY
where
xxxx
=
=
=
2560S
2520
1442
(MFCM Secondary station)
If the variable field contains the word DUMMY, all punch output
received from the central computer will be ignored with no indication
to the Model 20 operator.
HASP Remote Terminal Operator's Guide (Mode120) - Page 4.0-1
869
HASP
5 .0
CENTRAL COMPUTER CONTROL
Certain of the control cards recognized by HASP can be introduced
from the remote terminal site.
Following is a list and meaning of these
control cards.
71
12
Any Message
1
/*MESSAGE
The data punched into columns 12-71 of this card will be displayed
on the central computer operator's console at the time the job is being
read into the system.
special instructions
I
This may be used to identify certain jobs, give
etc.
The /*MESSAGE card may be placed anywhere
within the input job stream.
If this card appears within a job, the HASP
number assigned to that job will be appended to the message before
displaying it, otherwise the remote station ID. will be appended.
1
/*ROUTE
16
10
PRINT
PUNCH
LOCAL
This card, when included anywhere within a job being submitted to
the central computer, will cause the print or punch output (as indicated
in column 10) to be processed on local unit-record equipment.
This
card may be used to divert large volumes of print or punch to local high
s peed devices to avoid terminal congestion.
Both print and punch may
HASP Remote Terminal Operator's Guide (Model 20) - Page 5.0-1
870
HASP
be routed locally by including two
1
/*PRIORITY
/*ROUTE cards in a job.
16
nn
This card may be used to force the assignment of priority linn'!
to the job which immediately follows.
from 0-15.
linn!! may be any digit or digits
This control card when read locally by HASP is interrupted
as an absolute priority assignment to a job.
However, when read from
a remote station the card is regarded as a priority assignment to this
job relative to other jobs from the same station.
Thus a remote
operator can, via the /':~PRIORITY card order the sequence of jobs
submitted from only his station, for example, a
/~:~PRIORITY
15
(where 15 is the highest priority) would cause its job to be the next
job from that remote station to be processed, although not necessarily
the next job to be processed by the central computer.
The relative
position of the priority structure of a remote terminal with re spect
to the overall system priority structure is determined at HASPGEN
by central computer personnel.
The /*PRIORITY card must imm.ediately precede the 08/360 JOB
card of the job to which it refers.
HASP Remote Terminal Operator's Guide (Model 20) - Page 5.0-2
871
HASP
25
1
/*SIGNON
Password
This card appears at the end of the HASP/RTP program deck in front of
the //SYSPUNCH configuration card and is used to override the remote
identification number normally assigned to the HASP/RTP program deck.
For DIAL lines the /*SIGNON card may be used to submit a password which
I
if correct will allow the remote terminal acces s to the HASP system for
I
remote job stream processing. The value" n" must match the remote identification number assigned to the remote station by central computer personnel.
The value of the "password" must match the password assigned to the line
by the central computer operator when the communication line is .. started" .
1
/*SIGNOFF
This card is used to inform the central system that the remote terminal
operator desires to terminate a remote job stream processing session. When
submitted to the central system
I
HASP will, at the completion of the current
print and/or punch streams, disconnect the terminal from the system and
prepare the line for other remote stations to SIGN-ON.
1
/*command
Selected HASP commands may be submitted to the central system through
the remote terminal card reader. Commands submitted in this manner must
HASP Remote Terminal Operator's Guide (Model 20) - Page 5.0-3
872
HASP
be the first cards of a job stream (in front of the first job submitted).
which can be submitted are listed in the HASP operator' s
in column 3 of the card
1
/*SETUP
t
guide'~Hid
Commands
must start
i. e. the first 3 columns will be "/*$".
12
volume-serlt volume-ser2
71
t ••• t
volume-sern
The volume serials punched in columns 12-71 of the card will be
displayed on the central system console and the associated job will be placed
in HOLD status (not be scheduled for execution) until released by the central
operator. The /*SETUP card appears in the corresponding job input deck between
the OS
JOB card and the first EXEC card.
To continue a /*SETUP card t a
/*MESSAGE card should be used.
HASP Remote Terminal Operator's Guide (Model 20) - Page 5.0-4
873
HASP
6. 0 OPERATIONAL HINTS
1.
It is suggested that the remote terminal operator become
familiar with normal HASP operating procedures at the
central computer site.
The HASP OPERATOR'S GUIDE
is contained as section 11. 1 in the HASP SYSTEM
MANUAL
2.
During dormant periods, the Model 20 should be allowed
to maintain communication with HASP at the central
computer site so that printing (and/ or punching) may
begin as it becomes available.
3.
The communications line may be disconnected at any
time, which will cause HASP to hold all jobs awaiting
the terminal until the line is again established.
This
will allow the Model 20 to be used for other purpose s
during long dormant periods.
HASP Remote Terminal Operator's Guide (Model 20) - Page 6.,0-1
874
HASP
11.3
HASP/REMOTE TERMINAL (1978) OPERATOR'S GUIDE
The following section contains detailed instructions for operating
an IBM 1978 used as a remote terminal station with the HASP SYSTEM.
Although intended for use as a separate operator l s manual, it has been
included in the HASP SYSTEMS Manual to achieve completene s s.
HASP Remote Terminal Operator l s Guide (1978) - Page 11. 3-1
875
HAS P
(The remainder of this page intentionally left blank.)
876
HA~P
THE
HASP
SYSTEM
IBM 1978 REMOTE STATION OPERATOR'S GUIDE
877
HASP
TABLE OF CONTENTS
Page
Section
1. 0
Introduction
1. 0-1
Section
2.0
Operating Procedure s
2.0-1
2. 1
Initiating Processing
2. 1-1
2.2
Establishment of Communications Line
2.2-1
3.0
Error Recovery
3. 0-1
3. 1
Send Operation Error Stops
3. 1-1
3.2
Receive Operation Error Stops
3.2-1
Section
4.0
Central Computer Control
4.0-1
Section
5.0
Operational Hints
5.0-1
Section
T able of Contents - Page i
878
HASP
The HASP System is an automatic
spooling, priority scheduling system which, while operating in conjunction with OS/360, operates an unlimited number of peripheral
devices simultaneously with normal job execution, to perform the
functions normally associated with off line support computers.
The
function of HASP has been extended to operate, via several classes
of telephone line s, periphe ral device s located remotely from the
central computer cOIT1plex.
Through the use of the HASP Remote Job Entry feature, a user
located perhaps thousands of miles from. a particular System/360
installation can utilize the capabilitie s of that installation much as
if it were in the local cOITlputer room.
The unit record device s at a
reITlote station are logically operated by HASP as if they were local
readers, printers and punches, so that HASP can siITlultaneously,
while operating all local unit record devices, read jobs from several
reITlote readers into the queue of jobs awaiting processing and upon
com.pletion of the processing, can print and punch the results at the
remote site.
Although a variety of devices may be utilized as remote terminals,
this document discusses only the use of an IBM 1978 as a rem.ote station.
HASP Remote Terminal Operator's Guide (1978) - Page 1.0-1
879
HASP
Due to the use of blocking and variable length "data:'to minimize
line transmission time, the speed at which the 1978 devices are
operated is dependent on the data being transmitted.
Certain jobs,
because of their data characteristics, will enable the 1978 to operate
unit record devices at full rated speed.
Other jobs, with less
advantageous data characteristics, may cause the devices to operate
at Ie s s than full speed.
HASP Remote Terminal Operator's Guide (I978) - Page 1.0-2
880
HASP
2 .0
OPERAT1NG PROCEDURES
The following pages provide sufficient information for initiating
and operating the IBM 1978 as a HASP Remote Terminal.
HASP Remote Terminal Operator's Guide (1978) ~ Page 2.0-1
881
HASP
2.1 INITIATING PROCESSING
2. 1. 1 Transmission to the Central Computer
1.
Establish the communication line (see Section 2.
2.
Verify that the M/D and CHAR PHASE indicator
o. 2).
,lights are on 2.nd that the REC T /P light is off.
3.
Set the operation mode switch to the SEND BINARY
mode (see Note 1).
4.
Set the mode switch to the BINARY Position.
5.
Press START on the printer paneL
6.
Load the cards to be transmitted into the feed
hopper.
7.
Press the FEED key on the Reader /Punch.
8.
Press the START key on the Reader/Punch.
9.
Cards will be transmitted until the reader hopper
is emptied, at which tim.e the audible alarm will
sound and the feed check light on the Reader will
COll1.e on.
Additional cards may be transmitted at
this point by, beginning with step 6 again.
If there
are no more cards to be transmitted. . .
HASP Remote Terminal Operator's Guide (1978) - Page 2. 1-1
882
HASP
10.
Press the STOP key on the Reader Punch and signal
HASP in the central computer of the end of input by
pre s sing the EOT key.
NOTE 1:
Certain installations may, if all input card characters
are of the 64 BCD character set, direct the setting of the ope ration
mode switch to the SEND 1 st CHAR position, in order to improve
the transmis sion rate.
HASP Remote Terminal Operator's Guide (1978) - Page 2. 1-2
883
HASP
2.1.2 Reception from Central Computer
1.
Establish the communications line (see Section 2.2).
2.
Verify that the MID and CHAR PHASE indicator lights
are on and that the REC T
3.
Ip light is off.
Set the operation mode switch to the REC 1 st CHAR
position.
4.
Set the mode switch to the BINARY position.
S.
Load blank cards into the feed hopper of the Reader IPunch.
6.
Pre s s the FEED key twice on the Reade r IPunch ( only
if punching is to be done).
7.
Press START on the printer panel.
8.
Press START on the Reader /Punch (for punch).
9.
Jobs will, as available, begin printing (and optionally
punching).
HASP Renlote Terminal Operator's Guide (1978) - Page 2. 1 -3
884
HASP
2. 1. 3
Change of Operational Mode
In order to allow the 1978 operator to select the mode of operation
HASP provides the following feature:
At
the end of the output for each job (punch or print if
no punching i!!l done), HASP will automatically pause
for 28 seconds to allow the 1978 to be switched to the
send mode.
To initiate the sending of a job during
this interval, the operator should follow the procedure
outlined in part 2. 1. 1, beginning with step 3.
If the
1978 is not !witched to the send mode, the printing of
the next job, if available, will automatically begin
after the expiration of the 28 second period.
Should
no job be ready for printing, the 1978 will enter a
dorm.ant state to await either the receipt of print or
an' operator switch to the send mode.
Switching modes
while a transmission is occurring can only be done by
instructing the control computer operator to RESTART
the r,emote station.
HASP Remote Terminal Operator's Guide (1978) - Page 2. 1-4
885
HASP
2.2 ESTABLISHMENT OF COMMUNICATION
1.
LINE
Advise the operator of the central computer location
that job transmis sion is to be initiated.
(The central
computer operator must authorize HASP to process
jobs from a given remote term.inal.
This authorization
must be given only once pe r terminal. )
2a.
Leased (or private transmission lines) - place the
data set in the DATA mode.
2b.
Dial-up transmission lines - Press the TALK button
on the data switch and dial, exactly as in a normal call,
the number of the appropriate data set at the central
computer.
After the "ringing" sound, a shrill 'sound
indicates that the phone has been answered.
Immediately
upon hearing this sound, press the DATA button on the
data set and hang the telephone up.
3.
The CHAR PHASE light on the controlpanel should appear
to indicate synchronization of the terminal and the central
computer.
NOTES on communication line ,e stablishment:
a.
A "busy" signal indicates that the called data set is in use.
HASP Remote Terminal Operator' sGuide (1978) -Page 2. 2-1
886
H A.SP
b.
A line may be established by a cal1 from the central computer
to the remote site.
To receive such
a call, normal initializa-
tion procedures should be followed but rather than dialing, the
AUTO button should be pressed and the phone hung up to await·
the call.
c.
On a two-wire half-duplex telephone line, a period of several
seconds may be registered to synchronize the two computers.
d.
On the establishment of a connection other than the fir st, a
maximum time of 28 seconds may be required to begin
transmission of print and/or punch data.
e.
If the data set at the central computer is not in the AUTO
position, the operator may answer the call and, after talking
may press the DATA key.
An ensuing shrill sound indicates
the computer connection has been established.
HASP Remote Terminal Operator's Guide (1978) - Page 202-2
887
HASP
3.0 ERROR RECOVERY
This section indicates most possible error conditions, their
probable cause s and procedures neces sary for correction.
HASP Remote Terminal Operator's Guide (1978) - Page 3.0-1
888
HASP
i'
3.1 Slt'ND OPERATION ERROR STOPS
Figure 3.1. 1 illustrates possible .errors wh~cp may occur while
transmitting jobs from the 1978 to the central computer.
HASP Rem.ote Terminal Operator 1s Guide (1978) - Page 3.1-1
889
HASP
Figure 3.1. 1 Send Operation Error Stops
Error and
Indication
Validity
Check
1. Alarm
sounds.
2. SRP light
is on.
3. Validity
light is
on.
4. Card
check
light
may be
on.
Po s sible Cau se s
Correction Procedures
1. Invalid card
code character.
2. Card skew.
1. Remove cards from stacke r.
2. Remove cards from hoppe r.
3. Pre ss feed key and stop key
simultaneously twice to clear
machine of cards. First card
in stacker is the error card.
4. If ne c e s s a ry , cor r e ct e r ro r card or set mode switch at
prope r po sition (must be
BINARY). Other records may
have been sent incorrectly if
this switch was not set correctly.
5. (a) If the Cd/Pnt Bfr light is
on, generate a machine reset
by momentarily changing the
operation switch to another
position.
NOTE: this procedure may
result in a record check at the
central compute r which will be
ignored by HASP.
(b) If the Cd/Pnt Bfr light is
off, press the check start key
to reset the error condition.
6. Place the error card and the
card following it in front of
cards removed from hopper.
7. Follow normal start procedure
HASP Remote Terminal Operator's Guide (1978) - Page 3.1-2
890
HASP
Figure 3. 1. 1 Send Operation Error Stops (Continued)
Error and
Indication
Card
Check
l. Alarm
sounds.
2. Card
light is
on.
Possible Causes
Correction Procedures
1. Buffe r input
address error.
2. More or fewe r
than 80 colum.ns
read from card
(without Transmit Variable
Length Records
special feature).
l. Remove cards from stacke r ~
2. Remove cards f~om hoppe r.
3. Pre s s feed and stop key s
simultaneously ~wice to clear
machine of cards.
4. (a) If the Cd/Pnt Bfr light is
on, place the last card in the
stacker into the hopper.
(b) If the Cd/Pnt Bfr light
is off, place both of the cards
in the stacker into the hopper.
5. Replace the cards previously
removed from the hopper.
6. Pre s s check start button to
reset the error indication.
Follow
normal start procedure
7.
HASP Remote Terminal Operator's Guide (1978) - Page 3.1-3
891
HASP
Figure 3.1. 1 Send Operation Error Stops (Continued)
Error and
Indication
--
Input/
Output
Check
l. Alarm
sounds.
2. I/O
check
light
is on.
3. CTR
light
is on.
Possible Causes
Correction Procedures
1. Buffe r output
address error.
1. Note card count in input
counter lights to determine
number of cards stored in
buffer
2. Remove cards from hopper.
3. Remove cards from stacker
except the number indicated
by the input counter.
4. Press feed and stop keys
simultaneously twice to clear
machine of cards.
5. Place cards left in stacke r
into the hopper.
6. Replace cards removed from
hopper.
7. Gene rate a machine re set by
momentarily changing to
another position with the
ope ration switch.
8. Follow normal start procedure.
NOTE: This procedure may
result in a record check at the
central computer, which will be
ignored by HASP.,
HASP Remote Terminal Operator's Guide (1978) - Page 3.1-4
892
HASP
Figure 3. 1. 1 Send Operation ErrorStops
Error and
Indication
CR Check
l. Alarm
sounds.
2. CR light.
is on.
(Continu~d)
Possible Causes
,Correction Procedures
l. Bad character
out, of translator.
1. Remove cards from stacke r.
2. Remove cards from hopper.
3. Pre ss feed and stop keys
simultaneously twice to clear
cards from machine.
4. Place second card in stacker
into the hopper .
5. Replace cards removed from
hopper.
6. Pre ss check start button.
7. Follow normal start procedure
8. If the error occur s the second
time, perform steps 2 and 3
above again.
9. Generate a machine re set by
momentarily changing the
operation switch to another
position.
NOTE: This procedure may
result in a record check, at the
central compute r, which will be
ignored by HASP.
.
IO.Place both cards in the stacker
into the hopper. Replace the
cards removed from the
hopper.
II.Follow normal start procedure.
'
"
HASP Remote Terminal Operator's Guide (1978) - Page 3. 1-5
893
HASP
Figure 3. 1. 1 Send Operation Error Stops (Continued)
Error and
Indication
Corre ction Procedure
Possible Causes
Feed Check
1. Alarm
sounds.
2. SRP
light on.
3. Feed
check
light on.
1. Hoppe r empty
2. Card jam.
3. Failure to
register card
at one of
stations in
transport.
4. Misfeed at
hopper area.
S. Misfeed at
stacker area.
Ctr
1. Alarm
sounds.
2. Ctr
light
is on.
1. Input check.
0
1. Determine cause of feed check~
2. If hopper empty, put in more
cards and pre s s feed key
unle s sat end of operation, in
which ca s e pre s s the stop key
and the EOT key.
3. If a misfeed and no cards are
in machine, reshuffle cards
in hopper and check for a
nicked card which should be
replaced. Put cards back in
hopper and press the feed key.
4. If a card jam exists, follow
the misfeed correction procedure to remove it.
5. Repair any damaged cards if
necessary.
6. Place into hopper all cards
that have not as yet passed
the read station.
7. Press the feed key.
1. Depress card read-punch key.
HASP Remote Terminal Operator's Guide (1978) - Page 3.1-6
894
HASP
3.2 RECEIVE OPERATION ERROR STOPS
Figure 3.2.1 illustrates possible error stops which may occur while
receiving print (and/ or punch) from the central computer.
HASP Remote Terminal Operator's Guide (1978) - Page 3.2-1
895
HASP
.
-
Figure 3.2.1 Receive Operation Error Stops
Error and
Indication
Input/
Output
Check
l. Alarm
sounds.
2. I/O
light
is on.
3. CTR
light
is on.
4. Output
light
is on.
Possible Causes
Correction Procedure
The 1978 requests
retransmission of
an error record
two time s from the
transm.itting terminal. After the
three trie s the
machine stop s
and the error
indicator is
turned on.
1. Overflow of
data (exceeding the 7 subrecord limit).
2. Loss of an
addre SSe
3. Overflow of
buffer (card
check light is
also on). Maximum. of 329
characters.
4. RM/GM Check
also turns on
this light (see explanation of RM/
GM to indicate
wrong length
record.
l. Pre s s start key on card readpunch (printe r on Model 3) for
three more attempts at
transmis sian.
2. If card check light is on,
follow procedure for
correction of a card check.
3. If the error persists, the
System should be checked.
HASP Remote Terminal Operator's -Guide (1978) - Page 3.2-2
896
HASP
Figure 3. 2. 1 Receive Operation Error Stops (Continued)
Error and
Indication
Punch
Check
(Model 2
Only)
1. Alarm
sounds.
2. SRP
light
is on.
3. Punch
Check
light
is on.
Pos sible Cause s
Correction Procedure
1. Error in punching of a card.
2. Failure of card-:feed latch at the
of a feed cycle.
1. Flag last card in stacker.
2. Force feed one card by pressing stop and feed key simultaneously. Operation will
continue until all sub - records
remaining in MBS at time of
error have been punched, and
then it will stop. The card in
the stacker immediately after
the last card stacked before
stop, is the error card. If
error did not occur in the last
column to be punched, the
error card has been repunched
and the corrected card follows
the error card in the stacker.
The error card can then be
. thrown away. If the er~or
occurs in the last column to be
punched the entire card will
have been punched (if not, the
columns past the error column
will be left blank), arid the last
column of the card should be
checked and corrected if necessary, by manual methods.
3. If the error was due to a clutch
failure, the entire error,.card
will be blank and should. be·
discarded. In this case, the
flagged card should be che·cked
for scattered punching, and if
so, discarded and manually
corrected.
4. Pre s s start to re sume norrnal
operation. NOTE: The central
computer operator rnay be
notified to BACKSPACE or
RESTART the punch to retry.
~errninal
Operator1s Guide (1978) - Page 3.2-3
HASP Remote
897
HASP
Figure 3.2.1
Error and
Indication
Receive Operation Error Stops (Continued)
Possible Causes
Correction Procedure
Card
Check
l. Alarm
sounds.
2. Card
light
is on.
3. Other
lights
may be
on.
1. Address overflow of buffer
(transmittal
record too
long).
2. Address read
check (loss of
an address).
3. An invalid
character
in the translator or from
the line.
Punch Operation Only (Model 2
Only)
(a)
If
Cd/Pnt
Bfr
indicator
is
l.
on, remove all the cards from
the stacke r except one fewe r
than the nUITlbe r indicated by
the output counters.
(b) If Cd/Pnt Bfr indicator is
off, remove all the cards from.
the stacker except the nUITlber
indicated by the output counte r s.
2. Force feed one card by pre ssing the stop key and the feed key
simultaneously. Discard the
cards in the stacker.
3. Pre s s the check start key.
4. If Cd/Pnt Bfr indicator was on,
the first card entering the
stacker must also be discarded.
Character
Check
1. Alarm
sounds.
2. Character check
light
is on.
3. CTR
light
is on.
1. The mode switch
is not in the
BINARY position.
2. Caused by the
transITlis sion
line. (directly
or indirectly).
Three trie shave
been made to
obtain correct
information
before the
stop and error
condition occur s.
l. Verify the setting of the ITlode
switch.
2. Pre ss start on card read-punch
(printer on Model 3) for three
ITlore atteITlpts at transrnis sion.
3. If error per sists, the transmis sion line should be changed,
or the ITlode of the two ITlachine s
should be compared.
HASP Remote Terminal Operator's Guide (1978) - Page 3.2-4
898
HASP
Figure 3.2. 1 Receive Operation Error Stops (Continued)
Error and
Indication
Possible Causes
Correction Procedure
Record
Check
l. Alarm.
sounds.
2. Record
light is
on.
3. Output
light
is on.
l. Loss of a
record.
2. Duplication
of a record.
l. Flag the deck or printed report
to indicate the approximate
location for future reference
if necessary.
2. Pre s s the check start button.
3. The central computer operator
may be notified to BACKSPACE
or RESTART the job.
CR Check
l. Alarm
sounds.
2. CR light
is on.
l. Bad character
out of translator.
10 Follow procedure set up for
l. Receiving 1978
l. Follow procedure for Input/
RM/GM
l. Alarm
sounds.
2. RM/GM
light is
on.
3 0 I/O
light is
on.
correction of a card check.
has not received
a RM/GM at
proper position
in sub transmittal
record.
Output check.
HASP Remote Terminal Operator's Guide (1978) - Page 3.2-5
899
HASP
Figure 3. 2. 1 Receive Operation Stops (Continued)
Error and
Indication
Output
Check
1. Alarm
sounds.
2. Output
light is
on.
3. Other
check
lights
may be
on.
(Chipbox Full
Model 2
Only)
1. Alarm
sounds.
2. SRP
light on.
3. Chipbox
light on.
SYNC Check
1. Sync check
light is
on.
2. Ready
light is
off.
3. Run light
is off.
Possible Causes
Correction Procedure
1. I/O check.
2. Card check.
3. Record check.
1. Follow the procedure indicated
by the other check lights that
are on.
Z. If no other lights are on, press
the start key to re SUITle ope ration.
1. Full chip box.
1. Open door on lower rear panel.
2. Remove chipbox and empty.
3. Replace chipbox and close
cover.
4. Pre ss start on card read punch
to resume operation.
1. Typehar is
not inserted
correctly.
2. Printer
ribbon is
out of line.
10 Determine cause of error.
2. Correct according to 1443
procedure.
3. Press reset key.
4. Pre s s start on printe r (and
card read-punch on Models 1
and 2) to re sume ope ration.
HASP Remote Terminal Operator's Guide (1978) - Page 3.2-6
900
HASP
Figure 3.2.1 Receive Operation Error Stops (Continued)
Error and
Indication
Parity
Check
1. Parity
check
light
is on.
2. Ready
light
is off.
3. Run
light
is off.
Possible Causes
Correction Procedure
1. Invalid character
has been sent to
printer.
1. Press reset key.
2. Press check start button.
3. Pre s s start on printer '(and
card read-punch on Models 1
and 2) to resume operation.
Form Check
1. Forms in printer
1. Form check
are out of line.
light on.
2. Ready
light
off.
3. Run
light
is off.
1. Realign forms in printer
according to 1443 procedures.
Pre
s s the re set key.
2.
3~ Pre ss start on printer (and
card read-punch on Models 1
and 2) to resume operation.
4. The print may be BACKSPACED
or RESTARTed at the central
computer to recover lost time.
HASP Rem.ote Terminal Operator's Guide (1978) - Page 3.2- 7
901
HASP
Figure 3.2.1
Receive Operation Error Stops (Continued)
-
Error and
Indication
Possible Causes
Correction Procedures
End of
Form
l. End of
form
light on.
2. Ready
light off.
3. Run
light
is off.
1. Out of printe r
forms.
1. Insert new printer forms
according to 1443 procedure s.
2. Pre ss start on printe r (and
card read-punch on Models 1
and 2) to resume operation.
Carriage
Interlock
l. Carriage
interlock
light is
on.
2. Ready
light
is off.
1. Carriage brushes
are in a raised
position.
2. 6 or 8 line linch.
belt cover is
raised. '
l. Correct condition.
2. Press start on printer (and
card read-punch on Models 1
and 2) to resutne operation.
HASP Remote Terminal Operator's Guide (1978) - Page 3.2 - 8
902
HASP
Figure 3.2.1 Receive Operation Error Stops (Continued)
Error and
Indication
Possible
Feed
Check
(Model 2
Only)
1. Alarm
sounds.
2. SRP
light
is on.
3. Feed
Check
light
is on.
1.
2.
3.
4.
S.
Causes
Hopper empty.
Card Jam
Failure to
register a card
at one of the
station s in the
transport.
Misfeed at
hopper area.
Misfeed at
stacker area.
Correction Procedure s
Determine cause of feed check. If
the hopper is empty, follow normal
start procedure. Otherwise:
1. Remove cards from stacke r.
2. Remove cards from hopper.
3. If a card jam, follow misfeed
correction procedure to remove
cards.
4. If not a card jaITl, pre s s feed
and stop keys siITlultaneously
twice to clear cards from
machine.
S. Examine cards cleared frorn
machine in steps 3 or 4 and
discard any damaged cards, or
any that are incorrectly or in.completely punched. T4e
da:.:naged cards from a card
jam will have to be duplica,ted
manually, the othe r will be
repunched. (NOTE: The.
Central Computer Operator
may be notified to BACKSPACE
or RESTART the job to recover
damag8d cards.
6. Replace cards removed from
hopper.
7. Follow normal start procedure.
HASP Remote Terminal Operator's Guide (1978) - Page 3.2-9
903
HASP
4. 0 CENTRAL COMPUTER CONTROL
Certain of the control cards recognized by HASP can be introduced
from the relTIote terminal site.
Following is a list and lTIeaning of the se
control cards.
71
1
12
/;~MESSAGE
Any Message
The data punched into columns 12 -71 of this card will be displayed
on the central cOlTIputer operator's console at the tilTIe the job is being
read into the systelTI.
This may be used to identify certain jobs, give
special instructions, etc.
The
within the input job stream.
/~cMESSAGE
card lTIay be placed anywhere
If this card appears within a job, the HASP
number assigned to that job will be appended to the message before displaying i.t,
otherwise the relTIote station ID will be appended.
1
/~:O) is intended
primarily for standard WTO and WTOR support and may not function
properly under certain conditions. For example, HASP console
support may not function properly when:
•
REPLYs to WTORs are erroneously left pending .
•
A non-HASP (e.g., Z EOO) command issues a WTO or a WTOR,
unless it is operating under a separate task.
See HASPGEN parameter &NUMCONS for other restrictions. These
functional restrictions may be removed by using OS console
support (&NUMCONS=O).
C.
HASP will not operate correctly if two or more jobs being simultaneously processed by OS have identical job names. While HASP
will protect against this circumstance for jobs under its control, it is the responsiblity of the user to insure that no job,
submitted outside of HASP control, has the same job name as any
job being controlled by HASP.
O.
Because of the HASP/OS interface techniques and the total system
control status of HASP, no provision has been made to allow
processing to continue after a HASP failure. Any abnormal termination of HASP is considered a system failure and requires a
re-IPL.
E.
All unit-record devices of the type utilized by HASP must be attached to the system (appear as physically existent) at the time
HASP is invoked if they are to be subsequently utilized.
F.
If any SYSOUT data set contains more than 65,535 pages (or skips
to any channel in the carriage tape), then print positioning
(either forward/backward spacing or warm start spacing) will not
function after the 65,535 page (or skip) is reached.
General HASP Restrictions - Page 12.7-3
1105
HAS P
G.
While HASP makes an attempt to enter every WTO and WTOR in the
HASP System Log of the job associated with the message, there
are certain messages (e.g., DDR and MFT I/O Error messages)
which are not readily associated with any given job and may
not be logged.
H.
While HASP is programmed to recover from most catastrophic
Input/Output errors in such a way that the impact on the installation will be minimal, it is conceivable that multiple
unusual errors might occur in a time relationship such that
loss of data is inevitable and complete recovery by HASP is
impossible.
General HASP Restrictions - Page 12.7.3-1
1105.1
HAS P
(The remainder of this page intentionally left blank.)
1105.2
HASP
12 .8
JeL PROCESSING
The HASP philosophy of providing. an interface to OS/360 which is
essentially transparent to the user is supplemented by the collection of
HASP routines which examine and alter JCL statements during system
operation. Since the HASP routines have access to every JCL statement
destined for the
as
scheduler, it is unnecessary to provide a special
Procedure Library (SYSI. PROCLIB) for HASP operation. In addition,
HASP features such as priority and job class scheduling can be easily
realized by including or changing the appropriate "CLASS" and "PRTY"
fields on the JOB JeL statements.
HASP requirements for input stream
(DD*, DD DATA) and output stream (SYSOUT) correspondence to user
defined pseudo I/O units is a maj or function of the JCL routines.
Access to the JeL routines is provided thru the standard OS/360
Reader/Interpreter "exit list" feature which allows the user to specify
a routine to be given control whenever a JeL statement has been
encoded and is ready for individual statement analysis. The encoding
scheme used is described in the MVT Job Management PLM.
JeL Processing - Page 12.8-1
1106
HASP
12.8.1
JCL PROCESSING OS/360 INTERFACE
XNEXRCON - NEL Exit List Reconstruction
The Exit List Reconstruction program receives control from the HASP
LINK/XCTL interface routine when a LINK to the Reader/Interpreter
initialization module (IEFVH1) is intercepted.
The NEL (Interpreter
Entrance List) and associated Exit List is examined for a Special Access
method entry which indicates that the Reader/Interpreter is being used
as a subroutine to process "In-core" JCL. If the Reader/Interpreter is
being used to process jobs, a test is made for the HASP Reader identified
by the default SYSOUT device name of "SPOOL" in the HASPRDR Proclib
Procedure. When the HASP Reader is identified, the Exit List is modified
to include linkage to the main HASP JCL program (XJCLSCAN) from the
Reader/Interpreter after each JCL statement is encoded.
JCL Processing - Page 12.8-2
1107
HAS P
12.8.2
JCL PROCESSING MAIN PROGRAMS
XJCLSCAN - JCL Scan and Control
The JCL Scan and Control Program is entered from the Reader/
Interpreter module IEFVFA as a result of the Exit List linkage
established by the HASP routine XNEXRCON.
The following major
functions are performed:
1.
A return PSW is constructed from the IEFVFA return register
(R14) and the left half of the current PSW provided by entry
to the HASP initialization SVC routine.
This special use
of the initialization SVC allows the JCL routines to operate
disabled when necessary.
2.
The Reader/Interpreter internal text pointer is obtained and
saved for subsequent text processing. A test is made on the
first word of the text to determine if an extensive JCL
statement has caused overflow to SYSl.JOBQUE.
If this condition exists, HASP is unable to process the statement.
3.
The first JCL key in the Reader/Interpreter internal text is
tested for "JOB", "EXEC" and "DD" values and control passed
to the corresponding HASP processor as indicated below:
KEY VALUE
JOB
EXEC
DD
4.
HASP PROCESSOR
XJCLJBPR
XJCLXQPR
XJCLDDPR
All JCL processors terminate by passing control to XJCLEXIT
in the Scan and Control routine.
The termination function is
accomplished by restoring saved registers and issuing a LPSW
using the PSW constructed when the control routine is entered.
Control is returned to IEFVFA.
XJCLJBPR - JOB Statement Routine
The JOB statement routine examines and changes all JOB statements
processed by the Reader/Interpreter.
The major functions performed
are:
1.
A new JOB internal text string is constructed in a HASP workarea.
The new text consists of the original text with "CLASS",
"PRTY"; "TYPRUN" and "MSGCLASS" entries deleted if they were
specified by the user.
JCL Processing - Page 12.8-3
1108
HAS P
2.
A new CLASS entry is produced by extracting the "PITCLAS"
field from the PIT (Partition Information Table) associated
with the job being processed by the Reader/Interpreter.
3.
A new "PRTY" entry is produced by extracting the "PITPRIO"
field from the PIT.
4.
A MSGCLASS value corresponding to the first class given in
the parameter &WTRCLAS is entered into the text unless the
originally specified MSGCLASS corresponded to any class
given in &WTRCLAS.
5.
This newly constructed text is then moved to the Reader/
Interpreter text area.
XJCLXQPR - EXEC Statement Routine
The EXEC statement routine does not examine the associated internal
text if the Execution Task Monitor has not been selected
(&MONINTV=O).
If the Execution Task Monitor has been selected,
then XJCLXQPR performs the following functions:
1.
The value of the Monitor priority represented by the &XZPRTY
is compared with the PIT priority field associated with the
Job being interpreted.
If the values are not equal, then no
further action is taken on the EXEC statement.
2.
If the priorities are equal, the internal text is examined
for the key value of "DPRTY=".
If this parameter has not been
coded, no further action is taken.
3.
If "DPRTY" has been coded under the circumstances cited, it
is removed from the internal text and therefore not processed
by os.
The overall purpose of the action taken by XJCLXQPR is to prevent
circumvention of the function of the Execution Task Monitor by
coding the "DPRTY" field.
XJCLDDPR - DD Statement Routine
The DD statement Routine examines all DD statements for SYSOUT or
DD*, DD DATA Specifications and performs the following major
functions:
1.
The key content of the statement is determined by use of the
XINTSCAN routine.
2.
If the statement does not contain a SYSOUT specification, control goes to the DD*/DD DATA test routine XJCLDDDT.
JCL Processing - Page 12.8-4
1109
HAS P
3.
If a SYSOUT entry exists, the class is saved for possible
translation to a HASP pseudo unit. The class-pseudo unit
translation table (XTRTABLE) entry corresponding to the
SYSOUT class is examined for the values "*", "1", or "2".
If "*" is found, HASP processing is terminated for the DD
card.
If "1" or "2" is found (indicating special routing),
the card will be processed as if special forms were speci~
fied.
If the card was a simple SYSOUT=x, control goes to
the new internal text string build processor.
4.
If the SYSOUT entry includes a special output writer specification, control goes to XJCLDDWR.
5.
If the SYSOUT specified includes a forms field but not a
special writer, the forms field is extracted for later
processing.
6.
The DDNAME, if it exists, is moved to the HASP text buffer
where internal text for UNIT=x is constructed.
7.
If the forms field was detected, then control goes to
XJCLDDFR, otherwise the SYSOUT class is used to translate
to a HASP pseudo unit and the completed UNIT=x text is moved
to the Reader/Interpreter text buffer. Control returns to
the Reader/Interpreter via XJCLEXIT.
JCL Processing - Page 12.8-5
1110
HASP
12 .8.3
TCL PROCESSING INPUT STREAM PROGRAMS
XICLDDDT - DD*
I
DD DATA Test Routine
This routine tests for a DD* or DD DATA specification and goes to
XJCLDDDA if either is found.
*
If the DD statement does not contain an
or DATA, control returns to the Reader/Interpreter via XJCLEXIT.
,
NOTE: The positional parameters "*" and "DATA" are coded as "$"
and "CATA" by the HASP Card Reader Service Main Processor and are
recognized in these formats by XJCLDDDT.
XICLDDDA - DD*
I
DD DATA Processing Routine
This section of XJCLDDDT processes the DD* and DD DATA statements
in the following manner:
1.
The execution PCE for the current job is
est~blished
using
the XESTBPCE subroutine.
2•
The DDNAME (if it exists) and the internal text for
II
UNIT=xxx"
is constructed in the HASP text area.
TCL Processing - Page 12.8-6
, , , 1
HASP
3.
The execution DDT chain is searched for an unassigned DDT.
The EBCDIC unit is extracted from the first available DDT and
inserted in the "xxx" sub field of the "UNIT=xxx" text.
4.
If DCB parameters exist control goes to XJCLINDB, otherwise
I
the HASP default BLKSIZE (defined by &IBLKSZE) and RECFM=F
are added to the constructed text.
5.
Control goes to the termination section of XJCLDDPR where the
new internal text is moved to the reader text bu ffer and proce s sing is completed.
XICLINDB - DD*« DD DATA and DCB Processing Routine
Input stream statements (DD* I DD DATA) with DCB parameters are
processed by this routine in the following manner:
1•
The DCB preservation routine (XJCLDECB) is invoked to
extract and then delete user BLKSIZE and LRECL specifications
while preserving all other DCB parameters.
2•
The HASP maximum/default input stream BLKSIZE (defined by
&IBLKSZE) is moved to a test location (XDEFOBXX) for further
analysis by XJCLSHFL.
JeL Processing - Page 12.8-7
1112
HASP
3.
The BLKSIZE
4.
Control goes to the termination section of XJCLDDPR.
I
LRECL analysis routine XJCLSHFL is entered.
TeL Processing - Page 12.8-8
1113
HASP
12.8.4
TCL PROCESSING OUTPUT STREAM PROGRAMS
XICLDDCB - SYSOUT/DCB Routine
Output stream statements (SYSOUT) with DCB parameters are processed
by this routine as follows:
1.
The DCB preservation routine (XJCLDECB) is invoked to extract
and then delete user BLKSIZE and LRECL specifications while
preserving all other DCB parameters.
2.
The HASP maximum/default output stream BLKSIZE (defined by
&OBLKSZE) is moved to a test location (XDEFOBXX) for further
analysis by XJCLSHFL.
3.
The BLKSIZE, LRECL analysis routine XJCLHSFL is entered.
4.
Control goes to the termination section of XJCLDDPR.
XICLDDWR - SYSOUT with Special Writer Routine
DD statements with a SYSOUT specification which includes a special
writer entry are processed by this routine:
JCL Processing - Page 12.8-9
1114
HASP
1.
A test is made for a UNIT specification in the statement containing
the SYSOUT disposition.
If UNIT has been specified
I
control returns
to the Reader/Interpreter via XJCLEXIT.
2.
If UNIT is not specified
I
the text for UNIT=SYSDA is added to the
Reader/Interpreter text and processing is terminated via XJCLEXIT.
This addition is made to overcome the HASPRDR procedure default
SYSOUT unit of SPOOL.
XICLDDFR - SYSOUT with Forms Routine
This routine processes a forms specification in conjunction with a SYSOUT
disposition:
1.
A test is made to determine if the current job has depleted the special
forms pseudo devices (1442 for punch
I
1443 for print) and the forms
specification is ignored if so.
2.
The Execution Processor PCE for the current job is established using
the XESTBPCE subroutine.
3.
The Execution Processor .routine XGETDDB is used to get a DDT.
DDT is not available
I
It a
control goes to XJCLWAIT to place the Reader/
Interpreter task in an OS wait state pending the availability of a DDT.
4.
The Execution Processor routine XGETUCB is used to get the appropriate
pseudo device UCB.
If a UCB of the correct type is not available
I
control goes to XJCLWAIT.
JCL Processing - Page 12.8-10
1115
HASP
5.
The DDBTYPE entry in the acquired DDT is set to indicate the output
type according to the SYSOUT clas s specified (print, punch, special
routing print, or special routing punch).
6.
The DDBSTATI entry in the acquired DDT is set to indicate no primary
buffer.
7.
The DDBSTAT2 entry in the acquired DDT is set to indicate an allocatable DCB exists.
8.
The EBCDIC unit address from the DDBUNIT field of the DDT is moved
to the UNIT=xxx internal text establishing the HASP pseudo unit for
forms processing.
9•
10.
The extracted forms field is moved to the DDBFORMS field of the DDT.
The UNIT=xxx text is moved to the HASP text buffer and control goes
to the DCB test section of XJCLDDPR.
JCL Proces sing - Page 12. 8- 11
1116
HASP
12 .8.5
JCL PROCESSING SUBROUTINES
XTCLSHFL - BLKSIZE!LRECL Subroutine
This routine is used to analyze BLKSIZE and LRECL values, if specified,
for both input stream (DD* I DD DATA) and output stream (SYSOUT) statements.
1•
Processing proceeds as described below:
The key status word (XSTATUS) is tested for both BLKSIZE and
LRECL specifications and control goes to the section (XJCLBOTH)
which processes this case.
XJCLBOTH compares the user
LRECL with the maximum/default HASP BLKSIZE (&OBLKSZE or
&IBLKSZE).
If the specified LRECL is greater than the HASP
maximum BLKSIZE, both LRECL and BLKSIZE are set to the value
of the HASP maximum/default BLKSIZE (SOBLKSZE OR &IBLKSZE)
and processing is terminated.
2•
If both BLKSIZE and LRECL have not been specified, a test is
made for BLKSIZE only.
If BLKSIZE has not been specified, the
HASP default BLKSIZE (&OBLKSZE or &IBLKSZE) is used and proces sing is terminated.
3.
If BLKSIZE alone is specified, it is
u~sed
as is and processing
is terminated.
JCL Processing - Page 12.8-12
1117
HASP
XICLDECB - DCB Preservation Subroutine
The purpose of this routine is to investigate DCB parameters specified
on input stream (SYSOUT) and output stream (DD* I DD DATA) statements
and to perform the following functions:
1•
Locates the position of the DCB substring in the Reader/Interpreter
internal text by use of the XINTSCAN subroutine.
2•
Examines all DCB subparameters in the DCB substring.
BLKSIZE
and LRECL specifications are extracted by the XJCLXTRC Routine
for analysis by XTCLSHFL.
3.
All user DCB subparameters, except BLKSIZE and LRECL, are
moved to the HASP text buffer for retention.
4.
When the end of the DCB substring is reached, control returns
to the caller.
XICLXTRC - BLKSIZE!LRECL Data Extractor Subroutine
This routine is used to extract the user specified BLKSIZE or LRECL
data fields from the Reader/Interpreter internal text for later analysis
by XJCLSHFL.
Processing is as follows:
JCL Processing - Page 12.8-13
1118
HASP
1.
The address of the target field for the extracted data is contained
in Register WD.
2•
This field, is set to decimal zeros.
The maximum field length, defined by XJCLMXLT, is used to
extract the low order XJCLMXLT bytes from the Reader text for
insertion into the target field.
3•
Control returns to the caller.
XESTBPCE - Execution Processor PCE Search Subroutine
This routine finds the Execution Processor PCE associated with the
job being processed by the Reader/Interpreter.
1.
The current (Reader/Interpreter) TCB address is found via the
as
2.
Communication Vector Table.
The Execution Processor PCEI s are searched for the peE
corresponding to the current TCB.
3.
The correct PCE address is returned to the caller in the SAVE
Register.
JCL Processing - Page 12.8-14
1119
HASP
XINTSCAN - Internal Text Scan Subroutine
This routine provides two major functions.
The contents of the
Reader/Interpreter internal text with respect to the key values encoded
from the users original TCL statement can be determined.
The position of
a particular key value in the text string can be determined. The general
program logic is:
1.
The pointer to the first key in the internal text is obtained from
XINTKEYS which is set when XJCLSCAN is entered for each JCL
statement.
2•
A test is made on the contents of Register RO. If RO contains
the value of XJSENDKE (a special key value indicating the end
of the text string) then control goes to the section of XINTSCAN
which determines the key contents of the text. Any other value
in RO is as sumed to be a
reques~
to find that particular key in
the text string.
3.
When a particular key search is specified, the subroutine
XFINDKEY is used to obtain successive keys from the internal
text until the requested key is found or until the end of the
string is reached. A successful search is flagged by setting
RO non- zero and placing the pointer to the requested key location in Rl and returning to the caller. If the search is
JCL Processing - Page 12.8-15
HASP
unsuccessful, RO is set to zero before returning.
4.
The key contents of the internal text string is reflected by the
final disposition of the XSTATUS word. XSTATUS bits are set
on as dictated by the key values in the text and the selected
key values defined by the table XSTATDEF • Whenever an
internal text key is found which matches an entry in the
XSTATDEF table, a corresponding bit is turned on in the XSTATUS·
word. Using this scheme, the entire internal text string is
examined and the selected key values, if they exist in the
string, are reflected by XSTATUS.
5.
After the setting of XSTATUS, the address of the end key of the
text string is saved in XINTENDK and the length of the. text is
calculated and saved in XINTEXTL.
XSTATUS is placed in Rl
and control returned to the caller.
XFINDKEY - Next Key Byte Search Subroutine
This routine is used to find the position of the next key byte in the
internal text given the position of the preceding key byte.
Rl points to
the preceding (current) key byte on entry. Rl points to the next key byte
on exit.
JCL Processing - Page 12.8-16
1121
HASP
12.9
HASP/RJE LINE TRANSMISSION TECHNIQUES
The following sections discuss, in detail, the line transmission tech-
niques utilized by HASP to communicate with remote terminals which have
program.ming capabilities.
Transmission formats to mechanical terminals,
such as the IBM 1978, follow the specifications as outlined in the manuals
fa r tho se te rtninals.
HASP/RJE Line Transmission Techniques -
1122
Page 12.9-1
I-IASP
12.9. I
1-7/8 of 8 Encoding
In order to support the entire EBCDIC character set from a remote
station, with no unnecessary degradation of line transmission, a new
encoding technique, inadaquately named 1-7/8 of 8, was devised.
1-7/8
of 8 is (obviously) based on the standard STR-4 of 8 encoding and operates
in the following manner:
The standard 4 of 8 character encoding has been entirely re-defined
such that, the logically highest 48 characters of the 4 of 8 set have been
defined as the 48 most common EBCDIC (BCD) characters.
The rell'laining
16 4 of 8 characters have been reserved for use as 1-7/8 characters to
represent the remaining EBCDIC characters.
These 16 characters are
defined as the hexadecimal digits "0" - llF" so that any of 256 character
combinations ll'lay be repre sented with two (2) 1-7/8 character s.
Since
1-7/8 character s repre sent the nUll'lerically lowe st characte r s of both
the 4 of 8 character set and the EBCDIC character set, the receiving
program may detect 1-7/8 encoding (either before or after 4 of 8 trans1ation) by a single logical compare instruction.
This, then allows for
the intermixing, within a single record, of norm.al character encoding
(1 for 1) and 1-7/8 (2 for 1) with no additional control inform.ation.
Any
character repre sented by 1-7/8 encoding may be reconstructed with a single
MOVE WITH OFFSET instruction in the receiving program.
HASP/RJE Line Transm.ission Techniques -
1123
Page 12.9-2
HASP
Since a very high percentage of all characters contained in a prograIn
source deck are of the 48 character set, normal transmission of jobs
from a remote site will be in a I for 1 character representation with
an occasional "unusual" character represented by 1-7/8 encoding.
This feature also allows the random interspersing of 08/360
object decks in an input stream.
Figure 12. 9. I shows the 1-7/8 of 8
definitions for the 4 of 8 character set.
HASP/RJE Line Transmission Techniques -
1124
Page 12.9-3
HASP
Figure 12.9.1
Graphic
(1-7/8
(1-7/8
(1-7/8
(1-7 /8
(1-7/8
(1-7/8
(1-7/8
(1-7/8
(1-7/8
(1-7/8
(1-7/8
(1-7/8
(1-7/8
(1-7/8
(1-7/8
(1-7/8
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
1-7/8 of 8 -
EBCDIC
8)
8)
8)
8)
8)
8)
8)
8)
8)
8)
8)
8)
8)
8)
8)
8)
00
01
02
03
04
05
06
07
08
09
OA
OB
OC
OD
OE
OF
FO
Fl
F2
F3
F4
F5
F6
F7
F8
F9
Cl
C2
C3
C4
C5
C6
4 of 8 Conversion Table (48 characters)
4 of 8
OF
17
1B
ID
IE
27
2B
2D
2E
36
3A
3C
47
4B
4D
4E
56
5A
5C
63
65
66
69
6A
6C
71
72
74
78
87
8B
8D
Graphic
EBCDIC
G
H
C7
C8
C9
Dl
D2
D3
D4
D5
D6
D7
D8
D9
E2
E3
E4
E5
E6
E7
E8
E9
4B
4D
4E
50
5C
5D
60
61
6B
7D
7E
40
I
J
K
L
M
N
0
P
Q
R
S
T
U
V
W
X
y
Z
(
+
&
..
~,
I'
)
-
/
,
,
=
(blank)
HASP/RJE Line Transmission Techniques
1125
-
4 of 8
Page 12.9-4
8E
93
95
96
99
9A
9C
A3
A5
A6
A9
AA
AC
Bl
B2
B4
B8
C3
C5
C6
C9
CA
CC
D1
D2
D4
D8
E1
E2
E4
E8
FO
HASP
12.9.2
Character Compression Techniques
HASP
I
when communicating with a remote terminal with programming
capabilities (as indicated at HASPGEN)
I
optionally utilizes a duplicate
character compression algorithm to improve transmission line efficiency.
This algorithm breaks each logical record into one or more character
strings, prefaced by a pair of string control bytes (BCSs) to indicate the
type and extent of the character string.
sess are in the form - IT KL
where:
JL
=
a count describing the extent of the character string.
This count is obviously derived by combining the low
order digit of both SCBs.
Counts on records created
by HASP are one less than actual, while the count on
substrings received by HASP are expected to represent
the actual count.
I
=
a HEX digit which identifies the type of character
string as follows:
I=X'Q' - indicates a normal character string.
(i. e. the
number of characters described by • JL' should be inserted intact when reconstructing the record image.
I=X' F' - indicates that' JL' blank characters should
appear in the reconstructed record image.
Note that no
additional characters are required with this type of
string.
HASP/RJE Line Transmis s ion Techniques
1126
Page 12.9-5
HASP
,,
I=X 4
"
or X C
- indicates that the character
immediately following the SCB s should be
duplicated 'JL' times and inserted into the
image being reconstructed.
K
=
a HEX digit to additionally describe a character substring.
IS
K
presently 0 in all cases but is reserved for future expansion.
Any character in a normal character string or the sample character in non ,blank compre s sion may be encoded in a 1 for 1 repre sentation or in 1-7/8
representation (2 for 1).
The count indicated by 'JL' is a character count,
rather than a byte count, so that a character represented by 2 bytes (1-7/8)
cause s only a count increment of 1.
A logical OUTPUT record from HASP, which may consist of several
SCBs and associated character strings, is terminated by the special SCB
of X'FOFO'.
(This record terminator is not used on records sent to HASP
since a reconstructed record length of 80 may be assumed).
A physical
record, which may consist of several logical records, is terminated by
the special SCB of X'FOFO' immediately following the last logical record.
(Again in the case of input records to HASP the X'FOFO' is notused to
terminate the buffer)
The following examp1e illustrates each of the HASP encoding techniques.
Assume the record below is to be encoded by HASP for trans-
mission to a remote terminal as punched output.
HASP /RJE Line Transmission Techniques
1127
-
Page 12.9-6
HASP
o
00
33
8
55
44
44
o
67
56
43
78
23
******bbbbb ... bbAbTE8T? bbbbb? ? ? ? ? ? ? bbbb .... b
1
Where
b=BLANK=X'40',? =NON 48 Character Set Character=X'6F'
This record, after compression and before 4 of 8 translation, would appear
as below (with 8CB s underlined):
4005 5CF 1 OC0006C ~ 40E 3C5E2E 3060FF0044006060F~
Note that trailing blanks are not encoded by HASP.
After translating to 4 of 8
characters the record would be:
---
-
F02 7D25A4 70F2B 72FOB 18BACB 12B4E 56 IE F02B2B4E5656
- - -----
Note that 8CB characters are encoded, as required, in 1-7/8.
HASP/RJE Line Transmission Techniques
1128
Page 12.9-7
HASP
12.9.3
HASP Transmission Block Encoding
The following pages describe the format of physical records transmitted by HASP to a programmable remote terminal and the format of
phy sical records expected by HASP from such a terminal.
All value s are
indicated in EBCDIC (rather than 4 of 8) for simplicity.
HASP/RJE Line Transmission Techniques
1129
-
Page 12.9-8
HASP
PRrnT RECORD
The first two bytes of a logical print record are used to indicate
carriage control requirements to the remote terminal program.
The
following list indicates all current carriage control characters and their
meaning.
BYTE 1
BYTE 2
=
X'04'
Space immediate "N" spaces
=
X'05'
Skip immediate to channel "N"
=
x'o6'
Space "N" afte r print
=
X'07'
Skip to channel "N" after print
=
X'08' - Suppre s s space
=
X'Ol'
X'03'
=
X'Ol'
X'OF' - "N"
=
X'OO'
if suppress space is indicated above.
- "N"
as described in space commands above.
as described in skip commands above.
Immediately after the carriage control bytes, any number of character
strings constituting the line to be printed may follow, ended by a SCB of
X'FOFO' to indicate the end of record.
(In the case of carriage control only,
the X'FOFO' may immediately follow the carriage control information).
The
above sequence may be repeated as many times as buffer space permits,
followed finally by another X'FOFO' to indicate end-of-buffer.
HASP/RJE Line Transmission Techniques
1130
-
Page 12.9-9
HASP
NOTE:
In order to minimize CPU requirements at the remote terminal,
HASP does not utilize 1-7/8 encoding on print records.
The
16 characters normally utilized for 1-7/8 encoding are defined as
additional print characters, thus yielding a 64 character print
set. An attempt to print a character which is not in this character set results in the substitution of a blank for that character.
Figure 12.9.3 indicates the 4 of 8 definitions for the 64 character
print set. Although data characters are not encoded in 1-7/8
carriage control and String Control bytes may be encoded in
1-7/8 as required.
HASP/RJE Line Transmission Techniques -- Page 12.9-10
1131
I
HASP
Figure 12.9.3
Graphic
~
<
I
!
$
,
l
%
>
?
#
@
II
EBCDIC/4 of 8 Conversion Table (64 characters)
EBCDIC
4A
4C
4F
5A
5B
5E
5F
6C
6D
6E
6F
7A
7B
7C
7F
I-
EO
a
1
Fa
F1
F2
F3
F4
F5
F6
F7
F8
F9
C1
C2
C3
C4
C5
C6
2
3
4
5
6
7
8
9
A
B
C
D
E
F
4 of 8
OF
17
IB
ID
IE
27
2B
2D
2E
36
3A
3C
47
4B
40
4E
56
5A
5C
63
65
66
69
6A
6C
71
72
74
78
87
8B
8D
Graphic
EBCDIC
G
C7
C8
C9
D1
D2
03
D4
D5
D6
D7
D8
09
E2
E3
E4
E5
E6
E7
E8
E9
4B
4D
4E
50
5C
5D
60
61
6B
7D
7E
40
H
I
J
K
L
M
N
0
P
Q
R
S
T
U'
V
w
X
Y
Z
(
+
&
• W
','
)
/
,
I
=
(blank)
HASP /RJE Line Transm.ission Techniques -
1132
4 of 8
8E
93
95
96
99
9A
9C
A3
A5
A6
A9
AA
AC
Bl
B2 ~I~
B4
B8
C3
C5
C6
C9
CA
CC
Dl
D2
D4
D8
E1
E2
E4
E8
Fa
Page 12.9-11
HASP
PUNCH RECORD
A punch record generated by HASP for transmission to a terminal
has exactly the same format as a print record.
The punch record is so
identified by "carriage control" bytes of X·OFOF·.
In order to support
the punching of OS/360 object decks at the remote site, 1-7/8 encoding
is utilized as required.
HASP/RJE Line Transmission Techniques -
1133
Page 12.9-12
HASP
INPUT RECORD
Input records to HASP from a remote te rminal consist only of character strings and their associated SCBs.
Note that no end-of-record
characters are used to separate card images.
The end-of-logical-record
condition is assumed by HASP upon expanding the 80th character of a card
image.
The end-of-buffer condition will be detected by HASP for the byte
count of the data transmitted.
1-7/8 encoding is utilized when required.
HASP/RJE Line Transmission Technique
1134
-
Page 12.9-13.
HASP
12.10
HASP INTERNAL READER
A procedure exists in HASP to allow the introduction of jobs directly
into the HASP job stream from any other program operating in the system.
The following sections describe techniques to accomplish this.
HASP Internal Reader -
1135
Page 12.10-1
HAS P
12.10.1
PROCEDURE FOR USING THE HASP INTERNAL READER
The method of passing jobs to HASP through the internal reader
is by writing "cards" to a pseudo 2520 card punch device.
Standard
OS/360 QSAM put or BSAM WRITE macros may be used to write the "cards"
to the pseudo punch.
The information which would be physically
punched into a real 2520 card punch will be passed to the normal HASP
reader for insertion into the HASP Job Queue.
The last "job" must be
followed by a "card" with an end of file indicator (/*EOF in columns
1-5).
The end of file "card" is used to free the last job a110wirig
it to be scheduled for execution.
12.10.2
I
JCL CONSIDERATIONS
Since any resident (non-swappab1e) system or user task may utilize the HASP internal reader, the method of allocation and controlling the use of the device is via OS/360 Job Control Language.
Fig-
ure 12.10.1 shows an example of an OS/360 IEBGENER utility run which
reads Job Control Language card images from a disk data set passing
the jobs to HASP.
The program that created the data set inserted
the end of file card at the end of the data.
12.10.3
OS/360 - SYSGEN CONSIDERATIONS
Pseudo 2520 punch units must be specified at OS/360 SYSGEN time.
The device addresses selected as pseudo punches must be legal System/
360 addresses but must not be recognized by the physical devices
HASP Internal Reader - Page 12.10-2
1136
HAS P
or control units attached to the System/360.
One device should be
generated for each internal reader allocated at any given time and
I
should correspond to the value of the HASPGEN parameter &NUMINRS.
The following card might be used to generate an appropriate Unit
Control Block.
IODEVICE
I
UNIT=2520,ADDRESS=30l,MODEL=B2
The devices should be descriptively named for ease of allocation.
The following card might be used to name three internal
readers:
UNITNAME
12.10.4
unit=(30l,302,303) ,NAME=INTRDR
DELETION OF CURRENT JOB ON READER
If the submitting task determines that the previous JCL and/or
data of the job currently being punched into the internal reader is
incorrect a deletion card (/*DEL in columns 1-5) may be punched.
This will cause the job currently on the device to be deleted as
though cancelled by the operator.
HASP Internal Reader - Page 12.10-3
1137
HASP
Figure 12.10.1
Sample Use of HASP Internal Reader
IIPASSJOB JOB (OOOQ,OOOO) ,'PASS JOB STREAM',MSGLEVEL=l
IICOPY
IISYSIN
EXEC PGM=IEBGENER
DD DUMMY
IISYSPRINT DD SYSOUT=A
IISYSUTl
DD DSNAME=DAYSWORK,DISP=SHR
IISYSUT2
DD UNIT=INTRDR,DCB=(RECFM=F,BLKSIZE=80,LRECL=80)
1138
HASP
12 . 11
MULTI-LEAVING
"MULTI-LEAVING" is a term which describes a computer-to-computer
communication technique developed for use by the HASP SYSTEM.
gross sense
I
In a
MULTI-LEAVING can be defined as the fully synchronized
pseudo-simultaneous
I
bi-directional transmission of a variable number of
I
data streams between two or more computers utilizing binary synchronous
communications facilities.
The following section describes
of MULTI-LEAVING.
I
in general terms
I
the basic structure
Section 12.10.2 describes the detailed specifications
of the MULTI-LEAVING control information and Section 12.10.3 discl:lsses
the application of MULTI-LEAVING to the HASP BSe/RIE support.
12. 11.1 MULTI-LEAVING Philosophy
The basic element for MULTI-LEAVED
string:.
tr~nsmission
is the character
One or more character strings are formed from the smallest external
element of transmission - the phsyical record. These phsyical records are
input to MULTI-LEAVING and may be any of the classic record types (card
images
I
printed lines
I
tape records
I
etc).
For efficiency in transmission
I
each of these data records is reduced to a series of character strings of two
basic types. These two types are (1) a variable length nonidentical s,eries
of characters and
I
(2) a variable number of identical characters.
of the high frequency occurrance of blank characters
I
a special case is
MULTI-LEAVING 1139 '
Because
Page 12.11-1
HA8P
:made in 2 above when the duplicate character is a blank. An eight bit
control field
I
termed a String Control Byte (8CB)
I
precedes each character
string to identify the type and length of the string.
Thus a string as in 1
above is represented by an 8CB followed by the nonduplicate characters.
A string of consecutive
I
duplicate
I
nonblank characters (as in 2 above)
can be represented by an 8GB and a single character (the 8GB indicates the
duplication count and the character following indicates the character to be
duplicated).
In the case of an all blank character string
I
only an 8GB is
required to indicate both the type and number of blank characters. A data
record to be transmitted is therefore segmented into the optimum number of
character strings (to take full advantage of the identical character compression)
by the transmitting program. A special SGB is utilized to indicate the grouping
of character strings which compose the original physical record.
The receiving
program can then reconstruct the original record for processing.
In order to allow multiple physical records of various types to be grouped
together in a single transmission block
I
an additional eight bit control field
precedes the group of character strings representing the original phys ical
record.
This field
I
the Record Control Byte (RCB)
I
identifies the general
type and function of the physical record (input stream
I
print stream
I
data set
etc). A particular RCB type has been designated to allow the passage of
control information between the various systems. Also, to provide for
. simultaneous transmission of similar functions (i. e. multiple input streams
1140
I
I
HAS P
etc) a stream identification code is included in the RCB. A second 8 bit
control field, the Sub- Record Control Byte (SRCB) is also included immediately
following the RCB.
This field is utilized to supply additional information
concerning the record to the receiving program.
For example, in the trans-
mis sion of data to be printed, the SRCB can be utilized for carriage control
inf orma tion .
For actual MULTI-LEAVING transmission, a variable number of records
may be combined into a variable block size, as indicated previously (i. e.
(RCB SRCB, SCB1, SCB2 , ... SCBn, RCB, SRCB, SCBl , •.• etc).
I
Th~ MULTI-
LEAVING design provides for two (or more) computers to exchange transmission
blocks, containing multiple data streams as described above
leaved fashion.
I
in an inter-
To allow optimum use of this capability, however, a system
must have the capability to control the flow of a particular data stream while
continuing normal transmission of all others'.
This requirement becomes
obvious if one considers the case of the simultaneous transmission of two
data streams to a system for immediate transcription to physical I/O devices
of different speeds (such as two print streams) .To
provid~
for the metering
of the flow of individual data streams, a Function Control Sequence (FCS)
is added to each transmission block.
The FCS is a sequence of bits, each
of which represent a particular transmission stream.
The
receiv~r
of several
data streams can temporarily stop the transm.issionof a particular stream by
setting the corresponding FCS bit OFF in the next transmission to the sender
of that stream.
The stream can subsequently be resumed by setting the bit
ON.
MULTI-LEAVING -
1141
Page 12.11-3
HASP
Finally, for error detection and correction purposes, a Block Control
Byte (BGB) , is added as the first character of each block transmitted.
The
BCB, in addition to control information, contains a modulo 16, block sequence
count. This count is maintained and verified by both the sending and
receiving systems to exercise a positive control over lost or duplicated transmis sion blocks.
In addition to the normal binary synchronous text control characters
(STX, ETR, etc), MULTI-LEAVING utilizes two of the BSC control characters -ACKO and NAK. ACK 0 is utilized as a "filler" by all systems to maintain
communications when data is not available for transmission. NAK is used
as the only negative response and indicates that the previous transmission
was not successfully received.
Figure 12. 11 . 1 indicates the format of
a typical MULTI-LEAVING transmission block.
MULTI-LEAVING -
1142
Page 12.11-4
HASP
Figure 12.11.1 -
Typical MULTI-LEAVING Transmission Block
bytes
DLE
BSC Leader (SOH if no trans parency feature)
STX
BSC START-OF-TEXT
BCB
Block Control Byte
FCS
Function Control Sequence
FCS
Function Control Sequence
RCB
Record Control Byte for record 1
SRCB
Sub- Record Control Byte for record 1
SCB
String Control Byte for record 1
DATA
Character String
SCB
String Control Byte for record 1
DATA
Character String
SCB
Terminating SCB for record 1
RCB
RCB for record 2
SRCB
SRCB for record 2
SCB
SCB for record 2
DATA
Character String
SCB
Terminating SeB for record 2
RCB
Transmission Block Terminator
DLE
BSe Leader - (SYN if no transparency feature)
ETB
BSe Ending Sequence
MULTI-LEAVING -
1143
Page 12.11-5
HASP
12.11.2 MULTI-LEAVING Control Specification
The following pages indicate the bit-by-bit definitions of the various
MULTI- LEAVING control fields and notes concerning their utilization.
-MULTI::-L-EAVING -
1144
Page 12. 11- 6
HASP
String Control Byte (SCB)
10
K L
J J J J JI
o
7
Usage:
Control field for data character strings
Bit Meanings:
o
0 =
End of record (K L J J J J J = 0)
a
1
=
All Other SCB's
K =
0
=
Duplicate Character String
L
=
0 =
Duplicate Character is blank
L
=
1
Duplicate Character is non blank
(and follows SC B)
=
=
JJJJJ
K =
1
::t:
Duplication count
Nonduplicate Character String
=
LJJJJJ
=
Character String Length
NOTES:
1.
If KLJJJJJ
=0
and 0
= I,
SCB indicates record is continued in next
transmission block.
2.
Count units are normally 1 but may be in any other units.
The units
utilized may be indicated as function control sign-on or dyqamically
in the SRCB.
MULTI-LEAVING
1145
~
Page 12.11-7
HASP
Re?ord Control Byte (RCB)
10IIITTTTI
o
7
Usage:
To identify each record type within a transmission block
Bit Meanings:
o =
0
=
End of transmission block (I I ITT T T
o =
1
=
All Other RCB s
= 0)
I
III
=
Stream identifier - used to identify streams of
multiple identical functions (i. e. multiple print
streams to a multiple printer terminal, etc.)
III
=
Control information if TTTT
=
000
=
Reserved for future expansion
=
001
=
Request to initiate a function transmission
(Prototype RCB for function in SRCB)
=
010
=
Permission to initiate a function transmission
(RCB for function contained in SRCB) •
TTTT
= 011 =
Reserved
=
Reserved
100
=
=0
(control record)
= 101 =
Available for local modification
= 110 =
Available for local modification
=
III
General Control Record (type indicated in
SRCB)
=
Record type identifier
=
0000
=
=
= 0001 =
Control record
Operator message display request
MULTI-LEAVING -
1146
Page 12.11-8
HASP
TTTT = 0010 = Operator command
=
0011
= , Normal
=
0100
=
Print record
=
0101
=
Punch record
=
0110
=
Data set record
=
0111
=
Terminal mes sage routing request
=
1000
1100
=
= 1101
1111
= Available for local modifications
input record
Reserved for future expansion
MULTI-LEAVING -
1147
Page 12.11-9
HASP
Slib-Record Control Byte (SRCB)
10
o
8 8 8 8 8 8 81
7
Usage:
To provide supplemental information about a record
Bit Meanings:
a
SSSSSSS
=
1
(Must always be ON)
=
Additional record information - actual content
is dependant on record type. Several examples
are listed below --
SRCB for General Control Record
(character)
o
7
Usage:
To identify the type of generalized control record
Bit Meanings:
character
=
A
=
Initial terminal SIGN-ON
:c
B
=
Final terminal SIGN-OFF
=
C
=
Print initialization record
=
D
=
Punch initialization record
=
E
=
Input initialization record
=
F
=
Data set transmission initialization
= G
=
System configuration status
MULTI-LEAVING -
1148
Page 12.11-10
HASP
=
H
=
=
I
R
=
Reserved
=
S
Z
=
Available for local modification
Diagnostic control record
SRC B for Print Records
10
M C C C C
eel
o
7
Usage:
To provide carriage control information for print records
Bit Meanings:
o
=
1
(Must always be ON)
M
=
0
=
Normal carriage control
= 1 = Reserved for future use
CCCCCC =
Carriage control information
=
1000NN =
Space immediately NN spaces
=
IINNNN =
Skip immediately to channel NNNN
=
OOOONN =
Space NN lines after print
=
01XXXX
= Skip to channel NNNN after print
=
000000
= SUPPRESS SPACE
MULTI-LEAVING -
1149
Page 12.11-11
HASP
SRCB for Punch Records
IOMMBRRssl
o
7
Usage:
To provide additional information for punch records
Bit Meanings:
o
=
1
SS
=
Punch stacker select information
B =
M
(Must always be ON)
0
=
Normal EBCDIC card image
=
1 =
Column Binary card image
=
00 =
SCB count units =
1
=
01
=
SCB count units -
2
=
10 =
SCB count units =
4
=
11
RR =
=
Reserved
Reserved for future expansion
SRCB for Input Record
IOMMBRRRRI
o
7
Usage:
To provide additional information for input records
MULTI-LEAVING -
1150
Page 12.11-12
HASP
Bit Meanings:
o =
M =
RRRR
1
(Must always be ON)
00 =
8CB count units =
1
=
8CB count units =
2
8CB count units =
4
=
01
=
10 =
=
11
=
Re served
=
Reserved
, SRCB for Terminal Message Routing Record
IOTTTTTTT
o
7
Usage:
To indicate the destination of a terminal message
Bit Meaning s:
o =
1
(Must always be ON)
TTTTTTT
=
Remote system number (1 ~ T ~ 99)
TTTTTTT
=
Remote system group
TTTTTTT =
0 =
I
as HASPGENed (100 ~, T ~ 127)
Broadcast to all remote systems
MULTI-LEAVING -
1151
Page 12.11-13
HASP
Function Control Sequence (FCS)
loS
R R ABC Dr 0 T R R W X Y Z
o
7
8
I
15
Usage:
To control the flow of individual function streams
Bit Meanings:
a = 1 (Must always be on)
S = 1 = Suspend all stream transmissfon :(WAIT-A-SIT)
0
Remote console stream identifier
R
=
=
ABCD ... WXYZ
=
Various function stream identifiers (oriented only to
.recipient)
-
Normal print (or
-
Normal punch streams
-
Other functions
T
NOTE
-
=
Normal state
=
Reserved· for future expansion
input)~
A, B', C, ...
=
Z Y X, .••
I
I
=
a bit on =
continue function transmis sion
bit off'
suspend function transmission
=
MULTI"'LEAVING -
1152
Page 12.11-14
HASP
Block Control Byte (BCB)
10
X X X C C
ccl
a
7
Usage:
Transmis sion block status and sequence count
Bit Meanings:
o
=
1
(Must always be ON)
ecce =
Modulo 16 block sequence count
xxx =
Control information as follows --
=
000
=
Normal Block
=
001
=
Bypass sequence count validation
=
010
=
Reset expected block sequence count to
=
011
=
Reserved
=
100
= Reserved
::;::
101
= Available for user modification
= 110
= Available for user modification
=
= Reserved for future expansion
III
MULTI-LEAVING -
1153
ecce
Page 12.11-15
HASP
12.11.3 MULTI-LEAVING In BSC/RIE
The p~evious sections have grossly outlined the specifications of a
comprehensive, MULTI- LEAVING communications system. While the HASP
support for programmable BSe workstations
the MULTI-LEAVING design
I
iscompl~tely
consistent with
it does not utilize certain of the features
provided in MULTI-LEAVING. These features not utilized include:
1.
The transmission of record types other than print, punch,
input
2.
I
console and control is not supported.
The only general control record type utilized is the terminal
SIGN-ON control.
utilized~
3.
Only SeB count units of 1 are
4.
No support is included for column binary cards .
MULTI-LEAVING -. Page 12.11-16
1154
HAS P
12.12
HASP 2770 AND 3780 RJE SUPPORT
12.12.1
2770 Configuration
The basic 2770 with standard keyboard and either EBCDIC or USASCII
code is supported.
Optional supported devices are the 2502 Card Reader,' 2213 Printer,
2203 Printer, and 545 Output Punch. The printer must be attached
to OUTPUT PRINTER. The card punch must be attached to OUTPUT 2.
EBCDIC Transparency, Printer Horizontal Format Control, Space
Compression/Expansion, and any of the three buffer sizes (128, 256,
512) are supported by HASP programming. The Multipoint Data Link
Control feature and Identification features must not be present.
All other devices and features may be attached, but are either not
affected by programming or not supported.
I
12.12.2
I/O Formats
Although HASP formally supports only the keyboard, card, and printer
I/O devices listed previously in Section 12.12.1, the basic design
of the IBM 2770 (i.e., media formats independent of transmission format) may make it possible for individual installations to use other
I/O devices. This must be done only after careful analysis, design
and testing by the customer and local IBM Representative to establish the feasibility of the proposed device usage in the customer's
environment. Refer to the SRL GA27-30l3, especially pages 2772-9,
CU-2,3 and appropriate device sections. Also, the following descriptions of HASP's handling of input and output transmission blocks from
and to the 2770 will aid in analysis of other device usage possibilities.
Input
Input blocks to HASP from any device on the 2770 are transformed
into 80 character records of an as job stream, according to one of
the following two rules:
1.
If the block is non-transparent, it is interpreted as
one or more records of 80 or less data characters, each
ended by an IRS character which does not become part of
the record processed by as. Compressed blanks, indicated
by the IGS characters, are detected and expanded prior to
processing by OS, if the HASPGEN parameter &BSHPRES=YES.
HASP 2770 RJE Support - Page 12.12-1
1155
H A"-'S P
I
I
I
2.
If the block is transparent, it is interpreted as one or
more records of exactly 80 data characters. No record
ending characters are recognized.
,"Transparent and non-transparent input blocks may be mixed, in any
order, in any job or series of jobs transmitted to HASP. Proper
handling of compressed blanks in non-transparent input blocks and
proper handling of transparent input blocks are not dependent upon
the setting of the RMTnn HASPGEN parameter describing the particular
terminal.
Therefore, to' use other input devices, the input medium and device
must conform to the above. The device may be connected to any INPUT
position as long as that position is switched on before transmission
is initiated. Input which does not conform to these rules will cause
unpredictable deblocking when received by HASP and probably error
messages or incorre"ct results when processed by OS or the user's
program.
If the input medium/device cannot produce an IRS record ending character or if control characters are used as data, then the transmission must be unblocked and/or possibly transparent. The processing
program must handle as data any record ending character other than
IRS which the medium/device may produce."
An input medium other than cards may not be suitable for the preparation and transmission of OS JCL cards (e.g., //ANY JOB ••• up to
//SYSIN DD *) which are required preceding data in an OS input job
stream. The keyboard may be used to transmit such cards, followed
by data from the other device, using an operational procedure similar to that described for the keyboard and card reader on page 11
of the 2770 Operator's Guide.
Output
Output from HASP to the 2770 is in two forms: one intended for
printing~ the other for punching cards.
These outputs are produced
during OS execution of jobs by using the disposition SYSOUT= on DD
cards. The decision to produce printed or punched output from a
given SYSOUT class is controlled for the entire system by the
HASPGEN parameters $$x, as described in Section 7.
I
Output block maximum length is 128, 256, or 512 bytes, as indicated
the RMTnn HASPGEN parameter. Output records do not span transmission block boundaries. Each printed or punched output job is ended
by an EOT transmission.
HASP 2770 RJE Support - Page 12.12-2
1156
HAS P
Printed Output
Printed output is always sent as non-transparent blocks. All data
characters less than X'40' are translated to X'OO', or if the
&PRTRANS parameter is set to YES, all non-printing characters are
translated to X'40'. The first block ofa job contains the component selection character DC1. One or more variable length records
are sent in each block. Each record begins with the two character
ESC x carriage control sequence, has data characters up to the maximum specified for Printer Width in the RMTnn parameter, and ends
with the IRS character.
If indicated by parameter RMTnn (and supporting settings of &BSHTAB
and &BSHPRES) , blanks are compressed and encoded using either the
HT or IGS characters. Encoding by HT sets electronic tabs, every
10 columns beginning at column 11. This can be changed by altering
internal assembly variable &HTDIST.
The listing content for each job is the same as for all jobs printed
by HASP: beginning and ending separator pages (number of separator
lines controlled for all remotes in the system by the $TPIDCT parameter) , HASP System Log, OS System Messages (JCL, etc.) and any
printed SYSOUT data sets.
It is probably not very practical to direct printed output to another
device for output data purposes, because of the inclusion of separator
pages, messages, etc. The material could be directed to another medium (e.g., paper tape) for later listing offline or on another machine; however, because only the printer can be attached to the OUTPUT PRINTER position, HASP would have to be modified to use other than
DCl for print component selection. This would be a trivial one card
modification if all 2770s in the system were configured and used the
same way, but more difficult if not.
Punched Output
Punched output is sent as transparent blocks if the RMTnn parameter
indicates that the Transparency feature is present. In this case,
the component selection character DC2 is sent alone in a non-transparent block, at the beginning of the job. All other blocks are
transparent and contain one or more records of exactly 80 data characters, without any record ending characters.
I
I
If Transparency is not indicated by the RMTnn parameter, all punched
output data characters less than X'40' are translated to X'OO'. Only
non-transparent blocks are sent, with the DC2 in the first block.
Each block contains one or more variable length records. Blanks are
compressed and encoded using the IGS character, if indicated by RMTnn
(and supporting &BSHPRES). Each record contains 80 or less data
characters and ends with the IRS character.
HASP 2770 RJE Support - Page 12.12-3
-1157
HAS P
Punch job content is: separator card (described in Section 12.5.1),
punched SYSOUT data sets, and one blank card at the end of the job.
_,Blank cards may be produced at the end of each SYSOUT data set by .
.some OS access methods, but these are simply transmitted as data by
HASP. A second blank card at the end of each job is produced at the
545 Output Punch by a mechanical eject when EOT is received.
Punched output, except for separator and terminal blank cards, is
pure data output whose content is controlled completely by the application program execution. Therefore, it may be practical to direct
punched output to another device connected to the OUTPUT 2 position,
or other positions if HASP is appropriately modified to use other
than DC2 for punch component selection. If the non-transparency,
variable length record, form of punched output described above is
considered more desirable for the output device in question, HASP
may be forced to produce it by omitting Transparency in the RMTnn
parameter, even if the 2770 has the Transparency feature. This will
not prevent the 2770 from transmitting transparent input blocks to
HASP.
12.12.3
3780 Support
The previous description of 2770 support applies to the 3780 also,
with minor exceptions: The 3780 is assumed to have standard 512
byte buffers, card reader, printer, but no keyboard or card punch.
Component selection characters are not sent to the 3780. Although
features Transparency, Horizontal Format, and Compression are
standard; use of them for output is controlled by the RMTnn parameter, as with 2770.
HASP 2770 RJE Support - Page 12.12-4
1158
HAS P
12.13
HASP EXECUTION BATCH SCHEDULING
This feature is a modification of normal HASP scheduling of jobs
into logical partitions for execution by OS. The purpose is to allow the system to realize performance improvement by avoiding unnecessary OS Job Management overhead between "jobs" or "transactions"
processed by an appropriate batch processing program; while maintaining the flexibility of having these "jobs" or "transactions" submitted
to HASP independently, coming from possibly differing input sources,
having differing printed and punched output routing, and with separate
accounting for each job.
12.13.1
Batch Processing Program Characteristics
The processing programs to be used with the Batch Scheduling Feature
of HASP may cover a wide variety of application areas such as:
•
•
•
Compile and go debugging compilers
File inquiry programs
Hardware or software system emulators
However, a particular program to be used in the batch scheduling
mode must have certain characteristics:
•
It must read all user input from a single sequential
data set.
•
It must recognize a standard OS JOB card or its own control card to determine the beginning of a "job".
•
It must recognize a standard OS null JCL card (/1 followed
by 78 blanks) or its own control card to determine the
ending of a "job".
If it is necessary that the batch processing program have a WTOR
outstanding past the ending of one of its "jobs", the HASPGEN option &NUMCONS=O must be used.
The batch processing program will receive an actual end-of-file condition when a card having $$ in columns 1 and 2 is read while processing a "job". The program may continue to the next logical subfile by a variety of techniques.
It may simply reset appropriate
bits in as I/O control blocks and continue reading or it may CLOSE
the data set. The data set may then be re-OPENed to continue reading at the card following the $$ card.
It is desirable that the program process "jobs" or "transactions" of
relatively short duration.
If not, the saving in as Job Management
overhead between successive jobs may not be a large enough percentage
of total job execution time to justify use of this feature.
HASP Execution Batch Scheduling - Page 12.13-1
1159
HAS P
12.13.2
Submission Of Batch Jobs
To use a batch processing program under the Batch Scheduling
Feature of HASP, the user simply constructs jobs as follows:
The first card of each 'should be a standard HASP/OS JOB card,
which includes a CLASS=x parameter, where x is the class (installation defined) indicating which batch program is to process the
job.
The accounting field is interpreted by HASP just as for
non-batch jobs.
No other JCL is used. All other cards should be control cards,
source cards,~ata cards, etc., as required by the batch program.
These will be read by the batch program just as if they had been
placed in a DO * data set and the batch program had been invoked
by standard JCL.
If the batch program requires it, each logical
sub-file should be terminated by a card having $$ in columns 1
and 2.
12.13.3
Batch Scheduling Process
Special actions take place when HASP recognizes that a batch job
has been selected for execution.
If the batch program is not already active in the logical partition
for which the job was selected, then HASP generates and sends to
the OS R/I an internal job which uses JCL from proclib (see 12.13.4)
to invoke the program.
The entire user job as submitted (JOB card,
all other user input) followed by two null JCL cards added by HASP
is allocated as an input data set to the batch program.
If the batch program is already active and simply waiting for
another job, then HASP makes the input data set allocation as above
and processing begins immediately, without any use of OS Job
Management.
Job termination is detected by the batch program when it reads its
own ending control card or one of the null JCL cards added by HASP.
After writing any remaining SYSOUT data for the completed job, the
batch program simply attempts to read ahead in its input file for
another job. HASP detects this condition, temporarily forces the
batch program into a wait state, and does its job termination actions
for the job (flush output buffers, release input SPOOL space, queue
job for printing, etc.).
The batch program remains in the logical
partition.
When a batch program is waiting in a logical partition, HASP job
selection is altered.
Instead of scanning for all classes eligible
to execute in that partition, HASP first tries to start another job
of the same class as the batch program still in the partition.
If
HASP Execution Batch Scheduling - Page 12.13-2
1160
HAS P
successful, processing can begin immediately as described above.
If no more jobs of the same class are available to execute, then
all other job classes of the partition are scanned in order.
If
a job is found, HASP internally cancels the batch program and
normal scheduling takes place using OS Job Management.
If no jobs
of the other classes are found, then the partition remains idle
awaiting availability of a job in any of its classes.
If a job
becomes available in the class of the batch program still in the
partition, processing begins immediately.
If a batch program ends (abend or normal return to OS) ,HASP
detects this as a non-batch termination in the partition. OS Job
Management will be used to re-invoke the batch program when another
job for its class is selected.
Use of the operator commands $PI or $PIn will cause HASP to cancel
an idle batch program when the partition(s) becomes drained.
12.13.4
Installing Batch Scheduling
The Batching feature is included in HASP by setting the &XBATCHC
HASPGEN parameter equal to a list of job classes to be processed
by the rules described above.
The &XBATCHN parameter should also
be set (see descriptions of these two parameters in Section 7).
Each batch class should be used to represent one batch processing
program. Each batch class should be made eligible to execute in
one or more logical partitions, by setting the &CLS(n) HASPGEN
parameters or by use of the $T operator command.
The batch processing program for each class must be available in
loadable form somewhere in the system.
For each combination of batch class and logical partition in which
it may execute, there must be a procedure in SYSl.PROCLIB whose
name is "nnnnncid"j where nnnnn are the five characters assigned
to &XBATCHN, c is the particular batch job class (one of the list
assigned to &XBATCHC), and id is the one or two character logical
partition identification set by the parameters &PID(n). These
procedures actually call the batch processing programs for each
class and define all data sets other than the user input data set.
The procedures may either be single step or may have preliminary
steps before the single step which processes the user jobs. That
step must have a stepname of GO.
The processing program invoked
by this step must read its input from a ddname SYSIN or the procedure must refer to OONAME=SYSIN on a DO card whose name is the
one used for input by the processing program.
It is recommended
HASP Execution Batch Scheduling - Page 12.13-3
1161
HAS P
that the DCB parameter BUFNO=l be included on any SYSOUT data sets
in a procedure. This will help to insure that HASP has actually received all output produced by the batch program for a job or transaction, when the program is suspended while trying to read ahead to
the next job.
The special forms field in SYSOUT must not be used in any batching
procedure. If OS output spooling Ii1Usea-with any SYSOUT (see
HASPGEN parameter $$X), the output is not queued for the OS writer
until the batch processing program terminates, which is not necessarily when any batch job terminates.
If a given batch class is eligible to execute in more than one logical partition,- the requirement for a separate procedure name for
each class-partition combination may be satisfied by alias names of
a single procedure, or by actual separate procedures which may specify different region sizes, work files, etc.
The following example shows the internal job which HASP would generate to initially load a program to process batch class X jobs, in a
partition whose &PID(n)=3, assuming the default setting for &XBATCHN.
JOB 1,SYS,MSGLEVEL=1
IIFAKE EXEC $$$$$X3
IIGO.SYSIN DD DATA,DCB=BUFNO=l
11$$$$$X3
II
This job would call a procedure as shown. The following is an example of a procedure which an installation might use for a simple file
inquiry program which reads inquiry input from SYSIN, interrogates a
file, and prints responses to SYSPRINT.
IIGO EXEC PGM=FINDPART
IISYSPRINT DD SYSOUT=A,DCB=(BLKSIZE=12l,BUFNO=1)
IIPARTFILE DD DSN-PARTFILE.MASTER,DISP=SHR
IISYSUDUMP DD SYSOUT=A
This procedure would be placed in SYSl.PROCLIB with the name $$$$$X3.
HASP Execution Batch Scheduling - Page 12.13-4
1162
HAS P
12.14
HASP OVERLAY PROGRAMMING RULES
The following comments summarize the rules for coding and using
"overlayable code" in HASP. All rules apply to use of any control
sections created by use of the $OVERLAY macro, even if the code so
produced is optionally made permanently resident as part of the
overlay build process. HASP Overlay does not use any overlay
facility defined elsewhere in OS/360 documentation. More precise
details of Overlay Macros syntax, Overlay Build process, Overlay
Service and Overlay Roll internal logic are given in Sections
9.7, 10.2.2.3, 4.20 and 5.16.
12.14.1
Creating Overlay Control Sections
The beginning of a portion of HASP executable coding or tables to
be made overlayable is indicated by the $OVERLAY macro.
By convention, the name field begins with "HASP" and continues with up
to four more characters. The fifth character (first after "HASP")
usually indicates the Processor of which the overlayable code is
a part~ e.g., R for read, X for execution, P for print/punch, etc.
A specific example is "HASPXJI1", the name of the first of two
overlays used by the HASP Execution Processor for job initiation
actions. The name coded with $OVERLAY will be defined at the first
location coded by the programmer after the $OVERLAY and will be
used to derive a name for the control section created.
The operands of $OVERLAY specify the priority for use of overlay
resources and, in conjunction with the HASPGEN parameter &OLAYLEV,
whether the code created is to be actually disk or main memory
resident during HASP operation.
The $OVERLAY macro is a functional replacement for CSECT, USING,
and BALR or L when creating a HASP overlayable control section.
$OVERLAY creates an actual assembly control section and indicates
local addressability in register BASE3. Overlay Service and Roll
functions insure that the proper base value is loaded into BASE3
when an overlay section is being used.
An overlay control section's coding may be terminated and all
effects of a previous $OVERLAY cancelled in one of two ways.
Another overlay may be begun by a new $OVERLAY macro. Non-overlay
coding may be resumed by DROPing register BASE3 and re-establishing
an appropriate CSECT.
If it is desired to add more coding to a previously terminated
overlay section, the actions in the following example must be performed.
&xyz is a properly declared variable symbol. HASPabcd. is
the overlay name chosen by the programmer. Other·symbols are
defined in standard HASP assemblies. The second statement must
be placed after the $OVERLAY defining the overlay section to be
resumed, before another $OVERLAY is used.
HASP OVERLAY Programming Rules - Page 12.14-1
1163
HAS P
HASPabcd
&xyz
$OVERLAY 12,0
SETC '&OSECT'
&xyz
CSECT
'USING
12.14.2
Calling
(original definition)
(later additional code)
HASPabcd-OACEPROG+BUFDSECT,BASE3
Ov~rlay
Routines
The three executable macros $LINK, $XCTL, and $LOAD cause an overlay routine to be made available for use in addressable memory.
The single operand of each of these macros gives the name of the
overlay to be used, either directly or by providing (in register
form) the address of a $OCON macro which gives the name. The name
referenced is that used with a $OVERLAY macro to create the overlay
routine.
The overlay control section ($OVERLAY and following code)
may be in the same or a different HASP assembly as a macro which
calls it.
The $LINK and $LOAD macros must be physically placed in non-overlay
CSECTs and executed only when no other overlay routine is being
used, i.e., nested calling of overlays is not defined. With $LINK,
program control is eventually passed to the first instruction after
$OVERLAY of the called routine. The address of the caller's next
~nstruction is saved for later return.
$LOAD returns control to
the next instruction after $LOAD when the routine is available in
memory.
$XCTL relinquishes use of an overlay routine, previously called by
$LINK or $XCTL, and calls a new overlay routine which is entered
as if called by $LINK. Return address saved by the original $LINK
is not altered.
$XCTL must always be executed when an overlay is
in use, but may physically be in an overlay routine or in non-overlay
coding, subject to the requirements of 12.14.3.
$RETURN and $DELETE both relinquish use of an overlay routine, which
must be in use when they are executed.
These macros have no
operands; the routine released is the only one in use at the time.
$RETURN causes control to pass to the next instruction after the
$LINK previously executed by the Processor from non-overlay code.
$RETURN, like $XCTL, may physically reside anywhere.
$DELETE must
physically reside in non-overlay code and is valid only after a .
routine was previously called by $LOAD. Control continues following
$DELETE, after use of the overlay routine has been released.
Overlay routines may be called only by HASP Processors operating
under the primary HASP TCB, HASP Dispatcher, and PCE control (see
Section 5.1). Overlay routines may not be called in exits from
the Asynchronous Post Processor (see Section 4.8).
HASP OVERLAY Programming Rules - Page 12.14-2
1164
HAS P
12.14.3
Coding While Using Overlay Routines
On entry to an executable overlay by $LINK or $XCTL or after loading
an overlay with $ LOAD , the caller's registers RO-R7 and R9-R13
are preserved.
However, registers BASE3 (same as R8 or WG in unmodi·fied HASP)·, LINK, R15 and the condition code are destroyed and are
not later restored.
While an overlay routine is being used (after
the execution of $LINK or $LOAD but before the execution of $RETURN
or $DELETE), the program must not alter the value of register BASE3.
Coding in an overlay routine is "covered" by local addressability
provided by $OVERLAY. Coding physically outside an overlay but
referring to it (usual case after a $LOAD) must be "covered" by a
USING like that in the example in 12.14.1. Other addressability
(e.g., BASEl, BASE2) remains in effect if not dropped and may be
used.
Program control may be transferred out of or into an overlay routine
and its storage may be retrieved, as long as overlay control of that
routine is in effect (has not been released by $RETURN, $DELETE,
or $XCTL to a new routine) and proper addressability is maintained.
References to locations in an overlay routine from physically
outside the overlay at any other time are illegal.
Relocatable valued A or V type constants must not be physically
coded in overlay routines.
Such constants may be coded in non-overlay CSECTs and referenced from overlay routines.
Relocatable A or
V type literals may be coded if the literal pool containing them
is not physically in an overlay routin~. An A or V constant or
Ii teral containing an "un-paired" ·(see As sembly Language SRL)
reference to a symbol defined in an overlay routine is always
illegal, regardless of location.
When use of an overlay routine is released by $RETURN or $DELETE,
only the LINK and BASE3 registers are destroyed. All other registers
and the conditi~n code are preserved as set prior to the execution
of these macros.
Total size of all coding in an overlay routine must not exceed the
value of the internal assembly variable &OLAYSIZ, currently set
at 1024 bytes in unmodified HASP. An error message will be produced
during the Overlay Build process for each routine which violates
this restriction.
HASP OVERLAY Programming Rules - Page 12.14-3
1165
HAS P
12.14.4
Overlay Location Independent Coding
Whenever a HASP Processor which is using an overlay routine
executes $WAIT, regardless of the physical location of the
$WAIT, the Overlay Roll Processor may pre-empt the Overlay Area
for other ·use. When control is returned to the Processor following the $WAIT, the overlay routine may have been re-read from
direct access, destroying all self-modification or temporary
storage in the overlay, and may be in a different Overlay Area,
making all address values relative to the overlay routine's
location invalid (in registers or elsewhere).
The first effect above (destruction of temporary storage) is
similar to the effect on single (non-re-entrant) temporary
storages in non-overlay coding used by multiple Processors when
$WAIT is executed.
The effect on overlay storage may take place
when only one peE is using an overlay routine.
Re-entrant
temporary storage (e.g., in a PCE workarea) or re-construction
from known values after $WAIT will avoid errors due to this possible "re-freshing" of overlay routines.
The second effect (changing overlay location) is, of course,
peculiar to use of overlay routines.
System Overlay Service and
Roll logic automatically makes proper adjustments to registers
BASE3 (overlay routine base value) and RIS ($WAIT re-entry
address), if the $WAIT is physically in the overlay routine.
Other address values relative to an overlay routine are usually
created in registers by use of instructions such as LA (with
BASE3 as base), BAL, or BALR (the last two if physically in an
overlay routine).
These registers should be "relativized" prior
to $WAIT by "SLR n,BASE3" instruction(s) and "absolutized" after
$WAIT by "ALR n,BASE3" instruction(s). Equivalent techniques may
be created for other coding situations.
Certain HASP macros which call services subroutines represent a
"hidden" possible $WAIT. They must be treated as equivalent to
$WAIT in all cases previously described.
Specifically, any macro
for which the keyword parameter OLAY=YES is defined (see Section 9)
represents a hidden $WAIT, regardless of physical location.
The
OLAY=YES is coded only if the macro physically exists in an overlay
routine. Macro expansion and service subroutine exit coding handle
possible adjustment of the LINK register.
The services subroutines
assume that all parameter address values (in RO, Rl, or RlS) are
not relative to an overlay routine. Other addresses rel~tive to
an overlay routine must be adjusted before and after the service
macro call by the caller.
The $WTO macro is a special case.
It represents a hidden $WAIT
unless WAIT=NO is coded.
If coded physically in an overlay
routine, WAIT=NO must be coded.
It may be coded physically outside
an overlay routine without WAIT=NO, but then registers must be
treated as for macros which have OLAY=YES defined.
HASP OVERLAY Programming Rules - Page 12.14-4
1166
HAS P
12.15
HASP WITH OS CONSOLE SUPPORT
The following sections describe the HASP routines which are provided for the OS console support interface selected by specifying
the HASPGEN parameter &NUMCONS=O (see Section 7.1).
12.15.1
General Description
The functions included in HASP to provide an interface with the
OS console support are in the following major areas:
Initialization procedure
SVC 34 processing
SVC 35/36 processing
WTO subtask
Each of these areas is described in greater detail in the remaining
sections of this appendix.
The combined overall functions of the interface is to allow operator
commands (both OS and HASP) to be entered from any OS supported
console input device without special operator action and to
display the commands and associated information in accordance to
a combined OS and HASP criteria.
In addition, the unique HASP
features of abbreviated replies to WTORs and the HASP System
Log of WTO messages as part of the programs printed output are
included (subject to the restrictions noted in the description
of the &NUMCONS variable in Section 7.1).
12.15.2
Initialization Procedure
Preparation for the &NUMCONS=O option at the time HASP is invoked
includes the following functions in the INIT modules:
1.
Information concerned with the UCM base is extracted and
stored in the resident CON module.
Included are:
address
of UCM save area; TCB address of communication task; address
of UCM base fields containing address of first UCM entry,
size of each UCM entry, address of last UCM entry; contents
of Mode flag byte from UCM base.
The source of this information is OS release dependent.
See the OS MVT Supervisor
PLM for additional information on the UCM.
2.
The address of the HASP TCB is stored in CON to facilitate
OS POSTing of the HASP task.
HASP With
1167
as
Console Support - Page 12.15-1
HAS P
3.
The servicing of SVC 35 and, conditional on the HASPGEN parameter &WTLOPT, SVC 36 by OS is diverted to HASP by changing the
contents of the SVC table to enter the XEQ modules lOS interface
section and, subsequently, the CON module code $WTOSVC. If the
OS System is MFT, the SVC table is changed to indicate a Type 3
resident routine. If the OS System is MVT, the SVC table is
changed to indicate a Type 2 SVC. In both cases the original
SVC table contents are saved in the HCT prior to the indicated
changes. Note: The SVC table for MFT must contain four byte
entries in order to indicate a Type 3 resident SVC.
4.
An ATTACH is issued to the BRI module which executes a branch
to the address contained in register 1. Prior to the ATTACH,
register 1 is set to the entry point of the HASP WTO subtask
($HASPWTO). Register WA is set to the address of an ECB
($WTOECB) which is used to coordinate the activities of HASP
with the subtask. See Section 12.15.5 for further details.
5.
An error message, indicating the completion code provided by
the return from ATTACH, is issued if the ATTACH was unsuccessful. Control is passed to the HASPIOVD segment of INIT to
continue processing.
12.5.3
SVC 34 Processing
$MGCRSVC, a section of code contained in the CON module, is entered
whenever an XCTL to IGC0403D is detected by the HASP LINK/XCTL interface. The functions performed by $MGCRSVC are:
I
1.
Immediate return to perform,the XCTL if the SVC 34 was issued
by HASP.
2.
Performs backspace editing of the command in accordance with the
HASPGEN parameter "$BSPACE". Tests for possible HASP format abbreviated reply to outstanding WTOR. If the first character is
numeric, the abbreviated reply process is invoked to expand the
HASP form to a form acceptable to OS. The SVC 35/36 Processing
routine is entered for possible logging of the expanded reply on
the HASP SYSTEM LOG. Control is returned to process the XCTL
with expanded reply.
3.
If the first character is non-numeric, an explicit test is made
for a "$" which identifies HASP commands. Control is returned
to process the XCTL if the first character is non-numeric or
not a "$".
4.
If the first character is a "$", a test for at least one CMB
which is not being used to process HASP commands is performed
using a counter ($COMMCT) maintained in the HCT. If all CMBs
(except one) are being used to process commands or if no CMBs
are available, then control is returned to process the XCTL.
The command is subsequently
I
HASP With OS Console Support - Page 12.15-2
1168
HAS P
rejected by OS as invalid.
5.
If MCS is being used in the OS system, the authorization code
for the device indicated by the UCMID contained in the low
order byte of RO is extracted from the ucr1 and converted to
the HASP restriction level. Reference the HASP COMM Processor for additional information on the OS authorization code
and HASP restriction level relationship.
6.
The contents of the input buffer are copied to the acquired
HASP CMB and the CMB is queued for the HASP command processor
using the $COMMQUE pointer in the HCT. The command processor
is $POSTed for work and HASP is as POSTed.
7.
The resume PSW in the SVRB of the issuer of the XCTL to
IGC0403D is changed to point to CVTEXIT in the CVT. The current SVRB is terminated by issuing an SVC 3 which eventually
causes the whole process to be ignored by OS.
12.15.4
SVC 35/36 Processing
$WTOSVC, a section of the CON module, is entered from the SVC
SLIH via the Execution Processor lOS interface routine whenever
an SVC 35 or, optionally, SVC 36 is encountered. This section of
code operates as a Type 2 SVC and accomplishes the following
functions:
1.
XCTLs to the real first load of SVC 35 (IGC0003E) if the WTO
was issued by the HASP subtask ($HASPWTO).
2.
Saves registers in the current SVRB extended save area and
tests input for WTO or WTOR.
3.
If WTOR, adjusts input pointer (Rl) to beginning of message
and proceeds as follows (WTO processing):
4.
An internal table is used to compare the first eight bytes of
the input message and, if a match occurs, special processing
is invoked through a corresponding routine. The usual function
of the special processing is to bypass the display of redundant
system messages.
5.
A search of the Execution Processor PCEs is made to locate the
JCT for the job issuing the SVC 35 or 36. The TIQT and associated job name is used for the search.
If a match is not
found, control goes to the real first load of the SVC 35/36.
HASP With OS Console Support - Page 12.15--3
1169
HAS P
6.
If a CMB is available, the subroutine HASPCBUF is entered to
copy the message to the HASP Log for the particular job; HASP
is OS POSTed and control passed to the appropriate OS module:
IGC0003E or IGC0003f for SVC 35 or 36 respectively.
7.
If a CMB is not available, the caller is forced into an OS
WAIT .condition. The forced WAIT is conditional:
the Communication Task, DAR and SIRB controlled routines are
excluded.
In addition, if no PQE (used to retain the TCB
and define an ECB for the routine $FREEMSG to OS POST) is
available, the caller is not forced into a WAIT condition
and the message is not entered into the HASP Log.
12.15.5
HASP WTO Subtask
The HASP OS WTO interface ($HASPWTO) which operates as an ATTACHed
subtask to HASP is responsible for the processing of all WTO
messages generated by HASP processors as the result of $WTO macros.
$HASPWTO is implemented as a subtask in order to allow the normal
OS function of delaying the execution of a task due to predetermined
buffer limits. The "delaying" of the task, under these circumstances,
is in the form of an ENQ and WAIT procedure which causes the task
to be non-dispatchable until sufficient resources (buffers) are
available to process the WTO.
It is undesirable for HASP proper
to be forced into a WAIT state but it is tolerable for the $HASPWTO
subtask to be subjected to a forced WAIT.
$HASPWTO is assembled as part of the CON module and is executed as
a task via an ATTACH issued at HASP initialization. The overall
logic of this task is:
1.
The initial entry establishes local and HASP addressability,
POSTs a synchronization ECB for INIT and then WAITs for
work using a communication ECB which is POSTed by the CON
module routine $WQUEBUF.
2.
When the communication ECB ($VJTOECB) is posted, $HASPWTO
examines the CMB active queue ($BUSYQUE) for messages to be
sent to the OS console routines via a WTO. All messages on
the queue except those flagged for remote processing are processed by $HASPWTO.
If the queue is empty, $HASPWTO WAITs
for the next POST of $WTOECB.
3.
If the message selected from the active queue contains a UCMID
byte, then the MCSFLAGS field of the WTO calling sequence is
set to indicate RO contains the UCMID and, eventually, RO is
loaded with the UCMID.
This feature allows responses to HASP
commands to be returned to the indicated console.
HASP With OS Console Support - Page 12.15-4
1170
HAS P
4.
The routing code field of the WTO calling sequence is used
for non-UCMID CMBs. The HASP logical console bit indicators
(contained in the CMB) are used to translate to the equivalent as routing codes based on the following table:
HASP
as
LOG
ERROR
UR
TP
TAPE
MAIN
MASTER CONSOLE INFORMATIONAL
SYSTEM/ERROR MAINTENANCE
UNIT RECORD POOL
TELEPROCESSING CONTROL
TAPE, DISK LIBRARIES TAPE, DA POOLS
MASTER CONSOLE, ACTION AND INFORMATIONAL
Function
5.
The message is copied from the CMB to an internal buffer
corresponding to the WTO format.
If routing codes are being
used, the description code field is set to indicate a system
status message.
6.
The CMB is returned to the available CMB queue ($FREEQUE)
using the $FREEMSG subroutine. If $FREEMSG returns with a
condition code = 0, than an OS POST is issued to the
HASP ECB ($HASPECB), otherwise no POST is given.
7.
The WTO is issued for the copied CMB using either the UCMID
or the routing and descriptor code options. The procedure
described starting at step 2 is repeated.
HASP With
as
1171
Console Support - Page 12.15-5
HAS P
12.16
MULTIPLE DEVICES ON MULTI-LEAVING REMOTES
If a HASP System includes MULTI-LEAVING RJE support (&NUMLNES >0
and &BSCCPU=YES) and if any remote terminal to be supported has
multiple .devices (i.e., more than one reader, printer or punch),
then the following considerations should be reviewed before performing HASPGEN and RMTGEN for that configuration.
12.16.1
RMTGEN Considerations
The appropriate parts of Section 7 describe how to specify support
for a second (or third, etc.) reader, printer, or punch when
performing RMTGEN for the various types of MULTI-LEAVING remote
workstation programs.
12.16.2
HASP Processor Considerations
It may be necessary to increase the value{s) of the HASPGEN
parameters &NUMTPPR, &NUMTPPU, and &NUMTPRD to allow concurrent
operation of all remote devices in the total system.
For example, if &NUMLNES=3 and the default value &NUMTPPR=&NUMLNES
is taken, then the HASP System can only support three concurrent
remote print operations.
If all three lines are active and one
of the three active remotes has two printers, then unless &NUMTPPR
is increased to four, one of the four possible concurrent remote
print operations may be delayed until a print operation on
another remote comes to the end of a job.
The decision to increase these parameters and by how much, depends
on the total remote configuration and an estimate of how many
active remotes will usually be doing the same stage of job
processing.
12.16.3
HASP Remote Device Considerations
HASP generates a Device Control Table (OCT) for one of each type
of device (reader, printer, and punch) on each remote terminal known
to HASP (RMTOI through RMTnn where &NUMRJE=nn).
If a remote terminal has more than one of each type of device,
then a OCT for each such additional device must be generated.
Multiple Devices on MULTI-LEAVING Remotes - Page 12.16-1
1172
HAS P
Each additional DCT must be specified on a card of the following
format:
$RMTDCT type,device
-serial-
Values for the above card should be chosen from the following
table:
readers
printers
punches
~
device
serial
RJR
RPR
RPU
RMnn.RDm
RMnn.PRm
RMnn.PUm
N0730nnm
N0732nnm
N0736nnm
where linn" is the remote number (same as in the RMTnn HASPGEN
parameters but with a leading ~ omitted in device) and "m"
is the device number which must be 2 or greater, up to a maximum
of 7.
All the above cards describing additional devices for all remotes
in a system must be placed in ascending order by serial number
and added to the source module HASPINIT using the HASPGEN Update
facility described in Section 10.1.3. The following example
shows how to generate a second printer DCT for remote 2 and a
second reader DCT for remote 5.
Columns
1
./
10
16
CHNGE HASPINIT
$RMTDCT. RJR,RM5.RD2
$RMTDCT RPR,RM2.PR2
73
80
N0730052
N07'32022
Multiple Devices On MULTI-LEAVING Remotes - Page 12.16-2
1173
HAS P
12.17
3211 FORMS CONTROL BUFFER ADDITIONAL LOADS
Installations using HASP with 3211 printers may want to add carriage
tape images to HASP in addition to the images provided. Each such
image is named by a letter or a number, but the number 'I' is reserved to allow the operator to force single-spacing and the letter
'V' is reserved for the operator-variable FCB load. Of the 34 remaining alphanumerics, HASP supplies images for '6', '8', and lUI.
12.17.1
Adding and Changing FCB Loads
The mechanism for defining Forms Control Buffer loads in HASP is
the $FCB macro, defined in Chapter 9. To add or change an FeB
image, the installation system programmer
•
codes a $FCB macro for each image
•
assigns it a card sequence number from the numbers shown in
Section 12.17.3.
•
includes it in his HASPGEN modification deck
•
does a HASPGEN to create new source for HASPPRPU
•
re-assembles HASPPRPU
•
executes HASPOBLD to create a new HASP load module and overlay
library.
12.17.2
FCB Loads Provided by HASP
HASP provides three FCB loads, callable by the characters '6', '8',
and 'U'.
The '6' image is designed for 11-inch-10ng forms. Channell is
punched at line I, channel 2 at line 7, channel 3 at line 13, and
so on to channel 8. Channel 10 is at line 49, channel 11 at line
55, channel 12 at line 61, and channel 9 at line 63. The $FCB
macro is
FCB6 $FCB 6,66,1-1,2-7,3-13,4-19,5-25,6-31,7-37,8-43,10-49,
11-55,12-61,9-63
The '8' image is designed for 8-l/2-inch-long forms, at 8 lines
per inch. The punches are the same as for the '6' image, except
that channel 9 is at line 64. The $FCB macro is
FCB8 $FCB 8,68,1-1,2-7,3-13,4-19,5-25,6-31,7-37,8-43,10-49,
11-55,12.-61,9-64
3211 Forms Control Buffer Additional Loads - Page 12.17-1
1174
HAS P
The 'u' image specifies only carriage channell at line 1; other
carriage channels are filled in by the $FCB macro to prevent forms
runaway. The $FCB macro is
FCBU $FCB 6,66,1-1
12.17.3
Recommended Card Sequence Numbers
It is recommended that additional FCB images be assembled using
the following card sequence numbers:
Image
Name
A
B
C
D
E
F
G
H
I
J
K
L
M
N
o
P
Q
R
S
T
U
W
X
Y
Z
o
2
3
4
5
7
9
First
Sequence Number
P3458000
P3460000
P3462000
P3464000
P3466000
P3468000
P3470000
P3472000
P3474000
P3476000
P3478000
P3480000
P3482000
P3484000
P3486000
P3488000
P3490000
P3492000
P3494000
P3496000
P3540000
P3502000
P3504000
P3506000
P3508000
P3510000
P3514000
P3516000
P3518000
P3520000
P3524000
P3528000
Continuation
Sequence Numbers
P3458100-P3459900
P3460100-P3461900
P3462100-P3463900
P3464100-P3465900
P3466100-P3467900
P3468100-P3469900
P3470100-P3471900
P3472100-P3473900
P3474100-P3475900
P3476100-P3477900
P3478100-P3479900
P3480100-P3481900
P3482100-P3483900
P3484100-P3485900
P3486100-P3487900
P3488100-P3489900
P3490100-P3491900
P3492100-P3493900
P3494100-P3495900
P3496100-P3497900
P3540100-P3541900
P3502100-P3503900
P3504100-P3505900
P3506100-P3507900
P3508100-P3509900
P3510100-P3511900
P3514100-P3515900
P3516100-P3517900
P3518100-P3519900
P3520100-P3521900
P3524100-P3525900
P3528100-P3529900
3211 Forms Control Buffer Additional Loads - Page 12.17-2
1175
HAS P
(The remainder of this page intentionally left blank.)
1175.1
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37 Create Date : 2013:03:21 10:50:02-08:00 Modify Date : 2013:03:21 14:10:24-08:00 Metadata Date : 2013:03:21 14:10:24-08:00 Producer : Adobe Acrobat 9.52 Paper Capture Plug-in Format : application/pdf Document ID : uuid:341ccc38-09a4-4c13-8942-ba917599ca17 Instance ID : uuid:00ae6f4b-4008-47b7-ad60-e22171e16476 Page Layout : SinglePage Page Mode : UseOutlines Page Count : 1274EXIF Metadata provided by EXIF.tools