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'1111111111111191111111199999994.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