Stored program control with memory work area assignment in a communication switching system

Abstract

The executive or operating system for the central processor schedules tasks to be performed for call processing and maintenance. A call history table in the main core memory has an individual area for each register junctor for information relating to a call being processed. Work areas are assigned for tasks to be performed, with linkage to the call history table. The call history table also has linkages to work areas being used for each call.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to stored program control in a communication switching system, and more particularly to utilization of memory for temporary storage of call processing information.

2. Prior Art

There are two basic techniques for the assignment of parameter storage in a stored program system. One scheme provides dedicated storage to each call processing function, and the other provides dynamic storage allocated on a per call basis. The state of the art is discussed in Chapter 7 on Utilization of Computer Memory, of a book by James Martin, "Programming Real-Time Computer Systems," Prentice-Hall, Inc., Englewood Cliffs, N. J. (1965).

SUMMARY OF THE INVENTION

The invention relates to a communication switching system in which a register-sender subsystem provides for receiving and storing call digits, and a separate data processing unit provides other call processing functions such as digit analysis and call routing. The register-sender subsystem has register junctors connected via a switching network to calling lines during dialing and until the call is switched to a called line or outgoing trunk.

According to the invention, the main memory for the computer of the data processing unit has a call history table as dedicated storage for each register junctor, and dynamically allocated work areas for use during short intervals of a call for specific functions by segments of the program, with linkages between the call history table and the work areas. There is also a queue structure for scheduling of jobs and assignment of work areas. Work areas are used not only for call processing, but also for maintenance programs.

CROSS-REFERENCES TO RELATED APPLICATIONS

The preferred embodiment of the invention is incorporated in a COMMUNICATION SWITCHING SYSTEM WITH MARKER, REGISTER, AND OTHER SUBSYSTEMS COORDINATED BY A STORED PROGRAM CENTRAL PROCESSOR, U.S. patent application Ser. No. 130,133 filed Apr. 1, 1971 by K. E. Prescher, R. E. Schauer and F. B. Sikorski, now abandoned, and a continuation-in-part thereof, Ser. No. 342,323, filed Mar. 19, 1973, now Pat. No. 3,835,260 issued Sept. 10, 1974, hereinafter referred to as the SYSTEM application. The system may also be referred to as No. 1 EAX or simply EAX.

The memory access, and the priority and interrupt circuits for the register-sender subsystem are covered by U.S. patent application Ser. No. 139,480 filed May 3, 1971, now Pat. No. 3,729,715 issued May 31, 1973, by C. K. Buedel for a MEMORY ACCESS APPARATUS PROVIDING CYCLIC SEQUENTIAL ACCESS BY A REGISTER SUBSYSTEM AND RANDOM ACCESS BY A MAIN PROCESSOR IN A COMMUNICATION SWITCHING SYSTEM, hereinafter referred to as the REGISTER-SENDER MEMORY CONTROL patent application. The register-sender subsystem is described in U.S. patent application Ser. No. 201,851 filed Nov. 24, 1971, now Pat. No. 3,737,873 issued June 5, 1973, by S. E. Puccini for DATA PROCESSOR WITH CYCLIC SEQUENTIAL ACCESS TO MULTIPLEXED LOGIC AND MEMORY, hereinafter referred to as the REGISTER-SENDER patent application. Maintenance hardware features of the register-sender are described in U.S. patent application filed July 12, 1972, Ser. No. 270,909 now Pat. No. 3,784,801 issued Jan. 8, 1974, by J. P. Caputo and F. A. Weber for a DATA HANDLING SYSTEM ERROR AND FAULT DETECTING AND DISCRIMINATING MAINTENANCE ARRANGEMENT, this patent being referred to hereinafter as the REGISTER-SENDER MAINTENANCE patent.

The marker for the system is disclosed in the U.S. Pat. No. 3,681,537, issued Aug. 1, 1972 by J. W. Eddy, H. G. Fitch, W. F. Mui and A. M. Valente for a MARKER FOR COMMUNICATION SWITCHING SYSTEM, and also in U.S. patent applications Ser. No. 281,586 filed Aug. 17, 1972, now Pat. No. 3,806,659 by J. W. Eddy for an INTERLOCK ARRANGEMENT FOR A COMMUNICATION SWITCHING SYSTEM, Ser. No. 311,606 filed Dec. 4, 1972, now Pat. No. 3,830,983 issued Aug. 20, 1974, by J. W. Eddy and S. E. Puccini for a COMMUNICATION SYSTEM CONTROL TRANSFER ARRANGEMENT, Ser. No. 303,157 filed Nov. 2, 1972, now Pat. No. 3,809,822 issued May 7, 1974, by J. W. Eddy and S. E. Puccini for a COMMUNICATION SWITCHING SYSTEM INTERLOCK ARRANGEMENT, hereinafter referred to as the MARKER patents.

The communication register and the marker transceivers are described in U.S. patent application Ser. No. 320,412 filed Jan. 2, 1973, now Pat. No. 3,814,859 issued June 4, 1974, by J. J. Vrba and C. K. Buedel for a COMMUNICATION SWITCHING SYSTEM TRANSCEIVER ARRANGEMENT FOR SERIAL TRANSMISSION, hereinafter referred to as the COMMUNICATIONS REGISTER patent application.

The above system, register-sender, marker and communication register patents and applications are incorporated herein and made a part hereof as though fully set forth.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a telephone switching exchange;

FIG. 2 is a block diagram of the system showing the duplication of the subsystems of FIG. 1 and the reconfiguration control;

FIG. 3 is a diagram of interface information between the register-sender and the data processing unit;

FIG. 4 is a layout diagram of the register-sender memory;

FIG. 5 is a diagram of the call history table;

FIGS. 6-12 are layout diagrams of the call history table contents during time frames 0-6 respectively;

FIG. 13 is a field program block diagram flowchart;

FIG. 14 is a typical layout of a portion of the main core memory;

FIGS. 15-35 are memory diagrams and flowcharts for the executive program;

FIG. 36 is a combined hardware and software simplified flowchart for a local-to-local call;

FIGS. 37-44 are flowcharts and diagrams of the common maintenance program;

FIG. 45 is a high level flowchart for the diagnostic control program; and

FIGS. 46-95B are executive software flowcharts.

GENERAL SYSTEM DESCRIPTION

The communication switching system in which the invention is incorporated is shown in FIG. 1. The system is described at length in said SYSTEM patent application, and only a brief summary description is supplied here.

A stored program data processing unit DPU comprises a central processor (CCP) 135 with a main core memory 133, and a drum memory system (DMS) having drum control units 132 and a drum memory 131. The common control of the system comprises the data processing unit, and a register-sender subsystem shown in FIG. 1 as comprising common logic control 202 with a core memory RCM, register junctors RRJ, a sender receiver matrix RSX, tone receivers 302-303 and tone senders 301. A call originated at a local line which comprises the telephone lines connected to line circuits LC1-LC1000 is connected through a line group switching group to a register junctor RRJ. For example a call originated at line circuit LC1 is connected through an A matrix 111, a B matrix 112, an originating junctor OJ, and an R matrix 114, to one of the register junctors RRJ. The register-sender subsystem returns dial tone via the register junctor, after which the dialed digits in either dial pulse form or tone form are received and processed via the common logic 202 and stored in the core memory RCM. The digits are processed in the register-sender subsystem and the data processor unit subsystem after which a terminating path is completed from the originating junctor through the selector group through the A, B and C stages to a terminating junctor 115 of a line group if it is a local terminating call or to an outgoing trunk 121 if it is an outgoing call to another office. For a local call the route is extended through C, B and A matrices to the called line.

In the data processing unit DPU the central processor 135 operates with a main core memory 133, and also makes use of a drum memory 131 via drum control units 132. A communication register 134 provides for communication of data between the central processor and transceivers in the markers for the switching network. A maintenance control unit 137 connects the central processor 135 to a maintenance console 145; and an input-output device buffer 136 connects the central processor to other devices such as a teletypewriter 142 of tape unit 144 in a maintenance and control center.

Note that there may be two register-sender units, and that each has up to 192 register junctors, making a maximum of 384. Each register junctor has a dedicated area in the register-sender memory RCM, and also a dedicated area in a call history table of the main core memory 133.

As shown in FIG. 2, most of the units of the system are duplicated, and many configurations are possible, as described in the SYSTEM application.

FIG. 3 is a diagram showing interface information between the register-sender and the data processing unit, and FIG. 4 is a layout diagram of the register-sender memory, which are described in the SYSTEM application in Section 4 of the "Computer User Manual" portion, and are also explained in the REGISTER-SENDER patent applications.

CALL HISTORY TABLE - WORK AREA LINKAGE

There are two basic techniques for the assignment of parameter storage in a software system. One scheme would provide dedicated storage to each call processing function and the other would provide dynamic storage allocated on a per call basis. In the EAX system, however, both dedicated and dynamically allocated storage is provided for the processing of calls. The dedicated storage consists of the Call History Table. Each entry in this table is directly associated with a specific register junctor. The dynamic storage consists of work areas. Any work area and in fact several different work areas may be used in the processing of each call.

Each type of storage is utilized in situations for which they are best suited. The Call History Table is used to retain data concerning the call during major breaks in the processing where software has no role. Such a situation would be while awaiting dialed digits. The Call History Table is utilized under these circumstances because the register sender hardware has control of the call and the only link to a specific call is the register junctor identity which uniquely identifies the call history table entry associated with the call. Hence, the dedicated relationship between the Call History Table entries and register junctors. The work areas are dynamically allocated and released as needed to perform interfaces with Operating System software. These processing breaks are required to interface with other hardware subsystems such as magnetic drum and markers. The work area allows continuity of data during these breaks. Since these interfaces normally require significantly more storage, it is economically advantageous to utilize dynamic storage on a temporarily assigned basis.

Since both types of storage are used and in fact provide links across processing breaks, it is necessary to relate them to each other. Therefore, both the Call History Table and the work areas contain pointers to the other. As a consequence, whenever a work area controlled function is completed, the Call History Table address located in the work area may be used to associate the results of the function with the appropriate call. Similarly, when a hardware controlled condition (call abandoned) occurs while a work area is also in use, the appropriate work area can be located and if necessary, a change in processing can be initiated. This work area pointer in the Call History Table is referred to as a hitching post and is also used in the work area auditing process to help locate busy work areas.

The use of these two distinct storage types allows the system to minimize parameter storage requirements.

CALL HISTORY TABLE

The system has the capability of processing as many as 384 calls at one time. Any call that originates into the system must have a signaling path from the originating inlet to the common control (the register sender (RS) and the central processor unit (CPU). The register junctor is the component which provides this signaling path between the network and the common control equipment. Since the maximum number of register junctors in the system is 384, the maximum number of calls that the software can process is 384.

The software is structured in such a manner that it identifies the calls which it is processing by the register junctor identities which are being used to supply the signaling path for the call. Since the software must be able to process several calls at one time, it cannot work on one call continuously from the time of origination to the time it is connected through the network. Thus, the software performs several small tasks on a call when it is not doing other work in the system (i.e., ticketing, processing other calls, maintenance).

This implies that the software must have an area to save information about the call when it is performing other work. Since the software must be capable of processing 384 calls at one time, there exist 384 areas in core to save intermediate data for each call. The area in core which is used to save intermediate data for calls that are being processed is the call history table.

The call history table contains 384 entries. Each entry consists of a twelve word buffer to store intermediate data about the call which is associated with a particular register junctor. Each entry in the call history table is associated with one of the 384 register junctors in the system. Thus, an entry in the call history table is accessed by using the register junctor identity associated with the call being processed. A register junctor identity is defined as follows:

Register Junctor Identity = Register Sender Section in which the register junctor is part of (0,1) + Register Junctor Identity relative to the Register Sender Section that is part of (0-191)

Examples of information that is saved in the call history table are:

1. Originating class of service data

2. Digit translation data

3. Data which is internally generated by the software that is to be used for later processing of the call.

4. Data which will be sent to the ticketing software so that the call can be billed properly.

Another important item of information which is stored in the call history table is a pointer to the work area which is being used to perform a task for the call. Thus, it is easy to retrieve the work area associated with a call by knowing the register junctor identity associated with the call. It is worth mentioning that a work area is not always linked to the call history table. A work area is linked to the call history table when the software is performing a task to process the call (i.e., there is no work area linked to the call history table during the reception of digits).

A diagram of the call history table is shown in FIG. 5 It comprises 4608 words (384 entries .times. 12 entries/word). FIGS. 6-12 are diagrams of one entry of 12 words, which show that information is in a call history table entry during various stages of processing a call, identified as time frames 0-6. Note that there are groups of data (overlays) identified as CHA, CHC, CHE, CHG, CHH, CHL, CHM, CHQ, CHT, and CJA. Individual items in each group are identified by the three letters of the group followed by three additional letters. In some cases sets of items within the same word also have a common identity comprising the same group identity followed by three other letters, not shown in FIGS. 6-12. The entire word is also identified by the three group letters followed by W and a pair of digits 00-11 for the word; for example the first word of group CHA is identified as CHAW00, and is located in word three of the entry. Note that the items of a group may appear in an entry during one or more of the time frames of FIGS. 6-12, and that the same location in an entry is used for different items during the progress of a call through the time frames. The information for the various items of the groups is defined below. The tables at right are references for definitions and values.

Group CHA comprises six words 0-5 located in the entry in rods 3-8. This group is used to schedule program module C01 (class-of-service initialization) and by the F32 (CCR handler) module. Table CHA is also used by program module C01 in the process of obtaining a work area. The fifth and sixth words contain status information which is used for scheduling purposes. __________________________________________________________________________ Word CHAW.phi..phi. in entry word 3 Item Bits Description Table __________________________________________________________________________ LKC .phi.-14 Linkage control FWALKC TYP 15-20 Work area type indicator FWATYP BK.phi. 21-23 Constant value .phi. Word CHAW.phi.1 in entry word 4 NPG .phi.14 Next program identity FWANPG ELN 15-17 Entry line number FWAELN PRI 18-20 Priority PWAPRI BK1 21-23 Constant value .phi. Word CHAW.phi.2 in entry word 5 TPF .phi.14 Identity of program in control of FWATPF work area ADI 23 Audit indicator used by the work area audit routine (WARAUD) which determines is the call history table can be found in a queue or not. BK2 15-22 Constant value .phi. Word CHAW.phi.3 in entry word 5 FEP .phi.-14 Forced exit program identity FWAFEP ERP .phi.-14 Error program identity FWAERP FEL 15-17 Entry line number in forced exit program FWAFEL FPR 18-20 Priority of forced exit program FWAFPR HPB 23 Hitching post indicator indicates whether or not the call history table slot is being used as a hitching post for a work area. BK3 22-23 Constant value .phi. Word CHAW.phi.4 in entry word 6 RJI .phi.-14 Register-junctor identity FWARJI RJN 4-11 Register-junctor number FWARJN SEC 12 Register-sender section EIO 15-20 Error indicators from the I/O programs FWAEIO of the executive BK4 21-23 Constant value .phi. Word CHAW.phi.5 in entry word 7 WAA .phi.-14 Work area address indicates the address of the work area that is being used for the call. CCM 15-20 call condition modified indicates the call abandoned, a time out, or an interrupt has occurred. Field CCM contains the fields TIO, CAB and XTO. TRI 15-18 Translation interrupt FWBTRI CAB 19 Call abandon FWBCAB XTO 20 Time-out FWBXTO BK5 21-23 Constant value .phi. __________________________________________________________________________

Group CHC is used to store the originating marker data frames, which are the equipment information for originating calls. This information from the originating marker is used by call processing in the identification and processing of the call. CHC is accessed by the call history address assigned by the executive. It consists of two 24 bit words with a bias of 10 so that they appear in words 10 and 11. __________________________________________________________________________ Word CHCW.phi..phi. in entry word 10 SEC .phi.-1 Office section CTNSEC SBS 2-3 Subsection indicates orig. marker pair CTNSBS SSB .phi.-3 Section and subsection SEC + SBS MID 4 Marker identity FWCMID MTN 5 Test call FWCTCL INO 7-11 Instructions originating FWDINO-A,B BUN 16-19 B unit FWDBUN-A CSO 20-23 Call status originating FWDSCO-A Word CHCW.phi.1 in entry word 11 BUN .phi.-2 B unit outlet FWDBUO-A RUO .phi.-5 R unit outlet FWDRUO-A AUI 6-10 A unit inlet FWDAUI-A AUN 11-14 A unit FWDAUN-A ABG 15-17 AB group FWDABG-A MTX 18-21 Matrix FWDMTX ABX 15-21 Consists of ABG and MTX LMI 6-21 Line matrix inlet, defines the matrix and unique inlet of the matrix for a line or trunk. Consists of MTX, ABG, AUN and AUI. RBO .phi.-5 R unit, B unit combination. Consists of RUO and BUO. __________________________________________________________________________

CHE contains data used by the non-local pre-translator to access drum table CPD via a 1, 2 or 3 digit translation. CPD in turn contains data used to instruct the register sender to collect more digit or to standardized a non-standard digit pattern. The table consists of three words, with a bias of 0 so that they fall in words 0-2 shown in FIG. 8. __________________________________________________________________________ Word CHEW.phi..phi. in entry word .phi. XD6 .phi.-3 Sixth called number digit - obtained from FWBXD 6 XD5 4-7 Fifth " " 5 XD4 8-11 Fourth " " 4 XD3 12-15 Third " " 3 XD2 16-19 Second " " 2 XD1 20-23 First " " 1 X13 12-23 Consists of XD1, XD2 and XD3 - Part of the search key used to access table CPD. See CHESID. X23 12-19 Consists of XD2 and XD3 CD1 .phi.-23 Consists of XD1-XD6. Word CHEW.phi.1 in entry word 1 FTP .phi.-1 Fast time out digit position TIP 2-3 Translation interrupt digit position Specifies the digit position CHEXD1, XD2 or XD3 in the search key the FWBIDC value is to be placed when a TRI=1 inter- rupt has occurred and CHESID=1. UID .phi.-3 Use incoming digit counter. Specifies the digit position CHEXD1, XD2 or XD3 in the search key the FWBIDC value is table placed if CHESIO-1. SID 20 Search on incoming digit counter. Indicates whether or not to place the FWBIDC value in the digit portion of the search key. Part of the search key used for the table CPD. Word CHEW.phi.2 in entry word 2 AUI .phi.-4 A unit inlet AUN 5-8 A unit ABG 9-11 AB group MTX 12-15 Matrix SEC 16-17 Section LNI .phi.-17 Consists of AUI, AUN, ABG, MTX, SEC. __________________________________________________________________________

Group CHG is used to store code translation data from work area CXD which defines the routing information necessary to terminate a call. The table consists of four words with a bias of 0 so that they fall in words 0-3 as shown in FIG. 9. ______________________________________ Word CHGW.phi..phi. in entry word .phi. RTN .phi.-11 Route number CTTRTN TTN 12-15 Traffic type number CTTTTT TSR 16 Tandem selective routing CTTTSR LSR 17 Local selective routing CTTLSR RPV 18-19 Route plan value CTTRPV CDR 20 Coin deposit required CTTCDR DNT 21 Directory number translation CTTDNT Word CHGW.phi.1 in entry word 1 NJR .phi.-3 Next job to run CTTNJR CID 4-8 Code identification CTTCID AOS 9 Allowed on six CTTAOS EOP 10 Early outpulsing CTTEOP ECP 11 Elacs code protection CTTECP STR 12-14 Separate toll routing CTTSTR ZNC 17-19 Zone of charge CTTZNC ZTS 20-22 Tandem screening zone CTTZTS Word CHGW.phi.2 in entry word 2 OSV .phi.-3 Outpulsing start value CTTOSV FTO 4-7 Fast time out CTTFTO XTL 8-11 Totals CTTXTL Word CHGW.phi.3 in entry word 3 PJR .phi.-3 Previous job run by digit analysis OJR 4-7 Old job run. Used for ambiguous code processing. TAT 8 Translation action taken. ______________________________________

Group CHH is used to store routing information which may be used to retrace a call. CHH consists of one entry type format (format A) and a general format (format B). Table CHH consists of six words falling in words 0, 2, 4, 5, 6 and 7, shown in FIGS. 10, 11 and 12. __________________________________________________________________________ Word CHHW.phi..phi. in entry word .phi. RTN .phi.-11 Route number being processed if a route number or alternate route number translation was the last translation performed. (CHHDNX=.phi.) Word CHHW.phi.1 in entry word 2 SU1 .phi.-3 Selector units of the first loop through FWCSUT-A the selector matrix SN1 4-7 Selector tens of the first loop FWCSTN-A ST1 .phi.-7 Comprises SUI and SNI. Word CHHW.phi.2 in entry word 4 SU3 16-19 Selector units of the third loop FWCSUT-A SN3 20-23 Selector tens of the third loop FWCSTN-A ST3 16-23 Comprises SU3 and SN3. Word CHHW.phi.3 in entry word 5 SU2 .phi.-3 Selector units of the second loop FWCSUT-a SN2 4-7 Selector tens of the second loop FWCSTN-A ST2 .phi.-7 Comprises SU2 and SN2. Word CHHW.phi.4 in entry word 6 SAI .phi.-2 Selector matrix A inlet FWCSAI-A SAU 3-6 " A unit FWCSAU-A SAB 7-9 " AB group FWCSAB-A SMX 10-13 " SGI .phi.-13 Comprises SAI, SAU, SAB, SMX. Word CHHW.phi.5 in entry word 7 ARN .phi.-11 Alternate route number if route number CRNARN being processed cannot be terminated and CHHARI=1. LXT 13 Line matrix termination if = .phi.. or selector matrix if = 1. ART 14 Alternate route translation was last translation performed. REP 15 Previous route early outpulsing ARI 16 Alternate route exists, in CHHARN RTL 17 Retrial DAT 18 Delayed alternate route translation __________________________________________________________________________

Group CHL is for ticketing information, including the normalized called number, the calling director number, and the ticketing scan point. See FIG. 11. ______________________________________ Word CHLW.phi..phi. in entry word .phi. TCT 14-18 Terminating call type FNA 19 Foreign numbering area CL2 20-23 Calling directory number 7th digit NO7 20-23 " Word CHLW.phi.1 in entry word 1 CL1 0-23 Calling directory number first six digits NO6-NO1. Also Cl4 for 6th-3rd digits, and for 2nd and 1st digits. Word CHLW.phi.2 in entry word 2 CD2 8-23 Called number 7th-10th digits comprising XD10-XD7. Word CHLW.phi.3 in entry word 3 CD1 0-23 Called digits XD6-XD1 Word CHLW.phi.4 in entry word 6 TSG 15-22 Ticketing scanpoint comprising TSY and TSX. Word CHLW.phi.5 in entry word 7 TSB 19-23 Ticketing scanpoint - 3rd field. ______________________________________

Group CHM is used by maintenance to store data which is to be used by call processing modules C32. This data indicates to C32 whether or not to take a sender/receiver and/or register junctor off line. The table consists of one word with a bias of 4 so that it falls in word four. ______________________________________ Word CHMW.phi..phi. in entry word 4 SRS 22 Maintenance - takes sender/receiver off line RJS 23 " register junctor " ______________________________________

Table CHQ is used to store the program generated indicators which are generated by call processing programs during the processing of a call for use later on in the processing of the call. The table consists of four words with a bias of 8 so that they fall in words 8-11. ______________________________________ Word CHOW.phi..phi. in entry word 8 TMF 21-23 Time frame field. The value of which provides the means to identify the relative progression of the call through the call processing program and thus indicates how the data and the call table shall be interpreted. The value TMF = .phi. for time frame .phi. of FIG. 6, during which program modules F32 and C.phi.1 are run. The value TMD = 1, FIG. 7., has programs F51, C.phi.2, C.phi.3, C.phi.6, C.phi.7 and C.phi.9. The value TMF = 2, FIG. 8, is the time during which program modules F51, C.phi.4, and C.phi.5 are run. The programs that are run during time frame TMF = 3, FIG. 9, are C.phi.7, C.phi.8, C10, C12, C13 and C15A. The programs that are run during time frame TMF = 4, FIG. 10, are C14, C15B, C16, C17, C19, C20, C21 and C24. The programs that are run during time frame TMF = 4, FIG. 11, are C24, C26, and retrial programs. Program C26 sets TMF = 6 before instructing the register sender to clear its memory. Time frame 6 is the register junctor idle time frame and is succeeded by time frame .phi. when the register junctor beings to process a new call. Word CHOW.phi.1 in entry word 9 TIE .phi.-3 Translation instruction expected, contains the value of the translation instruction which is expected from the register sender during a TRI interrupt. The definitions of the various values of TRI are given in the REGISTER/SENDER patent application. TOV 4-7 Index of table FTT for program to run in case of fast interdigital time out. LWA 8-11 Leave word area. An index for accessing entries in table FTE for program to be run for an expected register-sender interrupt. IPS 12 Inhibit program scheduling WAL 13 Work area linked. Indicates that a work area is associated with the register junctor and is to be used when scheduling a program as a result of an RS interrupt. TST 14 Maintenance is using the RJ ROL 15 Off line RJ. RJB 16 Busy RJ ADR 17 Indicates no more digits expected. RSA 18 Sender/receiver assigned to call. TRS 19 Unused. CRJ 20 Maintenance is attempting to clear the RJ. DNP 21 Used by C32 to clear if no job is scheduled. ABC 22 Abort the call. EOP 23 Early outpulsing. Word CHOW.phi.2 in entry word 10 DNR 5 Directory number retrieved. SBM 6 Switch bit for maintenance used in C19. TPI 8-9 Type of print out RCC 10 Revertive call VPD 11-12 Value of prefix digit dialed RTO 13-14 Recorded time out LPI 15 Loop pulled in selector PGI 5-15 Comprises DNR, SBM, TPI, RCC, VPD, RTO and LPI T(No.) 20 Traffic service observation for ticketing TSS 21 Traffic sampling - ticketing MRR 22 Message rate service CHA 23 The call is chargeable TKR 20-23 Comprises TSO, TSS, MRR and CHA Word CHOW.phi.3 in entry word 11 PDL 3-5 Number of called digits previously deleted - used to restore deleted digits for alternate routing OJT 22 Originating junctor translation NCB 23 New call bit, used by CCR handler only gradual transition is in effect to indicate use of a specific copy of drum memory. ______________________________________

Group CHT is a table which contains general information about a call and its status while it is being processed. It consists of twelve words.

Group CJA is used to store the originating class-of-service data for a line or trunk which has originated. This information is obtained from a drum table CLN or drum table CTN, depending on whether the origination is a line or a trunk, and is placed in CJA. Group CJA is accessed via the address assigned by the executive. The table consists of two entry formats. Format type A is for trunk originations and format type B is for line originations. There is also a general format, format type C. The table consists of four words, with a bias of three so that it falls in words 3, 4, 5 and 6. ______________________________________ Word CJAW.phi..phi. in entry word 3 AUN 0-3 A unit identified during origination CLNAUN ABG 4-6 AB group " CLNABG MTX 7-10 Matrix " CLNMTX SEC 11-12 Section " SBS 13-14 Subsection " CTMSBS Word CJAW.phi.1 in entry word 4 TGI .phi.-7 Trunk group incoming OSN 8-10 Originating service number ACO 11 Annoyance call originating TCN 12-13 Terminating control DS1 14 Disconnect status 1 DS2 15 Disconnect status 2 PDG 17-21 Published directory number billing group DN1 18-22 Directory number 1 location Word CJAW.phi.2 in entry word 5 RCI .phi.-4 Receiving control index SCA 6 Special code allowed ZCL 7-9 Zone associated with class of service. FWS 10 Foreign WATS state MRS 11 Message rate service MRT 12-17 Modified routing type IDC 18-21 Incoming digit count INT 18-22 Intest circuit identity DN2 18-22 Directory number 2 location Word CJAW.phi.3 in entry word 6 SAI .phi.-2 Selector A inlet SAU 3-6 " A unit SAB 7-9 " AB group SMX 10-13 " Matrix SGI .phi.-3 Comprises SAI, SAU, SAB and SMX TXS 14-15 Trunk matrix section ETN 16-18 Equipment type and number MTP 19-21 Manual Test panel PTS 22 Pretranslator standardization required ______________________________________

FIELD PROGRAM DESCRIPTION

General

this section describes the "Field Program," the name given to the collection of programs that make up the software system. The purposes of this section are to:

1. Identify the generic programs that make up the software system.

2. Describe the functions each program performs in the system.

Field program

the Field Program is divided into five major divisions. They are:

a. Executive program.

b. Application programs.

c. Maintenance programs.

d. Data Base.

e. Debugging Technique program.

The executive program provides centralized supervision over the operation of the data processor unit hardware, and control of the execution of the maintenance and application program software. The application programs are responsible for providing the operational characteristics of the system; e.g., call processing, ticketing, metering, etc.

The maintenance programs provide system and subsystem level maintenance functions; reconfiguration, scheduling of subsystem diagnostic programs, special handling of interrupts that occur during diagnostic operations, etc. The data base contains all of the table data that is stored in the system by means of the data processor unit's ferrite core and magnetic drum memories. The debugging techniques program is used to locate troubles within the software programs.

Refer to FIG. 13 for a block diagram of the field program flowchart.

Executive program

the executive program is responsible for the scheduling of application and maintenance programs. The executive program's major objective is to provide an orderly and efficient means of utilizing system hardware for these programs. The executive program provides the following major system functions:

a. Scheduling of central processor time on a priority basis.

b. Distributing interrupts to the appropriate interrupt processors.

c. Providing for the detection and handling of level two traps.

d. Scheduling and handling input/output device operations.

e. Providing the ability to time programs and events.

Central Processor Control

Both central processor time and the used non-resident areas in core main memory are scheduled by the executive program. The allocation of central processor unit time is accomplished by eight level priority scheduling for the system software.

The eight levels are referred to as levels zero through seven. Priority level zero is the highest level and level seven is the lowest. The executive will attempt to service all central processor time requests for programs waiting in priority zero before handling priority one requests. Similarly, priority one requests will be handled before those on priority level two, etc. Any one of the eight priority levels may be used to request execution of core and drum resident programs. Since only one program can be running at any instant, the eight levels provide the executive with the program priorities needed to properly schedule their processing. For example, "catastrophic situation processing" programs are given the highest level priority (level 0), and "routining maintenance" programs are given the lowest priority (levels 5, 6, and 7). Call processing, ticketing, and metering programs are scheduled on levels 3 and 4.

The data processor unit scheduler module is part of the executive program. Its function, as previously mentioned, is to schedule other program modules on a priority basis. If the program selected to run is core resident, it is merely started. If the selected program is drum resident, it must first be brought into core memory before execution can start. There is only one area available in core for the execution of drum resident programs. This area is called the "non-resident area" (NRA). The NRA consists of 2048 locations of core storage.

Interrupt and Trap Control

Processing interrupts received by the computer complex is a function accomplished by the executive program through the use of its interrupt processor modules. These modules analyze the cause of an interrupt and initiate the appropriate software action.

There are eight hardware priority interrupt levels associated with the computer central processor. These eight interrupt levels are of a higher priority than the executive's eight software priority levels. This means that the lowest hardware priority interrupt level is higher than the highest software priority level.

In addition to the interrupt system there are two levels of hardware traps, the traps are of a higher priority than the interrupt levels. These hardware priority trap levels provide for a "third party trap" (Level one), and a "central processor errors trap" (Level two). The executive only "controls" trap level two. The activation of any traps immediately suspends the running of the current program. If this occurs, the trap program modules are initiated and run before resuming execution of the suspended program.

I/o device Control

The executive program also has control of the following input/output devices:

a. High speed paper tape punch and reader.

b. Teletypewriters.

c. Marker communications registers.

d. Magnetic drums.

e. Magnetic tape units.

f. Maintenance and control center.

The executive schedules the input/output devices so that they may be used with maximum efficiency. It performs all actions required to operate the various input/output devices, thereby releasing the application programs, etc., from the necessity of having to perform these functions.

The executive interprets input messages from the teletypewriters and schedules the correct program module, as determined by the message control routine. The output data is made available in specific formats with headers as required.

Timing Control

The executive maintains a real time clock which keeps track of seconds, minutes, hours, days of the month, and months of the year. The clock is normally read by an applications program when it requires the date and time of day. Also provided, is an interval timer which provides timing functions required by some application programs.

The application program timing requests are timed by the interval timer module in multiples of 16.67ms. For example, if a program is run every minute, it will be called when a total of 3620 time intervals have elapsed. (3620 .times. 16.67 ms. = approximately 60 sec.)

Call processing program

the call processing program controls hardware and analyzes data to enable the system to perform its primary function which is to process calls. The modules of the call processing program analyze the data received from the markers and the register-sender subsystems.

Origination and Digit Reception

Data is transferred between the markers, data processor unit, and the register-sender subsystems. These subsystems are directed to perform their functions of interfacing with the network and completing the call via the call processing program. The primary call processing modules that process an origination and prepare the register-sender to receive digits are referred to as follows:

a. Class of service initialization.

b. Class of service analysis.

c. Non-dial line store.

The class of service initialization module performs the task of obtaining a work area (spaces reserved in core memory) from the executive program. Also, parameters are collected so that a class of service drum translation for the originating line or trunk may be made.

The originating class of service analysis module obtains the class of service drum translation information, analyzes it, and writes it into the register-sender core memory. The information received from the drum translation is analyzed and the program determines if a DTMF or MF receiver must be connected in order to receive digits. Additional class of service information is obtained from core tables and is then written into register-sender core memory by the executive program as directed by the call processing class of service analysis module.

The non-dial line store module formats the non-dial line digits retrieved from drum storage so that they may be written into the register-sender memory. This module updates register-sender memory with the formatted digits and instructs the register-sender to examine its memory for these digits

Digit Analysis

The call processing program modules primarily responsible for analyzing data supplied by the customer for determining the call's destination are the following:

a. Pattern recognition handler.

b. Local and non-local pretranslators.

c. Digit translation initialization.

d. Digit translation analyzer.

The pattern recognition handler module is used when the register-sender has recognized certain dialed digit patterns. Specifically, the module initiates the routing of the call to an operator when a single zero has been dialed in an office not arranged for 0+ dialing. It also decreases the digits totals field of the register-sender core memory, upon recognition of 1+ dialing in an office so arranged.

The non-local pretranslator is scheduled by the call processing program when the origination is from a foreign office. The pretranslator is designed to add and/or delete digits as required. For example, if the call is from a direct control office to a local termination in this office, up to three (office code) digits may have to be added.

The translation portion of call processing begins with a local pretranslation of the incoming digits. The local pretranslator first determines if a "1" or a "0" prefix digit has been dialed. If so, the digit is deleted from register-sender core memory. Indicators (bits set in core) are then set to indicate that a prefix digit was dialed and what its value was (one or zero). If the register-sender has not accumulated three digits (excluding the 1+ or 0+ prefix digits), the digits total field in register-sender memory is updated to a value of three. This indicates to the register-sender that three digits are to be collected before a translation can be performed.

Digit translation initialization takes place and first initiates a three, then a four, five or six digit translation if required. The type of translation initiated will depend on the call destination which is usually apparent with the first three digits received.

The digit translation analyzer is responsible for deleting certain three digit prefix codes such as those associated with ticketing codes, reverting call access codes, and home numbering plan area codes and determining whether translations other than the normal three digit translation are required.

Routing

The routing function is controlled by a route translation initialization module which initiates the correct drum translation so that all of the information needed for the termination of a call is available.

A directory number translation is usually initiated if the call terminates locally, and a route number translation is usually performed if the termination is to a foreign office. A selective routing translation will be made in cases indicated by the originating route type attached to the originators class of service and by the prefix digits dialed.

Termination

The terminating cycle of call processing involves five major modules to accomplish the task; they are referred to as follows:

a. Route number and directory number translation analyzer.

b. Selector matrix routing.

c. Sender-receiver assigner.

d. Sending patterns and format control.

e. Termination cycle.

The route and directory number translation analyzer provides a preliminary analysis of data taken from drum after a route number or directory number translation. This module makes the following route checks:

a. Route for a permanent signal trunk.

b. Route for reorder tone or line busy tone application.

c. Route for intercept.

d. Alternate route indicators to access the alternate route control module.

The selector matrix routine module provides a means to determine the routing from a selector group inlet to a selector group outlet based on the type or types of equipment required to complete the call.

The sender-receiver assigner maintains a check on the busy-idle status of senders and receivers. It also maintains a check of the on-line/off-line status of senders and receivers. The sender-receiver assigner provides a map which shows the assignment of all senders and receivers to register junctors.

The sending pattern and format control module prepares the called number, calling number, and prefix digit storage cells to meet the sending pattern requirements of the receiving office. The register-sender memory is prepared by loading in register-sender memory the sending data contained in the route number expansion table. This module also gives the sending control information from the route number expansion table to register-sender.

The termination cycle acquires terminating information for the register-sender and the terminating marker. The terminating marker uses this information to connect a terminating path through the network. The register-sender uses this information for timing the termination process.

The termination cycle module determines most of the terminating requirements for the terminating marker and the register-sender. More specifically it accomplishes the following:

a. Readies the routing and control information to be used by the terminating marker and the data processor unit's communication register.

b. Acquires the calling directory number and determines if sending is required.

c. Schedules the succeeding call processing modules, if required.

Alternate Routing

The alternate route control module is called for whenever an alternate route termination is being processed. The primary purpose of the module is the determination of whether the conditions set up by the preceeding termination attempt require any modification.

To meet the requirements of an office, several types of alternate routing are provided. The types provided are as follows:

a. Route number alternate routing for lines or trunks.

b. Alternate routing for PBX lines.

c. Trunk group alternate routing for trunk groups with an availability greater than 80 (maximum scanning capability per group) and sequential selection of groups.

d. Alternate routing for oversize trunk groups providing a balance by random selection of one of two trunk groups for even traffic distribution.

Ticketing program

the primary purpose of the ticketing program is the collection, formating, and recording of toll data for future processing. The ticketing program consists of 16 modules to perform the necessary ticketing functions. The software operates in conjunction with the automatic toll ticketing subsystem hardware to provide ticketing data for Local Automatic Message Accounting (LAMA) operation.

The ticketing subsystem tickets subscriber dialed automatic number identification traffic. It tickets direct distance dialed (DDD) toll traffic as "timed" calls while ticketing message rate service (MRS) local traffic as "pegged" calls (calls recorded for answer only, not timed). Only calls originating within the local office are ticketed.

Ddd call

The brief description that follows illustrates the way in which the ticketing software handles a DDD call.

When a DDD call is originated, the call processing program determines the identity of the trunk that was seized. At this point, the call processing program stores the identity of the seized trunk for this call, and transfers control to the ticketing seizure module.

The seizure module checks the activity bit table to assure that the associated trunk activity bit is 0. This (activity bit 0) will inhibit the scanner from looking at the trunk supervisory contacts during outpulsing. Control is then returned to the call processing program.

If the last call of this trunk was incomplete, the activity bit will still be a 1 when checked by the seizure module. In this case, the seizure module would reset the activity bit to 0 and schedule the recording of the "incomplete call" information on magnetic tape (if traffic observation is being conducted).

Assuming a normal call, after cut-through (register-sender outpulsing completed) has occurred, the call processing program passes the equipment number of the trunk, the called number, and the calling number to the ticketing call completion module. The call completion module formats this information, and schedules its writing in a table on the drum. The call completion routine then sets an indicator causing the scan interrupt routine to begin interrogating this trunk for an answer condition. At this point the call completion module returns control to the call processing program.

The scan interrupt handler interrogates the trunk for an answer condition until an answer condition is found. When answer is first detected, the scan interrupt routine begins timing a 2.4 second charge delay interval. If the answer state remains true for the 2.4 second interval, the time of answer is recorded and is scheduled to be written into the drum cell associated with this trunk.

The scan interrupt handler continues to interrogate the trunk, looking for a disconnect condition. If a false disconnect is detected (called party on-hook, calling party off-hook), the disconnect time is stored in a table on drum and the associated trunk bit is set in the disconnect recorded table. The scanner will continue monitoring the trunk for as long as the calling party remains off-hook. If, while the calling party is still off-hook, the called party again goes off-hook, the trunk bit in the disconnect recorded table will be reset (0). This nullifies the disconnect time previously recorded. The scanner always continues its supervision until both parties have gone on-hook, indicating a true disconnect. When a true disconnect occurs, a request is generated to move the call data associated with the trunk from the drum cell to a work area in the computer core main memory. The scan interrupt handler also requests the scheduling of the output format module, after the call record has been read off of the drum.

The output format module is responsible for arranging call data into a useable format for magnetic tape output. On completion of its assigned task, it indicates that the call record buffer format module should be scheduled.

The call record buffer format module is responsible for moving the formatted call record into a buffer work area, determining where the call data should be stored, and when the buffer becomes full, indicating to the magnetic tape 1/0 scheduler that the buffer contents should be outputted on magnetic tape.

Mrs call

An MRS (message rate service) call is handled in a fashion similar to that of the DDD call, except that those operations necessary to time the call and detect disconnect conditions are not used. The MRS calls are recorded when the scanner detects a true answer condition. The record contains the calling number and the answer time.

Miscellaneous Functions

In addition to its normal recording tasks, the ticketing program also provides instructions for checking certain hardware malfunctions. The ticketing program provides for detecting trunks with scan contacts that remained in an open or closed state for more than a 24 hour period. It also provides for detection of any trunk on which a call was in progress for more than 1 hour. Such malfunctions are identified by TTY output messages.

Metering program

the metering program provides a means to measure traffic density through the office. Also measured is the application of reorder tone when such application is due to a system malfunction. The various metering modules are driven by the call processing and executive programs.

The metering program provides the following types of metering:

a. Overflow metering.

b. Call routing metering.

c. Call event metering.

d. Grade of service metering.

e. Reorder tone application metering.

Overflow Metering

Overflow metering measures the number of times a line busy condition exists from a selected group of local directory numbers. The count is taken each time a call termination attempt is made to one of these numbers.

Call Routing Metering

This function provides a count of the number of times specified traffic originations have been connected to specific traffic terminations. Lines and/or trunks may be counted.

Call Event Metering

The purpose of this metering is to count the number of times a given set of conditions occurs in the processing of a call through the system. The call event metering is driven by various call processing modules. Some of the events counted are:

a. Blocked call in the line matrix.

b. Call blocked by all register junctors busy.

c. Successful connection to register junctors.

d. Blocked calls in the selector group matrix.

Grade of Service Metering

Grade of service metering or, dial office administration, counts the ability of the system to switch calls through the network. A count is made of calls blocked in the switching matrices caused by all AB links busy. The grade of service metering module interfaces with the call processing program to acquire information necessary to perform this metering function.

Reorder Tone Application Metering

This metering function counts the number of times reorder tone is applied when caused by a system malfunction. The reorder tone metering function is driven by the call processing software so that various fault conditions resulting in reorder tone application initiate the count.

Input-Output Devices

The normal output of the metering program is via the high speed paper tape punch. The administrative teletypewriter may be used to output metering messages in response to an appropriate input request. The metering modules that require input parameters receive them via the high speed paper tape reader.

Maintenance program

the overall maintenance program consists of two major sections, having the capability of performing maintenance operations on the system and/or subsystem level. The maintenance program is composed of program modules and tables which are stored both in core and on drum.

This extensive maintenance software system is necessary to insure that the No. 1 EAX system meets its design goal of a maximum downtime of 1.5 hours in a 30 year period. The maintenance software needed to accomplish this goal makes up approximately 65% of the total software package.

That group of modules concerned with the overall control and service of system level maintenance functions is called common maintenance. Common maintenance programs have functions useful to most subsystem diagnostic programs but are not peculiar to any specific one. They provide centralized control to minimize interference among subsystem diagnostic functions.

The subsystem diagnostic program modules allow the hardware system to operate in the presence of faults and errors. They provide the following functions:

a. Malfunction detection.

b. Fault isolation (of a faulty unit).

c. Malfunction recovery and restart (after disturbances due to diagnostic testing or repairs).

d. Fault localization (to a location within a few circuit boards).

e. Repair verification (checking a "repaired" unit before placing it in service).

f. Routining (testing the capability of a subsystem or unit to perform certain tasks).

Common Maintenance

The major functions of the common maintenance are as follows:

a. Scheduling of subsystem diagnostics.

b. Reconfiguration of the system or subsystem.

c. Audits.

d. Power monitor scan of power failure detectors.

e. Central control of error counters.

f. Display lamp control.

g. Special analysis of TTY input messages.

The common maintenance programs have the capability of interfacing with each other and to the diagnostic subsystem programs. These common maintenance programs also interface with the executive program and the maintenance personnel in the office.

The common maintenance programs interface with each other and the subsystem maintenance programs via the normal interfaces of the executive, and the diagnostic control program (DIACON). When maintenance programs call DIACON (a common maintenance module) it will schedule these programs via the executive. DIACON uses a special indicator attached to the front of each of the executive's queues that permits control to be transferred from the executive to DIACON. This enables DIACON to gain control without the requirement of first having a work area. After DIACON receives control, it acquires a work area and schedules the requested program by using the executive's scheduler module.

The interface with the maintenance personnel is accomplished via requests from the MCC controls, TTY input messages, etc. This interface causes various common maintenance programs to be scheduled and effectively gives the maintenance man control of the system.

Part of the common maintenance software is a configuration control program (CONFIG) that exercises control over system status and configuration. This program performs the following major functions:

a. It receives requests for configuration changes. The requests come via TTY input, MCC pushbutton demands, diagnostic software, and power monitor scan software.

b. It determines if a configuration change can be made without affecting system availability.

c. It maintains a record of current system status in the system status table.

d. It performs all legal configuration changes that are requested, or calls the appropriate program to effect the change.

e. It provides for the appropriate TTY output which contains the configuration change information.

The maintenance interrupt and access program (MANIAC) and its associated tables provide centralized control over special processing of interrupts. This requirement is necessary because, during diagnostic functions, inadvertent or deliberate interrupts may occur. These interrupts must not be allowed to affect normal processing, therefore, the MANIAC program is used to provide the maintenance feature of allowing these interrupts to have special handling.

The system clear and start program (SYSCLR) provides centralized control for initializing or re-initializing the system/subsystem(s). The SYSCLR program is used initially (at cutover) to place the system into operation. It is also used to re-initialize the system on demand, and to recover the system (or subsystems) from malfunctions for which there are no other means of recovery and then return the system to normal processing.

The "audit" programs perform checks on significant software area. The following are the areas checked:

a. The specially protected areas of read only core memory.

b. The linking of work areas to queues, call history tables, and hitching posts. (Hitching posts are one entry queues reserved for a particular system function.) All lost work areas will be returned to the appropriate size spare work area queue.

c. The MF sender and MF receiver assignment tables to compare the on-line/off-line, busy/idle software status to the actual hardware status.

d. The MANIAC tables to insure that they are being correctly used by the programs accessing them.

e. The system status table to insure that all data within the table is correct and that no illegal entries have been made.

f. The call history tables to verify that the software indication of each register junctor's off-line and busy status is consistent with its actual hardware status. The audit programs also perform the following two timing checks:

a. The non-resident area audit of core memory to insure that a program does not maintain continuous control of the NRA. This software "time-out" feature allows a program to only occupy the NRA for a certain predetermined time. If this time is exceeded and certain other conditions are met, the system clear and start program will be called.

b. The input/output handler time-out audit to provide a software time-out check for each 1/0 device. This time-out check is required so that an 1/0 device does not hold up normal processing. If a device does not respond within a predetermined time, the appropriate 1/0 handler abort program is notified.

The power monitor scan program (PMSCAN) is used to reconfigure the system around any power failure that may occur. PMSCAN monitors the output lines from the office power alarm circuits via the power monitor adapter to ensure that all power conditions are reported to the system. If a power fault is detected in a particular unit, that unit is placed off-line by the configuration control program (CONFIG). CONFIG will update the system status table so that it will represent the current status of all units in the system.

The error count program (ERRCNT) provides centralized control over incrementing, reading out, or resetting of certain software counters. These "error" counters are used for reasons other than error counting. ERRCNT provides the requesting program with the ability of having their respective counters reset, read and printed out via TTY, or incremented and printed out via TTY upon overflow.

The lamplighter program (LMPLTR) provides software control over the lighting and extinguishing of the lamps associated with the maintenance display adapter of the maintenance display adapter of the maintenance control center (MCC). LMPLTR maintains the status of these lamps in a table in core memory. When a lamp is to be turned on or off, LMPLTR calls the MCC 1/0 handler program to perform this function. When a certain predetermined number of work area overload lamps are lit, the work area audit program (WARAUD) is scheduled via DIACON. WARAUD may call the system clear and start program under certain work area overload conditions.

The configuration pushbutton handler program (CNFPBH) provides the maintenance personnel with the capability of requesting reconfiguration of any of the subsystems from the maintenance and control center. Activating the applicable MCC pushbuttons will accomplish the reconfiguration via CONFIG. The CONFIG program will insure that both units of a pair are not taken out of service.

Subsystem Maintenance

The subsystem diagnostic programs that handle the faults and errors that occur in the system, and which permit the system to function in spite of these malfunctions are as follows:

a. Processor configuration group (PCG) diagnostic program.

b. Register-sender diagnostic program.

c. Markers and network diagnostic program.

d. Drum memory system diagnostic program.

e. 1/0 peripheral apparatus diagnostic programs.

f. Space divided equipment routining program.

In addition to the primary subsystem maintenance programs (malfunction detection, fault isolation, etc.) there are the routining and auditing programs. The malfunction detection, fault isolation, and fault recovery programs are handled quickly because call processing is inhibited during their execution. All the other subsystem maintenance programs are deferrable and are normally run intermixed with the call processing programs.

The malfunction detection programs respond to hardware detectors and provide for separation of faults and or errors, routining of seldomly used circuits, routining of malfunction detectors, and routining of space divided equipment. The fault isolation programs are used to determine which one of a pair of redundant units is faulty and to separate (isolate) the faulty unit from the rest of the system.

The malfunction recovery and restart program will return the hardware/software to normal operation after disturbances due to diagnostic testing or repairs. Fault localization programs are used to narrow down the location of the fault to a few circuit boards and provide a trouble report printout on the maintenance teletypewriter. The repair verification programs utilize combined diagnostic processes and are executed before returning a "repaired" unit to service.

A processor configuration group (PCG), consists of one each of the following computer complex units: central processor (CCP), memory control (CMC), core memory (CMM), and the priority interrupt and sense line circuits of the line processor (CLP). The PCG diagnostic program operates in response to hardware detected malfunctions. These malfunctions are primarily detected by the specially designed hardware of the computer third party circuit (CTP) which is used to insure the matching integrity of the duplexed PCG's.

When a PCG mismatch occurs, an isolation program will determine whether the malfunction was due to a fault or a transient error. The PCG mismatch caused what is known as a third party trap (level one). Both CCP's will be taken off-line, and therefore out of sync, when a level one trap occurs. The isolation program used to determine the fault (if a transient error was not the cause) will run both CCP's independent of one another through a set of the same diagnostic detection programs. These programs exercise all logic elements that could have caused the mismatch. The programs will return periodically with intermediate results to the CTP. A faulty unit is determined if an incorrect result occurs or if a diagnostic program fails to return for a check in either CCP.

The register-sender's isolation modules will also be initiated by a hardware detected malfunction. The synchronized common logic units of the register-sender are compared by special hardware matching circuits to determine the faulty unit. Isolation is accomplished by analysis of data collected at the time of the non-comparison, by a RCC logic simulator (stored in the drum memory system) used as a third party element, or by exercising RS functions under software control. The fault localization software will find the general location of the fault and will then initiate a TTY trouble report output to inform the maintenance man at the MCC. The register-sender diagnostic program also includes special software used for monitoring troubles in space divided apparatus outside of the RS common control equipment (e.g., MF senders and receivers, RJ's, etc.). This special software contains system trouble monitors and busy/idle and configuration status indicators for the space dividied apparatus.

The marker and network malfunctions are detected primarily by hardware contained within the markers. Hardware circuits take the affected marker out of service and an interrupt is generated which will cause the executive program to schedule the appropriate diagnostic program. The localization diagnostics are used to analyze faults in the markers,

The drum memory system diagnostic program operates in response to hardware detected malfunctions and software generated requests. It provides basis malfunction detection of parity checks, special drum timing checks, and special program segment marks. Isolation is performed via task retrys on the duplexed units. The fault localizing software finds the general location of the fault and will provide a TTY trouble report output. The DMS maintenance program also provides for data transfers and comparison checks between drums. Repair verification and routining software is also included in this program.

The I/O peripheral apparatus diagnostic programs are initiated by various hardware detected malfunctions. The I/O maintenance program includes diagnostics on the computer channel multiplexor and its associated controllers (TDB, MDB, CDB, AND CCR). Special diagnostic software is provided for the unique features of the peripherals. This software is used with the automatic peripherals (ticketing scanner unit and magnetic tape unit) and the manual interactive peripherals (teletypewriter, paper tape reader and punch, and the maintenance and control center displays and pushbuttons).

The space divided equipment routining provides test connections to space divided equipment (lines, outgoing trunks, junctors, senders, and receivers) to allow for manual testing. It also provides for automatic routining of this space divided equipment. Another feature of the space divided routining program is to provide for a metallic path for testing via an incoming remote test trunk. Routining requests from remote locations are provided for via a special incoming line.

The manual testing of space divided equipment is accomplished by a testman via controls on the MCC.

The automatic routining of space divided equipment is primarily performed by the maintenance routining logic (MRL) hardware of the MCC and its associated software. During and/or after testing, the MRL sends data (such as test status and test results) to the CCP. The diagnostics performed on the space divided equipment can be initiated by detection of an error, a request via the TTY to perform a specified routine, or the routine may be periodically scheduled by the timed routine scheduler module (L18).

Testing from a remote location (via additional testing equipment) can provide the following features in addition to manual and automatic routining:

a. Initiate single shot and repetitive automatic tests.

b. Initiate requests for system status or configuration reports.

c. Receive teletypewriter printouts of maintenance test data, system status, etc.

d. Perform manual tests on customer lines.

Data base

the data base contains all of the stored table data used by the system such as specific office data, translation data, etc. The data is stored in data processing unit core memory and on the drum memory.

The data base contains all of the stored table data used by the system such as specific office data, translation data, etc. The data is stored in data processing unit core memory and on the drum memory.

Office data is stored in tables and may be core or drum resident. The tables consist of a field or fields of data which are retrieved together and are contained in a single physical table. The following represents the types of data contained within the data base:

a. A series of data tables which contain variable data peculiar to each office (directory numbers, code translations, routing instructions, etc.).

b. Engineerable data concerning hardware configurations (i.e. line and selector matrix grading).

The following represents the type of variable data needed for an office. This type of information is normally supplied by the operating telephone company.

a. Line number identity.

b. Incoming trunk group identity.

c. Terminating classification.

d. Originating routing types.

e. Foreign numbering plan area.

f. Directory numbers.

g. Ringing mode (Frequency and line side).

h. Type of station apparatus (dial or DTMF).

i. Blocking of supervision on answer.

Organization

The data that appears on the drum and in core is arranged in a logical pattern. A drum layout typical arrangement has the drum divided into 18 segments. The core image (a duplication of the information in certain areas of core for reliability reasons) is found in the first 3-1/2 segments. The remaining 3-1/2 segments contain programs. Variable data, such as information pertaining to ticketing, is contained in segment 8. Segments 10 to 18 contain the translation data. A portion of segment 7 and segment 9 are spare areas.

FIG. 4 illustrates a typical organization of core memory. The patch areas shown are used in debugging operations. The constant data, is data that remains unchanged during the life of the program. The parameter data provides input to various programs so they may be properly run. The variable data consists of data that is held temporarily during processing; this information is held in a work area. The drum control unit initialization area contains tables of data that are used to enable transfer of other data between the drum and the core memory and between the core memory and the drum.

System update program

the purpose of the system update program is to allow the permanent data associated with the system to be modified, when required, and to provide a means to add new information to the stored data. Whenever a hardware change is made to an office, usually the data base will require an update; also, the addition of new customer's lines to the office and any changes in service require an update. These changes are accomplished by means of the system update program. The office administration program permits the following changes:

a. Adding new information to the system.

b. Modifying information already in the system.

c. Deleting information in the system.

To make any required modifications or changes to the system, the system update program is activated by an input via the:

a. High speed paper tape reader (HSPTR)

b. Low speed paper tape reader (LSPTR)

c. Office administrative teletypewriter (LOAT)

The system update program consists of 10 modules to accomplish its required task, that is, keeping all stored office information current.

In updating the office, various checks are required on the data supplied, such as limit checks on numeric data and reasonability checks on alphabetic data. Also checked is the quantity of data received to see that it is sufficient to program a successful update.

When the data is loaded into the system (via tape or teletypewriter) for the update, the program initializes this data, or converts it in form, so that it may be interpreted by the program. The data is then checked and analyzed, as mentioned previously, for errors and quantity of information provided.

If new information is being loaded, the program checks to see that the required number of storage locations are available for the data. If it is desired to remove information already in storage, a program module will zero all information existing in the location specified by the update request.

The program is capable of changing information in storage as indicated by the update request. The data is transferred to one drum for both core and drum resident data. A drum-to-drum transfer is then made to equalize the data between drums, and also to equalize the core data.

A punched paper tape of the new data is supplied by a module for office back up purposes. The tape may also be used to remove the update entered, via an input device.

Debugging techniques program

the debugging techniques program provides a means to locate troubles within the software programs. The program is not run automatically, but must be activated by office personnel.

The program has the ability to provide selective dumps of information existing in core, drum, register-sender or sense lines. The information is outputted on the administrative teletypewriter and analyzed to see that the information present is as it should be. Any program, at any point in the program, may be selected for dumping.

The program is enabled by an input set instruction, which specifies what is to be dumped and under what conditions it is to be provided. At specified points in the field program called breakpoints, which are variable and defined by the input instructions, the debugging techniques subprogram checks for the previously mentioned conditions and produces an information dump when the conditions are satisfied. Two types of breakpoints are available, hardware or software.

A computer programming console (PRCF) provides thumbwheel type switches for setting the address of the breakpoints. The hardware will now give control to the debugging techniques subprogram via an interrupt when the instruction at the address specified by the thumbwheel switches is executed. Software breakpoints are inserted into the program by the debugging techniques subprogram; this subprogram gains control when the instruction at the specified address is to be executed. The input set instruction is inputted via the teletypewriter.

EXECUTIVE PROGRAM DESCRIPTION

General

this section described the Executive Program, the program used to provide centralized supervision and control over the operation of the Data Processor Unit (DPU) hardware and over the execution of maintenance and application programs. The Executive Program is a part of the Field Program and is a major portion of the system software.

The purposes of this section are:

1. To identify the generic programs and tables that make up the Executive Program.

2. To describe the major functions of the "executive" and the individual functions of the associated program modules and tables.

Organization

the Executive Program (executive) provides a proper operating environment for execution of the ticketing, metering, and call processing application programs and for the maintenance programs. To accomplish this, the executive schedules the use of the central processor and its associated memory, and utilizes a priority interrupt system for efficient hardware operation.

The executive is used as a means of linking application programs. The executive contains program modules that are used to communicate with input/output (I/O) devices such as the teletypewriters, paper tape devies, magnetic drums, etc. These program modules schedule the operation of the devices and perform various I/0 functions upon requests from the application programs. The I/0 devices associated with the system are shown in FIG. 35 of the SYSTEM application.

Most real time systems have a scheduling routine which looks at the groups of programs waiting in line (in queues) to be run, and decides, according to a priority system, which program will be processed next. This scheduling routine obtains control whenever the program currently running relinquishes its control of the computer. In this system, the program module which performs this function is called the DPU Scheduler (E/1).

A "queue scan" routine is entered whenever an application program ends and the decision of which program to run next has to be made. By interrogating the queues, the queue scan routine determines the application program having the highest software priority, and passes control to this program. The scanning of queues is another function of the DPU Checuler (E01).

The Executive Program consists of a group of modules which exercise software control over the Data Processor Unit and its associated I/0 equipment, and also over execution of the application and maintenance programs. To provide this capability, the executive schedules DPU time, the use of various areas of core memory (work areas), and the processing of interrupt signals from the I/0 devices. These interrupt signals control the introduction of new tasks into the system via the I/0 devices.

The Executives Program modules access various tables in core memory and drum memory. Some of these tables (FIT, FII, FMA, etc. ) are considered part of the executive, while others such as the Call History Table (CHT) and the Program Locator Table (PLT) are accessed by several other programs, and are not considered part of the executive.

Queuing

As part of a basic understanding of the Executive Program scheduling process, a knowledge of queue structure is necessary. The queue structure consists of two parts: the entries in the queue and the queue root. The queue entries are work areas which are assigned to specific programs. Each queue has a unique root associated with it. This queue root consists of a six word table located in computer core memory.

A standard queue root format is shown in FIG. 15. An explanation of the information contained in each queue root word follows:

a. Word 0 (Bits 0-14) contains the address of the first word of the first entry in the queue. If there are no entries in the queue at this time, these bits will be set to zeroes.

b. Word 1 (Bits 0-14) contains the address of the first word of the last entry in the queue. If there are no entries in the queue, these bits indicate the address of the first word of the next queue root.

c. Word 2 (Bits 0-23) contains the number of entries currently remaining in the queue.

d. Word 3 (Bits 0-23) contains the total number of entries that have even been linked to the queue.

e. Word 4 (Bits 0-23) contains the total number of times that entries were linked to the queue after it was emptied.

f. Word 5 (Bits 0-23) contains the maximum number of entries that the current queue length attained.

For this discussion of the operation of the executive, the first three entries are the most important. Words 0 and 1 are used to link the queue root to the first and last entries in the queue. Word 2 represents the number of work area linked to the queue. Words 3 through 5 contain statistics used to determine how well the queue is performing.

FIG. 16 shows how work areas can be linked to each other in a queue. The method of linking uses the least significant fifteen bits of the first word of each entry. The first word of the queue root points to the address of the first entry in the queue, and the first word of the first entry points to the address of the second entry, the second entry points to the third, etc. The last entry, since it has no work area to point to, will contain all zeroes in its first word.

Work Areas

Work areas are sections of computer core memory used for intermediate storage of data during the processing of application programs. These work areas are divided into six sizes, which are 8, 16, 26, 38, 64, and 100 words in length. The quantity provided of each size is determined by the size of the system. Work areas are said to be residing in their "spare queues" when they are not assigned to any particular program.

Before the executive can schedule an application program module to be run, the program must request and obtain a work area. When the work area is assigned to the program, it will remain so until the required task is completed. When it is no longer needed, the work area is released. This action effectively places the work area back into its appropriate spare queue.

When requesting a work area, the caller (requesting program) must specify the proper size. The Executive Program then assigns a work area of the proper size (if available) to the requesting program.

The queue size data is placed in the Work Area Type indicator field of word 0 (FIG. 10). Bits 0-14 of this same word contain the core address of the next program on that priority level to be processed.

Word 1 indicates the next program to schedule and its priority. Word 2 contains the identity of the program presently using the work area. Word 3 contains the indentity and priority of the program to be run in case the program presently using the work area encounters trouble. Word 4 is used to indicate a particular RS pair and RJ identity. Bits 15-20 of word 4 are error indicators related to the various I/0 programs. Word 5 contains the address of the Call History Table entry associated with the RJ specified in word 4.

See FIG. 17, which shows the following fields in the first six words of a work area:

Lkc - linkage control used to link the work areas to queues

Typ - work area type (size) indicator indicating the proper work area queue to which the spare work area is to be returned

Npg - identifies the next program module to be scheduled

Eln - indicates the entry line number of the program specified in bits 0-14

Pri - indicates the absolute priority in which to run the task identified in bits 0-14

Tpf - identifies the program presently using the work area

Tel - indicates the entry line number of the program specified in the TPF field

Fep - identifies the program to be scheduled for forced exits (Error Program)

Fel - indicates the entry line number of the Error Program

Fpr - indicates the absolute priority in which to run the Error Program

Fji - indicates the particular RJ associated with a call (when the work area is used for call processing)

Cht - indicates the address of the entry in the Call History Table associated with a particular RJ

Software Priority Structure

The allocation of central processor (CP) time to various application programs is accomplished by eight software priority levels. These levels are 0 through 7, with level 0 the highest and level 7 the lowest. The executive attempts to service all CP time requests in priority level 0 before servicing those on level 1. Similarly, priority level 1 requests are handled before those on level 2, etc.

Any one of the eight levels of priority may be assigned to a program. Since only one program can be running at any instant, the eight priority levels provide the executive with the ability to schedule the processing of the most important programs first. For example, isolation programs for major system malfunctions are given the highest priority (level 0), and the routining maintenance programs are given the lowest priorities (levels 5, 6, and 7).

Certain guidelines have been formulated to generalize the assignment of programs to specific priority levels. These priority allocations are as follows:

a. Level 0 - castastrophic situation processing.

b. Levels 1 and 2 - general maintenance programs.

c. Levels 3 and 4 - call processing, ticketing, and metering programs. The Watch Dog Timer Manipulator Module (L40) is scheduled on Level 4.

d. Levels 5, 6, and 7 - routining and miscellaneous programs.

Priority Interrupt Levels

There are eight hardware priority interrupt levels associated with the central processor. These eight interrupt levels are of a higher priority than the eight software priority levels. Therefore, the lowest hardware interrupt level is higher than the highest software priority level.

The executive has the ability to identify any interrupt causes and transfer control to modules which service these causes. The eight hardware interrupt levels and their primary causes are listed below:

a. Level 1 - manual input requests from the attention key of the teletypewriters, power failure indications from the voltage monitors and power alarms, status and configuration control panel inputs, CCP/CTP configuration changes, and DDT matches.

b. Level 2 - drum control unit, computer memory control, computer communication register, and ticketing device buffer (TDB) errors; register-sender faults; and originating marker and terminating marker malfunction alarm indicators.

c. Level 3 - timed interrupts from the main and standby real time clocks every 16.67 milliseconds, and ready interrupts from the TDB's.

d. Level 4 - ready interrupts from the computer communication registers.

e. Level 5 - ready interrupts from the drum control units.

f. Level 6 - 1/0 error interrupts from the computer device buffers (CDB's).

h. Level 8 - register-sender error count and system trouble interrupts, general alarm errors (main clock, standby clock, etc.), and computer line processor errors.

The executive controls the cause identification and the processing of multiple simultaneous interrupts that occur, regardless of the interrupt levels involved. The executive provides for returning control to the interrupted program after all interrupt processing is complete.

When an interrupt occurs, the executive Register Stacking Module (F13) saves the contents of the computer central processors index registers (X1, X2, and X3), the contents of the A and Q registers, and that of the four pseudo registers (in core memory). When interrupt processing is completed, the F13 module restores the contents of the registers and returns control to the interrupted program at the calling location plus one.

Traps

In addition to the eight level interrupt system, there are two levels of hardware priority traps. These trap levels have a higher priority than any of the interrupt levels.

The level 1 or third party trap occurs when there is a mismatch between the duplexed central processors or the memory control units during synchronous operation. When a third party trap occurs, the instruction in process is completed, and the active CCP is forced to a dedicated location (address) in main memory. A third party trap program located at this address is used to determine the cause of the trap. The Executive Program does not become involved with third party traps.

Level 2 trap identification and processing is controlled by the Executive Program. Such traps are caused by internal errors that occur in one central processor during simplex operation, or simultaneously in both central processors during synchronous operation. A level 2 trap signal will be generated by one or both CCP's by any of the following:

a. Data even parity error - occurs when even parity (rather than odd) is detected from computer core main memory, the register-sender, or the channel multiplexor.

b. Instruction even parity error - occurs when even parity is detected while reading a new instruction from memory.

c. Division by zero - occurs during a division instruction when the divisor is detected as being all zeros.

d. Invalid operation code - occurs when the decode of the instruction operation field detects one of the following invalid codes: 00, 27, or 63.

e. Memory reference time-out - occurs when one of the memory reference signals (main or register-sender memories) remains true for more than 140 microseconds.

f. Port seven error - occurs when the central processor attempts to access memory out of range, or when it attempts to write into "read only memory".

Note: if, during synchronous operation, an error occurs causing a level 2 trap signal to be generated by only one CCP, the Computer Third Party Circuit (CTP) will generate a third party trap and the level 2 trap signal will be ignored.

Level 2 trap causes (a) and (b) result in a retry of the instruction. Causes (c), (d), (e), and (f), or failure of an (a) and (b) retry, result in a transfer to the System Clear and Start Program.

Program Linkage

The program modules of the executive, and also those modules associated with other programs, contain one or more entry lines. These lines serve as entry points into a program module. They are selected for the various functions they provide. Each module may have a maximum of eight entry lines. Linkage between application programs is via these entry lines and by the use of branch instructions (BUN, BSP, etc.).

The linking mechanism involves two vector tables, the Program Locator Table (PLT), and the Entry Line Locator Table (ELT). PLT is used as a pointer to an address in the ELT associated with the first entry of a specified core resident program.

PLT is also used to locate entry lines for drum resident programs. In such cases, the ELT is actually part of the program rather than a separate table in the core memory. The ELT is located at the beginning of each program read from drum and is referenced by the executive at this location.

When a program is coded, it is not necessary to know whether the program is core or drum resident because linkage from one program to another can be established by using a macro. A macro is a group of instructions which takes the identity of the requested program and its entry line address, and transfers directly to the requested program providing both the requesting and requested programs are core resident. If either program is not core resident the macro schedules the linkage through the DPU Scheduler Module.

FUNCTIONAL DESCRIPTION

This part briefly describes the five major functions of the executive and the major program modules associated with these functions. Some program modules are common to more than one major function such as those that "link" and "unlink" the work areas from the spare queues. Refer to Table EX1 as a reference to the titles of the major executive modules.

The primary objective of the Executive Program is to provide an orderly and efficient means of utilizing system hardware for processing application and maintenance programs. To accomplish this, the executive provides control over the following system functions:

a. Scheduling of central processor time on a priority basis.

b. Distribution of interrupt requests to the appropriate interrupt processors.

c. Detection and handling of level 2 traps.

d. Timing of system programs and events.

e. Scheduling and handling of input/output device operations.

TABLE EX1 ______________________________________ MAJOR EXECUTIVE MODULES GROUPED ACCORDING TO FUNCTION MODULE FUNCTION NUMBER MODULE NAME ______________________________________ E.phi.1 DPU SCHEDULER CENTRAL E.phi.6 QUEUE INTERROGATION PROCESSOR F.phi.2 LINK TO QUEUE CONTROL F.phi.3 UNLINK FROM QUEUE F.phi.4 WORK AREA ASSIGNMENT F.phi.5 WORK AREA RETURN E1.phi. TRAP 2 CAUSE ANALYSIS F13 REGISTER STACKING INTERRUPT F34 OM STANDBY INTERRUPT PROCESSOR AND TRAP E21-28 INTERRUPT CAUSE AND ANALYSIS CONTROL F51 RS INTERRUPT PROCESSOR F52 MARKER MALFUNCTION INTERRUPT HANDLER F58 TTY USE REQUEST INTERRUPT PROCESSOR E2.phi. HOT SENSE LINE FINDER F32B CCR READY INTERRUPT HANDLER E.phi.2 INTERVAL TIMER REQUEST ACCEPTOR E.phi.3 INTERVAL TIMER HANDLER TIMING E.phi.4 INTERVAL TIMER INTERRUPT PROCESSOR CONTROL E.phi.5 REAL TIME CLOCK E.phi.8 REAL TIME CLOCK INITIATE AND UPDATE E.phi.9 MINUTES TIMER F.phi.1 RS TIMING INTERLOCK DRUM INPUT/ F35 MANIPULATOR OUTPUT F29 DRUM SCHEDULER DEVICE F30 DRUM HANDLER CONTROL F40 DRUM HANDLER SUBROUTINE F41 DRUM HANDLER SUBROUTINE E07 BLOCK LOAD/STORE COMPUTER COMMUNICATION REGISTER F31 CCR SCHEDULER F32A CCR HANDLER F36 CCR SUBROUTINE 1 F38 CCR SUBROUTINE 2 F14 CHT ADDRESS CALCULATOR F33 RJ TRANSLATOR F37 CCR ERROR ISOLATION AND RECOVERY F39 CCR LOAD/UNLOAD TTY/PAPER TAPE AND TICKETING EQUIPMENT F.phi.6 INPUT MESSAGE ANALYSIS F.phi.7 OUTPUT FORMAT F.phi.8 RS ACCESS F1.phi. PRINTOUT INHIBIT F22 PAPER TAPE IDENTIFICATION F25 I/O INTERRUPT DISTRIBUTOR F26 I/O SCHEDULER F27 I/O HANDLER F28 TAPE CONTROL F23 HOURLY PRINTOUT F15 INTERNAL TO ASCII F16 PARITY CALCULATOR F17 CHARACTER PACKING AND DELETION F18 CHARACTER UNPACKING F19 ASCII TO INTERNAL F2.phi. NUMERICA CONVERSION F21 COMMON NUMERIC CONVERSION F72 TICKETER SCANNER I/O HANDLER F73 MAGNETIC TAPE SCHEDULER F74 MAGNETIC TAPE HANDLER F.phi.9 MATRIX GROUP IDENTIFICATION F11 INDIVIDUAL MATRIX IDENTIFICATION F6.phi. CHT AUDIT F61 SENDER/RECEIVER AUDIT F7.phi. PRIVILEDGED INSTRUCTION WRITER ______________________________________

Central Processor Control

To fulfill its function of controlling the central processor, the executive schedules the execution of programs within the confines of an eight level software system. It also provides the ability for application programs to schedule other programs.

If a program scheduled to be run is core resident, it is simply started. If the program selected is drum resident, it must be brought into core memory before it can be run. The area of core memory available for the execution of drum resident programs is called the Non-Resident Area (NRA). Because there is only one such area available, a second drum resident program cannot be processed until the one currently being executed is completed, and control of the NRA has been relinquished.

The scheduling philosphy is:

a. Give the most important job in the system to the computer.

b. Once a task is begun, allow it to be completed, (excluding processing interrupt and trap causes).

c. Once the NRA is loaded, place the drum program residing in it into the first position in the highest priority queue (0).

The scheduling duties of the executive are primarily handled by the DPU Scheduler Module (E01) (see FIGS. 52a-52e). There are five major functional sections or entry lines associated with the DPU Scheduler. These entry lines and their applications are as follows:

a. ACCEPT - Schedules program modules that require control to be passed back to the requesting program.

b. RELEAS - This section is used by programs that have completed their processing and want to return control to the central processor so that it can perform other scheduled duties.

c. RESKED - This section is used if a group of modules are scheduled consecutively using the same work area at the same priority. RESKED is also used when a work area overload occurs and it is necessary to reschedule a work area request.

d. RELOAD - This section is used by twopart programs, where both parts are drum resident. It permits the program to be run without being broken. The first part of a two part NRA program is read off the drum, placed into NRA, and executed. When this part has been processed (at priority 0), the second half of the program is scheduled at the same priority, and control of the NRA is retained. This eliminates the possibility of interleaving the parts of several non-resident programs of the same priority.

e. TIME - This section is entered any time a program relinquishes control of the central processor. TIME scans the eight software queues and gives control to a program according to the highest priority. In addition, this entry line is used to schedule drum resident programs to be read into the NRA. TIME calls the Data Manipulator Module (F35) to perform a drum to NRA transfer.

Supplementary program modules are used in conjunction with the DPU Scheduler. These modules perform functions such as linking and unlinking the programs contained in the priority queues. Other modules assign work areas from the spare queues and return them to spare status when they are no longer needed. See FIG. 53.

A work area (WA) is assigned to a requesting program by the Work Area Assignment Module (F04). The work area address is then passed to the DPU Scheduler to be placed into a queue at a specific numeric priority. If the desired size work area is not available in the spare WA queue, a maintenance program lights a WORK AREA OVERFLOW lamp on the maintenance and control console as an indication of a work area overload. The WA assignment program then looks for the next larger size WA. If again, none is available, another overflow lamp lights and this procedure continues until an available WA is found. If there are none available, control is passed to the RESKED entry line of E01, or back to the calling program. This choice is a programming consideration and is determined by the calling program.

If a program is to relinquish control of the central processor, it must pass control to the RELEAS section of the DPU Scheduler. RELEAS then returns the work area to the appropriate spare work area queue using the Work Area Return and the Link to Queue supplementary program modules (F05 and F02, respectively).

If a work area has to be removed from other than the front or the back of a queue, the Queue Interrogation Module (E06) is used. This module (FIG. 20) can locate and/or remove any entry from a specified queue. Since this module functions as a closed subroutine, it always returns control to the calling program.

Interrupt Control

Each of the eight hardware interrupt levels is associated with certain interrupt processors, such as the RS Interrupt Processor (F51), are part of the executive, while others, such as the maintenance interrupt processors, are not.

The Interrupt Cause and Analysis Program (ICAP) modules, E21 through E28, act as an interface between the interrupts and the interrupt processors. The processors schedule the appropriate program to handle the cause of the interrupt.

The ICAP modules receive and process the eight levels of interrupts; module E21 receives level 1 interrupts, E22 receives level 2 interrupts, and so on to E28. FIG. 55 shows a level 1 interrupt (Maintenance Teletypewriter Input Request) being processed by E21. The E21 module stores the address of the interrupted program. The Register Stacking Module (F13) saves the contents of the central processor registers. Its function is to prevent loss of the data contains within the A and Q registers, the index registers (X1, X2, and X3), and the four pseudo registers.

The E21 module obtains the sense group image of the sense lines that cause a level 1 interrupt. It uses closed subroutine E20 (Hot Sense Line Finder) to determine the identity of the "hot" sense line in the group. This sense line identifies the hardware system causing the interrupt (in this case, the maintenance TTY).

ICAP module E21 then calls the Maintenance Interrupt Access Program (MANIAC) to see if the interrupt was caused by a maintenance routining program. If this is the case, MANIAC instructs ICAP to ignore the interrupt since it was not valid, and control is returned to the interrupted program.

Assuming that the interrupt is valid, E21 passes control of the TTY Use Request Interrupt Processor (F58). F58 determines the identity of the TTY making the request, schedules the Input Message Analysis Program (F06) to initiate the I/O operation (via the ACCEPT entry line of E01), and then passes control back to ICAP. The Register Stacking Module restores the registers to their original state and returns to the interrupted program. Before exiting to the requesting program, ICAP resets the interrupt (sense line) that was just processed.

A variety of interrupt processors and handlers are used by ICAP to process the different types of hardware interrupts. In addition, there are various supplimentary modules used to accomplish interrupt processing. These modules are called as closed subroutines and must return control to the calling interrupt processor or handler after performing their required tasks. The processor then returns control to ICAP which passes control to the interrupted program at the point of interruption.

The subroutines used by the interrupt processors must be core resident, as the time required to read them from the drum (8 ms. average) would be too long. In addition, the non-resident area of core may be busy at the time of the interrupt, thus preventing the program from being brought in from drum.

The F32x/3 entry line of the CCR Ready Interrupt Handler Module (F32B) is used when a ready interrupt is generated by the Computer Communication Register (CCR) after two words are received from an Orginating Marker (OM). A CCR ready interrupt (level 4) causes the ICAP module E24 to call F32x/3. FIG. 22 shows a diagram of F32B and its major subroutines.

The CCR Ready Interrupt Handler:

a. determines if the interrupt came from the A or B unit (CCR A or CCR B),

b. determines the work area associated with the interrupt request,

c. determines if the interrupt request was sent successfully,

d. schedules maintenance routines (if necessary) via ACCEPT,

e. determines if the message was received successfully, and

f. determines if the request is for an originating or terminating marker.

The RRJ Translation Module (F33) is used by F32x03 during line or trunk call originations to determine the register junctor handling the call. F33x01 is entered to perform the translation of the data frame sent by the OM to the CCR when a line or trunk call origination occurs. This module translates the line matrix R outlet identity (LRO) for line call originations, or trunk register matrix B outlet identity (TBO) for trunk call originations into the corresponding register junctor identity (RJI).

The Call History Table Address Calculator Module (F14) is called by F32x03 (if the translation by F33 was successful) to calculate the CHT address from the RRJ identity. F32x03 calls F01x01 to access the RRJ slot and will then use ACCEPT to schedule call processing module C01x01 (the first call processing module to be run).

To complete the interrupt handling procedure and to disconnect the CCR from the marker, F32B calls the CCR Handler (F23A). The F32A module returns to F32B when completed and control is then returned to ICAP (E24). ICAP restores the registers and returns control to the interrupted program.

Trap Control

The Executive Program handles only level 2 traps, as shown in FIG. 23. The Trap Two Cause Analysis Module (E10) is the computer's internal error processing program. A level 2 trap is caused by any one of the errors listed under the heading Traps, paragraph on level 2. Recognition of this trap is immediate and the instruction in process is aborted.

The Trap Two Cause Analysis Module (E10) passes control for nearly all trap two causes to the System Clear and Start (L16) maintenance program. For instruction even parity errors (IEPE) and data even parity errors (DEPE), E10 will call the Parity Recovery Program (S30), a maintenance program) to determine if the trap was caused by a transient error. If so, the system will return to normal processing. If the parity error was definitely caused by a fault, the System Clear and Start Program will be called to reinitialize the system. This program is run when any unrecoverable system errors occur.

When System Clear and Start is called, it clears out all sybsystems and places them in an idle state, and clears out all interrupts stored by the central processors. To return the system to normal processing again, the L16 module reinitializes core main memory (CMM), enables the interrupt system, and restores the subsystems to an operational condition.

Timing Control

The information contained in paragraphs below describes the timing control functions of the executive modules. These modules allow the application and maintenance programs to time certain functions, schedule other programs at various time intervals, and be executed themselves at specified time intervals.

Timing control provides the capability of timing various events that are requested to be run at specific times. An example of this is the scheduling of the Non-Resident Area Audit Program (L39), which is run every minute to verify that a program is not improperly occupying the non-resident area of core main memory. The timing control modules provide interval timing and the initiation of requested actions when the intervals elapse. The Interval Timer Request Acceptor Module (E02) accepts timing requests by placing them into a general timer queue. Of the time interval requests in the general timer queue, the first interval in the queue is the one being timed at that particular moment. There is a 40 year software clock in the main memory that provides current time. This clock is initiated at cutover and provides current time which is used as a basis for placing interval timer requests into the general timer queue.

Timing control maintains a software clock called the real time clock. The real time clock (RTC) is used by application and maintenance programs to provide the time of day in hours, minutes, and seconds. It also provides the year, month, day of the month, and day of the week. The Real Time Clock Program Module (E/5) maintains the five counters that comprise the RTC, which is in a binary coded decimal (BCD) format. E05 updates the RTC and resets its counters at the appropriate times (FIG. 58).

A level 3 interrupt is received by ICAP module E23 every 16.67 ms. which causes E23 to call the Interval Timer Interrupt Processor Module (E/4). See FIG. 59. This action provides a standard time interval that is used to produce other intervals required by various timing programs. These intervals are all multiples of 16.67 ms. The following are some of the programs initiated by E/4:

a. The Diagnostic Control (DIACON) Maintenance Program Timer Module (L22X07) every 16.67 ms.

b. The Real Time Clock Program (E05) every second (60 - 16.67 ms. intervals).

c. The Minutes Timer Program (E/9) every minute (3620 - 16.67 ms. intervals).

d. The Non-Resident Area Audit Program (L39) every minute (3620 - 16.67 ms. intervals).

c. The I/O Time-Out Audit Program (L52) every 167 ms. (10 - 16.67 ms. intervals).

f. The Interval Time Handler Program (E03) which is called by E04 at the expiration of a requested time interval (a variable number of 16.67 ms. intervals).

g. The Ticketing Hardware Validation Program (W01) every 2.4 seconds (144 - 16.67 ms. intervals).

In FIG. 25, which shows the primary timing modules, the Interval Timer Interrupt Processor (E04) is shown as the heart of the timing functions. After the required number of 16.67 ms. intervals have elapsed, E04 calls the appropriate program. When E04 has completed its functions, it returns control to E23.

E04 calls the Real Time Clock Program after every 1 second interval has elapsed in order to update the system real time clock. This update is performed to provide the application programs with an accurate indication of the time.

As shown in FIG. 24, the Real Time Clock Module calls the Timed Routine Scheduler (TRS) maintenance program (L18) every hour. One of the modules that the TRS controls is the Hourly Printout Routine (F23). This module permits the time of day and the date to be outputted on both the maintenance and office administration teletypewriters.

The Interval Timer Request Acceptor (E02) is used to place timing requests from application programs into the general timer queue. If a program is to be run at a specified time, it calls E02. This module places the shortest interval requests at the front of the timer queue so that they may be processed first (FIG. 26). If a request is to be placed on the front or rear of the queue, the Link to Queue Module (F02) is used. For any timing requests that are to be placed somewhere between the first and last entries, E02 will not require F02.

If entry line E02X01 is entered, the exit will be back to the caller. If entry line E02X03 was used, the exit will be to the executive's TIME routine. E01X04 will then scan the CPU queues for the next task.

The interval Timer Handler's E03X01 entry line is entered from E04 at the expiration of the general interval timer (FIG. 27). The general interval timer is a counter that can be set to any requested time. For example, if a program is to be run in 2 minutes, the request is placed on the timer queue and when the 2 minute interval has expired, E04 will call E03X01 to handle the request. E03X01 will use F03X01 to remove the entry from the timer queue. This entry indicates to set a specified flag in memory, to transfer control direct to a specified entry line, or to schedule a program by using the ACCEPT entry line of E01. After the requested action has been taken, F05X01 is called to return the work area to the spare queue. E03X01 will then calculate the next interval to be timed. It will also set the timer to idle if no intervals are to be timed.

The E03X02 entry line is called from a program that wants to remove a request for a time interval before that interval has expired. E03X02 uses routine E06X03 to locate the entry to be removed from the timer queue. E06X05 is used to perform the entry removal before timer expiration. The Queue Interrogation Module (E06) is shown in FIG. 20.

Both E03X01 and E03X02 are called as closed subroutines. E04 receives control again after routine E03X01 has completed, and control is returned to the caller of routine E03X02 after the requested entry has been removed from the timer queue. The work area used for a timing request regardless of whether action was taken or the interval was aborted, will be returned to the spare queues by F05X01 (FIG. 19).

A timing function used to provide an interlock when accessing register-sender memory is accomplished by modules F08 and F01 (see FIGS. 28 and 29). F08 (the Register-Sender Access Module) and F01 (the Register-Sender Timing Interlock Module) are used to provide access to RS memory so that accidental alteration of the memory data cannot occur.

The F08 module is called by the call processing programs via entry line F08X01 to permit writing into RS memory. It uses F01X01 to provide an interlock between the DPU and the RS memory. Any data in a register junctor (RRJ) memory slot is protected against alteration by the DPU as a function of the F01X01 entry line.

When an RRJ slot is to be accessed by the CPU, F01X01 determines the amount of time remaining before the RS will scan the slot. From the input parameters received from the calling program, it knows the number of time slots required to modify the data within a particular RRJ (approximately 50 microseconds per slot). If enough time remains before the RS scan reaches the RRJ, control will be returned to F08 to permit the DPU to access the slot. The interrupts to the computer central processor (CCP) are disabled upon return to F08 to insure that F08 has the full time interval for its update.

If insufficient time is available to update, control is retained by F01 until the scan has passed the slot. At this time, the F01 Time Interlock Module will try again. Retries will continue until an interlock is obtained (600 tries are maximum).

The F08 02 entry line (FIG. 28 is used by maintenance programs for read and write requests. There are three functions performed by this routine. The first is to write from the work area into the RS memory, the second is to write from RS memory into the work area, and the third is a read/modify/write RS memory operation. This entry line also used F01 to prevent interference with the RS scan of the RRJ's. The exits of F08 are either back to the caller or to the Call Condition Analysis Program (C29).

As shown in FIG. 29, the exit points for F01X01 are either back to the caller for normal operations, or to the caller's error return in the case of an RS fault or RRJ trouble. The exit point for all programs calling F01X02 is back to the caller.

The watch dog timer (WDT) prevents software looping. If a program has control of the central processor for over 882 ms., the watch dog timer times out and a system clear and start is initiated by the Computer Third Party Circuit (CTP).

The TIME entry line of the DPU Scheduler (E01X04) permits scanning of the eight queues (0-7) associated with the central processor unit (CPU queues). If there are no entries in the queues, a watch dog time-out will occur (unless the WDT is reset). A time-out is not desirable at this time since there is no software looping involved. To prevent the time-out, E01X04 schedules a maintenance module called the Watch Dog Timer Manipulator (L40). The main function of this module is to reset the WDT.

If TIME scans the eight CPU queues and finds no work areas attached to any of the levels, it obtains a work area to schedule L40X01 (see FIG. 30). The work area is obtained by F04X01 and F03X01. The ACCEPT entry line (E01X01) places the work area containing the necessary parameters required by L40 on the front of the priority 4 queue.

ACCEPT returns control to TIME which will then rescan the queues. The work area for L40 is removed from the queue by F03X01, and L40X01 is then initiated. When processing of L40 is complete, control will pass to RELEAS (E01X03). RELEAS returns the work area used by L40 to the proper spare queue and passes control to TIME to rescan the eight CPU queues. If there are still no tasks in the queues, L40X01 is rescheduled and the manipulation of the watch dog timer is repeated.

Input/Output Device Control

The executive has control over the operation of the following I/O devices:

a. High speed paper tape punch and reader.

b. Teletypewriters (maintenance and office administrative).

c. Low speed paper tape punch and reader.

d. Marker communication registers (located within the originating and terminating markers).

e. Magnetic drums.

f. Ticketing magnetic tape unit.

g. Ticketing scanner unit.

The executive schedules the use of the I/O devices so that they may be utilized with maximum efficiency. The executive performs all actions required to operate the various I/O devices. This releases the application and maintenance programs from having to perform these functions.

If a request is made for an I/O operation, the operation is initiated immediately if the requested device is idle and a path to it is free. If the device or the path are not idle, the I/O requests are placed in the appropriate queue. The major queues used by the I/O programs are shown in Table EX2.

When a device becomes idle, its associated queue (or queues) is scanned in a present pattern. All tasks of the highest priority (first queue scanned), associated with the specified device, are processed before the next lower priority queue is scanned. Table EX2 defines the queues associated with each device, the order in which the queues are scanned, and the maximum length each queue may attain. Maximum queue length is equal to the number of work areas large enough to accomodate an I/O request for a specified device.

A normal request is one that does not require special attention or a particularly rapid response (most call processing I/O requests are normal requests). The high priority requests must be executed in a relatively short period of time as normal processing may depend upon these requests (e.g., maintenance requests used to isolate and diagnose malfunctions in the I/O devices).

The drum memory I/O operations are accomplished in much the same manner as operations for other I/O devices. The drum memory contains data needed by the system, and the programs used to access this data are the I/O schedulers, I/O handlers, and their associated subroutines.

The programs that access the drum are shown in FIG. 65 as users of the Data Manipulator Module (F35X01). This module is used by resident and non-resident programs and provides centralized control of all drum accesses. F35X01 obtains the required parameters needed for drum access and functions as a drum directory by locating the proper drum, drum segment, and start address required by the requesting program. The work area specified in index register one is used to process the request.

When a drum access request is received, F35X01 goes to its control tables in the core memory to obtain the parameter data needed to accomplish the access. This is unusual because most modules have the parameter data passed to them. The collected parameters are passed to the Drum Scheduler Module (F29) for scheduling the drum access operation.

The Drum Scheduler (F29X01) then schedules a drum read or write operation from the parameters it has received. It places the requester's work area into a queue associated with the desired drum control unit (DCU) pair. The work area is placed on the queue by the Link to Queue Routine (F/2X01) according to its assigned priority. Since there can be a maximum configuration of six DCU's, a maximum of three queues are used (one for each DCU pair). Each of these queues has three priority levels, as shown in Table EX2.

The F29 module exits to TIME when it cannot branch to the Drum Handler. At this time, an exit can also be made back to the requester; however, this action must have been previously specified in the requester's work area. If a software error occurs during F29X01 (e.g., the request number of the drum is invalid or the work area is too small for the I/O request), F29 will use ACCEPT (E01X01) to schedule an error return to the requester.

The Drum Handler Module (F30) performs the drum access. The Drum Scheduler calls F30X01 when it determines that the drum and DCU are not busy and that the request from F35 is valid. The Drum Handler uses the Drum Handler Subroutine Module (F40) to interrogate the request's work area data in order to obtain the required indications. F30 and the subroutines it calls are used to:

a. Remove the tasks from the appropriate queue.

b. Check request validity.

c. Initiate the DCU initialization.

d. Notify the requester if the request cannot be handled.

e. Disconnect the DCU after a request has been serviced.

Note: drum maintenance programs may also enter entry line F30X01.

TABLE EX2 __________________________________________________________________________ Queue Structure of I/O Devices. CONTROLLER I/O ORDER OF MAXIMUM (CDB OR DCU) DEVICE ASSOCIATED QUEUES QUEUE SCAN QUEUE LENGTH __________________________________________________________________________ Channel Maintenance Input (Keyboard) 1 1 Device TTY High Priority 2 N Buffer Output .phi. Normal Output 3 N HSPT Punch Output 4 N Input Keyboard or LSPT 1 2 Channel Office (Reader) Device Administrative High Priority Output Buffer TTY (Printer) 2 N 1 Normal Output (Printer or LSPT Punch) 3 N HSPT Reader Input 4 N High Priority (For Maintenance) 1 N (One Queue/DCU Pair) Drum Magnetic Block Transfer Control Drums (Program Read) Units (One Queue/DCU Pair) 2 N Normal (One Queue/DCU Pair) 3 N Computer Marker Communication Communication Communication Register (CCR Maintenance) 1 N Registers Registers High Priority Marker (One Queue for all Markers) 2 N Terminating Marker Normal (One Queue/TM Pair) 3 N Ticketing Magnetic Maintenance 1 N Device Tape Unit A Normal 2 N Buffer A Ticketing Magnetic Maintenance 1 N Device Tape Unit B Normal 2 N Buffer B __________________________________________________________________________

The exit to TIME from F30X01 occurs when the DCU's are busy. TIME will then scan the queues for another task that the central processor can perform until the drum access is retried. The Drum Handler normally returns to F29X01 which will check a bit in the requester's work area to determine whether to pass control back to the calling program, or to exit to TIME. The TIME exit is the most common.

The ACCEPT entry line of E01 is entered from F30X01 to schedule the following routines:

a. The requester's error return if a request cannot be serviced.

b. The next requested task when a DCU task has been successfully completed.

c. DCU maintenance when a DCU error occurs.

Ticketing write requests get special treatment by being attached to the front of the second drum queue by F02X02. The Drum Handler also uses F02X02 to link the non-resident programs that have not completed processing to the front of a zero priority CPu queue, thereby permitting these programs to be run first and freeing the non-resident area of core as quickly as possible.

The F03X01 subroutine is used to remove the indicated requests from the appropriate queue. DROP (F05X01) is used by F30 to release a work area when a task is completed after an I/O operation.

The CCR/Marker I/O operations are accomplished by the CCR Scheduler (F31) and the CCR Handler (F32A) programs and their associated subroutines (FIGS. 55, 55A, 56 and 56A-M). Various call processing and maintenance programs are the users of these modules.

The CCR Scheduler's F31X01 entry line accepts all requests for data transfers between the markers and the DPU via the CCR. F31X01 provides its users (calling programs) with the means of instructing the CCR to perform an input or output operation.

Entry line F31X01 takes the parameters in the requester's work area, determines if they are valid, and if they are, places the request into a CCR queue. The three types of queues used by the CCR Scheduler are listed in Table EX2. The work area size is also checked to see if it is large enough to accommodate the request. If the parameters are not valid or if the work area is not proper, the appropriate error routine is scheduled by F38. The CCR Scheduler exits to F32X01 when F31 finds that the appropriate marker (pair) and the CCR are in the idle state.

If an error occurs during the running of F31X01 (e.g., the work area obtained was not large enough for the task, a marker was checked in preparation for a data transfer and was found to be unequipped, etc.) F38X03 will schedule an error program. The LINK entry line (F02X01) is used to place entries on the back of the CCR I/O queue.

Entry line F31X02 is used to schedule CCR status dumps. A status dump includes such information as the scanner address, status of the CCR (idle scanning, sending, or receiving), if the message was sent or received successfully between the CCR and the marker, etc. The status is stored in the user's work area by F36X06. Control will be returned to the caller of F31X02 if requested. If no return was specified, F38X01 will act as an interface between F31X02 and E01X01 to schedule the next program.

The CCR Handler (F32A) uses two entry lines F32X01 and F32X05. F32X01 is used to perform operations necessary to prepare the markers and CCR for operation. It will initiate data transfers between the CPU and the CCR, and between the CCR and the markers. Entry line F32X05 is entered from the CCR Error Isolation and Recovery Module (F37) to retransmit the data transmission after an error has occurred.

The tasks placed in the CCR I/O queue by F31 are removed (via F03X01) so that they may be handled by F32A. F32X01 prepares the CCR and the appropriate marker pair for operation, and controls the data frame transmission by the CCR. The data frames consist of two 26-bit words for the originating markers (OM) or four 26-bit words for the terminating markers (TM). Data frame transmission to the OM is only performed for maintenance purposes.

If the requested marker is not available, F32X01 notifies the calling program. This is known as the requester's error return. Other subroutines used with F32X01 are F02X03 (LINK), which is used to add an unfinished non-resident task to the front of a CPU priority queue; F03X01 (UNLINK), which is used to remove entries from the CCR queues; and F01X01 (RS TIME), which is used for TM requests in order to perform an interlock with the register-sender.

The CCR Subroutines 1 Module (F36) handles common tasks required by the CCR I/O programs. F36 may be used to set up maintenance requests, unload the CCR data and status words, reconfigure the CCR, etc.

The CCR Subroutines 2 Module (F38) is also used for common CCR tasks. This module contains routines that provide an interface between the CCR Handler and the DPU Scheduler for scheduling of the next program to be run or of an error program. In addition, F38 can place a CCR maintenance-out-of-service (MOS) and schedule an isolation program, abort a task, etc.

The TTY and paper tape I/O devices are schedules and controlled by the I/O Scheduler (F26) and the I/O Handler (F27) modules, respectively, and their associated subroutines (FIG. 20). The I/O Scheduler accepts requests for and schedules the use of the following I/O devices:

a. Local maintenance teletypewriter (LMT)

b. Local office administrative teletypewriter (LOAT)

c. Low-speed paper tape reader (LSPTR)

d. Low-speed paper tape punch (LSPTP)

e. High-speed paper tape reader (HSPTR)

f. High-speed paper tape punch (HSPTP)

Entry line F26X01 is used to transfer I/O data via one of the peripheral devices listed above. F26X01 checks the parameters located in the requesters work area. The work area parameters include the work area size, name and priority of the requester's program, the next program to schedule in case of errors, etc. If errors are encountered, ACCEPT (E01X01) is called to schedule an error routine and will either pass control to E01X04 to permit scanning the queues for a new task, or will return to the calling program.

From the work area parameters, the I/O Scheduler determines the I/O device to be used and then checks to see if the device and its associated controller is available. (The controllers used with the TTY's and the paper tape devices are the channel device buffers - CDB's). F26X01 will check a table located in the core memory to determine if the requested device and its associated controller are available. If a device is not available, the I/O Scheduler can assign the request to an alternate device. If a request cannot be serviced because of hardware unavailability, the caller is notified via an error return.

The I/O Scheduler places each I/O device request into its appropriate queue by using the Link to Queue Module (F02X01). The I/O Scheduler exits to the I/O Handler (F27) when the I/O device is idle, the path to it is free via the channel device buffer, and the request is determined to be valid.

The I/O Handler Program (F27) performs all operations necessary to prepare each device for operation and affects the data transfer between the CPU and and selected device. Data manipulations, code conversions, parity checking requirements, etc., are provided by the various subroutines used by F27.

Upon entry, F27X01 unlinks the work area from the I/O queue via F03X01 and then stores the work area address into a table in the core memory. It also checks the availability of the peripheral adapter (PA) and channel device buffer (CDB), determines if the I/O request is an input or an output, and determines which device is to be used (LMT, HSPTR, etc.). The Interval Time Request Acceptor (E02X01) is called when a TTY input request is initiated. This routine allows 120 seconds maximum to input the message.

The CCS Recovery Module (S31) is used by F27X01 to check for any channel multiplex errors and to reset a CCX error counter. Another subroutine shown in FIG. 67 which is used by F27 is the Stop Time (E/3X02). This entry line is used when the I/O Handler wants to remove a task from a timer queue before the requested interval has expired. The entries are located and removed from the queue by the Queue Interrogation Module (E/6).

The Input Message Analysis Module (F/6) is primarily used to prepare the I/O system to receive a TTY input message, F/6 is accessed once for each TTY input, and at least once for each paper tape that is read. All TTY inputs are in ASCII code. ASCII code is converted to the computer's internal code and vice-versa by the F19 and F15 modules, respectively.

A TTY message consists of the ACTION CODE (the first four characters containing the identity of the program designated to receive the input data), and the inputted data. Each character in ASCII code will be converted to six binary bits by F19. The message length cannot exceed 72 characters, and the time required to input cannot exceed 2 minutes. Violations of either limit will cause the input message to be aborted and an error output message to be printed on the TTY.

The Paper Tape Control Module (F28) enables the paper tape to be read by the computer via a paper tape reader. It receives control when a maintenance man at a TTY types in the required ACTION CODE, or when an application program wants to read tape. The maintenance man placing the paper tape on the reader and typing in the proper ACTION CODE initiates the reading of the paper tape data into the system.

The data read into the DPU is placed into a 100 word work area. Input from either of the paper tape readers is limited to 70 words per request.

The inputted tape may be completely in ASCII code or it may only contain an ASCII code leader followed by binary data (core image).

Note: the first example is known as "ASCII paper tape" and the second is called "binary paper tape."

An application program or a maintenance program wishing to initiate a paper tape message output calls F26X01. The I/O Scheduler places the output request on the HSPTP queue (Table EX2). When the hardware necessary to service the request is available, the I/O Handler turns-on the device motor, allows the motor to reach operating speed, and initiates the paper tape output. Each paper tape punch output (high or low speed) is limited to 512 characters. Character packing, code conversion, parity checking, and other miscellaneous functions are performed by subroutine modules used by F27.

The magnetic tape transport (MTT) operations are scheduled by the Magnetic Tape Schedule Module (F73). The magnetic tape transports (the MTT is duplexed) are controlled and operated by the Magnetic Tape Handler Module (F74). See FIG. 68 for a magnetic tape software diagram.

The F73 scheduler module places the MTT access requests into an MTT queue according to priority via the Link to Queue Module, (F02) and the ACCEPT (E01X01) entry line of the DPU Scheduler. When F74 is entered at F74X01, these requests are removed from the queue and are processed by the Ticketing Magnetic Tape Unit (TMU). The MTT, its associated peripheral adapter, and the necessary read/write electronics comprise the TMU. This is a dual channel configuration used for ticketing purposes.

The Ticketing Output Format Module (T04) calls the Magnetic Tape Scheduler via F73X01 when the core resident Call Record Buffer Table is filled (when it contains a maximum of 15 call records). The Magnetic Tape Scheduler accepts the magnetic tape output request and schedules a call record data block which is formatted and transferred to tape by the Magnetic Tape Handler. If errors are encountered, ACCEPT is called to schedule an error routine and control is either passed to TIME or returned to the requester of F73.

Entry line F73X02 is called by the Magnetic Tape Label Routine (F75) in order to write a header label on tape. F73X03 is used to place a particular channel (A or B) of the ticketing subsystem on-line or off-line.

The F74X01 entry line of the Magnetic Tape Handler is the normal entry from the Magnetic Tape Scheduler. This program removes the requests from the MTT queue and initiates the tape output.

The F74A01 subroutine is used by F74 to output four data words on magnetic tape. F74T01 is a subroutine used by F74 as a 32 millisecond timer. DIACON and CONFIG are used by the Magnetic Tape Handler to schedule maintenance programs and to reconfigure the ticketing system hardware, respectively. DIACON schedules ticketing device buffer (TDB) localization routines and CONFIG is used to place the appropriate TDB maintenance-out-of-service (MOS).

The Ticketing Scanner Unit (ITSU) Handler Program (F72) permits the ticketing operations to be accomplished (FIG. 69). The Ticketing Scan Interrupt Module (T03), at 600 ms. intervals, calls F72 to enable the TSU to successfully interrogate all incoming trunks and OJ's. The busy/idle condition of local lines and trunks as well as the duration holding time of the trunk circuits is passed by F72 to the calling programs for analysis.

The requests for ticketing scanner unit operation from the TSU Handler's calling programs do not have to be scheduled by a scheduler program because of the high speed of TSU operations which permits a TSU to be effectively accessed on a continuous basis. F72 functions as an I/O program for ticketing and maintenance programs, enabling them to store information within the ticketing device buffer (TDB) and to interrogate and control the TSU.

Entry line F72X01 is always entered as a closed subroutine. In the event of a TSU fault condition, F72 schedules a fault localization routine (via DIACON) to attempt to rectify the condition. CONFIG is used to reconfigure a TDB/TSU channel to its alternate TDB/TSU channel.

The TSU Handler uses module L26 to count TSU errors in a given length of time. Thus, the error rate can be used to indicate a faulty TSU.

SIMPLIFIED OPERATION OF THE EXECUTIVE DURING A LOCAL-TO-LOCAL CALL

The simplified block diagram shown in FIG. 36 illustrates a local-to-local call including the executive and call processing program modules that are involved. Some of the basic modules that are required for this operation, such as the LINK or UNLINK from queue modules, are not shown.

The following definitions apply to FIG. 70:

Cfsv call For Service Voltage

Cht call History Table

Cos class of Service

Ccr computer Communication Register

Icap interrupt Cause Analysis Program

Om originating Marker

Dpu data Processor Unit

Rj register Junctor

Rs register-Sender

Rft request For Translation

Tm terminating Marker

When the originating marker (OM) senses a call for service voltage (CFSV) caused by the customer going off-hook, the OM sends a two word data frame to the computer communication register (CCR). This data frame contains the originating junctor identity, the customer's equipment identity, and the line matrix outlet identity. An interrupt is sent to the data processor unit (DPU) by the CCR which causes ICAP to pass control to the CCR Ready Interrupt Handler (F32). F32 analyzes and processes the data and then requests F33 to perform a register junctor (RJ) translation.

The F33 module translates the R-matrix outlet identity into a register junctor identity. The data frame is then stored in the call history table (CHT) in main memory (addressed by the register junctor time slot). The register-sender memory is updated to record the call origination in order for the register-sender (RS) to take over control of the originating path and allow the originating marker to drop control.

After the register junctor translation has been performed, F32 schedules a class-of-service (COS) translation to be performed by call processing module C/1. This translation consists of retrieving from drum, via Data Manipulator Module F35, the unique characteristics of the customer, which are recorded with his line equipment number identity. F35 schedules C/2 via the DPU Scheduler. C/2 then analyzes the COS information (e.g., billing information, type of receiver required, total number of digits required before requesting a translation, etc.). Part of the COS data is placed in the Call History Table in main memory and part is stored in register-sender memory. The data placed in register-sender memory is used to control the receipt and analysis of the dialed digits and to supervise the network via the register junctor.

The register-sender returns dial tone to the calling line and prepares to receive digits. The RS collects the first three digits and then program control is passed from the Call Processing Program to the Executive Program by a request-for-translation (RFT) from the RS. The RFT signal causes control to be transferred to F51, the Register-Sender Interrupt Processor. When F51 is completed, control is passed back to the Call Processing Program (module C06) for the three digit translation analysis. This is done to determine the type of call being analyzed, and is accomplished by accessing the three digit translation table on the drum.

As a result of the three digit analysis, call processing module C08 is scheduled and seven digits are accumulated in register-sender memory before another translation is requested. After collecting seven digits, the register-sender again generates a request-for-translation (RFT). The Register-Sender Interrupt Processor Module (F51) initiates a read-out from register-sender memory, stores the read-out in computer main memory, and then schedules Call Processing Program C06 to perform the seven digit translation.

Since this is a final translation, the Call Processing Program requests a directory number translation. This initiates a request to the F35 module for a drum look-up of the local director number table which provides the line equipment number of the called line, the proper ringing code, and any special called line features.

The Call Processing Program analyzes the data retrieved from the drum and obtains the originating line matrix identity, which defines the selector matrix inlet. The data needed to instruct the terminating marker to establish a path from the selector matrix inlet to the called local line, together with other control data, is loaded into four 26-bit words to be sent serially by the computer communication register to an idle terminating marker. This data transfer is scheduled by the CCR Scheduler (F31) and processed by the CCR Handler (F32A).

The terminating marker sets up the terminating condition and upon successful completion, communicates this result to the CCR. The CCR sends a ready interrupt to the central processor which is processed by E24 and the CCR Ready Interrupt Handler (F32B). The RS, upon instruction that the termination operation was successful, performs its terminating phase functions. Call processing module C26 returns the call history address to idle, and a cut-through and register junctor disconnect is initiated. Program control is then returned to the Executive Program for scheduling of the next task in the system via TIME (E01X04).

COMMON MAINTENANCE PROGRAM DESCRIPTION

1. general

1.01 this section describes the Common Maintenance Program portion of the Field Program for the No. 1 EAX System, which, together with the Executive Program, controls the system and subsystem maintenance functions.

1.02 The purposes of this section are:

1. To identify the generic programs and tables that make up the Common Maintenance Program.

2. To describe the major functions of these tables and programs.

2. FUNCTIONAL DESCRIPTION

2.01 the No. 1 EAX Maintenance Software is composed of the Common Maintenance Program modules and tables and the many Subsystem Diagnostic Programs. Together, they comprise well over 50% of all the software contained in the No. 1 EAX software system.

2.02 The Common Maintenance Program contains program modules, routines, and tables utilized by all maintenance programs. It provides system checks and centralized control over the maintenance programs.

2.03 The Common Maintenance Modules provide an interface between the Executive Program and the diagnostic maintenance programs which are associated with the No. 1 EAX subsystems (e.g., register-sender, drum memory system, etc.). These modules provide common functions used by almost all of the diagnostic programs.

2.04 The major functions of the Common Maintenance Program are as follows:

a. Scheduling of subsystem diagnostics.

b. Reconfiguring the system or subsystem.

c. Performing software audits.

d. Monitoring subsystem power conditions.

e. Providing central control of error counters.

f. Providing software control over lamp displays.

2.05 The Common Maintenance modules interface with each other and with the subsystem maintenance programs via the Executive Program and the Diagnostic Control Module (DIACON). Maintenance programs are scheduled by calling DIACON. Programs scheduled by DIACON are processed before all other programs because they are more important to the overall operation of the system. Accessing DIACON is faster than using the executive's DPU Scheduler, because the requesting program does not have to first obtain a work area in which to schedule the appropriate DIACON module.

2.06 The subsystem diagnostic program modules allow the No. 1 EAX hardware to operate in the presence of faults and errors. These modules provide the following functions:

a. Malfunction detection.

b. Fault isolation (of a faulty unit).

c. Malfunction recovery and restart (after disturbances due to diagnostic testing or repairs).

d. Fault localization (to a location within a few printed wiring cards).

e. Repair verification (checking a "repaired" unit before placing it in service).

f. Routining (testing the capability of a subsystem or unit to perform certain tasks).

2.07 The hardware subsystems of the No. 1 EAX are monitored to detect any malfunctions that occur. The subsystem maintenance software permits the hardware to function in spite of these malfunctions. Diagnostic programs discussed in this practice apply to the following hardware:

a. The Processor Configuration Group (PCG),

b. The Register-Sender,

c. The Markers and Network,

d. The Drum Memory System, and

e. The I/O Peripheral Apparatus.

3. MAINTENANCE PHILOSOPHY AND GOALS

3.01 the maintenance software, as well as the maintenance hardware, has been designed to ensure a high degree of reliability. Faulty equipment can be readily isolated by automatic fault detection features.

3.02 The general objectives of the No. 1 EAX maintenance design are as follows:

a. Reliability - obtained by the use of conservative circuit designs (adequate circuit margins) and long life components (transistors, integrated circuits, etc.).

b. Continued service during unit failures and routine preventive maintenance - provided by the use of redundant or duplexed units.

c. Rapid detection of faults - accomplished by continuous hardware and software checks.

Saving of message data while testing and configuring the system around faulty units - accomplished by fault recognition programs. These programs permit recovery of the call processing function and protection of calls in progress during hardware, software, or procedural (human intervention) difficulties.

e. Distinguishing between occasional errors and marginal/intermittent faults - accomplished by the use of error analysis programs.

f. Isolation of faults to the appropriate plug-in cards - performed automatically by diagnostic programs.

g. Rapid detection of faults and marginal troubles - provided by in-service checks of customer's lines.

3.03 Every hardware subsystem required to maintain service is provided in duplicate. This redundancy is provided primarily for dependability rather than to increase the traffic handling capacity of the system. In addition, faults must be found and corrected quickly to minimize the occurrence of system failure due to multiple faults. For this reason, all units are constantly monitored; and automatic detection of malfunctions and automatic switching of units provides system reliability.

3.04 When a malfunction is detected in the system, call processing is temporarily interrupted by a fault recognition program. This program determines the faulty redundant unit and removes it from service. It then requests the appropriate diagnostic program to be run at a later time and returns control to the Call Processing Program. This operation is performed so quickly that degredation of service is not detected by telephone customers.

3.05 Fault detection, isolation, and recovery programs are handled quickly because call processing is inhibited during their execution. All other programs are deferrable and are normally run intermixed with the call processing programs.

3.06 After the fault recovery programs remove the faulty unit from service, the localization programs will determine what set of printed wiring cards (five or less) associated with the faulty unit should be replaced to correct the problem. The maintenance man will replace the specified cards and a repair verification program will be executed which will insure that the unit is now operating properly. The fault recovery software will then return the repaired unit to an in-service condition.

3.07 System malfunctions can be caused by faults or they may be instigated by transient errors. In many cases, rather than interrupt program operation, the failed operation is repeated to see if the same malfunction condition will occur again. If it is determined that an error condition existed and the error did not recur on the retry, a counter is incremented. The counter is set to a predetermined count within certain time periods for each occurrence.

3.08 Maintenance functions fall into two general categories, automatically initiated and manually initiated. The following are automatically initiated functions:

a. Detection of malfunction performed by the hardware.

b. Isolation of fault - determine which of a pair of redundant units is faulty and it will separate or isolate the faulty unit from the rest of the system by a reconfiguration program. (The good unit will remain in service).

c. Fault localization - narrows down location of the fault to a section of the malfunctioning unit, indicates the few circuit boards that could cause the fault, and initiates a maintenance TTY trouble report to inform a maintenance man.

d. Repair verification - checking out a unit or section of a unit to verify that it is functioning properly before returning it to service.

e. Auditing - verifying the validity of the software, i.e., queue contents, table contents, etc.

f. Unit Clear and Start - clearing a unit and placing it in a predefined or initial state and then placing it in service. The clear function may be performed alone without being followed by the start function. A memory update may be required so that both memories agree before placing a unit in service.

3.09 The manually initiated maintenance functions are:

a. Reconfiguration - changing the status or configuration of the hardware unit(s). The Configuration Control Program (CONFIG) performs these functions.

b. Routining - exercising a unit or portion of a unit to see if it is functioning properly.

c. Auditing - verifying the validity of software status (same as paragraph 3.08 e).

d. Repair Verification - initiated by the maintenance man after a unit has been repaired. Its function is to see whether the repaired unit is operating properly. If it is, control will automatically be passed to the Unit Clear and Start Program.

e. Unit Clear and Start - initiated by the maintenance man. This procedure bypasses repair verification and performs the clear and start functions described in Paragraph 308, f.

4. MAJOR COMMON MAINTENANCE PROGRAMS

4.01 the common maintenance software is composed of program modules and tables which are stored in core memory and in the drum memory systems. This software provides functions that are ncessary to the subsystem diagnostic programs but not peculiar to any specific one. The major common maintenance functions are listed in Paragraph 2.04.

Diacon

4.02 the Executive Program allows the common maintenance program DIACON, the Diagnostic Control Program, to receive control without the need to first obtain a work area; a necessary requirement for all other programs in the system. This feature permits a maintenance program requesting to be run to be initiated before the other program requests in the associated central processor priority queue. This feature is accomplished by using a bit called DIAFLG located at the front of the CPU's priority zero queue. The DIACON Request module (L20A) will set this bit.

Note: there are eight DIAFLG bits, one for each interrupt priority level. Only three DIAFLG priority levels are assigned at this time. Priority level 0 is for DIACON, level 1 is for the TTY Use Request Interrupt Processor (F58), and level 3 if for CONFIG (the Configuration Control Program).

4.03 There are six major tables used by DIACON. These tables are listed below:

a. DIAJOB - called the "HDJ" table, it indicates the DIACON jobs to be done and the applicable unit involved. It consists of two tables, 10 words each, containing one bit for each unit to be diagnosed, in four categories (isolation, clear and start, diagnostics, and audits). DIACON will not schedule any programs that are not listed in DIAJOB. An example of one of the 10 word DIAJOB tables is shown in Table MP3. See Table MP1 for a glossary of the terms found in Table MP3.

b. DIAVEC - called the "HDV" table, it is used as a pointer to locations in the HDD table (DIADAT) for data storage. DIAVEC also indicated valid jobs, contains data lengths, and contains identities of immediate special programs (Timed Routine Scheduler - TRS, Power Monitor Scan - PMSCAN, Work Area Audit - WARAUD, and the Configuration Pushbutton Handler - CNFPBH).

c. DIADAT - called the "HDD" table, it is used to store any necessary data to be passed from the requester to the requested program. This data will remain in DIADAT until the requested program is scheduled.

d. DIATAB - called the "HDT" table, it is a block of core used by the DIACON client. However, it is not a work area and cannot be used for linkage to queues.

e. DIACTL - called the "LDC" table, it is DIACON's control table; containing the identity of the program to be scheduled, the required size work area, and necessary system configuration data.

f. DIALOC - called the "LDL" table, it is used by DIACON to locate the proper entry in DIACTL for a given job. It lists the number of tests, if any, for a specific job and identifies audit clients (see Table MP4).

4.04 the DIACON Request Module (DIAROT) can be entered at either of two entry lines (see FIG. 37). Upon entry, DIARQT (L20A) uses L12A to save the contents of the required registers (RQ, X1, X2, and the four pseudo registers in core), and uses L12B to restore them before exiting. The L20A module forms the job number, checks the range of the job type (0-7), and checks the validity of the job against validity data in the HDV table. DIARQT sets the appropriate bit in the first DIAJOB table, sets the level 0 DIAFLG, and exits to the Executive Program's TIME Module.

4.05 The DIAFLG Handler Module (L21A) provides an interface between the CPU queue scanning module of the executive (TIME) and DIACON (FIG. 38). There are three levels (out of eight) used at present that L21A is concerned with. (They are listed in the note preceding Paragraph 4.03.) The level that is applicable to this Practice is level 0. L21A checks the priority of the requested program and, if a number greater than seven is detected, a return is made to TIME. If a number equal to or less than seven is detected, control is passed to the appropriate program. For this discussion, it is assumed that level 0 was set; therefore, an exit is made to L21C.

4.06 the DIAJOB Interrogator module (L21C) is entered at L21X06. L21C sets up loop counters to permit a search of all four sections of the DIAJOB table for a bit set high, representing a "job to do" (isolation, clear and start, diagnostic, or audit). If a job is found, L23C will determine if it can be processed. DIACON jobs are referred to as "specials" or "immediate specials." The immediate specials (see Paragraph 4.03 (b)) are scheduled by the Drum DIACON Module (L23) which must first be scheduled by L21C. A work area is obtained, for the scheduing of specials, by calling the Work Area Getter Module - L01X02 (a CONFIG module). If a work area is available, Drum DIACON or an immediate special is scheduled, via ACCEPT, L21C then exits to TIME.

4.07 if no work areas are available, DIACON returns control to the DPU Scheduler's TIME module to permit processing of other programs waiting in the priority queques, and sets level zero DIAFLG again. The queues are schanned by TIME, and when TIME recognizes that DIAFLG is set, DIACON will reattempt to schedule the program.

4.08 Drum DIACON is entered at L23X01 for scheduling of special jobs. This entry lines of L23 is to the Client Scheduler (L23A). It will check DIAJOB to see if the client (the program to be scheduled) is an audit program. If it is, L23A will use the Audit Scheduler (L23B) to schedule the program (via ACCEPT). L23A will obtain the identity of a special program to be scheduled, obtain a work area of the proper size, and schedule the client (via ACCEPT). Data required by the client is transferred from the HDD table to the HDT table. Drum DIACON will then set up to search DIAJOB for more jobs. If a job is found, lever 0 DIAFLG is set and L23A will release NRA and pass control to the executive.

Config

4.09 the Configuration Control Program (CONFIG) is composed of several modules that provide centralized control over system status and configuration changes: config maintains a record of current system status in the System Status Table (HST). The HST table can be modified only by CONFIG and the Power Monitor Scan Program (PMSCAN), although its data may be read by any requesting program. Table MP6 contains the data located in the first 15 words of this table.

4.10 The CONFIG program has five tables associated with it. They are as follows:

a. HST - the System Status Table, reflects the current system configuration.

b. HCC - the CONFIG Control Table, equates requests to L01 entries.

c. LCC - the CONFIG TTY Input Control Table, equates reconfiguration requests to CONFIG entries.

d. HPD - the Constant Parameter Table - it is a table of Command Pulse Directives (CPD's).

e. HTT - the Reconfiguration Coded Message Buffer Table - contains system status updates used by V05.

4.11 config receives requests for configuration changes and determines if the changes can be made without jeopardizing system integrity, by checking the HST Table. It performs allowable configuration changes or calls the necessary programs to make these changes and then updates the HST table to reflect the change.

4.12 The System Status Table provides a means of conveying hardware availability and status information to requesting programs. It contains informaton that indicates the status of all hardware subsystems and devices in the No. 1 EAX (except the space divided equipment such as lines, trunks, etc.). The HST table is modified by CONFIG whenever a change is made to system configuration, or by PMSCAN whenever power is removed or restored to a unitl

4.13 Whenever CONFIG receives a configuration request, it checks the HST table to insure that granting the request will not adversely affect the system. If both units of a pair have to be placed temporarily "maintenance-out-of-service" (MOS), CONFIG will be called. Normally, CONFIG attempts to keep one unit of a pair in service, but there are instances when both units must be placed into this MOS condition. This configuration is only allowed for a predetermined amount of time.

4.14 If the requested change is determined to be allowable, it will be made by CONFIG or a submodule called by CONFIG and the HST will be updated to reflect the change. At this time, maintenance personnel will be alerted, if necessary, by calling a program which will set an alarm and/or generate a TTY output message.

4.15 When a hardware status change is made, CONFIG will verify that the change was actually made as requested. If the verification fails, CONFIG will pass any information pertaining to the reason the change was not made, to the requester.

4.16 CONFIG's L01 module uses six major entry lines to provide centralized control of system configuration. These entry lines are as follows:

a. L01X01 (FIG. 39) - Accessed by the SYSCLR Program and whenever a third party trap fault recovery is taking place. This module entry is used to update the RS/CCP and CCP/CCX interfaces. It also updates the System Table from the sense line status (so that the software status will reflect the hardware status). A TTY message will be outputted for every configuraion change.

b. L01Xo2 (FIG. 40) - Called by DIACON, THE TTY Use Request zinterrupt Processor (F58), or L01X03 to obtain a work area. It uses L12A and 12B to save/restore the central processor's X1, X2, and Q registers and the core memory's four pseudo registers. L01X02, the "Work Area Getter", calls the executive's Work Area Spare Module (F04X01) to remove the requested work area from the applicable queue.

c. L01X03 (FIG. 41) - Used to obtain a work area of the requested size and then schedule a TTY printout. This module calls L01X02 to obtain a work area and then places it in the proper CPU queue so that the Power Failure Printout Program (V05) can use it for its processing.

d. L01X04 (FIG. 42) - Used to control non-scheduled routines. The input parameters needed by this module are the unit number and the identity of the requested routine. L01X04 accesses the HCC table (see Table MP7) to obtain the CONFIG control word that contains the data associated with the requested routine. Module L01X04 can schedule the following routines:

1. PCG Off-line Request (L01B01).

2. ctp off-line Request (L01B02).

3. place CTP In-service (L01B03).

4. set the RES and TTY Bits in HST (L01B04). 5. Reset the RES and TTY Bits in HST (L01B05). 6. CCX/CCP Interface Update (L01B10). 7. CCX/MOS Request (L01B11). 8. Place CCX In-service (L01B12). 9. Set CCX A or CCX B Active (L01B13). 10. Set CCX A or CCX B Temporarily Active (L01B14). 11. Reset Temporary Condition of L01B14 (L01B15).

e. L01X06 (FIG. 43) - Used at the occurrence of a level 1 interrupt, to compare the CCP/CTP on-line hardware status with the MOS status located in the HST table. If they do not compare, a CCP/CTP configuration change must have taken place. If a change occurred, a TTY output will be initiated. L01A10 will add the message to the list (TTY output queue) and will use L03X03 to set level 3 DIAFLG (CONFIG). This will cause DIACON's DIAFLG Handler Module to pass control to CONFIG's L01X03 module. L01X03 obtains a work area (via L01X02) and schedules the power Failure Printout Program (V05X01), via ACCEPT. If, during the processing of L01X06 it is found that both CCP's are off-line and the CTP is on line, an exit will be made to System Clear and Start (L16X02). An exit is also made to L16X02 if both CCP's are on-line and the CTP is off-line.

4.17 The Marker Configuration Control Module (L02) is a closed subroutine used by programs desiring marker configuration changes. L02 places the required parameters (from the requestor) into a work area and the CCR Handler (an executive program) takes over control, using this work area, and performs the change.

4.18 L03 is the CONFIG Subroutines Module. This module is only called by other CONFIG modules. It is used to perform a variety of functions; e.g., Save Registers (different than other "save register" routines; saves X1, X2, Q, A, and the No. 1 and No. 2 pseudo registers), Restore Registers (same registers listed above), TTY Message Lister (adds messages to a TTY output list and sets level 3 DIAFLG, which initiates action by L01X03 to schedule the Power Failure Printed Program - V05).

4.19 the Ticketing Changeover Module (L04) is used when ticketing error interrupts occur (TDB, TSU, or TMU errors). This module permits reconfiguration of the duplexed ticketing hardware and localization and repair-verification of the cause of the interrupt.

4.20 CONFIG's L05 module is accessed by the Maintenance Input Analysis Program (MAININ-L32) when a TTY removal or restoral request occurs. L05's purpose is to either pass control to a special handler program for special handling functions, or to the CONFIG Control Module (L01X04 to perform the reconfiguration). The special handlers are a part of L05 and are accessed as subroutines (L05A02, L05A03, etc.).

4.21 The Routining Message Handler Module is called by L03X03 when a remove or restore message is generated by routining programs as opposed to being initiated by a TTY request from the MCC. The L06 module will always return control to L03X03. L03 will restore the registers (via L12B) and return control to the routining program.

4.22 There are four major categories of configuration change requests:

a. Power failure.

b. MCC configuration pushbutton requests.

c. TTY input requests.

d. Program requests.

4.23 Power Failure. A power failure causes a power alarm indication and initiates a level 1 interrupt (highest priority). This causes the Executive Program 's E21 module (ICAP) to call the Power Alarm Interrupt Processor (V04). In order to insure that all power alarm conditions are reported to the computer, a periodic scan of the data lines (a power monitor scan) is initiated, via DIACON, as a result of the occurrence of the first power alarm interrupt. This scan will continue, by the Power Monitor Scan Program (PMSCAN), until all power alarm circuits provide normal indications.

4.24 If a subsystem has gone to a power down condition, the following events occur:

a. CONFIG is informed that the unit has no power and it will place the unit "out-of-service"(OS) in the HST.

b. The MANIAC Program's HJI Table will have a bit set to indicate "just ignore" all interrupts.

c. The I/O Handler Program associated with the unit or device that had the power failure is informed of the power down condition so that it may perform any necessary operations required.

d. A message is outputted via the TTY to indicate a power failure for a specified unit.

4.25 If a subsystem has gone to a power up status, the following events occur:

a. CONFIG is informed that the unit is no longer OS, but is still MOS. CONFIG will indicate this status in HST.

b. A TTY output message will indicate that power is restored to the unit.

4.26 If any subsystem is in a power down condition after the Power Monitor Scan Program has run, PMSCAN will pass control to the Interval Timer Request Acceptor Program (E02). E02 will run PMSCAN at 1 second intervals. When all subsystems have power up. PMSCAN will go to RELEAS (E01X03) which relinquishes control to TIME. PMSCAN will be called again when the next power interrupt occurs.

4.27 MCC Requests. CONFIG is called whenever any of the MCC configuration pushbuttons are depressed. This CONFIG request is passed via the Configuration Pushbutton Handler Program (CNFPBH-V63). By the use of this module, the maintenance personnel has the capability of requesting configuration changes to any of the subsystems. These configuration requests via the MCC configuration pushbuttons generate level 1 interrupts as do the subsystem power failures. (CNFPBH is a common maintenance program.)

4.28 Maintenance personnel have the capability of overriding configuration requests from the MCC Configuration Panel. For example, a typical maintenance request may be: "Place one drum memory system (DMS) of a pair MOS (e.g., DMS1)." By depressing the pushbutton of the other DMS of the pair (DMS2), the original request is overridden. DMS1 is placed in service and DMS2 is placed MOS.

4.29 to place the unit back into service, the MCC pushbutton must be reset. The Configuration Pushbutton Handler Program will schedule, via DIACON, a repair verify program on the unit. This operation is treated in the same way as a normal TTY restore request except that the "MCC bit" is reset. The MCC bit is located in the Last Look table (HCL) which is maintained by CNFPBH to determine changes in status (see TAble MP7).

4.30 tty input Requests. A TTY input request for a configuration change also initiates a level 1 interrupt. Maintenance personnel can initiate a TTY input request at the MCC on either the office or maintenance teletypewriters.

4.31 When a TTY interrupt occurs, ICAP Module E21X01 is called. This module calls CONFIG Module L01X06 as a closed subroutine to check the hardware status of the CCP/CTP configuration against the MOS status in HST. To determine whether the interrupt that occurred is valid, the Maintenance Interrupt Access Program (MANIAC) is called. This program will access certain tables which will verify that the interrupt is not to be ignored, as would be the case if it were purposely generated by a diagnostic program.

4.32 Since the interrupt is valid, the appropriate interrupt processor program is called; in this case, the TTY Use Request Interrupt Processor (F58). F58 obtains a work area by using CONFIG's Work Area Getter Module (L01X02) and then schedules the Input Message Analysis Program Module (F06), via the ACCEPT entry line of the DPU Scheduler Program.

4.33 The Input Mesage Analysis Module examines the input message to determine the requested task and its data. F06 converts the inputted ASCII code to internal code (binary) and will schedule the Maintenance Input Message Analysis Program (MAININ - L32) via ACCEPT. MAININ changes the internal code data into parameters that CONFIG or DIACON can use and then schedules CONFIG module L05X01 via ACCEPT. The parameters received by L05X01 are the action code, unit type, request code, and the unit number. L05 will perform the request configuration by accessing any other CONFIG modules that may be needed to accomplish the task.

4.34 The units that can be removed from service by a TTY request are as follows:

a. Computer communication register (CCR)

b. Computer channel multiplex (CCX)

c. Maintenance device buffer (MDB)

d. Channel device buffer (CDB)

e. Ticketing device buffer (TDB)

f. Drum memory system (DMS)

g. Originating marker (OM)

h. Terminating marker (TM)

i. All peripheral adapters (PA's) for (d), (e), and (f)

j. Processor control group (PCG)

k. Computer third party (CTP)

l. Register-sender (RS)

m. Register junctor (RJ) group

n. Dual tone multifrequency (DTMF) receiver

o. Multifrequency (MF) receiver

p. Multifrequency (MF) sender

4.35 For removal requests, MAININ routes the request to CONFIG. For restoral requests, MAININ routes the request through DIACON to either a repair verify or a unit clear and start program. Normally a repair verify program will be scheduled by DIACON to determine if the unit to be placed into service is working properly. If verification passes, a unit clear and start "resync" module is called to place the unit in service. Maintenance personnel also have the option to request that verification be omitted; and if this occurs, DIACON will only schedule a unit clear and start program.

4.36 Program Requests. Program requests for configuration (status) changes are also handled by CONFIG. All units listed in Paragraph 4.34 can be requested by programs for configuration changes, although, CONFIG may deny the request for various reasons.

4.37 When CONFIG receives a request, it usually performs certain checks upon the data received as a result of the request. For example, if a request is made to place a PCG into a maintenance out-of-service status (MOS), CONFIG will check the other PCG and its associated half of the computer channel multiplex (CCX) to see if either is MOS. If either or both are MOS, the request will not be honored. If they are not MOS, CONFIG will take the PCG off-line with a command pulse directive instruction (CPD). The off-line condition of the PCG will be verified by checking the appropriate sense line, and the MOS status of the PCG will be written into the MOS bit of HST. CONFIG configures the RS/CCP and CCX/CCP interfaces around the on-line PCG and returns control to the requesting program at the configuration request address plus one.

4.38 CONFIG verifies hardware configuration changes, as was described in the preceding paragraph, where the MOS status of the PCG that was taken off-line was checked. If verification did not pass, CONFIG would have returned an error parameter to the requesting program. An exception to the hardware verification checks is made for some of the requests to the register-sender multiplex; such as, "configure the RS multiplex according to the CLU MOS states," or "set maintenance busy bit associated with the specified RJ." No verification is made on these requests because of hardware delays and the lack of indicators to monitor.

Maniac

4.39 the Maintenance Interrupt Access Program (MANIAC) provides another common maintenance function - centralized control over special processing of interrupts. MANIAC (L00) allows the system to operate normally without being affected by interrupts generated by maintenance programs.

4.40 MANIAC accepts requests for special handling of interrupts from maintenance programs that desire to have certain interrupts handled in other than the normal manner. The requester must indicate how it wants the interrupts handled, e.g., "just ignore," "reset and ignore," etc.

4.41 MANIAC accesses several tables to identify the sense lines associated with all interrupts. When an interrupt occurs, the Interrupt Cause and Analysis Program (ICAP) will be entered. ICAP "takes a snapshot" of the state of the sense lines associated with the interrupt level that occurred and will store this data in a specific area of core memory. A Hot Sense Line Finder Program (E20) is used by ICAP to find the particular interrupt sense line that is "hot." ICAP will access the MANIAC Program and will pass the number of hot sense lines found to it. MANIAC accesses its tables and returns the following information to ICAP:

a. An indication of whether or not any maniac or non-abnormal routing has been requested on this sense line.

b. The maniac routing can be any one of the following:

1. The interrupt is to be ignored without resetting the source (the interrupt sense line).

2. The interrupt is to be ignored and its source is to be reset.

3. The interrupt is to be routed other than normally (rerouted).

4.42 If the interrupt is to be rerouted, two additional words of data will be passed to the appropriate interrupt handler program. These two words contain the identity of the program to be run, the priority of the program, and the sense line number.

4.43 The MANIAC Program (L00) accesses three tables in the core main memory (CMM). These tables are:

a. HJI - requests in this table will be interpreted by the interrupt handler to cause the interrupt to be ignored without resetting the source (interrupt sense line).

b. HJJ - the requests in this table will be interpreted by the interrupt handler to cause the interrupt to be ignored and the source reset.

c. HRR - requests in this table will be interpreted by the interrupt handler to cause the interrupt to receive "special handling." The details of the special handling defined by the individual interrupt handlers. Each request in this table is two words in length. 4.44 The HJI and HJJ tables each contain one bit per interrupt sense line. An HRR table entry is two words in length and contains the following information:

a. Assigned sense line number.

b. RJ number, if required (determined by sense line and handler program).

c. Control bits used by the interrupt handler.

d. Entry line address of next program.

e. Priority at which next program is to be scheduled.

f. A bit (SOB) that indicates whether the next program is to be scheduled, or branched to directly.

4.45 There are three macros used by client programs to request any of the functions of the MANIAC Program. The requests made through the use of the macros will be passed to the appropriate interrupt handler, via ICAP, as a result of the sense line determination and a check of the maniac table data associated with the particular sense line.

4.46 The MANIAC macros are as follows:

a. MANCHK - used to access the three maniac tables and return sense line status information to the requester.

b. MANRST - used to reset appropriate indicator(s) in the maniac tables.

c. MANSET - used to set appropriate indicator(s) and store data within the maniac tables.

4.47 When a power-off condition is detected on a unit, all interrupt sense lines associated with that unit will be set to just-ignore (via MANIAC) by PMSCAN. Whenever a unit is placed in a hardware off-line state by CONFIG, all interrupt sense lines associated with this unit will be set to just-ignore (via MANIAC) by CONFIG.

4.48 when an isolation program is scheduled by an interrupt handler (via DIACON) all interrupt sense lines associated with the unit will be set to just ignore. This action is instigated by the interrupt handler, via MANIAC.

4.49 when localization is scheduled on a unit, all interrupt sense lines associated with that unit will be set to just-ignore by the program scheduling the localization. When diagnostic programs (see NOTE below) are run, they must consider the status of maniac functions associated with a particular unit. This means presetting the status of the interrupt sense lines, associated with the unit being diagnosed, to a desired state.

Note: diagnostic programs: all localization, repair verification, routining, unit clear and start, and scheduled isolation programs.

4.50 Localization and repair verification programs will leave the unit either in a "hardware off-line" or a "back in service" condition. For hardware off-line, the unit is marked MOS in the HST table and the specific interrupt sense line bit in the HJI table is set to just-ignore. If the unit is placed back in service, the MOS bit in HST and the interrupt sense line bit will be reset. CONFIG then removes all MANIAC requests on the interrupt sense lines associated with the unit.

4.51 There is also a Unit MANIAC Program (L50) that is a supplement to the previously described MANIAC Program (L00). The Unit MANIAC accomplishes maniac functions on specific units. L50 performs validity checks on the unit type and unit number data. The identity of the sense lines to be operated on is obtained from two control tables, the Sense Line Identity Table (HID) and the Type Vector Table (HTY).

4.52 the HTY table contains the address of the sense line data entry in the HID table associated with each unit type. HTY contains one word (24-bits) per unit type. The HID table contains the sense line data needed to perform the Unit MANIAC function on the specified unit type. This data consists of the total number of sense lines, the unit number, and the sense line identities to be acted on.

4.53 The HID table length is dependent on the amount of sense line numbers (SLN's) associated with the system hardware. The table length is determined by the formula: words required = [N+1)/2 ]+ 1. N equals the total number of SLN's. There are two SLN's per word entry (12 bits for each SLN). Word zero of HID is not used.

4.54 If a request is made to set, all sense lines associated with that unit will be set to just-ignore. If a reset request is made, all maniac requests on the sense lines are removed. After the request has been processed, a return will be made to the requesting program. When unit MANIAC is run, the contents of all registers, including the pseudo registers, will be destroyed. L50 always runs with the interrupt system disabled to prevent interruption before the request is performed. Interrupts are enabled before a return is made to the caller.

4.55 MANIAC (L00) calls Unit MANIAC (L50) to perform maniac functions on all interrupt sense lines associated with a particular unit. This interface is accomplished by two macros:

a. SETMAN - used to set the just-ignore indicator bits for all interrupt sense lines associated with a particular unit.

b. RSTMAN - used to reset all indicators set by SETMAN.

SYSCLR

4.56 the System Clear and Start Program (SYSCLR) is a common maintenance program that provides centralized control over initializing or re-initializing the system and various units within the system. The SYSCLR Program (modules L13, L15 and L16) is used initially (at cutover) to place the system into operation. It is also used to re-initialize the system on demand, and to recover the system (or portion thereof) from certain malfunctions and then return it to normal processing.

4.57 The three major reasons for entry into the System Clear and Start Program are as follows:

a. Software bugs, e.g.:

1. A program is in control of the NRA too long.

2. A work area is attached to an incorrect queue.

3. A level two trap occurs.

4. An invalid condition is discovered in the HST table.

b. Catastrophic system malfunctions such as power failures, hardware time-outs, etc.

c. Failures from which no other recovery methods exist.

4.58 The following are requirements of SYSCLR:

a. Start a new system at cutover.

b. Recover the system from any state, if an operable configuration exists.

c. Restore a maximum configuration of operable hardware.

d. Clear and place on-line simplex system configurations until an operable one is found.

e. Establish a duplex configuration (if possible) once an operable simplex configuration is found, by running diagnostics on the off-line hardware and restoring the hardware to service if the diagnostics pass.

f. Recognize when restoration of a duplex system is not possible, therefore leaving a simplex configuration.

g. Find an operable configuration quickly, as normal processing is inhibited until one is available.

h. Read in a fresh copy of core memory from drum, except for hardware switch protected ROM, and initialize writable core areas (junk storage, work areas, etc.).

i. Return gracefully (gradually) to normal processing so that an immediate work area shortage does not occur.

j. Return control to the software system with the system status table reflecting the hardware status of the system.

k. Restart all system hardware.

l. To be stored partially in the switch protected read only portion of core memory.

m. Make provisions for saving some dynamic system information (e.g., trap data table, non-resident area occupant, etc.).

n. Output the data saved [item (m)], if possible.

o. Update lights on the MCC to reflect system status.

p. Initialize drum resident writable areas.

q. Clear all I/O devices to a state acceptable to the I/O programs.

r. Return reorder tone to the calling party (if possible), and when required, return coins for calls dropped.

s. Restart the system after a trap occurs, when no other return is possible.

4.59 The entries into the System Clear and Start Program are:

a. Manual entry initiated by the MCC pushbutton - hardware entry.

b. Timer timeouts - hardware entry (watchdog and off-line timers in the CTP and CCP's respectively).

c. Program controlled entry - software entry.

4.60 The three preceding entries cause the following events:

a. Both CCP's finish executing the current instruction and their timing generators stop.

b. Both CCP's are taken off-line.

c. A delay of 100 microseconds to allow the CCM to become quiescent.

d. Logic in the CCP, CTP, CLP, CMC, AND CMM is reset to an initial condition.

e. The DCU configuration request indicator is toggled for every second clear and start entry.

f. The CTP is taken off-line by a signal sent to the configuration control circuit, which leaves one CCP on-line (a different CCP each time).

g. The on-line CCP will be started at location zero of the Clear and Start Program.

4.61 To return to normal processing in an orderly manner after SYSCLR, a "throttling" mechanism is required to restrict the amount of traffic entering the system. Throttling is necessary due to the possiblity of having a large number of customers awaiting service after the clear portion of L16 is performed. (All calls during this time that did not have a talking path were dropped.

4.62 The traffic is throttled at the originating marker (OM) to control the rate at which originations can enter the system. The OM is slowed by turning it on and off for desired intervals. The system is brought up to its full capability by shortening the marker's off time until it is on continuously.

4.63 After System Clear and Start is completed, 30 words will be outputted on the maintenance teletypewriter. These words will come from the HAK table in core. The data in this table is used by the maintenance man to determine the cause of the clear and start. The program that caused the clear and start will set up all (or a portion) of the table's first 23 words. The first word of HAK contains the program identity.

4.64 The last seven words of HAK are set up by SYSCLR and contain the following information:

a. Word 23 - the first word of DIATAB (HDT table).

b. Word 24 - the second word of DIATAB.

c. Word 25 - the identity of the last program given control by the executive.

d. Word 26 - the priority of the program referred to in (c).

e. Word 27 - the non-resident area occupant, if there was one.

f. Words 28 and 29 - the real time clock (RTC).

4.65 four techniques are used to meet the SYSCLR requirements:

a. First, a software counter called the configuration counter is used to select various hardware subsystems to be placed in service.

b. Secondly, a 5 minute interval called the sanity period is initiated at the start of SYSCLR. Any new SYSCLR occurring during this period is considered to be part of the original. After five minutes has elapsed, the SYSCLR control word is reset (see Table MP8).

c. The third technique is the use of three phases. These phases eliminate the possiblity of a bad maintenance program keeping the system down:

1. Phase one - tries to restore a duplex system.

2. Phase two - attempts to restore a simplex configuration.

3. Phase three - permits manual reconfiguration via the MCC. This is a last ditch recovery method that is used when the first two phases have failed.

d. The fourth SYSCLR technique is to reroute any traps that occur during SYSCLR back to entry line L16X02 to initiate another clear and start.

4.66 For phase 1, (paragraph 4.65, C, 1) repair verification is scheduled on all hardware left off-line unless it is power down or manually overridden from the MCC. The state of the configuration counter is used to select the desired configuration. In this phase, the system will eventually be running completely in sync (except for those portions that have power down or are manually overridden). The complete system will attempt to be brought up by using the repair verification programs.

4.67 The configuration counter is a software counter located in bits 0-7 of the first word of table HAM (the SYSCLR control word, shown in FIG. 8). The eight possible states of the counter are listed in Table MP1. If the PH2 or PH3 bits are not set, the system is considered to be in phase 1 (PH1).

4.68 in phase 2 (PH2 bit set in control word), no repair verification programs are scheduled. The configuration counter will select a simplex configuration. This phase is provided so that a single fault, which is not caught by repair verification will not hamper SYSCLR operation. It is assumed that the fault is either in an "A" unit or a "B" unit and not both, and that each simplex configuration will be tried to get around the fault.

4.69 Phase 3. In phase 3 again no repair verification programs are scheduled and in addition straight A units are selected, unless designated not to be used by the MCC. SYSCLR will remain in phase 3 until the system comes up successfully and returns to phase 1 5 minutes later without having another SYSCLR within that time frame.

4.70 The following paragraphs describe the SYSCLR modules as shown in FIG. 44. The Core Resident Control portion of SYSCLR (L16S and L16V) is part of the hardware switch protected read only memory (HROM). If the emergency restart button at the MCC is depressed or if the WDT is "mishandled," the Clear and Start Bootstrap Module (L16S) will be initiated. This module is used to read in HROM from drum when the memory protect is disabled on the MCC.

4.71 the bootstrap module exists to the Software Entry and Core Resident Control Module (L16U) at entry line L16X01. A software generated clear and start causes an entry into L16U at L16X02. HROM is never refreshed when an entry is made at this point. L16U will load 23 words of the HAK table (see Paragraph 4.51) and pass control to module L16A, Central Processor Clear.

4.72 Entry at L16A01 will reset the memory protect bits in junk storage tables FJB and FJP. Control is then passed to L16B, the MCC Verify and Initialize Routine, to determine if both CCX A and MRLF A have power. This routine will also try to place one CCX (A or B) on-line active and one on-line standby (depending on which CCP is on-line active and which is standby).

4.73 L16B returns control to L16A. L16C, the Power Check Routine, will determine if the central processors are running in simplex or duplex. It does this by checking the on-line sense lines from both CCP's. L16C will also make a on the PCG's and CCX's. The results are written into the power status word in junk storage table FJB (see Table MP10). If both CCX's have power, CCX A will stay on-line. Control will then return to L16A.

4.74 the Software Protect Initialization Module (L13V) receives control from L16A. L13V is used to protect data taken from drum and read into core that was not protected on drum but must protected in core. The L13V module uses table FCS to determine the locations in core to be written into and also the length of the data block taken from drum. L13V will set the memory protect bits for data read in core. This module then exits to L13G.

4.75 the Work Area and Call History Table Initializer Module (L13G) clears all non-image areas of core (areas not duplicated on drum), and after storing various data into a work area, connects the WA to a "hitching post." The hitching post used is actually table FHP, which is used to store the relative work area address. This table will locate the applicable work area. L13W, the Non-Imaged Common Initialization Module, is used by L13G as a closed subroutine to reset memory protect bits for all data in the specified non-imaged core memory data block. L13W will also clear or not clear (depending on a bit in table HAL) the specified data block, and then return control to L13G. Control is then passed to L13D.

4.76 the DCU Selection Module (L13D) selects a DCU to be placed on-line for normal processing. The DCU is selected by referring the DCU selection table, which is a four word table located within module L13D; this table indicates how many DCU's are available for service. L13D calls the MCC Check Routine for DCU's (L13E), which marks the DCU's available or unavailable in table FJB depending on the state of the MCC ignore indicator (in HAM), the inverter failure indicator, and the thermal overload indicators (they indicate that a preset drum temperature has been exceeded). The inverter failure and thermal overload indicators are found in HST. L13E returns to L13D, which will determine how many DCU's (if any) are available for service. One DCU from each installed pair is placed on-line by this module. L13D uses the DCU Configuration Module (L13F) to mark a DCU MOS and OS in HST if it has power down. L13F calls Unit MANIAC (150X02) to set all interrupts (error and ready) from the MOS DCU's to just ignore. This other function of L13F is to schedule repair verification, if necessary, on the out-of-service DCU. Control is then passed to L13H.

4.77 the input/Output Clear Module (L13H) checks the PCG configuration, the MCC override button, and power status conditions to determine which CCX/CCR will be placed on-line. (The status of the MCC manual override buttons has a higher priority than the SYSCLR Program.) If a unit is "manually overridden" it will not be placed on-line, even if SYSCLR determines that it is an operable unit. This feature provides the man at the MCC with the ability to control this portion of the normal software restart procedure. L13H will schedule via DIACON (L20X01), a repair verification program on the off-line CCX. It will also clear and disconnect all equipped CDB's and their associated peripheral adapters; and after a one instruction cycle delay, will clear both CCX's. The I/O Clear Module will place one CCR MOS, viia CONFIG, and exit to L13T. The Ticketing Clear Module (L13T) keeps all taped data on one tape by not reconfiguring the magnetic tape units after a clear and start occurs, L13T exists to L13J.

4.78 the RS common logic unit (CLU) to be placed on-line when the system is brought up. L13J calls L13K, the MCC/RS Status Check Module, to check the status of the CLU's and to mark all RS CLU's available. L13J calls L13R, the RS Clear Module to place one RSCLU MOS (via CONFIG). The other RS CLU is placed on-line. This module also causes all calls in the system that have not been terminated to drop, and reorder tone is returned to the calling parties (lines and trunks). The L13J module then exits to L13L.

4.79 the Terminating Marker Clear Module (L13L) clears the CCR's and the TM's. The TM's are cleared in pairs by sending four words of serial transmission to them. The L13L module exits to the L13P module.

4.80 The Drum Resident Control and Cleanup Module (L13P) schedules programs to update the MCC table and the system status table (e.g., PMSCAN, System Status Table Audit Program, System Clear and Start Cleanup, etc.). L13P schedules localization on the off-line PCG via DIACON if the Trap Return Program called clear and start. If it did not, repair verification will be scheduled on the off-line PCG. The L15 module (System Clear and Start Cleanup) is scheduled by L13P to clear the HAM table and to output table HAK on the TTY. The TTY provides three 10 word dumps of data loaded by the caller. L13P passes control to L13M after the data dumps.

4.81 The Originating Marker Clear Module (L13M) clears both OM's of pair one. It uses L13N, the Interrupt and Sense Line Clear Module, and L13Q, the Phase Threshold Detector Module, as closed subroutines. L13N clears the CLP and CLS (interrupt and sense line circuits). L13Q is used to calculate a phase indicator. The Originating Marker Clear Module initializes system trap locations, enables the software memory protect system, and passes control to the Executive Program's TIME Module (E01X04). This action ends SYSCLR processing and permits the scanning of CPU queues for a new central processor task (the next program to be run).

5. MISCELLANEOUS COMMON MAINTENANCE PROGRAMS

Timed Routine Scheduler

5.01 The Timed Routine Scheduler Program (TRS - L18 and L19) handles the scheduling of any routines necessary to be run. It also permits the scheduling of these routines at various predetermined times without any external command to do so. The scheduling will be performed by the DPU Scheduler (E01), an executive program module. The required timing functions for TRS are also provided by the executive.

5.02 The two major tables accessed by the TRS program are:

a. Entry Line Address Table (ELA) and,

b. TRS Calendar Table.

5.03 The Entry Line Address Table contains the address of the program to be run by the TRS program (Table MP10). The entry line index and the software priority of the program is also contained in the ELA table. This table contains one word entries. Each entry is associated with a different routine. The ELA table is directly associated with the TRS Calendar Table (Table MP11) on a one-to-one basis. That is, the first entry in the calendar table (two words per entry) is associated with the first entry in the ELA table. Both of these tables are drum resident.

5.04 The TRS Calendar Table is interrogated every hour by TRS. The data within is modified, when necessary, and may be read and/or printed out. Scheduling of routines will be accomplished on the day(s) indicated by the DOW field when the BWF bit is set and the BWI bit matches the state of the biweekly counter (BWC).

5.05 the biweekly counter is one word long and is located in core memory. It is used to schedule routines on a biweekly basis. The BWC keeps track of the "biweeks" by complementing one bit each Sunday at midnight.

5.06 The TRS program is entered every hour, at entry line TRSTRT, by the executive's Real Time Clock Module (E05). The TRS will then check the TRS Calendar Table for any routines to be run that hour. This table contains data that indicates when to run each routine; e.g., the day(s) of the week, the month(s) of the year, and the hour of the day.

5.07 When it is determined that the routine associated with a certain calendar table entry is to be scheduled, the TRS program obtains the necessary information to schedule this routine from the ELA table. The data obtained and the entry line identity are placed into a work area and the routine is scheduled (via the executive).

5.08 Each calendar table entry can be modified by a requesting program (software control) or by a TTY input request (manual control). The two entry points into the TRS program that are used to perform these calendar table modifications are called TRIOUP and CALMOD. The former is entered for TTY initiated modifications and the latter is entered for modifications initiated under software control.

5.09 TRIOUP is scheduled by the I/O Handler Program (F27) via a TTY input request. The inputted information will contain the calendar table entry number and the month, day, week, and hour that the routine will be run. CALMOD is scheduled by a program desiring to modify a specific calendary entry. The data needed to schedule this entry is located in the associated work area; i.e., calendar identities, layout of data to be placed in words 0 and 1 of the associated calendar, and the identity of a program to be scheduled if the request is unsuccessful. Invalid requests cause a return to the requesting program's error return or they initiate an error message output on the TTY, depending on the source of the request.

5.10 The TRS provides a readout of a particular calendar table entry (if requested by a program), or it provides a printout, via the TTY, of any or all of the calendar table entries (if requested manually). A software request uses the CALDMP entry line to access a particular table entry on drum. The requesters work area must contain the calendar table entry identity and the identity of the program is that to be scheduled and passed the calendar table data.

5.11 The TRDUMP entry line is used when a manual request has been made to dump the contents of any one or all of the calendar table entries via the TTY. The requesters work area will contain the particular calendar table entry identity or an indication that all table entries are to be printed. If a CALDMP or TRDUMP request is found to be invalid, an error output TTY message will be sent (for manual requests) or an error indication will be returned to the requesting program in the associated work area.

Auditing Programs

5.12 The auditing programs perform software checks on the system software. They perform high level system checks and report any discrepancies encountered. Auditing programs reside on drum and are transferred to core to be executed at specific time intervals. These programs perform a function related to the software similar to the function that the routining program perform on the hardware. Audits are scheduled by DIACON but are not controlled by DIACON during their processing.

5.13 Auditing programs check various tables by printing out their contents via a TTY for analysis by maintenance personnel, or they may make their own validity checks on the tables. The auditing programs perform software checks on the following areas of core memory:

a. Switch protected read only memory

b. Work areas

c. MANIAC tables

d. System status table

e. Sender/receiver assignment tables

f. Call history tables

5.14 Auditing programs also perform timing checks. They check the input/output device response time and also the nonresident area of core to prevent a program residing in this area more than a predetermined length of time.

5.15 The Switch Protected Read Only Memory (SP ROM) Audit Program (L53) ensures that programs and data residing in the SP ROM are valid. To accomplish this, each word of the switch protected ROM is compared with its core image residing in a dedicated location on drum.

5.16 The SP ROM Audit Program can be requested by another program or manually, via a TTY input message. When L53 has completed, an exit is made to the Executive Program via the DPU Scheduler's RESKED entry line (e01X06) to schedule the executive's Output Format Module (F07). F07 is scheduled upon completion of a TTY initiated audit or due to errors encountered during a SP ROM audit (either TTY or program initiated).

5.17 The Work Area Audit Program (L29) ensures that all work areas in the EAX system are accounted for and are linked to the proper queues. L29 interrogates all queues, call history tables, and hitching posts (hitching posts (hitching posts are one entry queues used for a specific system funtion). The current count of the entries in each queue (as recorded in the queue root) is compared with the actual count made. The Work Area Audit Program will return any lost work areas found to the proper spare queues. This program will be called by the Lamplighter Program when a certain predetermined amount of work area overload lamps on a MCC panel are illuminated. SYSCLR will be called when various conditions are encountered during the processing of L29, e.g., an entry appears in more than one queue, more than one work area is found linked to a hitching post, etc.

5.18 The MANIAC Program's tables (Paragraphs 4.43 and 4.51) are checked by the MANIAC Audit Program (L40 and L41) to determine if they are being properly used by those programs that access them. The MANIAC audit modules are drum resident.

5.19 The System Status Table Audit Program (L59) insures that all data located in the HST is correct. The software status of the system represented in the HST table is compared to the hardware status represented by the sense lines.

5.20 The Sender/Receiver Audit Program (F61) performs checks on the Sender/Receiver Assignment Tables. These tables contain a software indication of the busy/idle and on-line/off-line status of the senders/receivers. F61 compares this software status to the hardware status. The Sender/Receiver Audit Program makes two types of checks. The first is to determine if too many of a certain type of sender or receiver are marked off-line. The second check verifies that busy/idle table matches the true status of the hardware. F61 will correct any mismatches that are detected.

5.21 The Call History Table Audit Program (F60) verifies that the software indication of each RJ's off-line busy status is consistent with the actual hardware status. F60 will check the hardware status of an RJ whose corresponding call history table indicators imply busy or off-line. If the software does not agree with the hardware, the software will be corrected. An error message will be outputted via the TTY, stating the nature of the error and the RJ and office section involved. F60 is scheduled via DIACON or initiated by a TTY request.

5.22 The Input/Output Handler Time-out Audit Program (L52) provides a software I/O device time-out check. L52 monitors device response time (the time an I/O device takes to respond to a requested I/O operation). The I/O Handler Time-out Audit provides a "software time-out interrupt" for each I/O device. The L52 module does this by notifying the I/O Handler Program (F27) if a device does not respond within a predetermined time interval. L52 is called every 167 milliseconds by the executive (E04).

5.23 the Non-resident Area Audit Program (L38) functions as a software watchdog timer. It prevents the same program from occupying the non-resident area of core for over a predetermined time interval. If the time interval is exceeded, the System Clear and Start Program will receive control.

Error Count

5.24 The Error Count Program - L26 (ERRCNT) provides centralized control over the incrementing, reading, or resetting of counters. By using this common program to control these functions, redundancy of storage is prevented. Programs call ERRCNT to have their respective counters reset, read out, and/or printed out via TTY. ERRCNT can also increment a counter and print out its contents (via TTY).

5.25 some of the programs that use the ERRCNT program to reset various counters are:

a. The Timed Routine Scheduler (L18) - every hour and every 24 hours.

b. The Minutes Timer (E09) - every 5 minutes.

c. The Interval Timer Interrupt Processor (E04) - every 250 milliseconds.

Lamplighter

5.26 The Lamplighter Program (LMPLTR-L25) provides software control over the lighting and extinguishing of lamps associated with the miscellaneous device adapter (MDA) of the MCC. LMPLTR performs the following functions:

a. maintains and updates a lamp status table (HLS). See Table MP12.

b. calls the MCC I/O Handler Program (MCCIOH-V01) to turn a lamp on or off.

c. schedules the Work Area Audit Program (L29), via DIACON, when a certain predetermined number of work area overload lamps (for each size work area) are lit. See Paragraph 5.17.

d. enables the HLS table to be printed out on the TTY by a TTY input request.

5.27 The lamps associated with the MDA that are under software control are the:

a. alarm lamps

b. printout disable lamps

c. work area status lamps

e. system configuration lamps

f. miscellaneous trunk group lamps

5.28 The Lamplighter Program is executed as a closed subroutine; that is, it will receive control from the requesting program, perform its requested tasks, and return control directly to the caller. The LMPLTR contains the present software status of each lamp. LMPLTR can update this lamp status after recovery from a hardware fault. The contents of HLS can be printed out via a TTY request (only the first six words). This is done to provide a means of verifying that the lamps that are lit coincide with their respective status recorded in the table.

5.29 LMPLTR will generate the proper data needed to perform the desired lamp operation and reflect the new status of the lamp in the HLS table. To accomplish this, it required the identity of the lamp and whether it is to be turned on or off. Using the data, LMPLTR will obtain the correct word from the HLS table, modify the correct bit in the table, and schedule the MCC I/O Handler to change the status of the specified lamp.

5.30 LMPLTR can be entered at two points, L25X01 and L25X03. The L25X01 entry line is used to turn the lamps on or off. When L25X01 is entered, LMPLTR converts the requested lamp code number into a word and bit position contained in the first six words of the HLS table. If the lamp is to be turned on, a logic 1 will be placed in the appropriate bit position. If it is to be turned off, a logic 0 will be placed in the lamp bit position. The lamp will be turned on or off as requested. The entire HLS table word will be updated by the MCCIOH program.

5.31 The L25X03 entry to LMPLTR is used to update the lamp status on the MCC panel from the software status in HLS. This update must be performed after each power failure affecting the MDA, or after each time the power to the MDA was turned off for repair.

Power Monitor Scan

5.32 If a power failure occurs, it will cause a power alarm indication. Until the cause of the power alarm is removed, no other power alarms can be reported via that interrupt line (level one). In order to insure that all power alarm conditions are reported to the computer, a periodic scan of the data lines (power monitor scan) is initiated (via DIACON) as a result of the occurrence of the first power alarm interrupt. This scan will continue, by the Power Monitor Scan Program (PMSCAN), until all power alarm circuits provide normal conditions.

5.33 PMSCAN is used to reconfigure the system after a power failure occurs. It is scheduled, via DIACON, due to a system clear and start, MCC unit clear and start (on the MDB or PMA), or a major or minor power alarm interrupt (PM adaptor interrupt - PA of the MDB). PMSCAN is also scheduled whenever an I/O device fails to return a response to the I/O Handler within a certain time period after a communication has been made to the device.

5.34 The Power Monitor Scan program is made up of two modules (L30 and L51), one located on drum memory and the other in core. The majority of PMSCAN is found on drum. The preliminary scan "portion" and the "drum power portion" are located in core. The preliminary scan software checks the system power status to determine if any changes have occurred since the last scan. The drum portion of PMSCAN is called only if a change was detected, thus keeping the running time down to a minimum.

5.35 PMSCAN accesses three tables:

a. The Power Last Look Table - contains a representation of the system power status as it looked the last time PMSCAN ran. This data is compared with the present status to determine what changes (if any) were made.

b. Valid Power Failure Source Table - contains a bit set for each valid source of power from the PMA.

c. Drum to DCU Conversion Table - contains a map of the Drum/DCU assignments.

5.36 PMSCAN insures that communication with the MCC is possible. It does this by checking the power fail sense lines of the CCX, the MRLF, and the MDCF. If a power failure occurred in any of these units, PMSCAN will check the sense lines on a periodic basis until power is restored. If communication with the MCC is possible, PMSCAN will read the power status words of the PMA and MDA. (This is accomplished by using the MCC I/O Handler Program.) The power status words will indicate which power sources are valid and equipped.

5.37 The present status of the power sense lines and data sense lines are compared with their previous status (checked during PMSCAN's last run) to determine if there had been a change. The previous status is checked in the System Status Table (HST).

5.38 if a power status change occurred within the CMC or the DMS, PMSCAN will call CONFIG. If the power status checks all right for the CMC and DMS, the drum portion of PMSCAN will be scheduled to check the rest of the subsystems. For all power failures detected on a unit (CMC and DMS included), CONFIG is called to place the unit and all other related units OS (out-of-service) and MOS (maintenance-out-of-service) in table HST. CONFIG insures that both units of a pair are not taken out of service to normal processing.

5.39 PMSCAN will call the Maintenance Interrupt Access Program (MANIAC) to set a bit in table HJI to just-ignore all interrupts from any OS subsystems. PMSCAN also calls the I/O Handler Program associated with the unit or device that had the power failure. The I/O Handler is informed of the power down condition so that it may perform any necessary operations. A message is outputted via TTY to indicate that a power failure has occurred on a specified unit.

5.40 If a subsystem has gone to a power up status, CONFIG is informed that the unit is no longer OS but is still MOS. CONFIG indicates this status change is table HST. An output message via the TTY will indicate that power is restored.

5.41 If any subsystem is in a power down status after PMSCAN has run, control will be passed to the Interval Timer Request Acceptor Program (E02). E02 will run PMSCAN at one second intervals until all subsystems have power up. PMSCAN will call RELEAS (E01X03) which relinquishes control to TIME. The Power Monitor Scan Program will be called again when the next power failure interrupt occurs.

TABLE MP1 ______________________________________ Glossary of Softwave Terms Found in Figure 1. MNEMONIC DEFINITION ______________________________________ CHA Call History Table Audit CNF Configuration Control Audit DVD Drum Versus Drum Audit HSC Hardware Protected Read-Only- Memory Audit MAN Manual Audit MDSPD Space Divided Equipment-Special PBPROC Pushbutton Processor PMSCAN Power Monitor Scan RST Register-Sender Trouble SPRCR Receiver-Special SPSCR Sender-Special SPTRS Time Routine Scheduler-Special SRA Sender/Receiver Audit TRPOUT Trap Out Program Audit WAA Work Area Audit ______________________________________

TABLE MP2 ______________________________________ DCU/RS Configuration Scheme. CONFIGURATION COUNTER STATE CCPA CCPB ______________________________________ 1 DCU1 DCU3 RS1A DCU1 DCU3 RS1A 2 DCU2 DCU4 RS1A DCU2 DCU4 RS1A 3 DCU1 DCU4 RS1A DCU1 DCU4 RS1A 4 DCU2 DCU3 RS1A DCU2 DCU3 RS1A 5 DCU1 DCU3 RS1B DUC1 DCU3 RS1B 6 DCU2 DCU4 RS1B DCU2 DCU4 RS1B 7 DCU1 DCU4 RS1B DCU1 DCU4 RS1B 8 DCU2 DCU3 RS1B DCU2 DCU3 RS1B ______________________________________ ##SPC1## ##SPC2## ##SPC3## ##SPC4## ##SPC5## ##SPC6##

TABLE MP12 ______________________________________ Lamp Status Table (HLS). 23 0 WORD ______________________________________ LAMP STATUS WORD 0 0 LAMP STATUS WORD 1 1 LAMP STATUS WORD 2 2 LAMP STATUS WORD 3 3 LAMP STATUS WORD 4 4 LAMP STATUS WORD 5 5 WORK AREA STATUS 6 PREVIOUS LAMP STATUS 7 WORD NUMBER 8 BIT NUMBER 9 WA LAMP COUNT 10 ______________________________________

DIAGNOSTIC CONTROL PROGRAM (DIACON) DESCRIPTION AND USER'S DOCUMENT FIG. 45

I. introduction

the Diagnostic Control Program (DIACON) will provide centralized control over the maintenance programs executing on the base level and falling into one of the following categories:

a. Isolation (on base level)

b. Localization

c. Repair Verification

d. Routining

e. Unit Clear and Start

f. Audits

g. Certain other "special" programs

It is DIACON's function to:

1. enforce a one-at-a-time scheduling for maintenance programs that may interfere with one another. These will generally be those programs falling into categories (a)-(e) above.

2. provide a means of insuring that the programs under its control can be scheduled even though no work areas are available at the moment.

3. provide some priority scheme for the scheduling of these jobs.

4. provide a means of informing some jobs that they should abort themselves due to system occurrences possibly causing them troubles (such as traps) or requests for jobs of a more important nature having been requested (such as isolation).

Many times in this document, particularly in the macro definitions, reference will be made to a "job number". This is the name that has been given the identification of a particular job. The job number is developed from the unit type and the unit number relative to the type.

This number is the one used to find any information associated with that job in the DIACON tables. The job number as described above and those assigned to the special jobs and audits are essentially their bit number in the DIAJOB table.

Ii. diacon description

at some point in various programs it is determined that a maintenance program is to be scheduled. Requests for the scheduling of those programs, under the control of DIACON, will be made to DIACON via the macros provided (see Section III). Upon receipt of such requests, DIACON will check the validity of the request and, if invalid, return to the requestor with information pertaining to the reason for disallowing the request (refer to the macro descriptions). At present there appears to be only three reasons for disallowing requests and they are:

1. The request was made on a unit that has no maintenance programs (controlled by DIACON) associated with it. This problem is greatly limited by the allowable parameters in the macros and the scheme for re-assignment of job types as described in Appendix II.

2. the request is for a job on a unit that has a previous request of a higher, mutually exclusive, priority (see Appendix II).

3. the request involved a repeat test request and a repeat test is presently in progress (Only one repeat test is allowed in the system at a time).

If the request is found valid, which should be the general case, the appropriate flag in the DIAJOB table (Table DN1) will be set indicating which unit and what type of request has been made. The data to be passed to that maintenance program, if any, will be stored in the proper DIADAT table entry (Table DN3). The DIAFLG in the EXEC's job queue will be set informing the EXEC that DIACON has work to do (refer to Appendix V for a description of the DIAFLG mechanism).

In this manner as many requests as necessary may be made to DIACON without interference. Each request being saved for processing, in its turn, as it is made.

At the time of a request no work areas are needed. No work areas will be needed for this job until it is to be scheduled by DIACON.

During the normal processing of its job queues, the EXEC will encounter the DIAFLG set by DIACON. At this point, control will be transferred to DIACON. DIACON will interrogate the DIAJOB table and, finding a flag set (work to be done), get a work area. If unable to get a work area, the DIAFLG will be set again and control returned to the EXEC. Once a work area is obtained, the flag that was set will be checked for a special job. "Special" jobs are those scheduled by DIACON but not having control of DIACON (or DIATAB) during their execution (such as Work Area Audit from Lampliter, the trap output program, etc.). This is done via the DIAVEC table (Table DN2). If the job is special it will be scheduled immediately. The DIAFLG is set again so that DIACON will be re-entered to look for more work, and control returned to the EXEC. If the job were not a special one the drum resident job processing portion of DIACON will be scheduled (at EXEC job queue priority 0).

Once the job processor is read into core and given control, it will interrogate the DIAJOB table for work (non-special jobs only). Work is found by scanning the types of jobs requested in the following order:

1. isolation

2. unit clear and start

3. localization

4. repair verification

5. routining

6. audits

If the first job found is any of the types 1-5 above, DIACON will perform any checks of the system status dictated to be performed for this job by this job's associated entry in the DIACTL table (Table DN7). The checks that could be performed are of two types:

1. System Status table checks - verifying that the system configuration and other indications available in this table are such that this job can run.

2. Sense Line Checks - verify that specific sense lines are in a pre-determined states (generally used to check on/off line status but not limited to such). If any of these checks are unsuccessful that job will not be scheduled but the request will remain in the DIACON tables for processing at a later time. DIACON will then find the next job to process. If there are no other jobs the DIAFLG will again be set and control returned to the EXEC.

If all checks are successful, the program requested will be scheduled on the proper priority EXEC job queue qith the proper size work area. In addition, the scheduled program will be assigned the use of DIACON's DIATAB table (see Table DN4) and become the DIACON client at this point. This job's entries in both the DIAJOB and DIADAT tables will be removed. Any data to be passed to this program (the client) will be stored in the designated words of the DITAB table. The exact layout and quantity of this data will be defined by the associated maintenance programs. Also in the DIATAB table will be this job's number. In order for the client to determine the particular unit to be diagnosed, a constant for each type of unit will have to be subtracted from the job number.

If the job found had been an audit, there would have been no system status checks. Audits have only one word of data to be passed (found in the DIALOC table) and it is passed in the work area. Audits, it is felt, present no interference problems and are therefore scheduled to be run without becoming DIACON clients. As such, they are never assigned the DIATAB table and never have control of DIACON. It is possible that an audit could be running concurrently with other maintenance programs.

The DIATAB table has two additional areas in it. One, an area of about 30 words to be used by the DIACON client as he sees fit. He can use this area of DIATAB as "long term junk storage" for as long as he has control of DIACON. A client will have control of DIACON from the time he is scheduled to the time that he informs DIACON that he is finished. This period can span several real time breaks during which the "Non-Resident Area" will be given up. However, in order to protect DIACON from being tied up forever, an overall timer will be used to time the client. The period of this time is presently 2 minutes. Should this limit ever be exceeded the system will go through a System Clear and start.

The second area is set aside for the client to store the information necessary for him to abort himself gracefully. Such things as "abort entry lines", addresses as of work areas being used, subsystem status indicators, etc., can be stored here.

An "abort" scheme has been introduced into the system primarily to inform a maintenance program in progress, that could be relatively long in terms of real time control of DIACON, that a maintenance program of greater importance has been requested to be run (e.g. isolation). The scheme also provides a means of information the program in progress that some system occurrence, that may have an adverse effect on the test results, has occurred (e.g. a trap). In the latter case, this is the only way for the program in progress to be informed of the occurrence.

The abort scheme to be employed by DIACON and its clients is as follows:

1. In the DIATAB table there are several abort indicators. Each client program must check these indicators before it takes any real time breaks (gives up control of the CCP). If any are set, the client should abort his program by "cleaning" himself out of the system gracefully. This will involve the resetting of the subsystem, releasing of any work areas being used, re-scheduling itself via DIACON, if possible, and any other necessary actions.

2. The abort program does not have to be in core at this time of the decision to abort. It may be a separate drum resident program.

3. It is possible that the system configuration has changed since a maintenance program was started. Certain of these changes may cause the program to arrive at an erroneous conclusion and remove a good unit from service. In an effort to minimize this effect, each maintenance program will check the system status table at the completion of a test if the test failed. If such a change had occurred, no trouble report should be generated and the test should be treated as if it had been successful.

Once the scheduled program has been given control he must update the control information in the DIATAB table indicating his having been started. This is done by calling the SKEDIP macro.

If a maintenace program wishes to run in several segments, he may re-schedule himself through DIACON. The necessary information pertaining to which segment is to be run each time that DIACON schedules him can be passed in the variable data (possibly by different "test numbers") stored and passed via the DIADAT table.

Control of "repeat tests" is performed by DIACON. An indivicator is passed to the client as to whether or not the request is a repeat test so that any special actions required for repeat tests can be initiated by the client. The re-scheduling of requests and the "start" and "stop" printouts required are controlled by DIACON.

At the completion of the diagnosis, whether aborted or not, the client must inform DIACON that he is finished (via DIARLS macro) and then give up control to the EXEC.

Iii. diacon interfaces

contained in this section are the macros used by all programs to communicate with DIACON. The following is a list of the macros provided and their functions. An asterisk (*) indicates the associated programs run with interrupts disabled.

Diarqt* - request a maintenance program to be scheduled via DIACON.

Diarmv* - remove a maintenance program request from DIACON.

Audrqt* - request an audit to be scheduled via DIACON.

Audrmv* - remove an audit request from DIACON.

Skedip* - reset the "SKED" indicator and set the DIP indicator in DIATAB.

Rptstp - stop the repeat test in progress.

Diarls - release DIACON and DIATAB

Diabrt - abort job if specified program is present DIACON client.

Diatrp - trap has occurred.

Most of these macros will generate branches to subroutines provided by DIACON. All are closed subroutines, that is, they will always return control. No work areas are required for any interface with DIACON via these macros.

1. MACRO NAME: AUDRMV - remove an audit request from DIACON.

2. purpose: to provide the necessary interface with the DIACON program to remove a request for a specific audit that had previously been requested.

3. MACRO CALL: AUDRMV P1

4. `macro parameters:

p1 = audit name (see appendix IV for a list of valid values for this parameter).

5. ADDITIONAL PARAMETERS:

None

6. MACRO RETURNS:

1. original contents of all registers are destroyed.

2. Return will always be made to the client as macro call plus 1. At this time, the "A" register will contain a result code as follows: result code meaning ______________________________________ .phi. request has been honored .phi.1.phi. request denied due to in- valid job number ______________________________________

7. Only one Repeat Test is allowed to be performed at a time in the system. Repeat tests that run until they are stopped should only print start and stop messages. Repeat tests that run until a malfunction is encountered should also print the trouble message of that malfunction. The Start and Stop messages will be generated by DIACON.

8. all DIACON clients are limited by an overall timer (at present = 2 minutes). On the occurrence of a timeout of this timer, the system will go through a System Clear and Start.

9. Before any maintenace program replaces a unit into service (for normal processing) all MANIAC requests for that unit must be removed.

V. tables

diacon makes use of several tables to perform its function. A brief description of each follows and a pictorial description of each is attached.

Table dn1 - diajob - this table contains one bit for each unit to be diagnosed in each of the allowable categories; one set of bits for isolation (and special) requests, one set for unit clear and start requests, one set for diagnostic requests (localization/repair verification/routining) and one set for audits. The table is used to indicate "work to be done" and on which unit.

Table dn2 - diavec - this table is used to determine which job numbers are valid and, if valid, either point to the appropriate entry in DIADAT, for data storage, or indicate a special job.

Table dn3 - diadat - this table is used to store any necessary information to be passed from requestor to requested program.

Table dn4 - diatab - this is a dedicated block of core to be assigned to the DIACON client for his use. This is not a work area and cannot be used for linkage to queues.

Table dn6 - diactl - this is DIACON's control table where the program to be scheduled, its work area size and necessary system configuration information is found.

Table dn7 - dialoc - this is a "vector table" used by DIACON to find the proper entry in DIACTL for a given job.

Table dn8 - rptctl - this is the word used by DIACON to control a repeat test.

1. MACRO NAME: AUDRQT - request an audit to be scheduled via DIACON.

2. purpose: to provide the necessary interface with the DIACON program which will retain the request. At some later time the audit will be scheduled.

3. MACRO CALL: AUDRQT P1

4. macro parameters:

p1 = audit name (see appendix IV for a list of valid values for this parameter).

5. ADDITIONAL PARAMETERS:

None

6. MACRO RETURNS:

1. original contents of all registers are destroyed.

2. Return will always be made to the client at macro call plus 1. At this time, the A register will contain a result code as follows:

result code meaning ______________________________________ .phi. request has been honored .phi.1.phi. request denied due to invalid job number ______________________________________

1. MACRO NAME: DIARMV - remove a maintenance program request from DIACON.

2. purpose: to provide the interface with the DIACON program to remove a request for a specific job that had previously been requested.

3. MACRO CALL: DIARMV P1, P2

4. macro parameter:

p1 = type of unit (see appendix I for a list of valid values of this parameter).

P2 - type of job (see appendix II for a list of valid values for this parameter).

5. ADDITIONAL PARAMETERS:

1. index register 2 must contain a unit number relative to the type of unit (numbering for this purpose begins with 0).

6. MACRO RETURNS:

1. original contents of all registers are destroyed.

2. Return will always be made to the client at macro call plus 1. At this time, the A register will contain a result code as follows:

result meaning code ______________________________________ .phi. request has been honored .phi.1.phi. request denied due to invalid job number .phi.11 request denied due to invalid job type .phi.12 request denied due to non-existent job ______________________________________

1. MACRO NAME: DIARQT - request a maintenance program to be scheduled via DIACON.

2. purpose: to provide the interface with the DIACON program which will retain the specific request and its associated information. At some later time this maintenance program to be run will be scheduled.

3. MACRO CALL: The macro may be called in two ways:

A. diarqt p1,p2,p3,p4,p5

or

B. diarqt

4. macro parameters: for call A

P1 = type of unit to be diagnosed. (See Appendix I for a list of valid values for this parameter).

P2 = type of job to be run (See Appendix II for a list of valid values for this parameter).

P3 = source of request (See Appendix III for a list of valid values for this parameter).

P4 = repeat Request Code (See Appendix IV for a list of valid values for this parameter).

P5 = raw data dump request (See Appendix VII for a list of valid values for this parameter.)

For calling sequence B

If no parameters are specified then it is assumed that the above parameters, "ORed" together, are in pseudo register ERG001 before the macro call.

1. MACRO NAME: RVPSTP - Stop the Repair Verify request in progress.

2. PURPOSE: To provide the necessary code to stop a repair verify repeat test which is in progress and extinguish the Repair Verify Repeat lamps. If the test being repeated is in progress, that will be the last test but that test will not be aborted.

3. MACRO CALL: RVPSTP

4. macro parameters: none

5. ADDITIONAL PARAMETERS: None

6. MACRO RETURNS:

1. original contents of all registers are destroyed.

2. Return will always be made to the client at macro call plus 1.

5. ADDITIONAL PARAMETERS:

1. index register 2 must contain a unit number relative to the type of unit. (numbering for this purpose begins with 0).

2. index rsegister 1 must contain the address of the 1st word of data to be passed to the requested program, if any data is to be passed in addition to the data passed in the "Q" register. The quantity of dats is a pre-determined quantity.

3. the Q register must contain the information to be stored in the 1st word of the DIADAT entry for this program (see the description of the DIADAT table for a definition of the layout of this word - DIAGWD - in table DN3).

6. macro returns:

1. original contents of all registers except ERG002 and ERG003 are destroyed.

2. Return will always be made to the client at macro call plus 1. At this time, the A register will contain a result code as follows:

Result Code ______________________________________ .phi. request has been honored 1 job type has not been specified (zero) 2 job type out of range (too big) 3 invalid job number (too big or zero) 4 no such job in DIACON 5 invalid job type (not such job on this unit) 6 only one repeat or repeat-quit at a time 7 only one repair verify repeat at a time 10.sub.8 job requested is routining and verify is in tables 11.sub.8 job requested is routining and localization is in tables 12.sub.8 job requested is routining and higher priori- ty job is in tables ______________________________________

Iv. constraints on diagnostic programs

1. all units to be diagnosed must be MOS (Maintenance Out of Service) when the maintenance program is running. Programs requesting Isolation, Localization or Repair Verification must place the unit MOS at the time of the request. Programs performing Routining must place the unit MOS before testing is started.

2. Isolation requests are allowed on all markers simultaneously. All other requests (for RS isolation, localization, repair verification and routining) are only allowed on one of a pair. (See appendix II).

3. all diagnostic programs will use the high priority I/O queues.

4. All programs expecting to use DIATAB must be scheduled via DIACON.

5. all programs scheduled by DIACON must check the abort indicators (in DIATAB) before taking any real time breaks.

6. All programs failing a diagnosis shall check the system status table at the end of their tests for a system configuration that could have caused the failure. If such a configuration is found, no printout of the failure should be made and the test should be treated as successful (e.g. the unit restored to service).

1. MACRO NAME: DIARLS - release DIACON and DIATAB.

2. purpose: at the end of each DIACON client program (completion or aborted), DIACON must be informed so that he may begin processing any other work he has waiting to be scheduled.

3. MACRO CALL: DIARLS

4. macro parameters:

5. additional parameters:

1. the program making this request must have control of DIATAB at this time.

6. MACRO RETURNS:

1. original contents of all registers are destroyed except index register 1.

2. Returns will always be made to the client at macro call plus 1.

3. DIATAB will be zeroed.

1. MACRO NAME: SKEDIP - reset the SKED indicator and set the DIP indicator in DIATAB.

2. purpose: to provide the necessary code (expanded in the client program) to change the activity indication in the DIATAB table.

3. MACRO CALL: SKEDIP

4. macro parameters:

none

5. ADDITIONAL PARAMETERS:

None

6. MACRO RETURNS:

1. return is always at macro call plus 1.

2. The original contents of the A register is destroyed.

1. MACRO NAME: DIATRP - notify DIACON that a trap has occurred.

2. PURPOSE: To enable trap handlers to notify DIACON that a trap has occurred.

3. MACRO CALL: DIATRP

4. macro parameters:

none

5. ADDITIONAL PARAMETERS:

None

6. MACRO RETURNS:

1. no registers are affected.

2. Return is made at macro call plus 1.

1. MACRO NAME: RPTSTP - stop the repeat test in progress.

2. PURPOSE: To provide the necessary code (expanded in the client program) to stop a repeat test which is in progress and extinguish the Repeat test in progress lamp. If the test being repeated is in progress, that will be the last test but that test will not be aborted.

3. MACRO CALL: RPTSTP

4. macro parameters:

none

5. ADDITIONAL PARAMETERS:

None

6. MACRO RETURNS:

1. original contents of all registers are destroyed.

2. Return will always be made to the client at macro call plus 1.

1. MACRO NAME: DIABRT - abort job is specified program is present DIACON client.

2. PURPOSE: If a specific need to abort a particular job arises, this is the interface to be used to inform DIACON of the need. If the specified program is the present DIACON client, he will be told to abort via an abort indicator in the DIATAB table (ABRT).

3. macro call: diabrt p1

4. macro parameters:

p1 = type of unit being diagnosed (see Appendix I for a list of valid values of this parameter).

5. ADDITIONAL PARAMETERS:

1. index register 2 must contain a unit number relative to the type of unit and a code for the type(s) of job being run on the unit. This info must be formatted to coincide the format of this information in DIATAB.

6. macro returns.:

1. original contents of all registers are destroyed. 2. Return will always be made to the client at macro call plus 1. At this time, if the A register is non-zero the request will have been honored and the abort indicator set. If the A register is zero, then the request was not valid (e.g. the specified client was not the DIACON client.)

APPENDIX I

Contained below is a list of type of units and the corresponding code to be used in DIACON macros. ______________________________________ Code Type of Unit ______________________________________ SPSCR System Clock Alarm Rcy. SPRCR Real Time Clock Alarm Rcy. MDCCR Communication Register MDCCX Channel Multiplex MDCDB Channel Device Buffer (for TTY's and paper tape units.) MDCMC Core Memory Control MDCTT Teletypewriter Peripheral Adapter MDDMS Drum Memory System MDMDA MCC Display Peripheral Adapter MDMDB Maintenance Device Buffer (MCC) MDMRA MCC MRS Peripheral Adapter MDMRK Marker (O.M. or T.M.) MTMTA Magnetic Tape Peripheral Adapter MDPBA MCC Pushbutton Peripheral Adapter SPPBP Pushbutton Processor Program MDPCG Processing Configuration Group MDPMA MCC Power Monitor Peripheral Adapter MDPTA Paper Tape Peripheral Adapter MDRRS Register-Sender MDSPA Ticketing Scanner Peripheral Adapter MDTDB Ticketing Device Buffer MDCTP Third Party SPVMS Voltage Monitor Scan Program MDLPA Line Printer Peripheral Adapter MDCRA Card Reader Peripheral Adapter SPITP In-test program MDRST Register-Sender System Trouble ______________________________________

For MDCTT when identifying these peripheral adapters by unit number the "Office Administration TTY" with the low speed paper tape punch/reader will be number 1 and the maintenance TTY will be number 0.

For MDPTA when identifying these peripheral adapters by unit number the reader will be number 1 and the punch will be number 0.

APPENDIX II

Contained below are the codes used to indicate a type of job and the meaning attached to that job type:

Code Job Type ______________________________________ JTISO isolation program JTLOC localization class of program JTRPV repair verification class of pro- gram JTRUT routining class of program JTCAS unit clear and start class of pro- gram JTSP1 Special job to be run on Diagnos- tic level JTSP2 Special job to be run on C & S level JTSP3 Special job to be run on Isolation Level ______________________________________

A specific job classification should be assigned to a job request which will determine its priority within DIACON's scheduling scheme. Those classes of programs indicated by JTLOC, JTRPV and JTRUT are mutually exclusive and override each other in the following manner.

A. the JTLOC class will override both JTRPV and JTRUT previous request.

B. the JTRPV class will override the JTRUT class but not the JTLOC class.

C. the JTRUT class will not override either JTLOC or JTRPV classes.

D. a second request of the same class will override a previous request on the same device. This is true for all classed of requests (JTISO, JTLOC, JTRPV, JTRUT and JTCAS).

Any request that is overriden is lost from the system and there is no record of it or the fact that it was lost. Another consideration to be given to a job classification is the manner in which the maintenance program scheduled, as a result of the request, will handle the job. This is meant to imply that the type of request being made is not an arbitrary decision but must be coordinated with the designers of both the DIACON program and the maintenance program to which the request will be passed.

It should be noted that, in the "operational EAX program" whenever a request for an invalid or non-existent job type is made, that job type request will be modified according to the following table. The only types of jobs assumed to always be existent in an operational EAX program are those in the JTISO (isolation or special) and JTCAS (unit clear and start) classes. ______________________________________ Original Modified type type JTLOC a printout of the request will be made JTRPV JTCAS JTRUT reported to user as "invalid job type" ______________________________________

It should also be noted that DIACON will allow requests for marker isolation programs on all units. Register-Sender isolation, localization, repair verification, routining and unit clear and start type programs can only be requested on one unit of a pair at any time. In conjunction with the override capability this means that a localization request on unit B will override a previous localization, repair verification or routining request on either unit A or B of that pair.

Implementation of this procedure is based on the fact that only one unit of a pair can be MOS at a time and the unit must be MOS for maintenance to be performed on the unit. (Refer to list of Maintenance programming restriction in section IV).

APPENDIX III

Listed below are the valid values to be used when specifying the source of a request to DIACON. ______________________________________ Code Source ______________________________________ SCTTY Teletypewriter SCTRS Timed routine scheduler (TRS) SCSCS System Clear and Start SCISO Isolation program BLANK No source specified ______________________________________

APPENDIX IV

Listed below is a partial list of the audits and the corresponding codes to be used in DIACON macros. ______________________________________ CODE AUDIT ______________________________________ AU WAA Work area audit (work areas and queues roots) AU QRA Queue Root audit AU WAC Work area checker (work areas only) AU LMP Lampliter audit AU MAN MANIAC audit AU PBC Pushbutton checker AU PMC Power Monitor checker AU DVD Drum Vs. Drum check AU CNF Configuration Control audit AU TRP Trap Out Program AU TRT Third Party Trap Audit ______________________________________

APPENDIX V

DIAFLG MECHANISM

In order to fascilitate DIACON's ability of processing requests without having work areas at the time of request, the EXEC has provided the DIAFLG mechanism. This mechanism is a flag (DIAFLG) associated with each of the EXEC's 8 priority job queues. As the EXEC processes the job queues he will interrogate the DIAFLG for each queue as the first request on that priority and, if set, give control to DIACON. This gives DIACON an entry on each of the queues without the need of a work area.

When DIACON is entered, he will attempt to get a work area of the size required to do his job. If he is unable to obtain a work area as needed he merely sets his DIAFLG request again, returns to the EXEC to allow further processing of other requests and tries again the next time he is entered.

This mechanism provides two advantages. First, it allows scheduling of DIACON without the need for a work area. Secondly, it enaables the scheduling of maintenance jobs during a trap level. This second advantage would otherwise require a dedicated work area.

APPENDIX VI

Repeat Tests and Their Source Codes

The following source codes for repeat tests are valid:

Code Description ______________________________________ RPRPT the requested routining program is to repeat until a RPTSTP macro is executed. RPRPQ the requested routining program is to repeat until the test being run fails. RPRVR the requested repair verification pro- gram is to run once for every request made from the repair verify-repeat Push Button. When the test is success- ful, the unit is to be put in service and the repeat test stopped. ______________________________________

APPENDIX VII

Raw Data Dump Source Code

If a Raw Data Dump is being requested from the module being requested the following Source code will be used:

Source Code Description ______________________________________ RDUMP a raw data dump (if implemented) will be provided. blank No raw data dump will be given. ______________________________________

EXECUTIVE PROGRAM MODULES

F02 - figs. 48a - 48b

1. name: link to Queue Program

2. PURPOSE: The purpose of module FOx is to link a work area to a specified queue.

3. FUNCTIONS:

a. Maintains current, total and empty queue statistics.

b. Initiates a validity check for the type field.

c. Links to the front or back of a queue.

d. Maintains maximum length queue has attained.

4. INPUTS

4.1 software 4.1.1 core table

Fwa - executive Interface Work Area

Fra - queue Root

Esl - executive Storage Locations

4.1.2 DRUM TABLES

None

4.1.3 REGISTERS

X1 - identity of Work Area to be Queued

X2 - queue root identifier

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - executive Interface Work Area

Fra - queue Root

Esl - executive Storage Locations

5.1.2 DRUM TABLES

None

5.1.3 REGISTERS

None

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: reasons for entry

points

f02x01 link to back of Queue

F02x03 link to front of Queue

6.2 EXIT POINTS

Exit: reasons for exit

points: control is always returned to the calling program.

7. SUBROUTINES USED

Entry: functional names

points

none

8.0 narrative

8.1 discussion

the queue structure used by the executive consists of two parts: the entries in the queue and the queue roots. Each queue has a unique root, fixed table of six words, associated with it. The root points to the first queue entry, the first points to the second, etc. The last entry contains a zero instead of a pointer to indicate the end of the queue. The queue root also contains the last entry to facilitate adding new entries.

The F02 module provides two way linkage of a work area. A work area may be linked to the front or the back of the queue depending upon the entry line called. Both entry lines provide a route of initializing first and last entry pointers in the queue root if the queue is empty. Interrupts are disabled as a function of the LNKTAB macro. possibilities module

8.2 TECHNIQUE

When linking a work area to the back of a queue; entry is required from line F02X01. Upon entry an initial check is made to determine if the queue has other work areas in it. If it doesn't the empty queue counter is incremented and a check is made to see if the work area type is valid. If the work area type is valid the linkage word of the new entry is stored in the zeroed link field and the first and last entry pointers are stored in the queue root. The total and current entry counts are incremented and the maximum count is equated to the current count if the present maximum count is less than the current count. The interrupts are enabled and return is made to the caller.

When the initial check determines the queue is not empty and the type field is valid the new entry address is merged into the old last entry and the old last entry's linking address now points to the now last entry. Return is made to the caller after the entry counts are incremented and interrupts enabled as described earlier.

When linkage is required to the front of a queue, entry line F02X03 is called. If the queue is empty, processing remains the same as for an empty queue in F02x01. If the queue is not empty the address of the first entry is merged into the new entry linkage in the work area and the address of the new entry is placed in the queue root. The total and current empty counts are incremented and the maximum count is equated to the current count if the present maximum count is less than the current count. The interrupts are enabled and return is made to the caller. If upon any entry line (X01 or X03) the type field is found to be invalid, a call to work area audit is initiated.

F03 - fig. 49

1. name: - unlink from queue program.

2. purpose: - the purpose of module F03 is to unlink work areas from the front of the work area queue.

3. FUNCTIONS:

a. Maintains a current count of entries in the queue.

b. Passes the work area address of the entry being unlinked to the calling program.

c. Adjust pointers to entries remaining in the queue.

4. INPUTS

4.1 software

4.1.1 core table

Fwa - executive Interface Work Area

Fra - queue Root

Esl - executive Storage Locations

4.1.2 Drum Tables

None

4.1.3 Registers

X2 - queue Root Identifier

4.2 Hardware

None

5. Outputs

5.1 Software

5.1.1 Core tables

Fra - queue Root

Esl - executive Storage Locations

5.1.2 Drum Tables

None

5.1.3 Registers

Ra - < 0 - queue empty

> 0 - Normal return

X1 - work area identity if RA> 0

5.2 hardware

None

6. Control

6.1 Entry Points

Entry: Reasons for Entry

Points

F03x01 unlink from top of Queue

6.2 Exit Points

Exit: Reasons for Exit

Points: Control is always return to the calling program.

7. Subroutines Used

Entry: Functional names

Points

None.

8.0 NARRATIVE

8.1 discussion

the F03 module provides the capability of unlinking a work area from a queue over entry line F03X01 Unlike the linking module F02 unlinking can only take place from the front of the queue. The interrupts are disabled as a function of the LNKTAB macro.

Technique

upon entry via F03X01 the work area queue is checked to determine if any entries are present. If the queue is empty the error return indicator is set, the interrupts are enabled and return is made to the caller.

If the queue is not empty, the count is decremented by one and the queue is checked for additional entries. If only one entry is in the queue the queue root address is used as the last entry address.

The address of the entry being removed is stored for passage to the caller. The new first entries address is put in the first entry section of the queue root and a normal return is made to the caller after the interrupts are enabled.

*NOTES TO FIG. 49

1. interrupts disabled in entry line table by use of dismac.

2. enimac

f03xc1 used to remove first entry from a queue.

inputs: (xr2) = queue root identity

outputs: (xr1) - work area address if queue was not empty

(ra) .gtoreq. 0 if queue was not empty

(ra) <0 if queue was empty

f04 - figs. 50 - 50a

1. name:

f04 work area assignment program

2. purpose:

the purpose of module F04 is to assign a spare work area from the queue to fulfill a request from the caller because of an overload.

3. FUNCTIONS:

a. calls unlink to obtain a work area from the appropriate spare work area queue.

b. calls lamplighter for overload lamps

c. checks for overload condition

d. returns indication to user of successful or overload condition if requested

e. causes scheduling of user specified program an overload, if requested by user

4. Inputs

4.1 Software

4.1.1 Core Tables

Fra - queue Root

Esl - executive Storage Locations

Fwa - executive Interface Work Area

Eps - executive Parameter Storage

4.1.2 Drum Tables

None

4.1.3 registers

X1 - work Area to be used for Executive overload handling

X2 - work Area type indicator

Ra - overload return program name and Entry line. Bit 24 set indicates that Executive is to handle overload

4.2 Hardware

None

5. outputs

5.1 Software

5.1.1 Core tables

Fra - queue Root

Esl - executive Storage Location

Fwa - executive Interface Work Area

5.1.2 Drum Tables

None

5.1.3 registers

Ra = 0 if normal return

<0 if overload and caller is to handle

Work Area overload

X1 - work area identity if RA = 0

5.2 hardware

None

6. control

6.1 Entry Points

Entry: Reasons for Entry

Points

F04x01: obtain a spare Work Area

6.2 Exit points

Exit Points; Reasons for exits

E01x06: no Work Areas of size requested and executive is to handle overload; Otherwise, control is returned to the caller

7. Subroutines

Entry: Functional Name

Points

F03x01: unlink - obtain entry from Queue

L25x01: lmpltr - set work area overload lamp on MCC

8.0 narrative:

8.1 discussion

module E04 assigns work areas on the basis of the specified Work Area type indicator. Register A contains the program name and entry line. If bits 24 is set the exec is to handle the overload rather than returning to the caller at that time.

8.2 TECHNIQUE

Upon entry to F04 there is a call via macro PGLINK to unlink a work area from a spare work area queue. If a work area is available and is not the last one in the spare queue, the normal return indicator is set and return is made to the caller.

When a work area of requested size is not available and the exec is not to handle the overload the error return indicator is set. Return is then made to the caller after enabling the interrupts.

Upon non-availability of a requested work area the exec may be called to handle the overload. This is accomplished by calling the RESKED entry line (E01X06) for the overload rescheduling of the specified program.

When a work area is retrieved and it is the last one in the queue lamplighter is called to light the overload lamp. The interrupts are enabled if applicable and normal return is made to the caller.

F05 - fig. 51

1. name

work Area Return (WADROP) Module.

2. PURPOSE

The Work Areas Return Program (Module F05) returns Work Areas (WA's) to spare queues.

3. FUNCTIONS

Module F05 performs the following functions:

a. Calls the Link to Queue program (module F02).

b. Calls the lamplighter (if applicable) to extinguish the WA overload lamp.

4. INPUTS

4.1 software

4.1.1 core Tables

Hls - lamp Status Table.

4.1.2 Drum Tables

None.

4.1.3 Registers

X1 - contains the work area address.

4.2 HARDWARE

None.

5. OUTPUTS

5.1 software

5.1.1 core Tables

None.

5.1.2 Drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARE

None.

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F05x01: f05x01 is called to return temporary WA's to the proper spare WA queue.

6.2 EXIT POINTS

Exit: Reasons For Exit

Points

None: Control is returned to the calling program.

7. SUBROUTINES USED

Entry Functional Names

Points

F02x01: link to Priority Queue: Link to the Back of the Queue.

L25x01: lamplighter (LMPLTR).

8. narrative

8.1 discussion

module F05 is entered by calling entry line F05X01. Upon entry, information regarding the return of a WA to a spare queue and the size of the queue is obtained by accessing the linkage word and symbolic queue identifier.

A mask, indicating a Lit lamp, is compared with the lamp status table. If the lamp is already extinguished, a branch to module F02 is initiated. After control is returned to module F05, interrupts are enabled and control is returned to the caller. If the overload lamp is lit, a call to the Lamplighter subroutine is initiated to extinguish the overlamp. Then a branch to module F02 is initiated. After control is returned to module F05, interrupts are enabled and control is returned to caller.

8.2 TECHNIQUE

Not applicable.

* NOTES to FIG. 51

1. interrupts disabled in entry line table by dsimac.

2. interrupts enabled when required by use of enimac.

3. type is used as queue root identity of appropriate spare queue.

4. called to extinghish work area overload.

f05x01 used to return work areas to the spare queues.

input:

(xr1) = work area address

output: none

l13g

1. name

work Area (WA) and Call History Table (CHT) Initializer module.

2. PURPOSE

The WA and CHY Initializer program (module L13G) clears and initializes regular WA's, special WA's, and CHT's.

3. FUNCTIONS

Module L13G performs the following functions:

a. Sets the Register Junctor (RJ) off-line bit, in the corresponding CHT, for each unequipped RJ.

b. Initializes all regular and special WA's and links them to spare queues or hitching posts.

4. INPUTS

4.1 software

4.1.1 core Tables

Cep - engineered Office Parameters

Chq - call History Table

Esw -special Work Area Initialization Table.

Fjb - base level Junk

Hep -engineered Parameters

4.1.2 Drum Tables

None.

4.1.3 Registers

None.

4.2 HARDWARE

None.

5. OUTPUTS

5.1 software

5.1.1 core Tables

Chq - call History Tables

Fhp - hitching Post Table

Fjb - base Level Junk

Fza - special Work Area Table

5.1.2 Drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARD

None.

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

L13g01: l13g01 is branched to clear and initialize regular and special WA's, and CHT's.

6.2 EXIT POINTS

Exit: Reason For Exit

Points

L13d01: (end) L13D01 is used when all the WA's and CHT's are accounted for.

7. SUBROUTINES USED

Entry; Functional Names

Points

F05x01: wadrop - work Area Return.

8. NARRATIVE

8.1 discussion

since WA's and CHT's are not imaged on drum memory, module L13G must initialize these areas before control is transferred to the EAX system. Before the system begins operation, all WA's must be properly linked to a queue or hitching post, and each CHT must reflect its RJ's installed status.

8.2 TECHNIQUE

Module L13G first initializes all allocated CHT's. The quantity of CHT's in a section is an engineerable parameter. For each equipped CHT, a check is performed (in table HEP) to determine if the associated RJ is also equipped. When the bit in table HEP is not set (the RJ is not installed), the off-line bit in the associated CHT is set. A check is performed determining if Office Section two is installed. When Office Section two is installed, module L13G performs the same actions as in Office Section One.

Regular WA's are then initialized. Table HEP is utilized in determining the size, type number, and quanity of each Wa type. The relative depth in the Wa common area is computed for each WA. After the computation, the WA is dropped via the WA Return (WADROP) program (module F05). This operation is performed for each WA type.

Table ESW is utilized in the construction of the special WA's. Each special WA described in table ESW is hitched to its respective hitching post, and the type field of each WA is initialized.

F14 - fig. 52

1. name

call Histroy Table Address Calculator Subroutine.

2. PURPOSE

Module F14 provides centralized calculation of Call History table addresses from Register Junctor identities.

3. FUNCTIONS

Module F14 performs the following functions:

a. Determines whether the Register Junctor identity input is within the range of equipped units.

b. Calculates the relative address of the Call History Table slot in the Call History Table.

c. Returns control to the calling program.

4. INPUTS

4.1 software

4.1.1 core Tables

Cep - call Processing Engineering Parameters Table.

4.1.2 Drum Tables

None.

4.1.3 Registers

Ra - register Junctor identity consisting of Register Junctor Number (0-191) in bits 4-11 and Register Sender Section in bit 12 (0 = Section 1; 1 = Section 2).

4.2 HARDWARE

None.

5. OUTPUTS

5.1 software

5.1.1 core Tables

None.

5.1.2 Drum Tables

None.

5.1.3 Registers

A-register - Validity Indicator

(0 indicates register junctor is not equipped)

(1 indicates calculations successful)

Q-register - Register Junctor identity received as input.

Xr2 - call History Table slot relative address

Xr1 - saved and restored

All other registers are destroyed.

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F14x01: this is the only entry point of module F14 and is called by any program desiring Call History Table address calculation. It may be entered in base level or any interrupt level.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points: The exit point is to return control to the calling program.

7. SUBROUTINES USED

None.

8. NARRATIVE

8.1 discussion

the No. 1 EAX has many programs which need to access a Call History Table slot corresponding to a particular register junctor. The program may not have the index value for accessing the particular slot. To centralize the calculations of that index, module F14, Call History Table Address Calculator subroutine is provided.

8.2 TECHNIQUE

F14 makes a range check on the Register Junctor number before making address calculation.

If bit 12 of A-Register is zero, indicating Register Sender section 1, the Register Junctor number is compared with CEPRE1. If Register Junctor is not greater than CEPRE1, control is then returned to calling program. If Register Junctor number is greater than CEPRE1, A-Register is cleared and control is returned to calling program.

If bit 12 of A-Register is set, indicating Register Sender Section 2, the Register Junctor number is compared with CEPRE2. If the Register Junctor number is not greater than CEPRE2, XR2 is loaded (Register number + CEPRE1) *12 and A-Register is set to 1; control is then returned to calling program. If Register Junctor number is greater than CEPRE2, A-Register is cleared and control is returned to calling program.

Notes to fig. 52

inputs:

ra - rj identity w/section bit

outputs::

ra - validity indicator

xr2 - call HISTORY TABLE ADDRESS

Rq - incoming rj identity

cepre1 = highest value of an equipped rj in rs unit 1

cepre2 = highest value of an equipped rj in rs unit 2

cepra1 = number of call history table entries for rs unit 1

f29 - figs. 53 - 53c

1. name

drum Scheduler

2. PURPOSE

To accept requests for drum I/0, and to initiate or queue these requests depending on the availability of an idle DCU.

3. functions

a. Accepts request from Manipulator or the user.

b. Provides control interlock for the non-resident area.

c. Performs boundary tests to insure that the user has provided adequate buffer area to receive requested data.

d. Provides proper routing of accesses requiring gradual transition when the Update program is active.

e. Provides proper routings of transient write accesses.

f. Determines if the job can be executed on the required DCU(s).

g. Initiates the job if the required DCU(s) is (are) idle.

h. Queues the job on the appropriate drum queue if the required DCU(s) is (are) busy.

i. Returns control to the caller or releases to the Executive.

4. INPUTS

4.1 software

4.1.1 core Tables

Fwa - user's Work Area

Fje - executive Junk Storage

Ncw - update Status Word

Fdp - drum Parameter Table

Cep - engineering Parameter Table

Fsw - work Area Size Table

Chq - user's Call History Table

4.1.2 Drum Tables

None.

4.1.3 Registers

Xr1 - work Area Address

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - user's Work Area

5.1.2 Drum Tables

None

5.1.3 Registers

Xr1 - work Area Address

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: Reasons for Engry

Points

F29x01: this is the only entry point, called by the Manipulator or certain users for access to the drum.

6.2 EXIT POINTS

This module may take one of two exit paths, as specified by the caller:

1. Return to the caller

2. Exit to the Executive's TIME Loop (E01X04)

7. subroutines used

entry: Functional Names

Points

F30a15: called to determine if a job can be executed on a given idle DCU

F30a11 called to initiate a job on a specified DCU

F30a03 called to schedule a user's error program, if required.

F02x01 called to link a job to a specified drum queue

8. NARRATIVE

8.1 discussion

the scheduler acts as an interface between a requestor of drum I/0 and the drum handler. It performs routine functions suchu as NRA control interlock, final initialization of the work area and boundary size checks. The terminal function is to initiate the job (if a required DCU available) or queue it for execution later.

8.2 TECHNIQUE

The bulk of the scheduler's function involves boundary checks on user-provided buffer area, to prevent inadvertent overflow of this area. Several dedicated code paths exist for these checks designed to minimize the real-time required to make them. As employed elesewhere in handling the drum the user's access mode (see Technique section of Drum Handler, F30) is utilized to route the access through the required buffer size tests. Failure to pass these tests will result in termination of the job, and the user's error program being scheduled.

If these tests are passed (or are not required), a check is made to see if one or both DCU's of the specified DUC pair is idle. If so, a subroutine of the Drum Handler is called to verify that the status of the required DCU will permit execution at this time. If so, the Drum Handler is again called, to initiate the job on the DCU. If execution cannot proceed at this time (or the required DUC is busy), then the job is queued up on the appropriate queue for execution later.

F30 - figs. 54 - 54f

1. name

drum Handler

2. PURPOSE

To provide centralized control of I/O with the drum memory system and with DMS isolation programs.

3. FUNCTIONS

a. Provides external interfaces with:

1. Interrupt Cause and Analysis Program

2. DMS Isolation Programs

3. I/O Device Time-Out Audit isolating

b. Initializes DCU Initialization Table with proper control information as required for each specific access to drum

c. Scans queues of an idle DCU in search of jobs awaiting execution.

d. Schedules a user's error program when required.

e. Schedules the user's next program, when appropriate.

f. Handles the occurrence of ready interrupts from DCU's.

g. Processes data from DCU spills into a format requested by the user.

h. Initiates a DCU spill, if requested by the user.

i. Transfers data from DCU initialization table into a user's specified buffer area.

j. Performs validity check on data and control bit removal from data, if requested.

k. Deletes primary data cell and primary address of coincidence, if requested.

l. Clears DCU hardware and associated software indicator in preparation for next job.

m. Initiates a job on the DCU by issuing the appropriate CPD.

n. Supervises special hardware interface required for access into off-line care.

o. Maintains interface with I/O Device Time-Out Audit program.

p. Honors Maniac requests of Reset and Ignore, or Direct/Scheduled Reroute on either error or ready interrupts.

4. INPUTS 4.1 SOFTWARE

4.1.1 core Tables

Fwa - user's Work Area

Fdp - drum Parameter Table

Fsv - status Verify Table

Hst - system Status Table

Fjp - interrupt Level Junk Storage Table

Fdi - dcu initialization Table

Fdm - drum Data Mask Table

Fhp - hitching Post Table

Hrd - dms isolation Status Table

4.1.2 Drum Tables

None 4.1.3 Registers

Xr1 - work Area Address or DCU Identity

Xr2 - subroutine Caller Identity

Xr3 - entry Line Identity

4.2 HARDWARE

Dcu(s) either ready; in error; or in undetermined state, SG No. 65 CCP identity

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - user's Work Area

Fjp - interrupt Level Junk Storage FDI - DCU Initialization Table

Fdp - drum Parameter Table

Fhp - hitching Post Table

Eps - executive Parameter Storage Table

Hel - i/o device Time-Out Audit Timing Table

Cht - user's Call History Table

5.1.2 Drum Tables

None

5.1.3 Registers

Xr1 - work Area Address

Xr2 - dcu identity

5.2 HARDWARE

Dcu cleared: initialized; or placed in spill mode.

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F30x01: not used

F30x02 called by Interrupt Cause and Analysis Program for processing of a DCU ready interrupt.

F30x03: called by Interrupt Cause and Analysis Program for processing of a DCU error interrupt.

F30x04: called by DMS Isolation to process a DCU ready interrupt obtained from a retry of a job.

F30x05: called by DMS Isolation to schedule a user's error program and clear the DCU in use.

F30x06; called by DMS isolation to re-execute a job on a specified DCU.

F30x07: called by I/O Device Time-Out Audit to notify the handler that a DCU has failed to generate a response in the normal amount of time.

F30a02: called by Drum Handler Subroutines II (F41) to scan the queues of an idle DCU.

F30a03: called by Drum Scheduler (F29) to schedule a user's error program.

F30a07: called by Drum Handler subrouting I (F40) to schedule a user's next program.

F30a10: called by Drum Handler Subroutines II (F41) to clear down a DCU and its associated software.

F30a11: called by Drum Scheduler (F29) to initiate a job on an idle DCU.

F30a15: called by Drum Scheduler (F29) to clear a job for execution on a specified DCU.

6.2 exit points

return is always to the caller, regardless of which entry point is utilized; thus each entry is in essence a closed subroutine.

7. SUBROUTINES USED

Entry: Functional Names

Points

P01x01: dms isolation - Called to handle DCU errors on which no Maniac requests exist.

L09x01: maniac MANCHK Processor - Called to obtain Maniac information on a DCU error sense line.

F03x01: unlink - called to unlink a task from one of the DCU queues.

F02x01: link - called to link a job to a queue.

F05x01: wadrop - called to return a user's work area to the spare queue.

P02x01: dms isolation Ignore Error and Return Routine - Called to handle user errors on DCU's which have been allocated to a drum - drum transfer.

P01x03: dms isolation Response/No Job Handler - Called to handle an interrupt from a DCU on which no job is in progress.

8. NARRATIVE

8.1 discussion

all logic required for actual access to the DCU hardware is contained in this module. Those functions which are characteristic to all system device handlers (e.g., MANIAC processing, ready and error interrupt handling, etc.) are included, as well as functions characteristic to the drum alone.

Concerning error handling: the decision logic associated with isolation possible faults and performing necessary hardware configuration is the sole responsibility of the DMS Isolation Program. The Drum Handler provides several utilities that are required for this process; e.g., retries, scheduling the user's error program, processing a `pseudo` ready interrupt (i.e., success occurred on a retry), etc. These utilities are incorporated into the handler because:

1. The handler already contains the necessary code for these procedures (i.e., it is required for normal job processing) and/or,

2. Such an arrangement allows the handler to maintain more efficient and accurate control of the drum as a resource.

8.2 TECHNIQUE

The major criterion in designing the handler was minimization of the real-time requirement for call-processing-oriented accesses. To effect this, the call-processing path is coded separate (where feasible) from the more general processing paths. Since this technique tends to increase the core storage requirement (also at a premium) a secondary effort was made to minimize the additional core storage required. As a result, the handler is organized into a group of 14 functional subroutines, in order to consolidate redundant functions and promote organization.

The result of employing these techniques was to effect the required through put while actually decreasing the core storage requirement.

Functionally, the subroutines are organized as follows:

F30a01 - set up the DCU initialization table as required for a given access to drum.

F30a02 - scan the queues of an idle DCU pair in search of jobs awaiting execution.

F30a03 - schedule a user's error program with a specified error code.

F30a04 - place a work area on a specified executive work queue

F30a05 - not allocated.

f30a06 - process spill data following a DCU spill.

F30a07 - schedule a user's next program.

F30a08 - initiate a required DCU spill.

F30a09 - transfer data from the ITE into the user's specified buffer area.

F30a10 - clear down a DCU and its associated software indicators.

F30a11 - initiate the specified job on the specified DCU.

F30a12 - initialize the specified DCU.

F39a13 - start the I/O device time-out audit on the specified DCU.

F30a14 - perform interrupt processing common to both ready and error interrupts (i.e., handle response/no job, maintenance abort of a user's job, Maniac reset and ignore, maniac direct or scheduled reroute, etc.).

F30a15 - verify that a specified job can be executed on a specified DCU, in view of that DCU's system status.

Such an organization allows the handler to function in a minimum amount of core, while not significantly compromising the real-time objective. In addition to being utilized internally, these subroutines are also utilized by other drum modules (i.e., F29, F40 and F41) in order to satisfy interface requirements and promote core reduction.

As noted previously, every practical attempt is made to segregate call-processing accesses from other access types. Currently the only method available for doing this is to use the user's access mode. Each access to drum is assigned one of several access modes, which identifies access for certain processing characteristics. For call processing, the assigned access mode is zero; unfortunately, many other non-call-processing accesses also utilize this access mode, whose processing requirements may vary radically from those normally attributed to call-processing. Therefore, the user's access mode represents at best a `rule-of-thumb` for routing drum requests into dedicated code paths. Nevertheless, use of this and other techniques has enabled attainment of the throughput and core reduction goals.

F31 - figs. 55 - 55b

1. name

communication Control Register (CCR) Scheduler

2. PURPOSE

In a general sense, the CCR hardware and software is for the purpose of enabling communication between the Data Processing Unit (DPU) and the Marker subsystems (Originating Marker - OM and Terminating Marker - TM). In this context, F31 is the initial CCR processor (scheduler) of DPU software programs (clients) that desire to: (a) command the TM hardware for call processing purposes, (b) command and/or interrogate the CCR, OM, or TM, hardware for maintenance purposes.

The CCR, OM, or TM reply to a (F31 client) maintenance interrogation (or confirmation/response to a maintenance command is always in the form of data words put in the CCR hardware, this answer data will then be loaded into the F31 client work area. The TM's final "response" to a (F31 client) call processing command, is also in the form of data words put in the CCR hardware and then loaded into the F31 client work area (actually, this response is mostly the TM's indication that it has, or has not, completed the conversation path).

On the other hand, one type of communication between the marker and the DPU does not involve a F31 client; this is when the OM sends call processing data to the DPU. This communication is initiated solely by the OM and reaches the DPU without going through a F31 client.

F31, more specifically, schedules clients with I/O requests, for entry into the CCR Handler program F32, so that these requests may be carried out. As stated above, these clients can be divided into two general classes: Requests for normal call processing involving the TM, or requests for maintenance upon CCR hardware, the OM, or the TM.

3. functions

module F31 performs the following functions:

a. Checks that client requests are proper and fulfillable.

b. F31X01 classifies clients into one of the three following groups for entry into the CCR Handler program (the clients are actually put into one of five queues): (1) Maintenance on the CCR frame hardware, (2) Maintenance on the OM, or TM and (3) normal call processing involving the TM. Groups 1 and 2, above, are of a higher priority than group 3.

c. F31X02 allows a quick status snapshot of the CCR frame hardware, for CCR maintenance. In this case the client is branched directly (not scheduled) to the CCR Handler, to obtain the data.

d. During the CCR performance of the client I/O task, the client may, or may not, have control returned (as he requests). When control is not returned to the client, during the performance of the I/O task, then F31 branches to EO1X04 so that other DPU work may continue while the I/O task is being performed (the I/O task is like a closed subroutine). After completion of the I/O task, the events described below (item (e) will occur.

e. When F32 (and/or other CCR software) completes the I/O task for a "F31 client", the NPG (next program client requests) is then given control: this NPG is a F31 client parameter (selection), and may be merely a return to the client himself. In the event of an error occurring before completion of the I/O task, the ERP (error program client requests) is given control via EO1X01. After the I/O task is completed, then a CCR software program (usually F32 or F31) calls F38 which in turn calls the Executive scheduler E01X01, which schedules the NPG.

4. inputs

4.1 software

4.1.1 core Tables

Eps - (also an output table) Executive Parameter Storage

Esl - (also an output table) Executive Storage Location

Fat - ccr address Translation

Fsw - work Area Size

Fwa - (also an output table) Executive Interface Work Area

Fwd - tm sent Information

Hst - system Status

4.1.2 Drum Tables

None

4.1.3 Registers

X1 - work Area Identity

X3 - entry Line Number

4.2 HARDWARE

None

5. OUTPUTS

5.1 software 5.1.1 core Tables

Eps - (also an input table) Executive Parameter Storage

Esl - (also an input table) Executive Storage Location

Fwa - (also an input table) Executive Interface Work Area

Has - mcr audit

Swb - ccr dump Area B

5.1.2 drum Tables

None

5.1.3 Registers

X1 - work area identity if client of F31X02 requests return

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F31x01: called by clients wishing to communicate with the markers (OM or TM) by using the CCR; or clients just wishing to communicate with the CCR only

F31x02: called by clients wishing to obtain a quick status dump of the CCR A or CCR B hardware unit.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

E01x04: this exit returns control back to the Executive, so that the usual DPU software programming can continue.

Return to Caller: When exit E01X04 is not used, then return is always made to the client of F31.

7. subroutines used

entry: Functional Names

Points

F36x06: places the status of CCR A or B into table SWB so that the F31X02 client may receive it

F02x01: links the F31 client to one of the five queues for entry into F32X01

F38x01: used by entry line F31X02, when F31 client does not ask for return F38X01 will schedule the program that this client wants to run (NPG).

F38x03: used by entry line F31X02 and F31X01 to schedule the error program (ERP).

F32x01: initiates the I/O task which is requested by the F31 client. This program is not a usual F31 subroutine in the sense that once initiated by F31, it may start an I/O task for the highest priority F31 client and this task (being I/O) can continue after control is returned to F31. Software processing and this CCR I/O can occur at the same time, unlike the case of two software programs where only one can have control at a time.

8. NARRATIVE

8.1 discussion

8.1.1 entry f31x01

the first check by F31 is to determine if the client desires: (1) a Marker operation (which, of course, makes use of the CCR to communicate with the marker), or (2) a CCR-only maintenance operation. Checks are then made to ensure that a large enough work area had been asked for by the client (depending on the type of CCR or marker operation): if not, error field FWAEIO is set to 5. In the case of a marker operation, when the client specified marker is not in the present EAX office, error field FWAEIO is set to 3. In both of the above error situations, F31 will call subroutine F38X03 so that the client specified error program can be scheduled. After F38X02 has scheduled the error program, F31 continues with other client processing. Next, clients are classified into one of five queues: queue 0 = CCR maintenance operation; queue 1 = OM or TM maintenance operation; queue 2 = TM non-maintenance operation (pair one); queue 3 = TM non-maintenance (pair 2); queue 4 = TM non-maintenance operation (pair 3). The order of queue priority is as follows: queue 0 is highest; queue 1 is second, queue 2, 3, and 4 are of third order priority. The placing of clients into the above five queues is based on the values set in field FATQNU (for OM's and TM's); except that a TM maintenance operation is put into queue 1 rather than 2, 3, or 4. The decision to place a TM operation into queue 1 (rather than 2, 3, or 4) is based on its being a maintenance (high priority) rather than a call processing (low priority) operation (when field FWAPQT is 1, then the client is a high priority maintenance job, and the TM Client is put into queue 1). A CCR maintenance operation is placed into queue 0 when it is identified as such (by a 1 in field FWAOPT). When an OM operation (queue 1) is to be performed, a check is made to determine if the client has also asked for a high priority request (field FWAPQT set to 1); this high priority request should be made for all maintenance jobs, and an OM operation should be always be a maintenance job for F31 clients. If the high priority request is not made, then error field FWAEIO is set to 4, indicating a client mistake, and subroutine F38X03 is called. For TM operations, as stated above, field FWAPQT may be set to indicate either high or low priority (maintenance or non-maintenance).

After classifying client into one of the above five queues, this queue data is placed in junk storage FJE004, and a bias number is added, FQ036. At this time subroutine F02X01 is called to place the client job into the previously determined queue, for entry into the CCR Handler F32. Next, F32 is momentarily given control to allow it to initiate an I/O task for the highest priority job in its queues, (probably not the current F31 client), F32 may or may not be able to take advantage of this opportunity; if it does then it can initiate the I/O task and then pass control back to F31. Whether or not F32 can initiate an I/O task, control is shortly passed back to F31 (the main purpose of this program step, which occurs during every use of F31, is to allow every opportunity for the initiation of a F32 I/O task-which once initiated can continue on its own, while other processing continues by F31). The next program step by F31 is to return control to the client, if the client has asked for this option (field FWADGT set to 1); this allows the client freedom to perform some other job while F32 is working its way around to performing the client I/O task. When the client does not request control, then: (1) If the client was a non-resident program and he requested this non-resident area held for him, it is held; otherwise it is not held, and (2) Program E01X04 is given control so that other DPU processing may continue.

8.1.2 ENTRY F31X02

This entry line is used by clients wishing to obtain a quick status dump of CCR A or CCR B hardware.

First a check is made to ensure that the work area is large enough; if not, error field FWAEIO is set to 5, and if the client does not ask to be returned to, then the client specified error program is scheduled by F38X03 (this error program may be the client himself). If the client wants to be returned to (field FWADGT = 1), then he is and the error program is not scheduled. In any case (client return or not), the usual end flow of the program is the same: (1) F32 momentarily called to allow initiation of any pending I/O task - this task would not relate to a F31X02 client, (2) F32 release of non-resident area, if appropriate, and (3) calling of E01X04 to allow other DPU processing to continue. Note that other errors during F31X02 follow the same flow (other errors: CCR out of service, FWAEIO = 1; CCX error, FWAEIO = 1).

Assuming no errors, the client requested hardware unit A or B is selected and its status is looked up in core table HST. The status data is loaded into table SWB (by subroutine F36X06) where the client may access it. After this, when the client does not directly ask for a self-return, subroutine F38X01 schedules the NPG (which may also be just a return to the client; if client return is requested, when the NPG is not scheduled. In any case, the final sequence by F31 is the same as for the above error sequence: (1) Calling of F31 to allow any current (but unrelated) I/O task initiation (2) F31 release of non-resident area, if appropriate, and (3) scheduling of E01X04.

8.1.3 input flow

this section lists the type of request that a F31 client may make of the CCR software programs (principally, the CCR scheduler F31 and the CCR Handler F32) and thereby indicates the general functional flow involved in fulfilling these requests. The input which an F31 client must supply can be broken down into three areas: (1) Client input options; covered in a general way, in the description of input parameters (2) Client supplied input data, and (3) General input restrictions for F31 clients, not covered in other input parameter documents.

These three areas are listed below:

(a) Client Input Options of Special Importance.

1. P1; The identity of the next program to schedule at the completion of the I/O request (for a F31 client, the I/O task would be completed by F32; for F31X02 client, the task would be completed by F31). This parameter is not needed when the client is finished with his overall job after the completion of the I/O task. This NPG information is stored in field FWANPG.

2. P7: The logical request number which specifies the mode of data transfer to employ. These detailed options, for the F31 client, are listed in document D-3.44.21* appendix A: which covers the pertinent fields of core table FWA, dealing with the control of various I/O devices, (a F31 client would be employing the OM, TM and/or CCR). Some of the most important P7 options are described below, along with the name of the FWA field that relates to the option.

a. Enabling of the ability to specify a particular OM or TM; contained in field FWASMR. Specification of the exact OM or TM is accomplished in table FWD (see paragraph 8.1.3, (a), (2), below).

b. Specification of a particular CCR (CCR A or CCR B): contained in FWACRI and FWASCR.

c. Specification that the transmission be done in prime mode: contained in FWASMP.

d. Specifying CCR data dumps (status and data data) before and after the message is sent to the marker (OM or TM) and also after the message is received back from the marker: contained in FWADMC.

e. The ability to indicate that the client (who is performing maintenance) is using an OM to simulate calls entering the EAX office, and that if a malfunction occurs, maintenance recovery routines should be called: contained in FWAVTS.

f. Specification that should the client requested OM be found to be not on-line, then a standby CPD (control pulse directive) will or will not be issued: contained in FWASOM.

g. Specification of special modes of data transfer and scheduling in marker operations (includes direct commands to the markers): contained in FWACDR.

h. Specification of special modes of data transfer and scheduling in CCR operation, a 0 or 1 in this field specifies a marker or a CCR operation: contained in FWAOPT.

Note: when unload-CCR-status-word is specified, (an option of a F31X02 client) and return to client (FWADGT = 1) is also requested, the scheduling of the NPG is not performed by F31.

i. Client can specify timer size he wants in field FWATMS. If the client asks for timer size 5, and also requests FWACDR = 2 or 4, then he also specified a Schedule on Idle. This means that when the marker is idle, the program will know that the client job is completed; this is faster than the usual timeout method of knowing that the client job is completed.

3. P8: The program type, which specifies the type of action to be taken concerning return of control, scheduling of other programs, release of work area, and control of the non-resident area (see Document D-3.44.21*, appendix B, which describes the pertinent field FWAPGT).

4. P9: The priority queue type, which specifies the type of queue to link the client request to, for entry to F32.

b. Client Supplied Input Data

1. When a F31 client is using a TM for either call processing or maintenance purposes, he may also supply Register Junctor Identity (RJI) date (put into field FWARJI) and Register Sender Instruction data (put into field FWARIN); note that when FWARIN is set to 0, F31 will not act on this field: that is, the field will not be sent to the Register Sender for translation (as in OM maintenance). In the case of TM maintenance the client may employ field FWAVTS (when he is simulating a normal call entering the EAX office) so that in the event of an error, Maintenance recovery routines wlil be employed - rather than call processing recovery routines.

2. When the client wishes to send maintenance data to the OM, or TM, or to send call processing data to the TM, he must employ core table FWD words 00 through 03: among other options, this table allows selection of a particular OM or TM (the client must have employed field FWASMR so that table FWD can be used to specify an exact OM or TM, see paragraph 8.1.3, (a); (2), a. This four-word area of table FWD is set up to match the input format of the markers: the first two data words for OM requests; and all four data words for TM requests.

c. General Restrictions to clients of F31.

1. F31 must be called from base level, it cannot be entered in the interrupt mode.

2. Depending on the nature of the client requests, a large-enough work area must be asked for by the client to hold all pertinent data. The minimum size requirements for all clients are listed below:

a. All clients using entry line F31X02 must have a minimum of a 28-word area.

b. F31X01 client: If CCR status dumps are requested (FWADMC = 1), or if a CCR operation is requested (FWAOPT = 1) with a CCR-to-CCR transfer (FWACDR = 6 or 7), then a minimum of a 40-word work area is required.

c. F31X01 client: When a CCR status dump is not requested (FWADMC = 0), and a CCR operation is requested (FWAOPT = 1), other than a CCR-to-CCR transfer (FWACDR = 1, 2, 3, 4, or 5: for a non CCR-to-CCR transfer), then a minimum of a 28-word work area is required.

d. F31X01 client: When a CCR status dump is not requested (FWADMC = 0), and any marker operation is requested (FWAOPT = 0), then a minimum of a 20-word work area is required.

3. All F31 clients, other than TM call processing requests, should be marked as high priority (FWAPQT = 1). In the event a OM request is not marked high priority, F31 will give an error return because an F31 client should only be making a maintenance request regarding an OM.

4. If the client is non-resident (non-core-resident) and his error program (P3) is scheduled, he will not be allowed to remain in control of the non-resident area, even if he has asked to be. If the error program is non-resident, it must be read from the drum.

8.1.4 OUTPUT FLOW

The following description lists the type of output that an F31 client receives back from the CCR software programs (principally the F32 and F31 programs) and thereby indicated the general functional flow involved in fulfilling the F31 client request. Types of outputs that an F31 client receives are:

1. Error outputs, principally from F31 and F32,

2. data outputs from F32, and

3. "Indirect" outputs from F31.

These three areas are listed below:

a. Error outputs to F31 clients are contained in field FWAEIO (program F31 and F32 send the majority of these error outputs). Error outputs coming from F31 only, back to client, are: field FWAEIO = 1, 3, 4, or 5.

Another type of error output, actually a special maintenance data output to F31 clients, is contained in an overlay of the FWAEIO field: Maintenance data field FWAMDA (consists of bits MD1 through MD5) and bit FID.

When bit FID is 1, field FWAMDA is being presented, rather than field EIO, and the five bits that comprise it must be interpreted as individual bits, rather than one binary number. Specifically, bit FID is 1 when a maintenance request is being processed (an F31 client from queue 0 or 1) and field MDA is interpreted as follows (depending on the exact type of maintenance being performed by the F31 client and the options he selects):

1. Field FWAMDA (bits MD1 through MD5) Definition for given F31 clients in Queue 1. __________________________________________________________________________ a. OM maintenance client using FWACDR=1 No-error is usually option (SR data) indicated by this output __________________________________________________________________________ Bit MD1 1=CPD (control pulse directive sent out 1 from CCR. Bit MD2 1=Data received from marker 1 Bit MD3 1=Marker malfunction 0 Bit MD4 A 1 is inappropriate * 0 Bit MD5 A 1 is inappropriate 0 *"Inappropriate" means that a 1 occurring under these conditions indicates some unknown problem (for bit MD4 it is probably a sign of marker error). b. OM maintenance client using No-error is usually FWACDR=2 option (schedule on indicated by this output: fault or timeout): Bit MD1 1=Data sent out from CCR 1 Bit MD2 1=Data received from marker 1 Bit MD3 1=Marker malfunction 0 Bit MD4 When marker is on-line 1, if marker is on-line 1=standby interrupt rec'd from marker 0, if marker is off-line When marker is off-line a 1 is inappropriate Bit MD5 If client takes option, ** 1, if either option 1=status drum provided by is taken. CCR. If client takes option** 1=marker idle (indicating job final) 0, if no option taken. If option not taken a 1 is inappropriate **FWADMC = 1 for status dumps, timer size 5 and FWACDR = 2 or 4 for marker idle c. OM maintenance client using FWACDR=3 No-error is usually option (schedule on ready): indicated by this output: Bit MD1 1=Data sent out from CCR 1 Bit MD2 1=Data received from marker 1 Bit MD3 1=marker malfunction 0 Bit MD4 When marker is on-line 1, if marker is on-line 1=standby interrupt rec'd from marker 0, if marker is off-line. When a marker is off-line a 1 is inappropriate. Bit MD5 If client takes option, 1, if option is taken. 1=status dump provided by CCR 0, if no option is taken. If option not taken, 1 is appropriate. d. OM maintenance client using FWACDR=4 No-error is usually option (simulate origination): indicated by this output: Bit MD1 1=Data sent out from CCR. 1 Bit MD2 1=Data received from marker 1 Bit MD3 1=marker malfunction 0 Bit MD4 When marker is on-line 1, if marker is on-line 1=standby interrupt rec'd from marker. 0, if marker is off-line. When marker is off-line a 1 is inappropriate. Bit MD5 If client takes option, 1, if option is taken. 1=status dump provided by CCR 0, if no option is taken. If client takes option, 1=marker idle (indicating job finished). If no option taken, a 1 is inappropriate. e. OM maintenance client using FWACDR=5 No-error is usually option (reset CPD). indicated by the following output: Bit MD1 1=CPD sent out from CCR 1 Bit MD2 A 1 is inappropriate 0 Bit MD3 1=Marker malfunction. 0 Bit MD4 A 1 is inappropriate 0 Bit MD5 A 1 is inappropriate 0 f. TM maintenance client using FWACDR=1 No-error is usually option (SR data): indicated by the following output: Bit MD1 1=CPD sent out from CCR. 1 Bit MD2 1=Data received from marker 1 Bit MD3 1=Marker malfunction. 0 Bit MD4 A 1 is inappropriate. 0 Bit MD5 A 1 is inappropriate. 0 g. TM maintenance client using FWACDR=2 No-error is usually option (schedule on fault or indicated by the timeout): following output: Bit MD1 1=Data sent out from CCR. 1 Bit MD2 1=Data received from marker. 1 Bit MD3 1=Marker malfunction. 0 Bit MD4 A 1 is inappropriate 0 Bit MD5 If client takes option, 1, if option is taken. 1=status dump provided by CCR. 0, if option is not taken If option not taken, a 1 is inappropriate. h. TM maintenance client using FWACDR=3 No-error is usually option (schedule on ready): indicated by the following output: Bit MD1 1=Data sent out from CCR. 1 Bit MD2 1=Data received from marker. 1 Bit MD3 1=Marker malfunction. 0 Bit MD4 A 1 is inappropriate 0 Bit MD5 If client takes option. 1, if option is taken. 1=status dump provided by CCR. If option not taken, a 1 is inappropriate i. TM maintenance client using FWACRD=5 No-error is usually option (reset CPD): indicated by the following output: Bit MD1 1=CPD sent out from CCR. 1 Bit MD2 A 1 is inappropriate. 0 Bit MD3 1=Marker malfunction. 0 Bit MD4 A 1 is inappropriate. 0 Bit MD5 If client takes option, 1, if option is taken. 1=status dump provided by CCR. 0, if option is not taken. If option is not taken, a 1 is inappropriate. (2) Field FWAMDA (bits MD1 through MD5) Definition for an F31 client in Queue 0. CCR maintenance client employing CCR No-error is indicated to CCR transfer (FWAOPT=1, and by the following FWACDR=6 or 7): output: Bit MD1:1=Data transmission 1 initiated from CCR (to other CCR). Bit MD2:1=Receiving CCR received 1 data successfully. Bit MD3:1=Receiving CCR did not get 0 data successfully, but status dumps still provided. Bit MD4:1= Data not successfully 0 sent out from CCR (to other CCR), but status dumps still provided. Bit MD5:1=Data successfully sent 1 out from CCR (to other CCR). __________________________________________________________________________

b. Data output concerning TM call processing, and OM, TM, or CCR maintenance requests are contained in table FWC words 00 through 03. As in the case of input table FWD, output table FWC is set up to match the output format of the markers: two data words for OM outputs and four data words for TM outputs.

The other major output data is contained in words 00 through 03 of tables SWA, SWB, SWC, SWD and SWE. This information is data concerning certain CCR maintenance operations (this includes all CCR status dumps). Output data from the OM maintenance operations concerning a F31 client (performing maintenance) that is simulating a normal OM call processing request, is contained in the following fields: (1) FWARJI, which contains the RJ identity, and (2) FWACHT, which contains the call history table address.

c. Indirect outputs from F31 are changes in certain work area fields that F31 makes during the course of processing a client. These changes are not usually thought of as outputs but the changed field can be made use of by F31 clients, if desired. The following fields may be altered F31 clients, FWANPG, FWAELN, FWAPRI, FWAFEP, FWAFEL, and FWAFPR, and FWAFPR.

8.2 technique

not applicable.

F32a - figs. 56 - 56h

1. name

f32a - ccr i/o initiation handler

2. purpose

the purpose of F32A is to centralize control of hardware, to perform operations necessary to prepare the markers and CCR for operation and initiate data transfers between the CPU and the CCR and between the CCR and the marker.

3. FUNCTION

A. determine if the on line active CCR is available for output.

B. determine if an reconfiguration of the CCR's is required and, if so, call F36X08 - CCR Reconfiguration Subroutine.

C. determine if a request for I/O is queued for an idle device.

D. unqueue the request.

E. initiate the request (which may involve interlocking between a register junctor and a terminating marker.

F. interface with CCX recovery to detect and isolate faults in CPU-CCX-CCR path.

G. return to the calling program.

H. f32x05 is provided to enable retries of transmission a terminating marker by F37-CCR Error and Recovery.

I. f32x07 is a closed subroutine whose function is to attempt to place a specified CCR MOS request CCR Isolation on the CCR, and set a unit maniac just ignore on the device. It then will call F36X08 to achieve reconfiguration and return caller.

4. INPUTS

4.1 software

4.1.1 Core Tables

Els exec. storage Location Table

Fat ccr add trans. Table

Fcc om-rj identity

Fhp hitching Post Table

Ers register Save Table

Fjp interrupt Level Junk

Fqo --

fra queue Root Table

Fwa exec. interface Work Area

Fwb cp reg/SNOR Memory Image

Fwd tm sent Information

Hcd diacon config. Table.

Hcx ccx parity Error Flag

Hel i/o abort Entry Line

Hpp --

hst system Status Table

Spe --

sta --

swb ccr dump Area B

4.1.2 drum Table

None

4.1.3 Registers

None

4.2 HARDWARE

None

Entry Points

F32x01: scan I/O Queues

F32x05

ersked

speccr

loadcr

status

chkcpd

start

f32x07: set CCR MOS, Calls DIACON, set MANIAC to just ignore and reconfig. CCR's

5. OUTPUTS

5.1 software

5.1.1 Core Tables

Fcc - om-rj identity

Fwa exec. interface Work Area

Fwb cp reg/SNOR Memory Image

Hak system Clear

Swb ccr dump Area B

Swd ccr dump Area D

5.1.2 drum Tables

None

5.1.3 Registers

None

5.2 Hardware

None

6. Controls

6.1 Entry Points

F32x01 scan I/O Queue

F32x05

f32x07 set CCR MOS, CALL DIACON, Set Maniac to just ignore, and reconfigure CCR's

6.2 Exit Points

Return is made to client.

7. Subroutines Used

E01x03 dpu scheduler

E02x01 1 cap level 1 (Start Interval Timer)

F01x01 rs scan interlock

F02x01 link to mkr maint. queue

f03x01 unlink work area from i/o queue

f04x01 work Area Assignment

F02x03 link work area back to I/O QUEUE

F34x01 cr handler 2

F36x08 ccr reconfiguration: CR Subroutine 1

F38x04 abort I/O TASK: CR Subroutine 2

F38x03 schedule ERROR Program

L01x04 mainf interrupt access

l20x01 elt, diarot, diabrt

l50x02 set Unit Maniacs

S31x03 channel Multiplex Recovery

S31x01 clock CCX Errors

8. NARRATIVE

8.1.1 discussion

when a call is received by F32X01, the standard status word of the online active CCR is dumped by F36X06. IF the CCR is idle and scanning, a check for a reconfiguration request is made. If the CCR is not idle and scanning the time out audit bit is set and the system returns to the calling program. When reconfiguration is required, it is accomplished by F36X08. Then a check is made for a line transmission request by the Marker Fault Interrupt Processor (52), if so the Maniac is set to reset and ignore. Checks are now made for CCR requests, marker maintenances requests, and termination requests (in that order). If none of these are requested, the system is returned to the calling program.

Diagnostic Requests

In the event that the CCR queue are not empty (CCR request) A CCR-CCR transfer is tried. If successful F36X05 provides a sink for CCR status dump in SWD and sets up the CCR's. F36X06 then provides a source status dump in SWB. Four data words are loaded and sent to the other CCR and the system returns to the calling program. If the CCR transfer was unsuccessful, the status words are dumped into SWB and the data words are dumped into FWC. F38X01 then schedules the next program and the CCR request is checked again.

If there is a marker maintenance request, a marker is selected to be tested. In the case where there are no markers available, the check for a marker maintenance request is made again. When there is a marker available, a check for a CPD request is made. In the case of a CPD request, the CPD is sent. Then the check for the termination request is made and the system returns to the calling program. When there is no CPD request, a check is made to determine if this is an OM or TM request. If a status dump in SWB is requested, it is accomplished by F36X06. If this is a OM request, two words are loaded and sent to the OM and the system returns to the calling program. If this a TM request, a check is made to see if RJ interlock is required. If there is trouble with the interlock, EIO is set to 7 and the marker maintenance request is check again. If there is no trouble, four data words are loaded and sent to the TM and the system returns to the calling program.

If there is a termination request, a check is made to see if the TM is idle. If not idle, the termination request is check again. When idle, a TM is picked and checked for its availability. If not available, the termination request is checked again. If available an RJ interlock is executed if it is required. If there is trouble in the RJ interlock, EIO is set to 7, F38X03 schedules error program, and the termination request is check again. If there is no trouble, four data words are loaded into the CCR and sent to the TM. Now the system returns to the calling program.

F32b - -56i - 56n

1. name

f32b-ccr ready interrupt processor

2. purpose

module F32B is provided to handle all ready interrupts generated by the CCR hardware.

3. FUNCTION

A. provides maniac functions reroute and reset and ignore.

B. handles originations, including performing RJ translation, interlocking RJ with originating marker, and scheduling C01 with the call history table for the RJ selected by the OM.

C. completes termination attempts by putting 4 data words from terminating marker in users work area and scheduling his next program.

D. provides handling for diagnostic requests, including data words, status dumps options and scheduling options.

E. calls F32X01 to attempt to initiate next I/O request.

F. return to ICAP.

4. inputs

4.1 software

4.1.1 Core Tables

Chq program generated INDEX

Fcc om-rj identity

Fhp hitching Post Table

Fwa exec. interface Work Area

Fwc tm received information

Hab 6 bit error count B Table

Has mcr audit Table

Hcd diacon configuration table

Hcs cxx parity error flag

Hmd marker Matrix Comb Table

Hmn maniac Condition Table

Ncw update control word

Swa ccr dump Area A

Swb ccr dump Area B

Swc ccr dump Area C

Swe ccr dump Area E

4.1.2 drum Table

None

4.1.3 Registers

None

4.2 Hardware

None

5. OUTPUTS

5.1 software

5.1.1 Core Tables

Cha scheduling Information

Chc om data frame record

Chq program generated index

Fjp interrupt Level Junk

Fom ccr handler Control

Fwa exec. Interface Work Area

Fwc tm received information

Hel i/o abort entry lines

5.1.2 Drum Tables

None

5.1.3 Registers

None

5.2 Hardware

None

6. Controls

6.1 Entry Points

F32x02

6.2 exit Points

Return is made to ICAP

7. subroutines Used

C0x01 class of service initialization

E01x01 schedule F07X06 to Output (DPU Scheduler)

F04x01 work Area Assignment

F07x06 schedule Pre out

F02x01 link to CPU Queue

Schedule C01X01 with CHT as Work Area

F02x03 link WA back to I/O Queue

F14x01 call History Table Address Calculation

F32x01 scan I/O Queue

F32x03 return to ICAP

F33x01 rj translation

F36x02 handles Reroute

F36x06 cr subroutine: Dump Data into FWC and Status into SWE

F38x01 schedule Next Program

F38x03 schedule Error Program

F38x04 abort I/O Operation

K05x01 om-cfs recognition Test

L20x05 elt, diarot, diabrt

log - -

S31x01 check CCX Errors

8.1 DISCUSSION

This module handles data transmissions from CCR and markers to the computer central processor. The first case to be treated here will be a call processing origination. F32X03 is entered by the interrupt cause and analysis program for a CCR ready interrupt. F32B checks to see whether any MANIAC conditions exist on the ready interrupt. The I/O time-out audit is reset for the particular ready interrupt. The standard status word and data words 0 and 1 are gathered. At this point originations are separated from terminations. The CSO field is interrogated to determine if any blockage was indicated.

Next, the register junctor identity is translated from the marker data words. Then the call history table address associated with the call is calculated. The register sender memory is instructed and call history table initialized. Marker malfunction interrupts are checked for any MANIAC's. And C01 (the first call processing module) is scheduled with the call history table used as a work area.

The queues are scanned for any other jobs, if one is found it is initiated if not control is returned to Interrupt Cause and Analysis.

The second case is data sent from a Terminating marker to the computer central processor for a termination. Four terminating marker data words are unloaded from the CCR. The section field of the TM frame word is altered to correspond with the frame word passed by call processing. Call processing's next program is scheduled and the queues are scanned for another job to initiate. Afterwhich control is returned to Interrupt Cause and Analysis program.

The third case is that of the diagnostic access. The options for these accesses are:

1. Schedule upon ready

2. Schedule upon interval timer expiration

3. Reset the marker

4. Send shift register data

After retrieving the standard status word a check is made to determine whether diagnostic was an originating marker, a terminating marker or a CCR diagnostic. For a TM or a CCR diagnostic a status dump is performed.

For marker diagnostics the shift register data access will abort the job, schedule the next program and scan the queues.

For a fault or timeout with schedule on idle option the originating marker in question will be reset and the queues will be scanned.

For test calls an indicator will be set and RJ translation will be done and call history table address will be calculated except that C01 will not be scheduled because this is not a real origination.

Status dump may be taken if the access indicates. The CCR hardware is cleared down and reset for further use.

F-33-figs. 57 -57a

1. name

f33 - register Junctor Translation Program Module

2. PURPOSE

This module translates an Originating Marker communication frame, containing a line matrix R-Unit Outlet identity (LRO) or a trunk register B-Unit outlet identity (TBO), into the identity of the connecting Register Junctor (RJ number and Register Sender section number). This allows completion of the path from the inlet into the Register Sender.

3. FUNCTIONS

Module F33 performs the following functions:

a. Determines if the LRO or TBO identity input is within the range of equipped units and is a valid unit.

b. Looks up, in the RJ translation tables, the local RJ or an incoming trunk RJ that is valid and connects to the client-specified LRO or TBO.

c. Returns to the program that requested the translation with the local RJ or incoming RJ identity (this identity includes the Register Sender section containing the RJ).

4. inputs

4.1 software

4.1.1 core Tables

Fap - pointer to Absolute Matrix Table.

Fer - error Constant Register Junctor Translation Table

Flb - pointer-to-Line Register Junctors for Office Section 2 Table

Flr - line Register Junctor Table

Fsa - absolute Matrix For Subsection 1 Table

Fsb - absolute Matrix for Subsection 2 Table

Fsc - absolute Matrix for Subsection 3 Table

Fsp - pointer-to-Section Tables for Register Junctor Table.

Fta - pointer-to-Trunk Register Junctor for Office Section 1 Table

Ftb - pointer-to-Trunk Register Junctor for Office Section 2 Table

Ftr - trunk Register Junctor Table

Fts - pointer for Trunk Register Junctor for Selector Section Table.

4.1.2 Drum Tables

None

4.1.3 Registers

X1 - work area identity (optional).

Ra - originating Marker Data Frame word O.

Rq - originating Marker data frame word 1.

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

5.1.2 Drum Tables

None

5.1.3 Registers

X2 - trouble indicator.

Ra - rj identity

Rq - indicates incoming RJ or local RJ.

5.2 hardware

none

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F33x01: this entry point is called via the PGLINK macro to obtain RJ translation as a closed subroutine.

6.2 EXIT POINTS

Return is made to client.

7. SUBROUTINES USED

None.

8. NARRATIVE

8.1 discussion

the general method used to determine the appropriate local RJ (LRJ) or incoming RJ (IRJ) output is briefly described here. A lookup in Table FLR (containing LRJ's) or Table FTR (containing IRJ's) is made to find the RJ indexed by the input LRO or TBO. In this lookup process, two levels of indexing are used, first X1 for the section, then X2 for the matrix, to obtain a pointer to a block of 10 or 20 words in Table FLR or FTR. This block corresponds to a certain value for SEC, SBS, and MTX. The precise location of the desired RJ identity within the block is pointed to by the value of the RUO (local RJ) or BUN and BUO (incoming RJ). Thus, the complete definition of LRO or TBO identity points to the desired RJ identity.

In order to establish the final link of the path from the line group to the local RJ or from the trunk register group to the incoming RJ, it is necessary to identify the one unique RJ that connects to the specific RUO (for the trunk register group path), or to the specific BUO (for the trunk register group path). Therefore, when F33 is entered with part of an Originating Marker data frame (data words 1 and 0), containing the identity of an LRO or a TBO, F33 determines (translates) the identity of the RJ related to his LRO or TBO.

The complete identity for an LRO consists of the following fields in an Originating Marker data frame: Section (SEC), Subsection (SBS), Line Matrix Number (MTX), B-Unit Outlet (BUO), and R-Unit Outlet (RUO). The TBO consists of the following fields: Section, Subsection, Trunk Register Matrix (MTX), B-Unit Outlet, and B-Unit (BUN). The input to F33 also includes the AB group number. When the value of the AB group is 1 through 5, then the input is an LRO.

F33 returns the RJ identity to the client in the form of the RJ identity field of Table FWA.

Specifically, the output consists of an RJ number ( 0 through 191), and a Register Sender Section number (0 or 1): all RJ's are within RS section 0 or 1.

When the entry is an LRO, the RJ number identity is located by a lookup in Table FLR. This table contains a listing for all local (non-trunk serving) RJ's, and the location of the LRO identity within Table FLR specifies a particular RJ.

The general block of 10 or 20 words within Table FLR specifies the section, subsection , and matrix of the LRO which connects to a given RJ. The same RJ number is at more than one location within the same data block, because the RJ is connected to more than one R-Unit. Additionally, the RJ number may be located within several different data blocks, when the RJ is connected to more than one matrix. (In the case of the incoming trunk RJ, the connection will be to subsections and matrices.) Of course, only one RJ matches a given LRO entry.

The RJ number identity contained in Table FLR also has a validity bit indicating the useability of the particular RJ and LRO; when the validity bit indicates unuseability, or when the RJ is not found or is out of range. Register X2 equals 1, thereby indicating general trouble.

A similar procedure is followed for TBO's, which connect to incoming RJ's, as with LRO's, which connect to local RJ's, except that the IRJ identities are contained in Table FTR. In addition, when the given TBO is located in an EAX Selector Section, rather than Office Section, then an additional decoding process must be performed using Table FAP to determine the altered matrix identity associated with the TBO input.

8.2 TECHNIQUE

None.

Input to FIG. 115

Ra = data word 0

rq - data word 1

output:

xr1 is saved

xr2 = trouble indicator

0 = no error

1 = error

ra = rj identity

rq = fwbirj bit

notes:

1. bun is used for trunk register mtx and ruo for line mtx.

2. at this point, we verify actual values for sec, sbs,mtx.

3. at this point, we verify actual values for ruo(bun) and buo.

f34 - figs. 58 - 58a

1. name

f34 - standby Interrupt and Timer Expiration Handler

2. PURPOSE

The purpose of module F34 is to properly handle Originating Marker standby interrupts and to provide an entry line used (entered) when a timer expiration occurs during a diagnostic request.

3. FUNCTIONS

Module F34 performs the following functions:

a. OM Standby Interrupt Handler - F34X03

1. Provides Reset and Ignore and Reroute MANIAC handling for standby interrupt sense lines.

2. Resets interrupting marker's sense line.

3. Sets indicator for F32A that OM is ready for transmission (FCCOMT).

4. Calls F32X01 to scan I/O request queues.

5. Enables Schedule on Idle option for CCR users (F31 clients).

6. Returns to ICAP.

b. Timer Expiration Handler - F34X01

1. Terminates I/O request and schedules CCR user's next program.

2. Hitches special timer work area (FIX) to special hitching post (FHPA22).

3. Provides status and data dumps of source and/or sink CCR's, if not provided previously, for CCR to CCR transfer requests.

4. Calls F32X01 to scan I/O request queues (containing F31 clients).

c. Marker-Malfunction Cleanup Subroutine, F34X05.

1. Terminates I/O request and schedules CCR user's next program.

2. Calls F32X01 to scan I/O request queues.

3. Returns to calling program.

4. INPUTS

4.1 software

4.1.1 core Tables

Esl - executive Storage Location

Fcc - crr control Table.

Fhp - hitching Post.

Fwa - executive Interface Work Area

4.1.2 Drum Tables

None

4.1.3 Registers

X1 - work Area Address (F34X01).

4.2 hardware

none

5. OUTPUTS

5.1 software

5.1.1 core Tables

Esl - executive Storage Location

Fcc - ccr control Table

Fhp - hitching Post

Fwa - executive Interface Work Area

Fwc - tm received information

Swa - ccr dump area A

Swc - ccr dump Area C.

Swe - ccr dump Area E

5.1.2 drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARE

None.

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F34x01: timer Expiration.

F34x03: standby Interrupt

F34x05: marker Malfunction Cleanup.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

None: Return to user.

7. SUBROUTINES USED

Entry: Functional Names

Points

F36x03: program Name (F36): CCR I/O

F36x08: handler Subroutines No. 1

F36x06: none

F32x01: program Name (F32A): CCR I/O Initiation Handler.

F38x03: program Name (F38): CCR I/O.

F38x0: handler Subroutines No. 2

L20a: diarqt - request Acceptor.

8. NARRATIVE

8.1 discussion

8.1.1 f34x03 - om standby Interrupt Handler

After checking MANIAC function and finding none set, F34X03 checks to see if a maintenance request F31 client is expecting this interrupt. If no request is in progress, a request to DIACON is made for maintenance routining of the marker. If a request is in progress, the sense line is reset and a check is made to see if transmission has been initiated. If not, FCCOMT is set indicating the OM is ready for transmission and F32X01 is called to attempt initiation of the transmission. If the transmission has been initiated, a check is made to see if the user (F31 client) request scheduling or idle. If so, field FWAMD5 is set indicating that marker went idle and the user's next program is scheduled. Then F32X01 is called to scan I/O queues.

Finally control is returned to ICAP.

8.1.2 f34x01 - timer Expiration Handler.

First, the special work area, table FIX, is hitched to the special work area, hitching post FHPA22. Then the current I/O request is terminated via a call to F36X03. A check is made to see if the request was a CCR to CCR transfer. If so, the I/O Audit bits are reset for both CCR's and a check is made to see if status and data dumps were provided for the sending CCR (FWAMD5) and the receiving CCR (FWAMD2). If either bit is reset, a status and data dump is provided and bits FWAMD4 and FWAMD3 will both be set, thus indicating that the dumps have been provided. The CCR's are then restored to their original scan state.

The CCR's are then restored to their original scan state.

8.1.3 F34X05 - Marker-Maintenance-Cleanup Subroutine

The operation is the same as for F34X01, except that the special work area is not received input and therefore the work area is not hitched.

8.2 TECHNIQUE

Not Applicable.

F35 - figs. 59 - 59h

f35a

1. name: manipulator Request Analysis Routine

2. PURPOSE: This module performs a routine preliminary analysis and routing of all requests for drum I/O.

3. functions:

a. Provides interlock for proper control of the non-resident area.

b. Determines the type of access being requested.

c. Performs necessary routing of request for additional processing, if required.

d. Properly formats the work area and calls the drum scheduler for non-resident accesses.

4. INPUTS

4.1 software

4.1.1 core Tables

Fwa - user's Work Area

Eps - executive Parameter Storage

Fan - access Number Table

Ftd - table Directory

4.1.2 Drum Tables

Fcb - control Buffer Table

4.1.3 Registers

Xr1 - address of User's Work Area

Xr2 - user's Access Number

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - work Area

Fje - executive Junk Storage

5.1.2 Drum Tables

None

5.1.3 Registers

Xr1 - work Area Address

Xr2 - index to Table Director (FTD)

5.2 hardware

none

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F35x01: access point whereby a user requests drum input/output.

F35a02: return from module F35P, when access number is less than 25 but not a request predefined for fast access processing.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

F29x01: drum Scheduler - Called when access is determined to be non-restricted.

F35p01; fast Access Formatter - Called when access number is less than 25, for determination of fast-access requirement and associated processing.

F35b01: parameter Collection Routine - Called for restricted accesses.

7. SUBROUTINES USED

None

8. NARRATIVE

8.1 discussion

all user access to the drum must be carried out via the Manipulator. When an access request is first accepted from the user, a certain amount of common processing is necessary to properly control system interlock functions and determine the exact nature of the request so that it can be channeled through required and appropriate processing.

8.2 TECHNIQUE

Requests entering the Manipulator fall into two general categories:

a. Requests from drum resident programs.

b. Requests from core resident programs.

In processing requests from drum resident programs, care must be taken such that the non-resident area is properly controlled. For this purpose, a special interface is provided between the Manipulator and the Drum Scheduler/Handler. This will be further clarified later.

For either drum or core resident requests, however, a determination must be made as to the specific nature of the user's request; this is accomplished by use of the user's access number. These access numbers uniquely identify each requests and are predefined by the user and the Manipulator. These access numbers divide user's into the following categories:

1. Core resident requests

a. qualifying for fast access

b. qualifying for general access

c. non-restricted

2. Drum resident requests s

a. requiring control table access

b. non-restricted

All core resident accesses qualifying for fast access have access numbers less than or equal to 25. The term "fast access" merely means that a dedicated code path exists for each request so designated (note: not all requests with access numbers less than 25 qualify for fast access processing). Requests which do not qualify for fast access processing are channeled into a generalized, less efficient processing path.

Whereas the control information for core resident requests is itself core resident, the control information for drum resident requests is drum resident. Therefore, drum resident requests which require control information will require the reading of the necessary table from drum before the access can be completed. The Manipulator recognizes such requests, and will automatically initiate the reading of the necessary control table as a preliminary to processing the request. A second possibility is that the requestor may provide all information necessary to properly access the specified drum data; therefore, no control table is required, and the Manipulator will forward the request on to the Drum Scheduler, with only minimal processing. Such requests are termed "non-restricted". It should be noted that non-restricted accesses are not limited to drum resident programs; such accesses may be utilized by core resident programs as well.

As noted previously, control of the non-resident area is an important factor where the requestor is drum resident. For example, the requestor may wish to release the non-resident area as a function of requesting drum I/O. However, the Manipulator is structured such that it can not concurrently process several requests requiring access to its drum-resident control tables. Therefore, to prevent the initiation of other requests, the Manipulator will specify (via the special interface alluded to previously) that the non-resident area is to be held during the access of its control tables. When the control tables have been brought in and the Manipulator, using the information contained therein, makes the actual data access to drum as requested by the user, the non-resident area is released. Such a mechanism prevents attempted multiprocessing of drum resident requests.

F35b

1. name: manipulator Parameter Collection Routine

2. PURPOSE: This module collects various fields supplied by a requestor of drum I/O and formats them into one or more key parameters to be used in making the requested drum access.

3. FUNCTIONS:

a. Extracts parameters from either the call history table or work area, as specified by the requestor.

b. Scales each parameter, if required, by a predefined scale factor.

c. Range checks each parameter, if required, against a predefined maximum value.

d. Compresses parameters, if required, according to a predefined number base.

e. Formats collected parameters into one or more predefined key words.

4. INPUTS

4.1 software

4.1.1 core Tables

Fwa - user's Work Area

Cht - user's Call History Table

Ftd - table Directory

Fpc - parameter Collection Table

4.1.2 Drum Tables

Fcb - control Buffer Table

4.1.3 Registers

Xr1 -work Area Address

Xr2 - table Directory Index

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fje - executive Junk Storage

Fwa - user's Work Area

5.1.2 Drum Tables

None

5.1.3 Registers

Xr1 - work Area Address

Xr2 - parameter Collection Table Index

5.2 HARDWARE

None

6. CONTROL

6.2 exit points

exit: Reasons for Exit

Points

F35n02: error Scheduling Routine - Called if a parameter fails a required range check.

F35c01: common Functions Routine - This is the normal exit and is called at the conclusion of parameter collection.

7. SUBROUTINES USED

None

8. NARRATIVE

8.1 discussion

one of the principal functions of the Manipulator is to provide an interface between the user and the system data base, such that changes in the data base structure need not be the concern of the user. This objective is accomplished by the user providing those parameters necessary to access a given drum table, not necessarily in this format required for the actual access. The Manipulator, using tables which describe the data base structure, then formats these parameters as required to properly access the specified data.

8.2 TECHNIQUE

Basically, the parameters which are passed by the user go to make up the search key used to access the required table. But the Manipulator must first format these various parameter fields into a search key corresponding to the particular table structure.

Associated with each such access is an entry in table FPC, the parameter collection table. This table entry in essence describes:

1. parameter fields supplied by the user.

2. the composition of key words (e.g., a search key) which are to be derived from these parameters fields.

3. special utility functions (e.g., range checking, scaling, etc.) to be performed on specified parameter fields.

The Manipulator will accept input parameters from either the user's work area or call history table, as specified. The control information for each parameter specifies the position in the user's buffer in which the parameter is located, its maximum permissible value, a scale factor (if required), the position which the parameter is to occupy in the key word being constructed, and other factors. Using this control information, the Manipulator removes a specified parameter from the user's buffer and performs any requested utility functions (such as scaling or range checking). The parameter is then merged into its appropriate position in the key word under construction.

The end result of collecting several such parameters will be the required keywords for the drum access. Generally, only one keyword, the search key, need be constructed. However, some accesses require construction of additional key words such as the number of words contained in each cell of the table being accessed, or an index value into a portal of the table.

F35c

1. name: manipulator Common Functions Routine

2. PURPOSE: This module performs functions common to all drum accesses; i.e., certain parameters common to many access types are generated here in preparation for the drum access.

3. FUNCTIONS

a. Generates following parameters:

1. DCU instruction word.

2. Number spill words required.

3. Data mask index.

4. Drum address (i.e., DCU pair, segment, and physical address).

5. Read/Write indicator.

b. Determines, via a predefined algorithm, the portal number to be accessed, using user-supplied parameters.

4. INPUTS

4.1 software

4.1.1 core Tables

Fwa - user's Work Area

Ftd - table Directory

Fpd - portal Description Table

4.1.2 Drum Tables

None

4.1.3 Registers

Xr1 - work Area Address

Xr2 - tables Directory Index

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - user's Work Area

Fje - executive Junk Storage

5.1.2 Drum Tables

None

5.1.3 Registers

Xr1 - work Area Address

Xr2 - table Directory Index

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F35c01: entered from F35B following parameter collection.

R35c02: entered as return from F35M.

6.2 exit points

exit: Reasons for Exit

Points

F35d01: single Level Counter Search Routine - Called to perform final processing unique to counter - start (block) accesses.

F35e01: single Level Associative Search Routine - Called to perform final processing unique to associative search accesses.

7. SUBROUTINES USED

Entry: Functional Names

Points

F35m: portal Number Calculator - This module is called to calculate the portal number; each entry line corresponds to a specific algorithm unique to certain accesses for which this calculation is required.

8. NARRATIVE

8.1 discussion

all accesses to drum must specify certain common parameters which are not unique to any given access. An example of such a parameter would be the DCU instruction word, required to instruct the hardware as to what type of search is being requested. These parameters may be predefined in some cases; in others, dynamic calculations are required to determine them.

8.2 TECHNIQUE

Parameters which may be predefined at assembly time are coded into the FTD (table directory) and FPD (portal description) entry for each specific access. At run time, these parameters are retrieved from FTD and FPD and placed in a temporary buffer area.

The portal number may be supplied by the user, in which case Manip performs no calculation. However, generally, the portal number is determined by parameters unique to a given call being processed thru the system. In such cases, Manip will execute a predefined algorithm, utilizing these calldependant parameters, to arrive at the appropriate portal numbers for the table being accessed.

F35d

1. name: manipulator Single Level Counter Search Routine

2. PURPOSE: The purpose of this module is to perform routine initialization of those parameters unique to counter start drum accesses.

3. FUNCTIONS

Generates certain parameters required for counter start accesses.

4. INPUTS

4.1 software

4.1.1 core Tables

Fwa - user's Work Area

Ftd - table Directory

Fje - executive Junk Storage

4.1.2 Drum Tables

None

4.1.3 Registers

Xr1 - work Area Address

Xr2 - table Directory Index

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - user's Work Area

5.1.2 Drum Tables

None

5.1.3 Registers

Xr1 - work Area Address

Xr2 - table Directory Index

5.2 Hardware

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F35d01: entered by F35C for initialization of counter start parameters.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

F35g01: manipulator Termination Routine - Called for final processing and termination to Drum Scheduler.

7. SUBROUTINES USED

None

8. NARRATIVE

8.1 discussion

this module performs generation of parameters required specifically for counter start accesses to the drum.

8.2 TECHNIQUE

Certain parameters may be predefined at assembly time; these are coded into the table directory (FTD) and retrieved by Manip during execution for insertion into a temporary buffer.

Some parameters (i.e., the index into the portal and the word count) may be specified by the user and supplied as input to the Manipulator access. For these cases, Manip will utilize these parameters; generally, these are generated during the parameter collection process (see documentation on module F35B).

F35e

1. name: manipulator Single Level Associative Search Routine.

2. PURPOSE: To generate those parameters unique to an associative search access to drum.

3. FUNCTIONS: Generates and formats those parameters which are uniquely required for an associative search access of drum.

4. INPUTS

4.1 software

4.1.1 core Tables

Fwa - user's Work Area

Ftd - table Directory

Fje - executive Junk Storage

4.1.2 Drum Tables

None

4.1.3 Registers

Xr1 - work Area Address

Xr2 - table Directory Index

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - user's Work Area

Fje - executive Junk Storage

5.1.2 Drum Tables

None

5.1.3 Registers

Xr1 - work Area Address

Xr2 - table Directory Index

5.2 Hardware

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F35e01: called by F35C for formatting and generation of parameters unique to associative search accesses.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

F35g01: termination Routine - Called for final processing and termination to the Drum Scheduler.

7. SUBROUTINES USED

None

8. NARRATIVE

8.1 discussion

certain parameters are unique to the associative search access (i.e., not required for a counter start access). These parameters must therefore be initialized separately.

8.2 TECHNIQUE

As in other portions of Manipulator processing some parameters may be pre-defined, while others may be constructed (if required) from user-supplied access parameters.

The principle purpose of this module is to generate the word count, index value, search key and mask word for the associative search access. The word count and index value may be pre-defined or dynamically calculated. The search key is always dynamically calculated, while the mask word is always pre-defined. Pre-defined items are retrieved from the respective table directory entry and placed in a temporary buffer area. Items which are dynamically calculated are generated in the parameter collection routine (F35B) using user-supplied parameters as input.

F35g

1. name: manipulator Termination Routine

2. PURPOSE: The purpose of this module is to collect parameters generated by previous processing routines and format them into the work area.

3. FUNCTIONS:

a. Collects all generated parameters and completes final initialization of the work area.

b. Terminates to Drum Scheduler.

4. INPUTS

4.1 software

4.1.1 core Tables

Fwa -user's Work Area

Fje - executive Junk Storage

4.1.2 Drum Tables

None

4.1.3. Registers

Xr1 - work Area Address

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - user's Work Area

Fje - executive Junk Storage

5.1.2 Drum Tables

None

5.1.3 Registers

Xr1 - work Area Address

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F35g01: entered from either F35D or F35E, to perform final processing and terminate to Drum Scheduler.

F35g02 entered from F35H for same purpose.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

F29xq1: (drum Scheduler) - Called to initiate or schedule the drum access.

7. SUBROUTINES USED

None

8. NARRATIVE

8.1 discussion

this routine serves as a final processor and common exit point from the Manipulator.

8.2 TECHNIQUE

The various parameters generated by previous processing are now collected from the temporary buffer and placed in the appropriate fields within the work area. These include the drum address register word and the DCU instruction word. Also, a "pseudo" spill word is formatted and placed in the appropriate location if the access is counter start and a single spill word is required. The drum address, which is supplied in logical format, is converted by algorithm to its physical counterpart, as required for input to the DCU hardware.

Finally, Manipulator processing is complete when control is transferred to the Drum Scheduler.

F35h

1. name: manipulator Exhaustive Search Routine

2. PURPOSE: This module will successively search each portal of a given table for the data requested by the user.

3. FUNCTIONS:

a. Determine if the required data has been located.

b. If so, schedules the user's next program.

c. If not, determines next portal to be searched and initiates the access.

d. If all portals have been searched and coincidence has not been found, schedules user's next program with indication of no coincidence.

4. INPUTS

4.1 software

4.1.1 core Tables

Fwa - user's Work Area

FPD - Portal Description Table

4.1.2 Drum Tables

None

4.1.3 Registers

Xr1 - work Area Address

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - user's Work Area

5.1.2 Drum Tables

None

5.1.3 Registers

Xr1 - work Area Address

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F35x02 - entered from executive as next program for each portal searched.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

F35g02: manipulator Termination Routine - Called to initiate an access to the next portal of a table.

F35n03: schedule User's Next Program - Called to schedule the user's next program at the conclusion of the exhaustive search.

7. SUBROUTINES USED

None

8. NARRATIVE

8.1 discussion

some users may require that an entire table be searched for given information, not knowing in which portal of the table the information resides. To facilitate this process, the Manipulator provides the internal capability to successively search all portals of a given table. This frees the user from the code and logic required to continue searching each portal of the table until coincidence is found or all portals are exhausted.

2. TECHNIQUE

In order to ascertain the results of each portal search, Manip specifies itself (F35X02) as the next program for each access to drum. Upon regaining control at this entry point, the non-coincidence indicator of the work area is checked. If it is not set, coincidence was found in the last portal searched and the access is complete; the user's next program is then scheduled by Manip.

If this indicator is set, coincidence was not found in the last portal searched. A test is made to see if all portals have now been searched; if so, the user's next program is scheduled with the indication that coincidence could not be found. If all portals have not been searched, the information describing the table's next portal is extracted from FPD and properly formatted into the work area. The Manipulator Termination Routine is then called to initiate the next drum access.

This process is reitereated until (1) coincidence occurs, or (2) all portals of the specified table have been searched.

F35m

1. name: portal Number Calculator

2. PURPOSE: F35M contains algorithms to develop portal numbers for drum access requested by call processing or update modules.

3. FUNCTIONS: F35M calculates portal numbers required to access the following tables:

a. CDN

b. CLN

c. CRN

d. CSX

e. CGT

4. inputs

4.1 software

4.1.1 core Tables

Cep - engineerable Office Parameters

Chc - om data Frame Received

Cja - original Class Data

Fac - npa normalization Table

Fal - search Key Conversion Table

Fdn - directory Number Normalization Table

Fje - executive Junk Storage

Ftd - drum Access Description Table

Fwa - executive Interface Work Area

Fwb - cp register/Sender Memory Image

Fwc - tm received Information

4.1.2 Drum Tables

None

4.1.3 Registers

X1 - client's Executive Interface Work Area Address

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - executive Interface Work Area

Fje - executive Junk Storage

5.1.1 Drum Tables

None

5.1.3 Registers

Ra - portal Number to be searched.

X1 - executive Interface Work Area Address

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry : Reasons for Entry

Points

F35m01: f35m01 is entered to convert Directory Number to portal to search.

F35m02: f35m02 is entered to convert office section and matrix to drum portal to search.

F35m03: f35m03 is entered to convert route number from FWASW1 to drum portal to search.

F35m05: f35m05 is entered to convert office section and matrix to drum portal to search.

F35m06: f35m06 is entered to search table FAC for area code match and add NPA from FAC to the search table FAC for area code match and add NPA from FAC to the search word for a six-digit translation.

F35m07: f35m07 is entered to selected the proper party from a two-party line and specify the drum portal where the LNI of the party resides.

F35m08: f35m08 is entered to load the A register with FJE009 (Parameter collected in F35B) for drum portal to search.

F35m09: f35m09 is entered to test the search word to compute the drum portal to search.

F35m10: f35m10 is entered to extract ("collect") data from the client's work area to be processed by F35M01.

F35m11: f35m11 is entered to grab search word from client's work area for processing by using table FAL and portal determination routines in F35M05.

F35m12: f35m12 is entered to determine segment, drum address and DCU pair information for next drum access.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

F35c02: manipulator Common Functions Routine (F35C) is entered at F35C02 with a portal address to continue processing for a drum access.

F35n04: manipulator Identifier Reconstruction Routine F35N04 is entered to set client's no coincidence found indicator and schedule client's next or error program.

F35c03: manipulator Common Functions Routine (F35C) is entered at F35C03 with drum address information to continue drum access.

8. NARRATIVE

8.1 discussion

f35m is called from F35C (Common Function Module) when no portal is specified by the client program. The selected routine constructs the required portal number for the access and returns to F35C02 or F35C03.

8.2 technique

f35m01 selects the portal for table CDN. Using the first four digits table FDN is searched for a match. When that is found the portal number is extracted annd control is returned to F35C02. If no coincidence is found the error program is scheduled through F35N04.

F35M02 determines whether the matrix number falls between 1 and 5 or 6 through 10. If the number is greater than 5, one is added to the portal number. Control is then returned to F35C02.

F35M03 extracts the route number from the work area and clears all but the two high order bits. The word is then properly positioned in the A-register and control is returned to F35C02.

F35M05 extracts the section number and the matrix from the work area. The two items are used as search key to find the proper pointer to the portal description word in table FAL. Control is then returned to F35C02.

F35M06 searches table FAC for the area code match. If a match is found the normalized area code is extracted and added to the search word for a six digit translation. If the search of table FAC is successful control is returned to F35C02, otherwise F35N04 is called to schedule the error program.

F35M07 extracts the pointer to the call history table; determines if it is a two-party line; selects the proper party and specifies the portal where the LNI of the party resides. Control is returned to F35C02.

F35M08 loads the A register with FJE009 (Drum Address Register) and returns to F35C02.

F35M09 tests the search word to determine the section number. If the section number is greater than 2 the portal number is incremented by 2. The matrix is range checked and if it is not greater than 5, the portal number is incremented again by 1. Control is then returned to F35C02.

F35M10 extracts data from the work area to form a search word to be processed by F35M01.

F35M11 grabs the search word from the work area and formats the search word for table FAL. The search of table FAL is an internal routine found in F35M05. Upon completion of the search F35C02 is called.

F35M12 determines whether the DCU pair and/or the portal number is to be altered prior to calling F35C03.

F35n

1. name: identifier Reconstruction Routines

2. PURPOSE: The purpose of F35N is to extract data from the call history table or the work area, order the data for the drum search, and schedule F40.

3. functions: module F35N performs the following functions:

a. Extracts the first four digits of a 1 or 2 party line.

b. Schedules the error program is no coincidence is found in table FDN.

c. Schedules users next program through closed subroutine F40X06.

4. inputs

4.1 software

4.1.1 core Tables

Cep - engineerable Office Parameters

Cja - original Class Data

Esl - executive Storage Location Table

Fdn - directory Number Normalization Table

Fje - executive Junk Storage

Fpd - portal Description Table

Fwa - executive Interface Work Area

Fwb - cp register Sender Memory Image

4.1.2 Drum Tables

None

4.1.3 Registers

Ra - client's Executive Interface Work Area Address

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - executive Interface Work Area

5.1.2 Drum Tables

None

5.1.3 Registers

X1 - client's Executive Interface Work Area Address.

Rq - eio value for F40X04.

X2 - tells F40X06 Manip is calling.

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F35n01: f35n01 is entered for LNI to Directory Number Conversion Completion

F35n02: f35n02 is entered to set EIO for parameter conversion and schedule client's error program.

F35n03: f35n03 is entered when access is complete to schedule user's next program.

F35n04: f35n04 is entered to schedule client's next or error program when drum coincidence was not found.

F35n10: f35n10 completes LNI to Directory Number Translation for update.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

E01x04: e01x04 is entered to release the control of the CPU.

7. subroutines used

entry: Functional Names

Points

F40x04 client's ERP Scheduling Subroutine.

F40x06 client's NPG Scheduling Subroutine.

8. NARRATIVE

8.1 discussion

f35n extracts a pointer from either the call history table or work area and searches table FDN for a match of the pointer. If the search is successful a four digit code is transferred from table FDN to table CXK and F40X06 is called to schedule the next program. Should the search not be successful the error program is scheduled through F40X04.

Interrupts are disabled prior to entering F40 and enabled upon return. Control is released to F01X04.

8.2 technique

f35n is called for identifier reconstruction from call processing and update accesses. F35N01 services Call Processing and F35N10 services update. Both routines are capable of working with either TPL or TPS offices. The major difference between the routines is that the input data to F35N01 is in the call history table while the input data for F35N10 resides in the work area.

F35N01 determines whether party one or party two is to be serviced. The pseudo portal number is used as the Key to search table FDN. The first four digits are extracted from the FDN entry and stored in table CXK. If it is a TPL office F40X06 is called to schedule the next program. If the office is TPS the address or coincidence is converted to TBCD (digits 5, 6 and 7) and stored in table CXK. F40X06 is then called to schedule the next program. F35N10 provides a similar service for update requests. Input data is stored in the work area instead of the call history table. Again a test is made to determine whether the office is TPS or TPL. The TPS office requires additional processing prior to calling F40X06 to schedule the next program.

F35N02 is an error processing routine. Parameter errors are flagged through this module. A call to F35N04 indicates no coincidence found. An additional test is made to determine whether coincidence is required. If not, the next program is scheduled; if coincidence is required the error program is scheduled.

F35N03 is the routine used to schedule F40X06. Upon return from F40X06 or F40X04 control is returned to the executive through E01X04.

F35p

1. name: manip fast Access Formatter.

2. PURPOSE: F35P processes Call Processing's most frequently used accesses to drum. These accesses are coded away from the normal line of processing to conserve on processing time of calls.

3. FUNCTIONS: The function of F35P is to do the following:

a. Collects and formats the required parameters for the access.

b. Performs range checks on the parameters if required.

c. Selects the portal on drum to be entered.

d. Sets the number of words per cell.

e. Initializes the mask word and the instruction word.

d. Formats the instruction words for the DCU scheduler and calls the DCU scheduler.

4. INPUTS

4.1 software

4.1.1 core Tables

Cdn - local Directory Number.

Cep - engineerable Office Parameters.

Cgd - tgn to Directory Number.

Chc - om data Frame Received.

Che - pretranslation Access Store Data.

Chh - route and Path Data.

Cja - original Class Data.

Cln - line Equipment Number.

Clo - line Matrix Outlet.

Cpd - pretranslation Data.

Csx - selector Matrix Outlet.

Ctn - trunk Equipment Number.

Fal - search Key Conversion Table.

Fdn - directory Number Normalization Table.

Fje - executive Junk Storage.

Fpd - portal Description Table.

Fwa - executive Interface Work Area.

Fwb - cp register Sender Memory Image.

Fwc - tm received Information.

4.1.2 Drum Tables

None

4.1.3 Registers

X1 - executive Interface Work Area Address.

X2 - manipulator Access Number.

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fwa - executive Interface Work Area Address.

5.1.2 Drum Tables

None

5.1.3 Registers

X1 - executive Interface Work Area Address.

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F35p01: f35p01 is scheduled as the only entry point into F35P.

6.2 exit points

exit: Reasons for Exit

Points

F29x01: dcu scheduler program: F29X01 is called to schedule the drum operation specified by the client thru F35P.

F35n02: manip Parameter Error Routine: F35N02 is entered when F35P finds an error in the parameters passed by the client. F35N02 schedules the user's ERP with an EIO of 2.

F35n04: manip no Coincidence Found Routine: F35N04 is entered when no coincidence is found while associatively searching a table. F35N04 schedules the user's ERP or NPG depending on whether the client has specified coincidence required.

7. SUBROUTINES USED

None

8. NARRATIVE

8.1 discussion

f35p formats request for the following MANIP accesses: FM001 (CLO), FM003 (CGD). FM004 (CSX), FM006 (CTN), FM007 (CDN), FM009 (CRN), FM021 (CTT), FM022 (CPD), FM023 (CTT), FM025 (CLN). F35P is entered with the work area address in X1 and the requested access number in X2. The routine to process the access is entered through a BUN table modified by X2. If it is not a fast access to be processed, control is returned to F35A02.

Most of the parameter collection is performed by the KEYGEN macro. Special Handling is required in only a few cases. Portal algorithms are required for several accesses (FM004, FM007, FM009, and FM025). Special handling is also required for FM007 to determine whether the office is TPL or TPS.

8.2 technique

not Applicable

Notes to FIG. 59J

*1. f40x04 - will Set FWAE10=(RO) and schedule the error program.

2. F40X06 - Will schedule the next program.

F36 - figs. 60 - 60e

1. name: f36 - ccr i/o handler Subroutines No. 1

2. PURPOSE: In order to centralize functions and conserve core memory, six subroutines have been provided in module F36 for use by other CCR I/O Handler modules.

3. FUNCTIONS: Module F36 performs the following functions:

a. F36X01 - Unlink diagnostic request clients from I/O queue, (containing "F31 clients") hitch request to maintenance hitching post, and start timer for I/O request.

b. F36X02 - Handles reroutes via scheduling or branching to the appropriate requested module.

c. F36X03 - Cleans up I/O request when complete. This includes resetting timers and/or audits bit associated with request, resetting hitching post and marker busy bit, and resetting markers and restoring CCR's to original scan state if modified for this request.

d. F36X05 - Provides proper configuration of CCR's for requests requiring special configurations.

e. F36X06 - Unloads all data and/or status word from CCR's.

f. F36X08 - Reconfigures CCR's as requested by CONFIG.

4. inputs

4.1 software

4.1.1 core Tables

Fsl - executive Storage Location.

Fcc - cm-rj identity.

Fhp - hitching Post.

Fwa - executive Interface Work Area.

Hel - i/o abort Entry Lines.

Fex - executive Inst for F36.

Ftl - timer.

Hst - system Status.

4.1.2 Drum Tables

None

4.1.3 Registers

X1 - work Area Identity.

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Esl - executive Storage Location.

Fcc - om-rj identity.

Fex - executive Instructions for F36.

Fhp - hitching Post.

Fix - ccr maintenance Work Area.

Ftl - timer.

Fwa - executive Interface Work Area.

Hel - i/o abort Entry Lines.

Hst - system Status.

Swd - ccr dump Area D.

5.1.2 drum Tables

None

5.1.3 Registers

Ra - error Indicator for F36X06.

5.2 hardware

none

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F36x01: see Section 3 for all listed entry points

F36x02

f36x03

f36x05

f36x06

f36x08

6.2 exit points

exit: Reasons for Exit

Points

None: Return to client.

7. SUBROUTINES USED

Entry: Functional Names

Points

F03: unlink from Priority Queue.

F34 originating Marker Standby Interrupt Handler.

E02 interval Timer Request Acceptor.

E03x02 stop Timer (STTIME)

E01x01 timer Expired

S31x01 multiple Channel Recovery

8. NARRATIVE

8.1 discussion

f36x01 will unlink the diagnostic request from the I/O queue and hitch the work area to FHPA08. Then set FCCMJI to indicate a maintenance job in progress, and set FWAFID in the user's work area indicating the request has been initiated. F36X01 will then index into table FTL with FWATMS to obtain the number of 16.6 msec. intervals to pass to E02X01 when it requests the timing of the I/O request. F36X01 then unhitches special work are FIX (FZB) from FHPA22 and calls E02X01 to time I/O request and transfer to F34X01 should timeout occur. It then returns to the calling program.

F36X02 receives as input the two reroute words from the MANIAC program. It then transfers to/or schedules the appropriate module and returns to the calling program.

F36X03 receives as input the scan address for the I/O request it is to clean up and three indicators indicating whether this is a maintenance request, whether to send a reset CPD to a marker.

If the maintenance request indicator is set, F36X03 resets FCCMJI and FCCOMT. If FCCSCR is set, indicating that CCR's are in a special scan state, and no reconfiguration bits for the CCR's are set in FCCREC. F36X03 will set the approprate bits in FCCREC to restore CCR's to original state and then reset FCCSCR and FCCMIU. Then F36X03 will unhitch the work area from FHPA08 and attempt to remove special work area FIX from the timer queue. If the work area was present in the timer queue, it will hitch the work area back to FHPA22.

If the input scan address is for TM, F36X03 will reset the I/O Handler audit Bit for the TM, reset the pair busy bit, and reset the TM pair hitching post.

Then F36X03 will issue the appropriate CPD's if any, and return to the calling program.

F36X05 will set up CCR's for a specified CCR I/O request or a CCR to CCR transfer request. First F36X05 checks the system status table, HST, to be sure that the CCR(s) to be used is not OS. If it finds a CCR OS, it will return to the calling program with an error indication.

If the request is a CCR to CCR request, F36X05 will both CCR's into standby scan mode and point the sink CCR toward the source CCR and provide a status dump of sink CCR in word SWD via a call to F36X06 and then set FCCSCR to 1 and FCCMIU to the identity of the originally online active CCR.

If the request is for a specified CCR, and the specified CCR is not the CCR currently in active use, F36X05 will place both CCR's online standby and master reset the active CCR to eliminate interference during the transmissions. Then F36X05 will set FCCSCR and FCCMUI as above.

In all cases, return is made to the calling program with the sending CCR connected and the receiving CCR disconnected.

F36X06 is entered with five indicators set and two sink addresses furnished and XR2 contains the channel identity of the CCR.

The first indicator checked is for a single status word dump. If set, the standard status word is unloaded at the address in ERG001 and sense group 046 or 047 is stored in the next sequential location.

The second indicator checked is for a full status word dump. If set, the standard status word and the two error status words are stored sequentially, followed by sense group 046 or 047, starting at the address in ERG001.

The third option is a two word data dump. If requested, the first two data words will be stored sequentially at the address in ERG002.

The fourth option is a two word data dump. If requested, the first two data words will be stored sequentially at the address in ERG002.

The fifth indicator checked is whether CCR should be disconnected. If set, the CCR will be disconnected.

Options one and two are mutually exclusive as are options three and four. Control is always returned to the calling program.

F36X08 is entered with its input in FCCREC. FCCREC contains six bits. They indicate:

1. CR B should be placed online and active.

2. CR A should be placed online and active.

3. CR B should be placed offline.

4. CR A should be placed offline.

5. CR A should be placed online and standby.

6. CR B should be placed online and standby.

F36X08 will process any bits set in the order listed and then reset the bits. It will then return control to the calling program with any reconfigured CCR's connected to the I/I bus.

8.2 TECHNIQUE

Not applicable.

Notes to FIG. 60A

Input: ra = second Reroute Word

F37 - figs. 61 - 61d

1. name: f37 - ccr error Isolation and Recovery Module.

2. PURPOSE: Module F37 has been provided to handle all error interrupts from the CCR's.

3. FUNCTIONS: Module F37 performs the following functions:

a. Provides reroute and reset and ignore maniac functions on the CCR error sense lines.

b. Provides fault/error isolation and CCR/MKR isolation.

c. Takes appropriate recovery steps to achieve a workable subsystem. 4. INPUTS 4.1 SOFTWARE 4.1.1 Core Tables

Fcc - cm-rj identity.

Fjp - executive Junk Storage.

Fwa - executive Interface Work Area.

Fwc - tm receiver Information.

Swb - ccr dump Area B.

Swe - ccr dump Area E.

4.1.2 drum Tables

None

4.1.3 Registers

None

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Erg - pseudo Registers.

Fjp - executive Junk Storage.

F38x03: schedule error program.

F38x04: abort Job.

I00: maintenance Interrupt Access.

I01: configuration Control.

I20: elt, diarqt, diabrt.

i50: extra Lines for L00.

S31x01: ccx errors Check.

8. NARRATIVE

8.1 discussion

after checking maniacs on the interrupting device, module F37 then proceeds to determine the cause of the interrupt. If the interrupt occurs during a CCR to CCR transfer, F37 will ignore the interrupt and return to ICAP. If the interrupt occurs during a maintenance request, F37 will schedule the user's error program with FWAEIO = 12 after providing a CCR status word dump in FWC and then reset and ignore the error. If a transmission error interrupt occurs during an origination or termination, F37 will immediately retry the I/O operation, either by calling F32X05 to send data out again if error was in sending or by backing up scanner one marker and allowing CCR to receive data again. If the retry is successful, the ready interrupt will be rerouted through F37X03 and counter. If the transient error rate exceeds 1%, CCR Isolation is requested on the device. If the retry is unsuccessful, we have found a fault, and fault/error isolation is complete. F37 will proceed to CCR/MKR isolation stage. If a timeout error occurs at any time during call processing I/O, F37 will call CCR Isolation immediately. If an error occurs with a MOS marker, F37 will set the disable receiving errors latch in the active CCR to prevent constantly receiving error interrupts.

Upon entry to the CCR/MKR isolation stage, F37 will attempt to switch the active CCR by requesting that the active CCR be placed MOS. If the request is denied because the other CCR is not available, F37 will set the disable receive errors latch in the CCR and reset and ignore the error. If the reconfiguration request is allowed, F37 can then do more retry to accomplish CCR/MKR isolation. If the retry is successful, F37X03 again receives control via a reroute of the ready interrupt and will assume that the original CCR is fault and will request, through DIACON, that CCR Isolation be run on that CCR. If the retry is unsuccessful, F37 will assume the marker fault, and will request that CCR/MCR Isolation be run on the original CCR and the faulty CCR after putting the marker MCS.

When F37 has completed its isolation, it will call F32X01 to scan the I/O queues and then return to ICAP.

F38 - figs. 62 - 62c

1. name: f38 - ccr i/o handler Subroutines - 2

2. PURPOSE: F38 contains six subroutines used by other programs associated with CCR and marker hardware.

3. FUNCTIONS:

a. F38X01 handles the interface between the I/O programs and the non-I/O executive in regards to scheduling the user's next program after successfull completion of I/O request.

b. F38X03 handles the interface between the I/O programs and the non-I/O executive in regards to scheduling the user's error program after unsuccessful completion of the I/O request.

c. F38X02 provides interface between the I/O Handler Timeout Audit Program and the CCR I/O Handler for CCR timeouts.

d. F38X05 provides interface between the I/O Handler for terminating marker timeouts.

e. F38X04 attempts to find and abort an I/O request associated with a particular CCR scan address.

f. F38X07 provides interface between terminating marker isolation programs and the I/O handler when isolation is completed. This entry line will schedule either the next program or error program of the termination request depending on a indicator passed by calling program.

4. INPUTS

4.1 software

4.1.1 core Tables

Est - priority State Table.

Fcc - om-rj identity Table.

Fhp - hitching Post Table.

Fjp - interrupt level junk Table.

Fwa - executive Work Area Table.

Has - mcr audit Table.

4.1.2 Drum Tables

None

4.1.3 Registers

X1 - work Area Address.

X2 - scan Address of Marker.

Ra - schedule Error or Next Program.

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Eps - executive Parameter Storage Table.

Esl - executive Storage Location Table.

Est - priority State Table.

Fhp - hitching Post Table.

Fwa - executive Work Area Table.

Has - mcr audit Table.

5.1.2 Drum Tables

None

5.1.3 Registers

X1 - work Area Address.

X2 - scan Address of Marker.

Ra error Indicator.

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F38x01: entered to call the Executive Audit Program for CCR timeouts.

F38x03: entered to call the Executive to schedule the user's error program.

F38x04: entered to find and abort an I/O request associated with a particular scan address.

F38x05: entered for terminating marker timeouts.

F38x06: entered to provide interface between terminating marker isolation programs and CCR I/O handler when isolation is complete.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

None: Control is always returned to the calling program.

7. SUBROUTINES USED

Entry: Functional Names

Points

F02x02: link to front of queue.

E01x01: schedule program and return control.

F05x01: return work area to system pool.

F36x01: set marker MOS and just ignore.

L20x01: schedule marker maintenance.

F32x01: scan CCR I/O queues.

8. NARRATIVE

8.1 discussion

f38x01 and F38X03 provide implementation of the "hold NRA" option and the "drop work area" option in field FWAPGT of the I/O request.

F38X02 and F38X05 provide interface between I/O Handler Timeout Audit (IOHTOA) and I/O Handler. F38X02 will call F32X07 to put the CCR MOS and Call CCRISO. F38X05 will call CONFIG to put the TM MOS, make a DIARQT for MRK routining, set unit just ignore maniac on the marker, and abort any request in progress via a call to F38X04, and schedule the user's error program with FWAEIO = 9. Both F38X02 and F38X05 will drive F38X02 to scan the I/O queues and then return to the calling program.

F38X04 will abort any I/O request in progress on the CCR scan number it receives as input and return the requestor's work area address in index register one.

F38X07 will reset the hitched work area bit (FHPJHT) passed by marker isolation and scheduler either the next program or the error program (with FWAEIO = 8) of the request that was hitched to the special hitching post.

8.2 TECHNIQUE

Not applicable.

Notes to FIG. 62

Inputs: xr1 = work Area Address of Program to schedule.

Notes to FIG. 62C

This routine to reset TM H.P. after MKR fault and schedule hitched program.

Inputs: ra = 0 indicates schedule next program.

Ra .noteq. 0 indicates schedule error program.

X1 = waa -- will be saved.

X2 = scan address -- will be saved.

Outputs: ra = 0 indicates no error found.

Ra = -1 indicates error was found.

Error conditions:

1. Invalid SCA (not in range) SCA 14)

2. job not hitched at spare HP. RJ and ERG001 - 004 are destroyed.

F39 - fig. 63

1. name: f39 - ccr load/Unload Subroutine.

2. PURPOSE: This module performs certain I/O functions for S45, CCR Link Localization. It is provided to minimize interface requirements for that program.

3. FUNCTIONS:

a. Loads CCR standard status word from input.

b. Unloads CCR status words upon request.

c. Checks for CCX errors.

d. Returns to calling program.

4. INPUTS

4.1 software

4.1.1. core Tables

Rsa - computer communications Register Maintenance Table.

4.1.2 Drum Tables

None

4.1.3 Registers

X2 - channel Controller Number (06000 or 07000).

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Sra - ccr maintenance Table.

5.1.2 Drum Tables

None

5.1.3 Registers

Rq - error Indicator

0 = No error

Negative = Error in loading CCR.

5.2 hardware

ccr scanner Address Loaded.

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F39x01: entered to load CCR scanner for link localization only.

F39x02: entered to give CCR error status dumps for link localization only.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

None: Control is always returned to the calling program.

7. SUBROUTINES USED

Entry: Functional Names

Points

S31x01: ccx recovery to check for channel multiplex errors.

F36x06: to dump 4 status words.

8. NARRATIVE

8.1 discussion

f39x01 loads input word into CCR standard status word and then calls S31X01 to check for possible CCX errors. The module will do retries if requested by S31X01. When standard status word has been successfully loaded, F39 will return to S45 with a no error indication. If CCX errors are encountered, F39 will return with indication that errors occurred.

F39X02 formats interface information and the calls F36X06 to obtain a status dump of the CCR. F39X02 then returns error indication from F36X06 to S45.

8.2 technique

not applicable.

F40 - figs. 64 - 641

1. name: f40 - drum Handler Subroutines I

2. purpose: provides required interface with the Manipulator and DMS Isolation for scheduling a user's next or error program.

3. FUNCTIONS:

a. Schedules the next program.

b. Schedules an error program with a specified error code.

4. INPUTS

4.1 software

4.1.1 core Tables

Fwa - user's Work Area

4.1.2 Drum Tables

none

4.1.3 Registers

Rq - error Code.

Xr2 - negative, indicating caller identity.

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

None

5.1.2 Drum Tables

None

5.1.3 Registers

None

5.2 HARDWARE

None

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F40x: called by Manipulator and DMS Isolation to schedule a user's next or error program.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

None: Return is always made to the caller.

7. SUBROUTINES USED

Entry: Functional Names

Points

F30a07: utilized to schedule the user's next program.

F30a03: utilized to schedule the user's error program.

8. NARRATIVE

8.1 discussion

occasionally, the Manipulator and DMS Isolation will schedule a user's next or error program as part of its processing. In order to take advantage of the Drum Handler's program scheduling capability (including work area release, non-resident area control, state indicator control, etc.), a special entry line has been provided for use by the Manipulator and DMS Isolation for this purpose.

8.2 TECHNIQUE

Module F40 exists solely to satisfy interface agreements with the Manipulator and DMS Isolation. While these programs may call entry lines F40X04 or F40X06 (per original agreement), entry actually occurs at F40X (or F40X01) due to F40's special PIT (i.e., no indexing by XR3). F40 determines which entry time is being accessed (by the value in XR3), calls F30A03 or F30A07 to perform the required program scheduling and returns control to the caller. Interface requirements specify that calls to F40 be executed with interrupts disabled (to eliminate re-entrancy problems associated with F30). When calling F40X06 to schedule the next program, XR2 must be negative (to identify the caller of F30A07 as Manip, since minor processing differences are associated with the Manip Call). When F40X04 is called to schedule an error program, RQ must contain the EIO field (error code) with which the error program is to be scheduled.

F41 - figs. 65 - 65c

1. name: f41 - drum Handler Subroutines II

2. purpose: provides required interface with DMS Isolation for clearing down a specified DCU and its associated software indicators, and an interface to allow DMS Isolation to initiate a DCU queue scan (to ensure all queued jobs are found).

3. FUNCTIONS:

a. Clears the DCU and places it in an idle state.

b. Clears any software indicators associated with that DCU.

c. Initiates a DCU queue scan, when instructed to by DMS Isolation.

4. INPUTS

4.1 software

4.1.1 core Tables

Fjp - interrupt Level Junk Storage.

4.1.2 Drum Tables

None

4.1.3 Registers

None

4.2 HARDWARE

None

5. OUTPUTS

5.1 software

5.1.1 core Tables

Fdp - drum Parameters Table.

Fhp - hitching Post Table.

5.1.2 Drum Tables

None

5.1.3 Registers

None

5.2 HARDWARE

Dcu in a clear, idle state.

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F41x: called by DMS Isolation to clear down a specified DCU or initiate a queue scan on a DCU pair.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

None: Return is always made to the caller.

7. SUBROUTINES USED

Entry: Functional Names

Points

F30a10: called to clear down the DCU and its associated software indicators.

F30a0z called to initiate a DCU queue scan.

8. NARRATIVE

8.1 discussion

during the process of isolating a fault on a DCU pair and after two retries on the error unit, the job may be tried on the mate unit. It is therefore necessary to clear the error unit (should it be placed back in service). DMS Isolation therefore makes use of an existing Drum Handler subroutine to accomplish this task. Such an arrangement enforces accurate and efficient control of the DCU as a resource.

The queue scan entry is needed to ensure jobs queued on a DCU-pair basis get started again after DMS isolation is finished. Without this entry, a job queue would not get serviced again after isolation, because queue scan is normally started only on an interrupt basis, and no interrupts would come in on a DCU pair shut down for isolation purposes.

8.2 TECHNIQUE

Module F31 exists solely to satisfy an interface agreement with DMS Isolation. While Isolation calls entry line F41X02 (per original agreement), entry actually occurs at F41X (or F41X01) due to F41's special PLT (i.e., no indexing is XR3).

F41 immediately calls F30A10 to accomplish the necessary clearing of the DCU and its associated software, and returns control to DMS Isolation. Interface requirements specify that FJPB22 contain the identity of the DCU to be cleared.

When DMS Isolation enters F41 calling for F41X01, F41 immediately calls F30A02 to initiate a queue scan on the SCU pair indicated by X2 and returns control to DMS Isolation.

F52 - figs. 67 - 67a

1. name: f52 - marker Malfunction Interrupt Handler.

2. PURPOSE: The purpose of module F52 is to enable approprate handling of malfunction interrupts from both originating markers and terminating markers.

3. FUNCTIONS: Module F52 performs the following functions:

a. Appropriately handles MANIAC conditions on the interrupts associated with marker malfunction sense lines; see paragraphs 8.1(b) and (c).

b. Interfaces with maintenance diagnostic programs when malfunction interrupts occur during the accessing of a marker by a normal (non-maintenance) Call Processing client of F31.

c. Provides an indication of interrup (assoicated with a marker malfunction sense line) who is performing maintenance on a marker. In the event of this marker interrupt:

1. F52 Terminates the program and returns control back to the F31 client (originating diagnostic program).

2. Cleans up the hardware and software for the requester: That is, resets the malfunction sense line, and resets software indicators so that other F31 clients may be properly acted on.

d. Attempts to initiate the next I/O request from F31, if such a request is queued.

e. Returns to the calling program.

4. INPUTS

4.1 software

4.1.1 core Tables

Esl - executive Storage Location. (Also an output table.)

Fcc - ccr control Table. (Also an output table.)

Fhp - hitching Post. (Also an output table).

Fjp - interrupt Level Junk.

Fwa - executive Interface Work Area. (Also an output table.)

4.1.2 Drum Tables

None.

4.1.3 Registers

None.

4.2 HARDWARE

None.

5. OUTPUTS

5.1 software

5.1.1 core Tables

Esl - executive Storage Location. (Also an input table).

Fcc - ccr control Table. (Also an input table.)

Fhp - hitching Post. (Also an input table.)

Fwa - executive Interface Work Area. (Also an input table.)

5.1.2 Drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARE

None.

6. CONTROL

6.1 entry points

entry: Reasons for Entry

Points

F52x01: see Purpose paragraph 2.0, above.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

Calling Program: Return to calling program.

7. SUBROUTINES USED

Entry: Functional Names

Points

F32: ccr handler.

F34: originating Market Standby Interrupt Handler.

F36: ccr subroutines.

F38: ccr scheduler B and Aborts.

L00: maniac - maintenance Interrupt Access.

L01: config - configuration Control Program.

L20: diacon - diagnostic Control Program.

L50: unit MANIAC.

K70: omrjcl - originating Marker RJ Clear.

8. NARRATIVE

8.1 discussion

the following is a summary of the major (flowchart) decisions and actions performed by F52; see the F52 flowchart for the exact detailed flow, not indicated here.

F52 first major action is to check the MANIAC passed by the Interrupt Cause and Analysis Program (ICAP); this indicator is the Reset-and-Ignore condition. One out of three major categories of action is then performed by F52 (primarily dependent on the 1 or 0 state of the Reset-and-Ignore indicator); the three possibliites which possibilities F52 can perform are listed below under (a), (b), and (c). Listed under these three major categories are several subdivisions that are the additional necessary (or possible) decisions comprising that area of the program; it must be remembered, however, that the material below is only a general overview of the major program decisions.

a. When Reset and Ignore is not set, then:

Closed subroutine F36X02 is called if reroute is set, and only if reroute is set. Then, whether reroute is set or not, a check is always made to see if the malfunction is associated with a diagnostic request concerning the marker:

1. If the malfunction is associated with a diagnostic request on the marker (FCCMJI = 1), then closed subroutine F34X05 is called to clean up the request and schedule the clients next program. In addition, if test call mode is used, F52 performs the operation listed under the second paragraph of condition.

Or

2. if the malfunction is not associated with a diagnostic request on the marker (FCCMJI = 0), then control is passed to closed subroutine F38X04 so that if the I/O request is in progress (the job being a termination attempt by the TM), it may be aborted. If the request is in progress, then in addition to the job being aborted, the work area will be hitched to a special hitching post, unless that hitching post is busy, in which case the user's error program is scheduled with FWAEIO = 8.

Next, the interupting marker is placed MOS (via a call to CONFIG). A unit Just-Ignore MANIAC is then put on the interrupting marker, a DIARQT for marker isolation is made, and the Reset and Ignore malfunction MANIAC is put on the other marker pair. Then F32X01 is called to scan the I/O queues, after which control is returned to ICAP.

b. When Reset-and-Ignore is set, and an I/O request is in progress with the marker, then:

If the maintenance request is not waiting for standby (see page 1 of flowchart), then: The client requested error program is scheduled with FWAEIO = 8. Otherwise, if the maintenance request is waiting for standby, then: The I/O request is a diagnostic program for an OM, the (replacement) marker is not yet employed by the diagnostic program, and at this time an unrelated malfunction indication occurs in connection with the marker (maintenance request not waiting for standby). This malfunction indication, however, is ignored and the marker is still employed by the diagnostic program; that is, F52 still continues processing as if the marker malfunction was not indicated.

Next, whether the maintenance request is or is not waiting for standby, the Reset and Ignore Override indicator (FWARIO) is checked:

1. If FWARIO is set, the malfunction interrupt sense line will be reset. Then, F32X01 is called to scan the I/O queues, and then control is returned ICAP.

Or

2. if FWARIO is not set, the marker is reset and a on-line transmission is sent to the marker. Then, F32X01 is called to scan the I/O queue, and then control is returned to ICAP.

c. When Reset-and-Ignore is set, and an I/O request is not n progress with the marker, then:

K70x01 is called to check if RJ (Register Junctor) needs to be cleared. An on-line transmission is sent to the marker. Then F32X01 is called to scan the I/O queues, and control is then returned to ICAP.

Executive -- maintenance modules

the following software module descriptions relate to programs for executive control and scheduling of maintenance programs. They relate to DIACON, MANIAC, and CONFIG.

L00

L00-1. name

l00 - maintenance Interrupt Access Program.

L00-2. purpose

the purpose of this module is to set or reset maniac conditions on an individual sense line or on all sense lines associated with a subsystem.

L00-3. functions

module L00 performs the following functions:

a. Sets/Resets a just ignore condition on any sense line.

b. Sets/Resets a reset and ignore condition on any sense line.

c. Sets/Resets a reset and ignore once condition on any sense line.

d. Sets just ignore all sense lines associated with a specified subsystem (Unit Maniac).

e. Resets any maniac condition which is present on the specified subsystem.

L00-4. inputs

4.1 software

4.1.1 core Tables

Hav - vector Points to HAW.

Haw - unit Maniac list all sense line to be JI.

Hbl - branch Field Loader.

Hmn - maniac Table Entry.

4.1.2 Drum Tables - None.

4.1.3 Registers - None.

4.2 HARDWARE - None.

L00-5. outputs

5.1 software 5.1.1 core Tables

Hmn - maniac Table Entry.

Hrr - maniac Reroute TBL.

5.1.2 drum Tables - None.

5.1.3 Registers - None.

5.2 HARDWARE - None.

L00-6. control

6.1 entry points

entry Points: Reasons for Entry

L50x01: rstman will cause any Maniac request on all interrupt sense lines associated with a particular device to be removed.

L50x02: setman will cause all interrupt sense lines associated with a particular device to be set to Just Ignore.

L00x05: manset rr and MANRST RR. The setting and resetting of NEW reroute request.

L00x06: the Removal of MANSET RR and MANRST RR.

L00x04: set Maniac to Just Ignore (MANSET JI).

L00x03: reset and Ignore once (MANSET RO).

L00x02: reset and Ignore Maniac (MANSET RI).

L00x01: reset JI/RI/RO Maniac Requests (MANSET JI/RI).

6.2 exit points

exit Points: Reasons for Exit

None: Return is made to client.

L00-7. subroutines used

entry Points: Functional Names

L00x01: rest of JI (Just Ignore)/(reset and ignore once) Maniac Request.

L00x02: reset and ignore indicator.

L00x03: reset and ignore once indicator.

L00x04: set Maniac to Just Ignore.

L00x05: setting and resetting of new reroute request.

L00x06: removal of MANSET RR and MANRST RR.

L00-8. narrative

8.1 discussion

the function of this module is to set or reset any of the possible maniac conditions on a given sense line. The four possible maniac conditions are:

1. Just Ignore.

2. Reset and Ignore.

3. Reset and Ignore Once.

4. Reroute.

This module also provides for the setting of all sense lines in a given subsystem to a just ignore state which would be used when removing a unit from service. There is also a provision for resetting all maniac condition which exists on aa given subsystem.

8.2 TECHNIQUE

A unique entry line is provided for each function of the Maniac program. A total of nine entry lines are provided. Module L50 is used to provide additional entry lines for module L00. The first four entry lines of this module perform very similar functions and therefore utilize common code. The four functions are to set just ignore, to set reset and ignore, to set reset and ignore once and to reset all maniac conditions on a given sense line. Table HMN is indexed by the sense line number and the appropriate indicators are set or reset.

The next two entry lines set and reset the reroute conditions on a given sense line. For each reroute, two words of data are stored in table HRR. An index into table HRR is stored in table HMN and the 23rd bit is set to indicate that a reroute is present on the sense line. If table HRR is full, the error return is used.

If the reroute is to be reset, the associated word in table HMN is extracted. The reroute index is removed and used to clear the appropriate data words in table HRR. Finally the reroute data is cleared in table HMN for the sense line specified.

The next two entry lines set and reset the unit maniacs for an entire device. That is, all maniacs on the device are reset or a just ignore is set on all sense lines associated with a device.

The unit number passed by the caller is used to index table HAV which is a pointer to table HAW. Table HAW contains all information necessary to perform the unit maniac. This includes the number of sense lines, the maximum unit index and a list of the sense lines.

Unit maniacs for all subsystem are handled the same except for Markers. Register Senders and Device Buffers. Markers are unique because all fourteen Markers can be referenced relative to their individual type. The Device Buffers are unique because the sense lines associated with the B units are eight sense lines away from the A unit rather than being adjacent as in most subsystems. Register Senders are unique because two sense lines on the mate of the requested unit must also be set to just ignored on a Maniac request.

L01c

l01c-1. name

register Sender (RS) and Common Logic Unit (CLU) Reconfiguration Program.

L01c-2. purpose

this program provides the configuration change capability for the RS and the CLU's.

L01c-3 functions

program L01C configures the interface of the RS Computer Central Processor (CCP) on the basis of three types of requests: (1) System Status Table configuration requests: (2) Calling Program instructions; or (3) following a third-party trap.

The reconfiguration requests available through L01C consist of:

a. Placing a particular RS-CLU in a Maintenance-Out-of-Service (MOS) condition, and reconfiguring the interface.

b. Switching the RS-CLU configuration.

c. Placing the RS-CLU in a crosswrite configuration.

d. Placing the RS-CLU in an In-Service condition.

e. Providing the capability to place an RS temporarily not usable in fault isolation status.

L01c-4. inputs

4.1 software

4.1.1 core Tables

Hst - system Status Table.

4.1.2 Drum Tables - None.

4.1.3 Registers

Rq - tty initiate Indicator.

X3 - client address identification.

X2 - rs-clu identification.

Register X2 may have values of 0 through 3, thereby identifying one of the two CLU's associated with RS1 or RS2, as follows:

X2 = 0 indicates RS1A; X2 = 1 indicates RS1B; X2 = 2 indicates RS2A; and X2 = 3 indicates RS2B.

4.2 hardware - none.

L01c-5. outputs

5.1 software

5.1.1 core Tables

Hst - system Status Table.

5.1.2 Drum Tables - None.

5.1.3 Registers

Ra - status of the request.

If RA is equal to 0, the request is completed without error; if RA is not equal to 0, the request is rejected.

5.2 HARDWARE - None.

L01c-6. control

6.1 entry points

entry Points Reasons for Entry

L01c01: to configure the RS-CCP interface via the Systems Status Table.

L01c02: to configure the RS-CCP interface as specified by the calling program.

L01c03: to configure the RS-CCP interface after a third-party trap.

L01c10: to verify the RS-CCP interface.

L01c11: see L01C10.

L01c20: to place an RS-CLU MOS and configure the RS-CCP interface.

L01c21: to place the MOS-CLU In-Service, and to place the In-Service CLU MOS.

L01c22: to reset the MOS condition on an RS-CLU and to configure the RS-CCP interface.

L01c23: see L01C22.

L01c24: to set an RS temporarily not usable.

L01c25: to place In-Service an RS set temporarily not usable through L01C24.

L01c26: to configure temporarily the RS-CLU interface.

L01c27: to reset the temporary RS-CLU configuration effected through L01C26.

6.2 exit points

exit Points: Reasons for Exit

Exit from all the L01C entries is to the caller's return address, as specified in Index Register 3.

L01c-7. subroutines used

entry Points: Functional Names

Special Entry Point: L11 - Register Save program.

Special Entry Point: L12 - Register Restore program.

L30x03: l03 - configuration Control Utility program.

8. NARRATIVE

8.1 discussion

the program configures the RS-CCP interface through entry points L01C01, L01C02, and L01C03. The status of both the Processor Configuration Group (PCG) and the RS is determined by the entry point; i.e., L01C01 indicates a request originating in the HST Table, L01C02 identifies a user request, and L01C03 identifies a request transmitted on sense lines.

The program sets Select Latches in the CLU, thereby effecting the required RS-CCP configuration.

The program verifies the RS-CCP interface through entry points L01C10 and L01C11. The sense line status showing the CCP Receive mode and the RS Select status is compared with the desired status, as determined by the Systems Status Table; if a discrepancy exists, an error return is passed to the user program.

Entry point L01C20 is used to place an RS-CLU in a MOS condition and to configure the RS-CCP interface. If the alternate CLU is MOS, the request is rejected. Otherwise, the CLU is set MOS and Remove message is issued, if the CLU is not already MOS. The RS-CCP interface is then reconfigured via entry point L01C01, verified via L01C11, and finally, the unit is set MANIAC Just Ignore for the MOS CLU via Subroutine L03.

The MOS CLU In-Service and the In-Service CLU MOS are switched through entry point L01C21. The request is rejected if the MOS on one CLU is not set, or if one of the flags SWT, MCC, or OS is set. The MOS CLU is placed In-Service via entry point L01C23, and the In-Service CLU is placed MOS via entry point L01C20. After the switch has occurred, the SWT flag is set.

An RS-CLU is placed is crosswrite via L01C22. The request is rejected either if one CLU is not MOS, or if the TEM flag is not set. Prior to client return, the on-line CCP is configured to write into both CLU's of an RS.

The program places an MOS CLU In-Service through L01C23. The request is rejected if the MCC override is set, or if the CLU is Out-of-Service (OS). The MOS status bit is reset and a Restore message is output to the TTY if the unit is found MOS. The RS-CCP interface is then configured via L01C01, then verified via L01C11, and finally, the CLU unit is reset MANIAC Just Ignore via Subroutine L03.

An RS may be placed in a temporarily not usable condition via L01C24 by setting the TEM flag and initiating a timer which indicates a System Clear and Start condition if the flag is not reset in two minutes.

Entry point L01C25 is used to reset the temporary condition and disable the timer set by L01C24.

The program temporarily configures the RS-CLU interface via L01C26. The request is rejected if either CLU is OS. The interface is configured with user-supplied status via L01C02, and verified via L01C10. The temporary flag is then set via L01C24.

The temporary configuration set in L01C26 is reset via L01C27. If both CLU's are OS, the request is rejected. The interface is reconfigured via L01C01 and verified via L01C11. The temporary condition is then reset via L01C25.

Entry points L01C30 and L01C31 are internally entered routines used to format Remove and Restore Reconfiguration (RC) messages for RS-CLU's.

8.2 TECHNIQUE

The functions performed by L01C are entered by user programs through entry points and returned via L01A.

L01d

1. name

l01d - register Sender Multiplex Reconfiguration Program

L01d-2. purpose

this module configures the RSM through the L01X04 Configuration Control Interface.

L01d-3. functions

module L01D performs the following functions:

a. Configures RSM according to common logic unit status.

b. Exercises Register Sender pulse and latch control.

L01d-4. inputs

4.1 software

4.1.1 core Tables

Hst - system Status Table.

4.1.2 Drum Tables - None.

4.1.3 Registers

L01d01:

x2 - register Sender Section Identity (0-1).

L01d02:

x2 - rs-clu identity (0-3).

Ra - pulses sent exactly as to be written into RS Memory.

L01d03/4:

x2 - rs-clu identity (0-3)

Ra - group busy bits to be set/reset.

Bit 0 set - Group 0/4

Bit 1 set - Group l/5

Bit 2 Set - Group 2/6

Bit 3 Set - Group 3/7

L01d05/6:

x2 - register Sender section identity (0-1).

Ra - register Junctor Identity (0-191).

L01d07/8/30:

x2 - register Sender CLU Identity.

0 - RS1A

1 - rs1b

2 - rs2a

3 - rs2b

4 - rs1 both CLU's

5 - RS2 both CLU's

Ra - the Pulse/Latch word to be written into RS Memory.

L01d10:

x1 - clu indentity.

0 = A

1 = b

2 = both A and B

X2 - register Sender Section Identity (0-3).

Ra - word to be written into RS Memory.

4.2 HARDWARE - None.

L01d-5. outputs

5.1 software

5.1.1 core Tables

Hst - systems Status Table.

5.1.2 Drum Tables - None.

5.1.3 Register

Ra - status of the request.

5.2 HARDWARE

The Register Sender is exercised via pulse and latch control.

L01d-6. control

6.1 entry points

entry Points: Reasons for Entry

L01d01: configures the RSM according to CLU MOS status.

L01d02: configures the RSM enable for a specified CLU.

L01d03/4: sets and resets the RS Group Busy.

L01d05/6: sets and resets the RJ Maintenance Busy Bity.

L01d07: writes pulse words into RS Memory.

L01d08: writes Latch Words into RS Memory.

L01d30: writes user- upplied Latch Words into RS Memory.

6.2 EXIT POINTS

Exit Points: Reasons for Exit

Exit for all entries into L01D is effected thru the return address passed on entry in X3.

L01d-7. subroutines used

entry Points: Functional Names

L01c: configures the RS-CLU per status in HST.

L03: configuration utility subroutines.

F01: schedules access to RS Memory.

L01d-8. narrative 8.1 discussion

l01d01 - configures the Register Sender Multiplex (RSM) according to the CLU status in HST.

1. check RS-CLU MOS status; specify in-service CLU's and update pulse control word.

2. Configure CLU RSM interface aacording to CLU MOS states.

3. Write into the in service CLU's Pulse and Latch words.

L01d02 - configures the Multiplex enable for a specified CLU.

1. if specified CLU is MOS, reject request.

2. Write pulse word and update pulse control word as specified by user.

L01d03/4 - sets (resets) group busy by setting (resetting) appropriate latch in RS Memory.

1. The request is rejected if associated CLU is MOS.

2. the latch word is written into RS Memory and the table is updated.

3. A TTY message is added to the list.

L01d05/6 - sets (resets) the Register Junctor (RJ) maintenance busy bit.

1. Update the RJ maintenance busy bit for specified RJ in HST.

2. if state of bit changed, TTY message is added to list (remove or restore).

L01d07 - write pulse words.

1. Clear any multiplex enable bits.

2. Set up parameters and write pulse word via L01D10.

L01d08 - write latch word.

1. Sets RS Multiplex and RJ busy bits per HST.

2. set up parameters and write latch word via L01D20.

L01d10 - writes into RS Memory and executes desired CPD for desired pulse and latch control. No checks are made; only error condition arises when RS time is unable to access RS Memory. In this case, an error return is made to user program.

L01d20 - formats latch requests handled by L01D10.

L01d30 - formats latch requests handled by L01D10 in which a user-supplied latch word, without formatting, is written into RS Memory.

8.2 TECHNIQUE

The functions performed by L01C are entered by user programs Through entry points and returned via L01A.

L01f

1. name

l01f - drum Memory System Reconfiguration Program.

2. PURPOSE

This program provides the configuration change capability for the Drum Memory System (DMS).

L01f-3. functions

the following functions are performed by Module L26:

a. Remove a drum from usage in case of faults or for routining purposes.

b. Restore a repaired drum to usage by the system.

c. Configure the Drum Memory System Computer Processor Group (CPG) interface.

L01f-4. inputs

4.1 software

4.1.1 core Tables

Hst - system Status Table.

4.1.2 Drum Tables - None.

4.1.3 Registers

X2 - drum Memory System Identity (0 to 5).

X3 - return Address.

4.2 HARDWARE

L01f-5. outputs

5.1 software

5.1.1 core Tables

Hst - system Status Table.

5.1.2 Drum Tables

None.

5.1.3 Registers

Register A gives the status of the return: if RA equals 0, the return is completed; if RA is not equal to 0, the return is rejected.

5.4 HARDWARE

The DMS is exercised by the reconfiguration subroutines via Control Pulse Directive (CPD) instructions.

L01f-6. control

6.1 entry points

entry: Reasons for Entry

Points:

L01p01: to place a DMS pair in a temporary Maintenance-Out-of-Service (MOS) condition for isolation purposes.

L01f02: to reset the temporary condition set in L01F01.

L01f03: to reset the condition set in L01F01, then places the specified drum MOS.

L01f04: to place a specified drum MOS.

L01f05: to place a drum hardware unit off-line.

L01f06: to place a drum hardware unit on-line.

L01f07: to place a drum in-service and Available for Transient Writes (ATW).

L01f08: to make a drum unavailable for transient writes.

L01f09: to configure a Drum Control Unit (DCU) to an off-line Computer Central Processor (CCP).

L01f10: to configure a DCU to an on-line CCP.

6.2: exit points

upon completion of each configuration request, control is returned to the requestor, via the return address, to L01X04 passed in X3.

L01f-7. subroutines used

entry: Functional Names

Points

L03x03: l03 - configuration Utility Program

L03x04

l03x05

l03x06

l03x07

l01f-8. narrative

8.1 discussion

when L01F01 is entered, the program places a drum pair in temporary MOS Maintenance Busy (MB) condition for fault isolation purposes. If either drum is MOS, the request is rejected. Otherwise, the pair is set MOS and MB, and a two-minute timer is initiated via subroutine L03.

The program enters L01F03 to reset the MOS and MB condition set in L01F01, and to leave a specified drum OS. The effect of scheduling this entry point is to reset the temporary condition via L01F02, and to place the specified drum MOS via L01F04.

When L01F04 is entered to place a specified drum MOS, the program rejects the request if the alternate drum is MOS, or if either of the two drums is ATW. If the drum is not already MOS, it is set MOS and a TTY REMOVE message is added.

Entry point L01F05 causes a specified drum hardware unit to be placed off-line. If the drum is not MOS, the requests if rejected. If the drum is MOS, it is set off-line and cleared via CPD instructions. The program then verifies the drum's off-line status via sense lines, then sets the unit to a MANIAC Just Ignore status for the specified drum.

Entry point L01F06 is used to place a specified drum hardware unit on-line. The program rejects the request if the drum is OS. However, if the drum is not OS, it is placed on-line via CPD instructions. If RESYNC is in progress in the CPG, the prograam sets the CCP Port On-Line Register (POLR) off-line. Finally, the program verifies that the drum is on-line and returns with an error message if the drum is off-line.

At entry point L01F07, the prograam resets the MOS state; i.e., places the drum in-service. The request is rejected if a Maintenance and Control Center (MCC) override is in effect. If the drum is MOS, the prograam resets the MOS state, sets the ATW state, and adds a RESTORE message. Finally, it resets the unit MANIAC for the drum.

Entry point L01F08 causes the program to reset the ATW state. If the drum is MOS, the request is rejected. If the drum is not MOS, the program resets the ATW state and the unit MANIAC.

At entry point L01F09, the program configures a DCU to an off-line CCP. If one PCG is not MOS, the request is rejected; similarly, if the drum is MOS or ATW, the request is also rejected. If the request is not rejected, the DCU is set off-line and MOS. Subsequently, the instructions contained in the Set Port Enable Test Register and the Set Port On-Line Register are executed in an off-line CCP.

When entry point L01F10 is entered, the program configures a DCU to an on-line CCP. If the Off-Line Flag (OFL) is not set, the request is rejected. If the OFL is set, the Port Enable Test Register is reset in the off-line CCP, and the Port On-Line Register is set in the on-line CCP.

8.2 technique

the functions performed by L01F are entered by user programs through the entry points and returned via L01A.

L09 1. name

l09 - manchk program.

L09-2. purpose

this program determines which Maniac condition is set on the requested sense line and passes the information back to the caller.

L09-3. functions.

module L09 performs the following functions:

a. Determines which Maniac condition is set and returns an indicator to the caller.

b. If a re-route is set, this module also returns the re-route data.

L09-4. inputs

4.1 software

4.1.1 core Tables

Erg - pseudo Register.

Hmn -maaniac Condition Table.

Hrr - maniac Status Table.

4.1.2 Drum Tables

None.

4.1.3 Registers

None.

4.2 HARDWARE

None.

L09-5 outputs

5.1 software

5.1.1 core Tables

Erg - pseudo Register.

Hmn - maniac Condition Table.

5.1.2 Drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARE

None.

L09-6. control

6.1 entry points

entry: Reasons for Entry

Points

L09x: to set Maniac condition.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

None: Return.

L09-7. subroutines used

none.

L09-8. narrative

8.1 discussion

this module checks the maniac condition present on the requested sense line and passes an indicator back to the caller. Interface to the module is via the MANCHK macro. This module never receives control unless a maniac condition has detected by the MANCHK macro.

If a re-route is present on the requested sense line, the re-route data is passed back to the caller. If a reset and ignor once condition exists on the sense line, a reset condition is cleared in table HMN. If a just ignore or a reset and ignore is set on the sense line, the approprate indicator is passed to the caller.

L11

1. name

l11 - register Save Routine / L12 - Register Restore Routine.

L11-2. purpose

provides re-entrable, the capability to save multiple sets of registers in the Base, Interrupt and Trap modes for Common Maintenance Programs.

L11-3. functions

modules L11 and L12 perform the following functions: Save and restore registers RQ, X1, X2, ERG001, ERG002, ERG003 and ERG004.

L11-4. inputs

4.1 software

4.1.1 core Tables HRP - Return Address Pointer.

4.1.2 Drum Tables None.

4.1.3 Register RA - The Return Address.

4.2 HARDWARE

None.

L11-5. outputs

5.1 software

5.1.1 core Tables HRP - Return Address Pointer.

5.1.2 Drum Tables None.

5.1.3 Registers None.

5.2 HARDWARE

None.

L11-6. control

6.1 entry points

entry: Reasons for Entry

Points

L11x01: branched to directly to save registers.

L12x01: branched to directly to restore registers.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

Calling Program: For both L11 and L12, exit is to the address specified in the RA register.

L11-7. subroutines used

none.

L11-8. narrative

8.1 discussion

upon entry to L11 the Return Address Pointer (HRPRA1) is incremented by one and the contents of the RA is saved. The Last Register Stored Pointer (HPSRS1) is then incremented by one as each register is stored in turn. After all registers are saved, the Return Address Pointer is decremented by one prior to returning to the calling program.

Upon entry to L12 the Return Address Pointer is incremented by one and the contents of the RA is saved. The registers are loaded from the address specified in HPSRS1 which is decremented by one after each restore operation. The Return Address Pointer is decremented by one prior to the return to the calling program.

8.2 TECHNIQUE

According to this Trap and Interrupt Re-entrable Register Save/Restore technique, the registers must be restored in reverse order in which they have been saved. Thus, the latest set saved must be the first set restored.

L20a

1. name

l20a - diacon request Handler (DIARQT).

L20a-2. purpose

module L20A performs the initial analysis of each request to schedule a maintenance program presented to DIACON.

L20a-3. functions

program module L20A performs the following functions:

a. Accepts requests to schedule maintenance programs.

b. Determines the validity of the request (checks the range of the request type and job number.)

c. Determines the job type (Isolation, Unit Clear and Start, Localization, Repair Verification, Routining, or Special), and establishes job priority.

d. Sets up DIACON's tables for scheduling the client (sets the appropriate bit in Table HDJ; moves into Table HDD any data to be passed to the maintenance program to be scheduled).

e. Sets the level 0 DIAFLG bit in the Executive's job queue Table EDC) to indicate that DIACON has work to do.

f. Return any error indicators to the requesting program.

L20a-4. inputs

4.1 software

4.1.1 core Tables

Hdd - diadat table.

Hdj - diajob table.

Hdo - diagonal Ones Table.

Hdr - repeat Test Control Words.

Hdv - diavec table.

Hps - register Save Pointer.

4.1.2 Drum Tables

None.

4.1.3 Registers

RA - Contents depend on the entry point used. RA contains the return address of the calling program (L20X03), or the diagnostic request word (L20X01).

X1 - Contains the starting location in core for storage of data to be passed to the maintenance program to be scheduled.

X2 - Contains the identity of the unit upon which maintenance is to be performed.

Q - Contains the DIAGWD Word.

4.2 HARDWARE

None.

L20a-5. outputs

5.1 software

5.1.1 core Tables

Edc - diaflg table.

Hbl - branch Field Loader.

Hdd - diadat table.

Hdj - diajob table.

Hdr - repeat Test Control Words.

Hdt - diatab table.

Hjc - diacon executive Instruction.

Hps - register Save Pointer.

Hrp - return Address Pointer.

5.1.2 Drum Tables

None.

5.1.3 Registers

RA - Contains any result code or error indicator which is to be returned to the requesting program.

5.2 HARDWARE

None.

L20a-6. control

6.1 entry points

entry: Reasons for Entry

Points

L20x01: this entry point is used by a requesting program to input the device type, request type, source code, repeat code, and dump code as individual parameters. Source of request is the Interrupt processors.

L20x03: this entry point is used by a requesting program if the information contained in the request has been preformatted and stored in ERG001. Source of request is MAININ.

6.2 exit points

exit: Reasons for Exit

Points

Calling Program: Control is returned to the requesting program.

L20a-7. subroutines used

entry: Functional Names

Points

L11: re-Entrant Register Save. The first instruction encountered after entry into module L20A is a macro call to L11 (SAVERG). This sub-routine stores all registers for the requesting program.

L12: re-Entrant Register Restore. Before returning control to the requesting program, L12 is entered as a closed subroutine via macro call RESTRG. L12 restores all registers saved by L11.

L20a-8. narrative

8.1 discussion

l20a is a core-resident module which may be entered in either the Base mode or the Interrupt mode, and re-entered from the Trap mode. The module may be called by any application program which has determined that a maintenance program controlled by DIACON should be run. L20A is entered as a closed subroutine.

Module L20A accepts the request to schedule a maintenance program and determines if the request is valid. If the request is not valid, an error indicator and program control are returned to the requesting program. If the request is valid, L20A determines the job type, performs DIACON users status checks to verify that the requested maintenance program can be run, and stores any data to be passed to the maintenance program. Before returning control to the requesting application program, module L20A sets the Executive's Level 0 DIAFLG bit, indicating that DIACON has work to do.

8.2 TECHNIQUE

Not applicable.

L20c

1. name

l20c - diacon abort Handler.

L20c-2. purpose

module L20C alerts maintenance programs which are currently running under control of DIACON that they should abort.

L20c-3. functions

program module L20C performs the following functions:

a. Receives the abort request.

b. Determines that the request is intended for the program that currently has control of DIACON and returns a verification message to the requesting program.

c. Sets the abort bit in word 0 (Control Word) of table HDT.

L20c-4. inputs

4.1 software

4.1.1 core Tables

Hdt - diatab table.

Hbl - branch Field Loader.

4.1.2 Drum Tables

None.

4.1.3 Registers

Ra -contains the return address of the requesting program.

4.2 HARDWARE

None.

L20c-5. outputs

5.1 software

5.1.1 core Tables

Hdt - diatab table.

5.1.2 Drum Tables

None.

5.1.3 Registers

Q - Contains a job verification message to be returned to the requesting program. (RQ = 0 indicates that the client designated in the abort request is not in control of DIACON; RQ = 1 indicates that the requested client has control of DIACON and the abort bit is set in the control word.

5.2 HARDWARE

None.

L20c-6. control

6.1 entry points

entry: Reasons for Entry

Points

L20x07: this entry line may be called by any application program which has determined that a maintenance program which has been requested should be aborted. Entry is made via the macro call DIABRT.

6.2 exit points

exit: reasons for Exit

Points

Calling Program: Program control is returned to the requesting program.

L20c-7. subroutines used

none.

L20c-8. narrative

8.1 discussion

l20c is a core-resident module which may be entered in either the Base mode or the Interrupt mode, and re-entered from the Trap mode. The module is entered as a closed subroutine.

The abort capability is used to inform a maintenance program in progress that a higher priority program has been requested, or that something has happended within the system which may have an adverse effect on the test results.

8.2 TECHNIQUE

Module L20C sets the abort bit (ABT) in Table HDT if the abort request received is for the maintenance program which currently has control of DIACON. Before a maintenance program running under control of DIACON takes any real-time breaks, it must check ABT.

If ABT is set, the maintenance program determines what action to take. Words 10 through 19 of Table HDT contain control data that effect a successful program abort. The program abort sequence includes re-setting the subsystem, releasing any work areas being used, re-scheduling the program being aborted, if possible, and taking any other actions peculiar to the program being aborted. Upon completion of the abort sequence control is returned to the Executive.

L21a

1. name

l21a - diacon diaflg handler Module.

L21a-2. purpose

l21a provides interface between the Executive's DIAFLG mechanism and program modules which use DIAFLG (DIACON, TTY INPUT, and CONFIG).

L21a-3. functions

module L21A performs the following functions:

a. Verifies that the DIAFLG priority level received from the Executive is within range, and that a job is in Table HDF at that level.

b. Transfers control to the appropriate program module.

L21a-4. inputs

4.1 software

4.1.1 core Tables

Hdf - diaflg clients.

Fwa - executive Interface Work Area.

4.1.2 Drum Tables

None.

4.1.3 Registers

X2 - Contains the priority level (0 through 7) of the set DIAFLG bit detected by the Executive.

4.2 HARDWARE

None.

L21a-5. outputs

5.1 software

5.1.1 core Tables

None.

5.1.2 Drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARE

None.

L21a-6. control

6.1 entry points

entry: Reasons for Entry

Points

L21x01: this entry line is used by the Executive upon finding a set DIAFLG bit in its job queue.

6.2 EXIT POINTS

Control is passed to the DIAFLG client associated with the set DIAFLG bit.

a. Level 0 DIAFLG - The client is DIACON; Module L21A passes control to Module L21C at entry point L21X06.

b. Level 1 DIAFLG - The client is TTY INPUT; Module L21A passes control to Module F58 at entry point F58X02.

c. Level 3 DIAFLG - The client is CONFIG; Module L21A passes control to Module L01 at entry point L01X03.

d. Level 2, 4, 5, 6, and 7 DIAFLG bits are not used.

If table HDF has no client waiting to be processed, control is returned to the Executive.

L21a-7. subroutines used

none.

8. NARRATIVE

8.1 discussion

l21a is a core-resident module which is entered by the Executive whenever it detects a set DIAFLG bit in its job queue. The module may be entered from either the Base mode or the Interrupt mode, and re-entered from the Trap mode. L21A performs system checks and transfers control to the called program module. After the called program module has completed processing, control is returned to the Executive through Module L21A.

8.2 technique

not Applicable.

L21b

1. name

l21b - diacon rvpstp handler Module.

L21b-2. purpose

module L21B processes requests to stop a Repair Verify Repeat test which is currently active in DIACON.

L21b-3. functions

module L21B performs the following function:

Resets a control bit in DIACON Table HDR, causing the currently active Repair Verify Repeat test to be stopped.

L21b-4. inputs

4.1 software

4.1.1 core Tables

None.

4.1.2 Drum Tables

None.

4.1.3 Registers

None.

4.2 HARDWARE

None.

L21b-5. outputs

5.1 software

5.1.1 core Tables

Hdr - repeat Test Control Words.

5.1.2 Drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARE

None.

L21b-6. control

6.1 entry points

entry: Reasons for Entry

Points

L21x05: entry is made by the macro call RVPSTP, for the purpose of stopping a Repair Verify Repeat test.

6.2 EXIT POINTS

Control is returned to the requesting program.

L21b-7. subroutines used

none.

8. NARRATIVE

8.1 discussion

l21b is a core-resident module which may be entered in either the Base mode or the Interrupt mode, and re-entered from the Trap mode.

Module L21B zeroes the Repair Verify Repeat bit (RVP) in DIACON Table HDR. This stops the currently active Repair Verify Repeat test and extinguishes the REPAIR VERIFY REPEAT lamps at the Maintenance and Control Console (MCC). Although the Repair verify test in progress will not be aborted, it will be the last test run.

8.2 TECHNIQUE

Not applicable.

L21c

1. name

l21c - diacon - diajob interrogater.

L21c-2. purpose

schedules all IMMEDIATE SPECIAL jobs into the proper level of the Executive's work queue. If the job is not an IMMEDIATE SPECIAL, L21C schedules DRUM DIACON (modules L23A, L23B, and L23C), whcih will be responsible for scheduling the maintenance program.

L21c-3. functions

program module L21C performs the following functions:

a. Searches DIACON's DIAJOB Table HDJ for a request to schedule a maintenance program.

b. Determines the job type.

c. Acquires the proper size work area to allow the maintenance program to be scheduled to run.

d. Schedules all IMMEDIATE SPECIAL jobs, or schedules DRUM DIACON if the job is not an IMMEDIATE SPECIAL.

L21c-4. inputs

4.1 software

4.1.1 core Tables

Hdj - diajob table.

Hdo - diagonal Ones Table.

Hdq - wa queue identifier for DIACON.

Hdt - diatab table.

Hdv - diavec table.

Hjc - diacon executable Instructions.

4.1.2 Drum Tables

None.

4.1.3 Registers

None.

4.2 HARDWARE

None.

L21c-5. outputs

5.1 software

5.1.1 core Tables

Edc - diaflg table.

Fwa - exec interface Work Area.

Hdj - diajob table.

Hdt - diatab table.

Lwe - diacon work Area Overlay.

5.1.2 Drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARE

None.

L21c-6. control

6.1 entry points

entry: Reasons For Entry

Points

L21x06: entry is made for DIACON Module L21A as a result of the level 0 DIAFLG bit having been set.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

Executive Program: Program control is returned interrupt (associated Executive through DIACON Module L21A.

L21c-7. subroutines used

entry: Functional Names

Points

E01x01: dpu scheduler, E01 is an external subroutine L21B01 or L21A01.

L01x02: configuration Control. L01 is an external subroutine entered for the purpose of acquiring a work area.

L21a01: is an internal subroutine which schedules all IMMEDIATE SPECIAL jobs.

L21b01: is an internal subroutine which schedules DRUM DIACON (Modules L23A, L23B, and L23C).

L21c01: is an internal subroutine which performs the job search of Table HDJ.

L22a03: diacon timer (L22C) is an external subroutine entered from subroutine L21B01. Control is returned to L21C at L21B02.

L21c-8. narrative

8.1 discussion

l21c is a core-resident module which can be entered from the Base mode only, from DIACON Module L21A. L21C is not re-enterable; i.e., once the module is entered, processing must proceed to completion before the module can be re-entered with a new request.

Module L21C searches DIACON's work-to-do Table HDJ for a job that can be scheduled. Table HDJ is searched sequentially, thus establishing job priority. The first word searched is Isolation word 0, and the last word searched is the Audit word.

In some cases, the job found cannot be scheduled; for example, the job requires DRUM DIACON Modules L23A, L23B, and L23C, and DRUM DIACON has already been scheduled to handle another request; or the job requires control of DIACON and DIACON is already busy. When the job found cannot be scheduled, the search is continued. IMMEDIATE SPECIAL jobs do not require control of DIACON or the use of DRUM DIACON. These jobs are scheduled immediately by Module L21C (Subroutine L21A01).

Once a job which can be scheduled has been located, a work area of the proper size is obtained from the Executive's spare work area.

If the job is an IMMEDIATE SPECIAL, it is scheduled by subroutine L21A01. If the job is not an IMMEDIATE SPECIAL, DRUM DIACON is scheduled at Executive Priority Level 0, and a timer within module L22C is started. The timer keeps track of the length of time that DRUM DIACON waits to be serviced. If this interval exceeds approximately 30 seconds, a System Clear and Start is initiated. When DRUM DIACON is called it is responsible for scheduling the requested maintenance program.

Before Module L21C returns control to the Executive, a check is made to determine if any bits in Table HDJ are still set, thereby indicating that DIACON has more work to do. If any bits are set, the Level 0 DIAFLG bit is set so that DIACON Module L21C will be entered again.

8.2 TECHNIQUE

Not applicable.

L21d

1. name

l21d - diacon diarls module.

L21d-2. purpose

module L21D is used to clear DIACON after the termination of a maintenance program so that a new job may be started.

L21d-3. functions

program module L21D performs the following functions:

a. Verifies that the maintenance program requesting release is the one that is currently in control of DIACON.

b. Determines if the program has completed processing, or should be re-scheduled.

c. Re-schedules the job, if necessary.

d. Provides control of indicator lamps on the Maintenance and Control Console.

e. Zeroes DIACON's DIATAB Table.

f. Stops the timers associated with the main tenance program being released.

L21d-4. inputs

4.1 software

4.1.1 core Tables

EDC - DIAFLG Table.

FJB - Base Level Junk.

HDJ - DIAJOB Table.

HDO - Diagonal Ones Table.

HDR - Repeat Test Control Words.

HDT - DIATAB Table.

HLS - MDA Lamp Status.

4.1.2 Drum Tables

None.

4.1.3 Registers.

XI - Contains the return address of the requesting program.

4.2 HARDWARE

None.

L21d-5. outputs

5.1 software

5.1.1 core Tables

EDC - DIAFLG Table.

FJB - Base Level Junk.

HDJ - DIAJOB Table.

HDR - Repeat Test Control Words.

HDT - DIATAB Table.

HLS - MDA Lamp Status.

5.1.2 Drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARE

None.

L21d-6. control

6.1 entry points

entry: Reasons for Entry

Points

L21x07: entry must be made by any maintenance program running with control of DIACON which has either completed processing, or has been directed to abort. Entry caused DIACON to be cleared so that a new job may be started.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

Calling Program: Control is returned to the caller.

L21d-7. subroutines used

entry: Functional Names

Points

L22a02: diacon timer Module (L22C). This subroutine causes interval timing associated with the client maintenance program to stop. Control is returned to L21D at line L21A07.

L21d-8. narrative

8.1 discussion

l21d is a core-resident module which may be entered in either the Base mode or the Interrupt mode, and re-entered from the trap mode. The module is entered as a closed subroutine by macro call DIARLS.

L21D must be entered by each maintenance program running under control of DIACON before that program gives up control. If the program is terminating as the result of an abort directive. Module L21D re-schedules the program, if possible.

8.2 TECHNIQUE

Not applicable.

L21e

1. name

l21e - diacon audit handler

L21e-2. purpose

module L21E adds or removes AUDIT requests from DIACON's work queue.

3. FUNCTIONS

Program module L21E performs the following functions:

a. Accepts and stores the request for an AUDIT job.

b. Determines whether the request is to add or remove an AUDIT, and verifies that the job number is valid.

c. Performs the add or delete operation, or returns an error Indicator to the requesting program.

d. Provides a Return-to-user path for DIACON Module L22A.

L21e-4. inputs

4.1 software

4.1.1 core Tables

HBL - Branch Field Loader.

HDO - Diagonal Ones Table.

HJC - DIACON Executable Instructions.

4.1.2 Drum Tables

None.

4.1.3 Registers

A - Contains the return address of the requesting program.

Q - Contains the job number of the AUDIT request to be added or deleted.

4.2 HARDWARE

None.

L21e-5. outputs

5.1 software

5.1.1 core Tables

EDC - DIAFLG Table.

HDJ - DIAJOB Table.

5.1.2 Drum Tables

None.

5.1.3 Registers

A - Contains status information to be returned to the requester (register A equals 0 if the request is succcessful; Register A is negative if the request is not successful).

5.2 HARDWARE

None.

L21e-6. control

6.1 entry points

entry: Reasons for Entry

Points

L20x03: entry is made by macro call AUDRMV to remove an audit request from DIACON's tables.

L20x05: entry is made by macro call AUDROT to add an audit request to DIACON's tables.

L20b01: entry is made from DIACON module L22A. L20B01 is used as a common Return to Caller subroutine by Modules L21E and L22A.

6.2 exit points

control is returned to the requesting program.

L21e-7. subroutines used

entry: Functional Names

Points

L20a01: this internal subroutine performs the add or delete operation.

L20b01: this internal subroutine is used to return control to the requesting program.

8. NARRATIVE

8.1 discussion

l21e is a core-resident module which may be entered in either the Base mode or the Interrupt mode, and re-entered from the Trap mode.

The module verifies that the AUDIT job number received in macro call AUDRMV or AUDRQT is valid (72 to 95 inclusive), before processing the request. If the request is valid, the appropriate bit in the audit word of Table HDJ (DIACON's work queue) is set or reset, thereby adding or removing the AUDIT job.

If an AUDIT request is being added to Table HDJ, the level 0 DIAFLG bit in the Executive's job queue (Table EDC) will be set, thus indicating that DIACON has work to do.

If an AUDIT request is being removed from Table HDJ, the Level 0 DIAFLG bit in EDC will not be reset. The next time that the Executive interrogates DIAFLG, control is transferred through DIACON Module L21A to L21C. If the AUDIT request removed had been the only job waiting in Table HDJ, control will be returned to the Executive.

Exit Routine L20B01 stores any error messages in Register A and returns control to the requesting program. L20B01 is used by this module and by DIACON Module L22A as a common return to requester subroutine.

8.2 TECHNIQUE

Not applicable.

L22a

1. name

L22A - DIACON - DIARMV Module.

L22a-2. purpose

module L22A is used to remove a job which is in DIACON waiting to be scheduled.

L22a-3. functions

program module L22A performs the following functions:

a. Receives requests to have jobs removed from DIACON's work queue.

b. Verifies that the request is valid.

c. Removes the job.

d. Returns a result code to the calling program.

L22a-4. inputs

4.1 software

4.1.1 core Tables

HDO - Diagonal Ones Tables.

HDV - DIAVEC Table.

4.1.2 Drum Tables

None.

4.1.3 Registers

A - Return address of the requesting program.

Q - Contains the job type (bits 7 to 14) and the devide number (bits 0 to 6).

X2 - Contains the unit number.

4.2 HARDWARE

None.

L22a-5. outputs

5.1 software

5.1.1 core Tables

HDJ - DIAJOB Table.

5.1.2 Drum Tables

None.

5.1.3 Registers

A - Register A contains a result code which is to be returned to the calling program.

5.2 HARDWARE

None.

L22a-6. control

6.1 entry points

entry: Reasons for Entry

Points

L22x01: entry may be made by any application program which has determined that a job in DIACON waiting to be scheduled should not be processed.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

L20b01: control is returned to the calling program through DIACON Module L21E. Subroutine L20B01 of L21E is used as a common return by DIACON Modules L21E and L22A.

L22a-7. subroutines used

none.

L22a-8: narrative

8.1 discussion

module L22A is a core-resident module which may be entered from either the Base mode or the Interrupt mode, and re-entered from the Trap mode. Entry is made by macro call DIARMV.

The module verifies that the job type and device number received in macro call DIARMV are valid before processing the request. If they are valid, the job number is formed and the corresponding bit in DIACON's work queue (Table HDJ) is reset.

Module L22A does not reset the level 0 DIAFLG bit in the Executive's job queue when it removes a job. If only one job is waiting in DIACON to be scheduled, and that job is removed, DIACON will still be entered by the Executive. When DIACON's work queue (Table HDJ) is searched, no jobs will be found and control will be returned to the Executive.

L22A will not remove a job from DIACON if that job is already running.

8.2 TECHNIQUE

Not applicable.

L22b

1. name

l22b - diacon skedip module.

L22b-2. purpose

module L22B updates control information in DIACON's DIATAB Table to indicate that a job which has been scheduled in now running.

L22b-3. functions

program module L22B performs the following functions:

a. Updates control information in Table DIATAB (HDTA01) control word.

b. Calls DIACON Module L22C to start interval timers associated with the maintenance program which has been given control.

L22b-4. inputs

4.1 software

4.1.1 core Tables

HDT - DIATAB Table.

4.1.2 Drum Tables

None.

4.1.3 Registers None.

4.2 HARDWARE

None.

L22b-5. outputs

5.1 software

5.1.1 core Tables

HDT - DIATAB Table.

5.1.2 Drum Tables

None.

5.1.3 Registers

None.

5.2 HARDWARE

None.

L22b-6. control

6.1 entry points

entry: Reasons for Entry

Points

L22x03: this entry point must be called by each maintenance program once that program receives control.

6.2 EXITS POINTS

Exit: Reasons for Exit

Points

Calling Program: Control is returned to the requesting program.

L22b-7. subroutines used

entry: Functional Names

Points

L22a01: diacon module L22C is entered as a closed subroutine at entry line L22A01. This subroutine starts timers associated with the maintenance program.

L22b-8. narrative

8.1 discussion

module L22B must be called by each maintenance program controlled by DIACON immediately after receiving control.

8.2 TECHNIQUE

Not applicable.

L23a

1. name

l23a - diacon drum Resident Module Scheduler.

L23a-2. purpose

module L23A schedules all jobs handled by DIACON which are not IMMEDIATE SPECIALS OR AUDITS. Program module L23A performs the following functions:

a. Determines the type of job requested.

b. Performs system checks to verify that the request is valid and that the maintenance program being requested can be run.

c. Acquires the proper size work area to allow the job being scheduled to run.

d. transfers control to DIACON module L23B if the request is for an AUDIT program (123B sets up DIACON's tables to allow the scheduling of AUDIT programs and returns control to L23A).

3. schedules the requested maintenance program.

L23a-4. inputs

4.1 software

4.1.1 core Tables

EDC - DIAFLG Table.

FWA - Executive Interface Work Area.

HDD - DIADAT Table.

HDJ - DIAJOB Table.

HDO - Diagonal Ones Table.

HDT - DIATAB Table.

HDV - DIAVEC Table.

HST - System Status Table.

LCW - Work Area Queue Identifier.

LWE - DIACON Work Area Overlay.

4.1.2 Drum Tables

LDC - DIACON DIACTL Table.

LDL - DIACON DILOC Table.

LJP - Drum DIACON Local Storage

4.1.3 Registers

X1 - Address of Drum DIACON Work Area.

4.2 HARDWARE

None.

L23a-5. outputs

5.1 software

5.1.1 core Tables

EDC - DIAFLG Table.

FWA - Executive Interface Work Area.

HDJ - DIAJOB Table.

HDT - DIATAB Table.

LWE - DIACON Work Area Overlay.

5.1.2 Drum Tables

LJP - Drum DIACON Local Storage.

5.1.3 Registers

X1 - Address of Drum DIACON Work Area.

5.2 HARDWARE

None.

L23a-6. control

6.1 entry points

entry: Reasons for Entry

Points

L23x01: entry is made by the Executive for the purpose of scheduling a maintenance program.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

E01x07 dpu scheduler. Control is returned to the Executive.

L23a-7. subroutines used

entry: Functional Names

Points

E01x01: dpu scheduler.

F04x01: work Area Assignment Module F04 is entered as a closed subroutine from internal subroutine L23A08 for the purpose of acquiring a work area.

F05x01: work Area Return. Module F05 is entered as a closed subroutine if the job requested cannot be scheduled at this time. This subroutine returns the work area to the square work area queue.

L22x05: diacon timer Module. Module L22C is entered as a closed subroutine from internal subroutine L23A07. Entry at L22X05 causes timing of DIACON to be stopped and timing of the Executive takes longer than approximately 10 seconds to call the scheduled maintenance program, a System Clear and Start in initiated.

L23a01: this internal subroutine saves registers A, Q, X1, X2, and X3 in table LJP (DIACON Local Storage).

L23a02: this internal subroutine restores the registers saved by subroutine L23A01.

L23a03: this internal subroutine is entered prior to scheduling the client, this subroutine acquires the priority level that the program should be scheduled on.

L23a04: this internal subroutine returns work areas to the spare work area queue. The subroutine is entered if the work area acquired is not large enough to meet the requirements of the maintenance program being scheduled.

L23a05: this internal subroutine removes the job being scheduled from DIACON's work queue. The subroutine is entered just prior to scheduling the job so that DIACON will not try to process the request a second time.

L23a06: this internal subroutine forms the control word, inserts it into Table HDT (DIATAB) and determines where the user's data is being stored in DIACON's tables.

L23a07: this internal subroutine determines if control is returned to the Executive. if there is more work to do, the Level 0 DIAFLG bit is set so that DIACON will be re-entered to process the request.

L23a08: this internal subroutine is used to acquire a larger work area. The subroutine is entered whenever the work area which has been acquired for a maintenance program being scheduled is not large enough to allow the program to run.

L23b01: diacon drum Resident Module audit Scheduler. DIACON Module L23B is entered as a closed subroutine if it is determined that the program being scheduled is an AUDIT program.

L23b02: diacon drum Resident Module Print Program. DIACON module L23C is entered to print an error message if the job requested is not available at this time. This subroutine will be used if the unit upon which maintenance is to be performed is out of service, or if maintenance is requested on Register Sender and the other Register Sender of the pair is out of service (both Register Senders of a pair cannot be out of service at the same time).

L23e01: diacon drum Resident Module Print Program. DIACON module L23C is entered as a closed subroutine at L23E01 whenever an invalid entry is found in Table LDL (DIALOC). The subroutine outputs an error message to the TTY.

L23e02: diacon drum Resident Module Print Program. DIACON module L23C is entered as a closed subroutine at L23E02 if an invalid AUDIT request is encountered.

L23e03: diacon drum Resident Module Print Program. DIACON module L23C is entered as a closed subroutine at L23E03 is it is determined that a request which is being processed cannot be scheduled at this time. All registers will be saved so that an attempt to schedule the job can be made at a later time.

L23a-8. narrative

8.1 discussion

diacon module L23A is a drum-resident module which is scheduled by DIACON module L21C (subroutine L23B01). Once module L23A is read Into core, it may be entered from either the Base mode or the Interrupt mode, and re-entered from the Trap mode.

Module L23A schedules all DIACON-controlled maintenance programs except IMMEDIATE SPECIAL jobs. IMMEDIATE SPECIAL jobs are programs which can be scheduled without having data input to them from the requesting program. These jobs are scheduled by DIACON module L21C (subroutine L21A01).

Requests to schedule AUDIT program are processed by module L23B (refer to subroutine L23B01).

DIACON module L23C consists of subroutines which are used by L23A and L23B to effect the printout of error messages from the TTY.

8.2 technique

not applicable

L23b

1. name

l23b - diacon drum Resident Module Audit Scheduler.

L23b-2. purpose

module L23B processes requests to schedule AUDIT programs. This module sets up DIACON's tables so that an AUDIT program may be scheduled.

L23b-3. functions

program module L23B performs the following functions:

a. Verifies that the request presented to DIACON is for an AUDIT program and that the request is valid.

b. Acquires the proper size work area so that the AUDIT program to be scheduled can run.

c. Forms and stores in DIACON's tables the control words required to schedule the AUDIT program.

L23b-4. inputs

4.1 software

4.1.1 core Tables

HDQ - Work area Queue Identity for DIACON

LWE - DIACON Work Area Overlay.

4.1.2 Drum Tables

LDL - DIACON DIALOC Table.

4.1.3 Registers

X1 - address of Drum DIACON Work Area.

4.2 HARDWARE

None.

L23b-5. outputs

5.1 software

5.1.1 core Tables

Fwa - executive Interface Work Area Table.

5.1.2 Drum Tables

LJP - DIACON Local Storage Table

5.1.3 Registers

X1 - Address of Drum DIACON Work Area.

5.2 HARDWARE

None.

L23b-6. control

6.1 entry points

entry: Reasons for Entry

Points

L23b01: entry is made for DIACON module L23A as the result of that module having encountered a request to schedule an AUDIT program.

6.2 EXIT POINTS

Exit: Reasons for Exit

Points

L23a03: diacon drum Resident Module Scheduler. This exit point is used when all system checks performed have been successful and a work area has been acquired. Module L23B has set up DIACON's tables and the AUDIT program requested will be scheduled by module L23A.

L23a04: diacon drum Resident Module Scheduler. This exit point is used when a work area large enough to meet the requirements of AUDIT program being scheduled cannot be acquired. DIACON will look for another job to schedule. If no other jobs are waiting to be scheduled, control will be returned to the Executive.

L23b03: diacon drum Resident Module Print Program. This module is entered if L23B has determined that the AUDIT requested has an invalid job number. An error message will be output to the TTY.

L23b-7. subroutines used

entry: Functional Names

Points

L23a01: diacon drum Resident Module Scheduler. Entry into module L23A at L23A01 causes registers A, Q, X1, X2, and X3 to be saved in Table LJP (DIACON Local Storage).

L23a02: diacon drum Resident Module Scheduler. Entry into module L23A at L23A02 causes the registers saved at L23A01 to be restored.

L23a05: diacon drum Resident Module Scheduler. If all checks performed by L23B are successful and if a work area has been acquired, entry is made into DIACON module L23A at L23A05. This subroutine causes the job to be removed from DIACON's work queue so that DIACON will not attempt to schedule the job a second time. Immediately after completion of this subroutine the job will be scheduled (exit point L23A03).

L23a08: diacon drum Resident Module Scheduler. Module L23A is entered at L23A08 when the work area which has been acquired is not large enough to meet the requirements of the job. This subroutine returns the work area to the Executive and attempts to secure a larger work area.

L23b-8. narrative

8.1 discussion

module L23B is a drum-resident module which can be entered only from DIACON Module L23A. Module L23B uses as closed subroutines portions of DIACON modules L23A and L23C.

8.2 technique - not applicable.

L23c

1. name

l23c - diacon drum Resident Module Print Program.

L23c-2. purpose

diacon module L23C formats and controls the output of error messages from DIACON modules L23A or L23B.

L23c-3. functions

program module L23C performs the following functions:

a. Saves control information if an attempt to schedule the maintenance program will be made at a later time.

b. Formats the message to be output to the TTY.

c. Removes the job from DIACON's work queue.

L23c-4. inputs

4.1 software

4.1.1 core Tables

FWA - Executive Interface Work Area.

HDD - DIADAT Table.

LWE - DIACON Work Area Overlay.

4.1.2 Drum Tables

LJP - DIACON Local Storage.

4.1.3 Registers

X1 - Address of work area passed.

4.2 HARDWARE - None.

L23c-5. outputs

5.1 software

5.1.1 core Tables

LWA - Executive Interface Work Area.

5.1.2 Drum Tables - None.

5.1.3 Registers

X1 - address of work area passed.

5.2 HARDWARE - None.

L23c-6. control

6.1 entry points

entry Points: Reasons for Entry

L23b02: entry is made from DIACON module L23A if the job requested cannot be found in table LDC.

L23b03: entry is made from DIACON module L23B after that module has encountered an AUDIT request with an invalid job number.

L23e01: entry is made from DIACON module L23A if an invalid entry is encountered in Table LDL (DIALOC).

L23e02: entry is made from DIACON module L23A if an invalid AUDIT entry is encountered.

L23e03: entry is made from DIACON module L23A if one of the system status checks or sense line checks required by the program being scheduled does not pass, an abort error message will be output to the TTY.

6.2 exit points

exit Points: Reasons for Exit

L23a07: diacon drum Resident Module Scheduler. Program control is returned to DIACON module L23A. If DIACON has more work to do, the Level 0 DIAFLG bit will be set, indicating to the Executive that DIACON has more work to do.

L23c-7. subroutines used

entry Points: Functional Names

E01X01: DPU Scheduler.

F07X07: Output Format and Print.

L23a01: diacon drum Resident Module Scheduler. This subroutine stores registers A, Q, X1, X2, X3 and data block lengths in Table LJP (DIACON Local Storage).

L23a05: diacon drum Resident Module Scheduler. This subroutine (part of DIACON module L23A) removes the job being scheduled from DIACON's work queue.

L23a06: diacon drum Resident Module scheduler. This subroutine (part of DIACON module L23A) forms the control word, inserts it into Table HDT (DIATAB), and determines where the user's data is being stored in DIACON's tables.

L23c01: this internal subroutine sets up the error message which will be output to the TTY.

L23c-8. narrative

8.1 discussion

l23c is a core-resident module which may be entered in either the Base mode or the Interrupt mode, and re-entered from the Trap mode.

The module formats and outputs messages as dictated by error information received from DIACON modules L23A and L23B.

8.2 technique - not applicable.

L24a

1. name

l24a - diacon repeat Handler.

L23a-2. purpose

module L24A performs two unrelated functions for DIACON. The module ensures that repeat tests are run one at a time; in addition, it inserts into Table HAK the identity of expired timers contained in DIACON Module L22C.

L24a-3. functions

program module L24A performs the following functions:

a. Verifies that a repeat test is not currently running before allowing another repeat test to be scheduled.

b. Loads Register A with the identity of an expired timer.

L24a-4. inputs

4.1 software

4.1.1 core Tables

EDC - DIAFLG Table.

HDJ - DIAJOB Table.

HDO - Diagonal Ones Table.

HDR - Repeat Test Control Words.

4.1.2 Drum Tables - None.

4.1.3 Registers - None.

4.2 HARDWARE - None.

L24a-5. outputs

5.1 software

5.1.1 core Tables

EDC - DIAFLG Table.

HAK - System Clear and Start Output Table.

HDJ - DIAJOB Table.

5.1.2 Drum Tables - None.

5.1.3 Registers - None.

5.2 HARDWARE - None.

L24a-6. control

6.1 entry points

entry Points: Reasons for Entry

L24x01: entry may be made from any application program desiring to schedule a repeat test.

L24x03: entry is made from DIACON module L22C if the Drum Resident DIACON interval being timed expires.

L24x04: entry is made from DIACON module L22C if the client interval being timed expires.

6.2 EXIT POINTS

Exit Points: Reasons for Exit

Calling Program: Program control will be returned to the caller if the module had been entered at L24X01. If entry is made at L24X03 or L24X04, module L16U (System Clear and Start) is entered at L16X02.

L24a-7. subroutines used - none.

8. NARRATIVE

8.1 discussion

l24a is a core-resident module which may be entered in either the Base mode or the Interrupt mode, and reentered from the Trap mode.

Module L24A is entered at L24X01 prior to scheduling any repeat test. L24A verifies that another repeat test is not currently running. If a repeat test is running, L24A sets the appropriate bit in Table HDJ (DIACON's work queue), and sets the Level Q DIAFLG bit in the Executive's work queue. DIACON will be entered at a later time to process the repeat request. Program control is returned to the calling program.

Entry at L24X03 or L24X04 causes the identify of the expired timer in DIACON module L22C to be inserted into Table HAK. Program control is transferred to module L16U (System Clear and Start).

8.2 TECHNIQUE - Not applicable.

L50

1. name

l50 - extra Entry Lines for L00.

L50-2. purpose

this module provides two additional entry lines for module L00.

L50-3. functions

module L50 performs the following functions:

a. Provides an entry line for the unit Maniac Set.

b. Provides an entry line for the unit Maniac reset.

L50-4. inputs

4.1 software

4.1.1 core Tables - None.

4.1.2 Drum Tables - None.

4.1.3 Registers - None.

4.2 HARDWARE - None.

L50-5. outputs

5.1 software

5.1.1 core Tables - None.

5.1.2 Drum Tables - None.

5.1.3 Registers - None.

5.2 HARDWARE - None.

L50-6. ccntfci

6.1 entry points

entry Points: Reasons for Entry

150X: To clear the Set/Reset Indicator.

6.2 EXIT POINTS

Exit Points: Reasons for Exit

150X01: Resets Unit Maniacs.

150X02: Sets Unit Maniacs.

L50-7. subroutines used

entry Poins: Functional Names

150X01: Resets unit maniacs on an entire subsystem.

L50X02: Sets unit maniacs on an entire subsystem.

L50-8. narrative

8.1 discussion

this module was provided since there were not enough entry lines in module L00 to do all the required functions.

8.2 TECHNIQUE - Not applicable.

V00

1. name

v00 - configuration interrupt handler (CNFPBH).

V00-2 purpose

this module handles the Recongifuration Pushbutton Interrupt initiated by the maintenance man at the Maintenance and Control Center.

V00-3. functions

a. If there is no MANIAC on the interrupt, V00 schedules the Pushbutton Handler Program (V63).

b. If the interrupt is to be rerouted, V00 schedules, or goes directly to, the designated reroute program.

c. Under all other conditions, V00 takes no action and returns control to the Interrupt Cause and Analysis Program (ICAP).

V00-4. inputs

4.1 software

4.1.1 core Tables

FJP - Interrupt Level Priority Junk Storage.

4.1.2 Drum Tables - None.

4.1.3 Registers - None.

4.2 HARDWARE - None.

V00-5. outputs

5.1 software - none.

5.2 HARDWARE - None.

V00-6. control

6.1 entry points

Entry Points: Reasons for Entry

V00v01: entered by ICAP upon occurrence of the Reconfiguration Pushbutton Interrupt.

6.2 EXIT POINTS

Exit Points: Reasons for Exit

Icap: after completion of processing, V00 returns to ICAP via a RTN through V00's entry line table. The return address is stored there by ICAP.

V00-7. subroutines used

entry Points: Functional Names

E01x01: accept - used to schedule the Reroute program's work area. The Reroute module is at the address identified in FJPA00 when V00 gains control.

E03x02 sttime - used to take the Reroute program's work area off the Timer Queue.

L20x01 diarqt - used to schedule the Pushbutton Handler (V63).

V00-8. narrative

8.1 discussion

the system provides two defined ways to reroute an interrupt via MANIAC (L50). One is to place a properly initialized work area on the timer queue and have MANIAC place the work area address in the MANIAC Reroute Table. When the interrupt comes true, the handler removes the work area from the timer queue and schedules it. The second method is to supply MANIAC with a Program Locator Table Address and entry line. The handler will BSP thru the PLT address to the reroute Module. In this case the Reroute Module must return control to the Interrupt Handler.

8.2 TECHNIQUE

When V00 is given control by ICAP, if first checks the MANIAC conditon imposed on this interrupt as identified in FJPA97. If it is to be handled normally, V00 schedules V63 (the Pushbutton Handler) via DIACON and returns to ICAP.

If the interrupt is to be rerouted, V00 checks bit 23 of FJPA99, the MANIAC Schedule on Branch (SOB) bit. If this bit is set, V00 assumes the Reroute Program is to be scheduled. It requests the work area identified in FJPA99 to be taken off the timer queue and schedules. If the work area is not on the timer queue, V00 returns to ICAP. If the bit is not set, V00 assumes the FJPA99 contains a PLT address and entry line. V00 executes a BSP thru this PLT address indexed by the entry line. Upon return from the reroute module, V00 returns to ICAP.

V63

1. name

v63 - configuration Push Button Handler (CNFPBH) Module.

V63-2. purpose

the CNFPBH program (module V63) provides a maintenance man the ability to reconfigure the system from the Maintenance and Control center (MCC). The MCC configuration takes precedence over any software configuration and it has equal status with the power configuration. Module V63 does not allow the maintenance man to place the system in a configuration where two units of a pair are off-line and/or powered down. When module V63 takes a unit off-line, it sets the MCC bit for that particular unit.

V63-3. functions

module V63 performs the following functions:

a. Performs a validity check on all push button requests, to take a unit off-line.

b. Decides whether or not the push button off-line is valid. Module V63 then interfaces with the Configuraton Control (CONFIG) Program (module L01) to place a unit Maintenance-out-of Service (MOS) and off-line.

c. Resets a units MCC bit and schedules the unit's verificaton program via the Diagnostic Control (DIACON) Program (module L20).

d. Outputs a message informing the maintenance man that a push button request was denied.

V63-4. inputs

4.1 software

4.1.1 core Tables

FJB - Base Level Junk.

FWA - Executive Interface Work Area.

HCC - Configuration Control Table.

HCL - Configuraton Pushbutton Last Look Table.

HCT - Configuraton Pushbutton This Look Table.

HDO - Diagonal Ones Table.

HDP - Configuration Push Button Handler Data.

HST - System Status Table.

LWB - Error Parameters

4.1.2 Drum Tables - None.

4.1.3 Registers - None.

4.2 HARDWARE

Sense Line 03100.

Sense Line 55004.

Sense Line 74001.

Sense Line 74002.

V63-5. outputs

5.1 software

5.1.1 core Tables

Fwa - executive Interface Work Area.

HCL - Configuration Pushbutton Last Look Table.

HCT - Configuration Pushbutton This Look Table.

HDP - Configuration Pushbutton Handler Data.

LWB - Error Parameters.

5.1.2 Drum Tables - None.

5.1.3 Registers - None.

5.2 HARDWARE - None.

V63-6. control

6.1 entry points reasons for Entry

V63x01: v63x01 is scheduled, via DIACON, when module L20 receives a request to schedule module V63.

V63x02: v63x02 is entered when CNFPBH detects a unit that is to be placed on-line.

V73x03: v63x03 is entered when CNFPBH detects a unit that is to be placed off-line.

V63x04: v63x04 is scheduled, via Executive (EXEC) by the Marker Configuration program (module L02), to place a marker in service. Module V63 transfers control to module L02 for this operation.

V63x05: v63x05 is scheduled, via the EXEC by module L02 to place a marker off-line. Module V63 transfers control to module L02 for this operation.

6.2 EXIT POINTS

Exit Points: Reasons for Exit

V64x03: cnfpbh program: V64X03 is used to place a marker back in service.

V64x04: cnfpbh program: V64X04 is used to place a marker MOS and off-line.

V63-7. subroutines used

entry Points: Functional Names

E01x03: data Processing Unit (DPU) - Scheduler (RELEAS).

L01x04: config program.

L02x01: marker Configuration.

L03x02: configuration Subroutines - Restore Registers.

L03x03: configuration Subroutines - Teletypewriter (TTY) Output.

L20x03: diacon - request Acceptor (DIARQT).

V01x05: mcc i/o handler (MCCIOH).

V63-8: narrative

8.1 discussion

each configuration unit in the system has as a minimum of four status bits under the control of either CONFIG, CNFPBH, or PMSCAN. These bits are as follows: MOS, Out of Service (OS), MCC, and Power Down (POW). If no bits are set, the unit's stats is in-service. The MOS bit signifies that the unit is available only to maintenance programs. This bit can only be set and reset by CONFIG. The OS bit signifies that this unit is not equipped power down, or not to be used since another unit is power down. The OS and POW bits only can be set by PMSCAN. If the POW bit is set, one or more units must be OS. All units which are OS must also be MOS. The MCC bit signifies that the unit is MOS and was taken off-line by a request initiated from the MCC push buttons. The OS and MOS bits are located in the table HST, the POW bits are located in the PMSCAN last look table, and the MCC bits are located in the CNFPBH last look table.

The MCC push buttons and power have equal status, thus both have a higher priority than the TTY or program requests, when requesting configuration changes. A request from the MCC overrides any TTY or program request, however, it does not override any decisions initiated in PMSCAN, because of power requirements.

The system's configuration philosophy, of always having at least one unit of a pair in service at all times, (except for a temporary MOS configuration in some subsystems) is followed by CNFPBH. Before requesting that a unit be taken off-line CNFPPH requests that its mate be placed in-service. The request will be denied if the mate unit is OS or MOS. Since these states cannot be overridden, CNFPBH regards the request as invalid and prints out a message denying the push button request. If the mate is only MOS or already in service, the request to CONFIG is honored and CNFPBH requests CONFIG to take the unit MOS and off-line. CNFPBH then sets the MCC bit. With the MCC bit set no source of reconfiguration requests can make the mate MOS. This is because no source has the priority to override the MCC bit. Another push button request on the mate or a power request to take the mate unit OS is denied, since they have equal priority on a first come first serve basis. No request can place the unit back inservice until the MCC bit is reset. The MCC bit only can be reset by resetting the push button or when it is impossible to communicate with the MCC. The last condition prevents lock-out on units which have the MCC bit set at the time a fault occurs in the MCC.

When the push button is reset, CNFPBH resets the MCC bit and schedules repair verification on the unit. Since the MCC bit is reset the repair-verify program is free to set the unit in service if the unit passes or MOS if it does not. Scheduling of repair-verification instead of CNFPBH directly placing the unit in service assures that the unit is functioning correctly before it is placed in service.

If a unit is MOS and an off-line pushbutton request is initiated on its mate, CNFPBH directly forces the MOS unit in service via CONFIG enabling its mate to be taken MOS and off-line. Caution should be exercised in this override.

Upon finding a push button request which CNFPBH cannot honor, CNFPBH utilizes PRFPNT to output a message. To accomplish this, CNFPBH passes a code corresponding to a particular output message to the Configuration Subroutines - TTY Output program (module L03). Module L03 places the code word in table HTT and schedules PRFPNT via DIACON. When PRFPNT gains control, it formats the message and transfer control to the output program. The output program reschedules PRFPNT after the message is outputted. This cycle continues until all entries in table HTT are outputted. This mechanism is utilized by CNFPBH, CONFIG, and PMSCAN assuring their messages are in the correct order and do not cause a Work Area (WA) overload condition.

8.2 TECHNIQUE

Cnfpbh is scheduled by DIACON as a result of a request by either System Clear and Start, MCC Unit Clear and Start, or the Push Button Configuration Interrupt Handler programs. In all situations, entry point V63X01 is used. CNFPBH first checks a flag in table HDP verifying that it has not already been scheduled and taking a real time break. When CNFPBH takes a real time break it releases control. When CNFPBH is not taking a real time break, since line 03100 is checked. Sense line 03100 indicates the status of the Maintenance Device Buffer (MDB) push button. If the MDB push button is set, the MDB is taken MOS off-line, its MCC bit is set and CNFPBH is released. If the MDB pushbutton is not set and the MDB MCC bit is set, CNFPBH schedules the MDB Clear and Start program on the unit and releases controls. When sense line 03100 indicates that no action is required on the MDB, CNFPBH checks if communications with the Push Button Adapter (PBA) is possible. The procedure includes checking the power status of the Computer Channel Multiplex - A (CCX-A) the Maintenance Routining Logic Frame-A (MRLF-A), and the on-line/off-line status of the MDB (as indicated by sense line 55004). If either CCX-A or the MRLF-A is power down, or if the MDB is not or cannot be placed on-line, CNFPBH prints a message, resets all MCC bits, and releases control.

When communication with the PBA is possible CNFPBH uses the MCC I/O Handler (MCCIOH) program (module V01) to read the status of the push buttons from the PBA. The words are OR'ed with table HCV to zero bits which correspond to nonequipped units or are spare bits. The results are stored in table HCT.

Module V63 compares the Drum Control Unit (DCU) bits of tables HCT and HCL. First a search for the reset push buttons is initiated. If a reset push button is found, the MCC bit (in table HCL) is reset and table HUD is referenced to obtain the repair-verification code necessary to schedule the repair verification program, via DIACON. CNFPBH searches for push buttons which were just set. If one is found, the unit's mate is placed in-service and the unit is taken MOS and off-line, via CONFIG requests. The request code numbers are found in table HCA. If these CONFIG requests are honored the units MCC bit in table HCL is set; otherwise, a TTY message is outputted. AFter all DCU requests are processed, tables HCT and HCL are compared. If they are equal, (no further requests) CNFPBH releases control. If they are not equal all other bits in tables HCT and HCL are compared in the drum portion of CNFPBH, via the scheduling of the CNFPBH program (module V64).

Claims

What is claimed is:

1. In a communication switching system including a switching network having a plurality of terminals, a plurality of line circuits individually connecting communication lines to individual ones of said terminals, a plurality of register junctors individually connected to other of said terminals, marker means to independently find idle paths and establish connections through said network between terminals and to detect originating call requests from calling line circuits and for each call request to select and establish an originating connection for the call to an idle register junctor, a register subsystem including the register junctors with means to receive and store call digits for each call, a data processing unit which includes a central processor and a central processor memory for processing call data, data communication means interconnecting the data processing unit with the marker means, data transfer means interconnecting the data processing unit with the register subsystem, the marker means being effective after said originating connection between a calling line circuit and a register junctor has been selected to seize the data communication means and transmits an originating data message identifying the calling line circuit and register junctor terminals to the central processor, the register subsystem including individual storage means for each register junctor for storing said call digits and other information relating to a call, a method of storing information, comprising:

providing the central processor memory with a portion thereof designated a call history table with individual storage areas for each register junctor;

storing information in the call history table for the register junctor indicating that a call has been initiated in response to the receipt of said originating data message;

finding class of service information relating to the calling line to be used in processing the call;

transmitting control information via the data transfer means from the central processor for storage in the storage means for the register junctor, to indicate that a call as been initiated and to provide processing information to prepare to receive called number digits;

providing the central processor memory with a plurality of areas designated as work areas;

assigning work areas to a call during different processing steps thereof, a first work area being assigned to a call in response to receipt of said originating data message; and

storing information both in the call history table and in the assigned first work area to link them both by identifying the said first work area in the call history table and by identifying the part of the call history table for the register junctor in the said first work area.

2. In a communication switching system a method as claimed in claim 1, further including releasing said first work area after initial call processing for the call in the data processing unit;

said system further including at least one register sub-system sense line coupled from the register subsystem to the data processing unit, said register subsystem including a register memory comprising a plurality of register word stores, wherein said individual storage means for each register junctor comprises a given number of the register word stores for each register junctor, including control word stores and called number digit word stores, and wherein the register memory also includes common word stores, one of which is a service request word store, the register subsystem being responsive to given conditions requiring further processing by the data processing unit to generate service request signals and to apply them to said sense line, the register subsystem further placing address information in said service request word store identifying the register junctor used for the call requiring said further processing;

further including detecting service request signals on said register subsystem sense line, in response thereto using said data transfer means to obtain the address information from said service request word store and scheduling further call processing to assign again a work area, placing the identity of the part of the call history table for the register junctor therein, and placing the identify of the last said work area in the call history table to thereby link them for use during said further call processing.

3. In a communication switching system a method as claimed in claim 2, wherein a section of each said work area assigned for call processing is a register memory image area, the data processing unit responding to the detection of service request signals on said register subsystem sense line and using said data transfer means, reading information from certain of the control word stores and called number digit word stores of the register junctor for the call and placing the last said information in the assigned register memory image area for use by the data processing unit in processing for the call;

wherein the processing steps in the data processing unit include analyzing digits, said analyzing including determining if enough called number digits have been received to complete a connection through the switching network to a terminal, and if not using said data transfer means to place processing information in a control word store of the register junctor, said processing information comprising an instruction to collect a specified total number of called number digits for the next generating of a service request signal applied to said register subsystem sense line, and releasing the last assigned work area after placing the last said information in a control word store.

4. In a communication switching system a method as claimed in claim 3, wherein the register subsystem performs given operations in a relatively short time in response to certain instructions included in processing information received from the data processing unit until generation of a service request signal applied to said sense line;

and when said certain instructions are included in processing information placed in a control word store of the register memory, retaining the work area then being used for the call while awaiting the next service request on said sense line for the call.

5. In a communication switching system a method as claimed in claim 3, wherein said data processing unit further includes an auxiliary memory system comprising an auxiliary memory, control storage means, and means to retrieve data from the auxiliary memory under control of data in the control storage means either by direct addressing or by associative search while the central processor is operating independently, there being class of service and called number translation tables in the auxiliary memory, memory control means coupling said central processor memory to the central processor and to the auxiliary memory system with means to transfer address and data information between the central processor and the central processor memory, and also to transfer address and data information between the auxiliary memory system and the central processor memory;

wherein said step of finding class of service information relating to the calling line comprises deriving input information from said originating data message and supplying said input information via the memory control means into said first work area;

further including the steps of supplying a signal to the auxiliary memory system to cause it to transfer information from the first work area to said control storage means, said retrieving data from the auxiliary memory being effective to obtain the class of service information, and transferring the last said information via the memory control means into first call storage means consisting of said first work area and the call history table;

during processing steps when called number digits have been transferred from the register memory into current call storage means consisting of the then assigned work area and call history table for the call, performing a translation from said tables in the auxiliary memory and placing the resulting translation information in said current call storage means.