Note: Descriptions are shown in the official language in which they were submitted.
~0!9Z714
BI~CKGROUND OF TIIE INVENTION
_ _ .
2 In multi-program data processing systems, such as the IBM *
3 Systems/360 or 370, it is not unusual to have control pass in
4 an oscillatory ("ping-pong") mode from an interrupting program
to an interrupted program and immediately back to the same
6 interrupting program (due to existence of pending requests for
7 interruption in the same class as the interruption attended to
8 by the interrupting program). This gives rise to "wasted
9 motion" in system operation; especially in respect to operations
associated with the exchange of status (and environmental)
11 information.
12 Systems such as IBM Systems/360 and 370 have in~tructions
13 for examining and conditionally clearing a specific inter-
14 ruption request (e.g. instructions such as TEST I/O and CLEAR
I/O). However each such instruction i8 used only relative to
16 one specific interruption request source associated with one
17 specific class (I/O interruptions). In a system capable of
18 serving many (e.g. hundreds of) relatively asynchronous I/O
19 devices, and thereby sub;ect to having many I/O interruption
requests pending concurrently, it would be extremely inefficient
21 and virtually unfeasible to use such "source-specific" instru-
22 ctions to attend to all (or a moderately large subset of all)
23 pending I/O interruption requests and obviously impossible to
24 use such instructions to attend to interruption requests not
related to I/O functions. However we have found that there
26 is at present a need which appears not to have been appreciated
27 or recognized by others, although nonetheless important for
28 effective operation, for having a capability to efficiently
29 link the handling of non-specific interruptions in a given
*Registered Trade Mark of International Business Machines .
Corporation
PO9-76-017 -2-
B ~.
109~714
1 class (or subset of a class) on a program-controllable basis
2 without having to displace environmental and/or program state
3 information. This need i8 sati6fied by the pre~ent invention.
4 SUt~lARY OF THE INVENTION
In accordance with the foregoing discus~ion the invention
6 provides a facility for smoothly linking the recursive handling
7 of interruptions in one class to the handling of an original
8 interruption in said class; which facility is: a) not inter-
9 ruptible in its operation for the given class; b) operable
only when the system is under control of a supervisory program;
11 and c) operable effectively without any displacement or manipu-
12 lation of program status information and/or other environmental
13 information.
14 More specifically the invention provides a particular
program instruction (TPI) which operates the system to: a)
16 examine a set of multiple non-specific (i.e. not specified in
17 this instruction) source~ of requests for interruption in one
18 specific class of interruptions; b) clear (terminate) one
19 pending request, if at least one is pending; c) set a condition
code indicating such clearance (or non-clearance); and d) store
21 interruption code information accessible to the program
22 currently in control of the system identifying the source of a
23 cleared request (when one is cleared).
24 The invention contemplates execution of said instruction,
at a point (phase) of program execution in a supervisory
26 interruption handling program associated with a said specific
27 class, ~uch that the controls of the system are effectively
28 disabled from accepting unscheduled interruptionQ in said
29 class prior to and immediately after execution of the
P09-76-017 -3_
109~714
1 instruction. Execution of sa'd instruction has the effect of
2 momentarily over-riding such disablement, and of permitting
3 "instru^tion-controlled zcceptance" of d ~on-specific inter-
4 ru~tion in said class; but characterized by the absence of any
s movement of status and/or environmental information associated
6 with ordinary enablement and ordinary acceptance of interruption.
7 The invention further contemplates utilization of said
8 TPI instrl.ction at a stage of program execution at which all
g operations relative to servicing of an accepted interruption
in said specific class have been completed and at which the
11 program i9 "prepared" to return control of said system to a
12 previously interrupted program.
13 The invention contemplates further that as a consequence
14 of instruction-controlled "acceptance" of interruption in
said class, as characterized above~ the program currently in
16 control of said system when the TPI instruction is executed
17 (i.e. the program containing said instruction) is capable of
18 attending directly to the "accepted" interruption request by
19 a 8imple branch subroutine conditioned on TPI execution;
such subroutine being significantly shorter than the recursive
21 program operations which would be required otherwise to attend
22 to acceptance of an unscheduled interruption in said class.
23 Furthermore, as a corollary, such controlled "accep-
24 tance" provides a basis for eliminating instructions from
existing programs for recursively handling interruptions in
26 one class, and thereby for improving the utilization of system
27 resources.
28 As another corollary such controlled acceptance and
29 shortened service operation are expected to provide performance
PO9-76-017 -4-
~09Z714
1 improvements which potentiallv could-reduce the statistical
2 frequency of over-runs in ti~ne-dependent proces~es and thereby
3 pot~ntially could reduce the amount of system processing time
4 "wasted" on di~gno~tic, corrective and re-initiating pro-
cedures.
6 The foregoing and other features, aspects and objectives
7 of the present invention may be more fully understood and
8 appreciated by considering the following detailed description
g of the drawings and claims.
In the drawings:
11 FIG. 1 illustrates the sequence of instruction execution
12 and interruption acceptance operations in prior art environ-
13 mental systems in which the subject invention may be advanta-
14 geously applied and which are conveniently adaptive for such
application;
16 FIG~ 2 illustrates adaptation of such environmental
17 systems in accordance with the subject invention;
18 FIG. 3 illustrates a typical application of the subject
19 invention in an environmental system supervisory program for
interruption handling; and
21 FIG. 4 illustrates for comparative purposes "prior art"
22 programming of such environmental systems for recursive handling
23 of interruptions in a common class.
24 DETAILED DESCRIPTION
FIG. 1 illustrates the sequence of operations associated
26 with execution of program instructions and acceptance of
27 unscheduled interruption in "prior art" multiprogrammed
28 computing systems which represent environmental systems
28 adaptable to utilize the subject invention advantageously;
in particular, IBM System/360 and 370 systems.
P09-76-017 -5-
lO9Z71~
1 Architectural principles of operation and organization
relevant to the present invention are given in "IBM System/370
Principles of Operation", forms A22-6821 (System/360) and
GA22-7000 (Sy~tem/370).
Organizations of microprogram sequence contrQls in various
models of such systems are described in U. S. Patents 3,400,371
(Gran,ted September 3, 1968 to G. M. Amdahl et al) and 3,585,599
(Granted June 15, 1971 to D. C. Hitt et al); and in "Microprogram
Control For System/360" by S. Tucker, IBM Svstems Journal, Vol.
6, No. 4., pp 222-241.
Operating System (Supervisory) programs for performing
interruption handling services relevant to the present descrip-
tion are given in: Forms GC28-5634 (Introduction to OS) and
GC28-6535 (OS Concepts And Facilities) and SY26-3823 (OS/VS2 I/O
Supervisor Logic) and SY28-0716 (OS/VS2 System Logic Library).
FIG. 1 illustrates the sequence of execution of program
instruction~ and unscheduled interruptions in the environmental
systems. Program instructions are executed by actions of
system sequence controls (e.g. microprogram controls) which
serve to perform the actions of (1.1) fetching an instruction
at a storage address usually designated by an instruction
address count, (1.2) decoding the operation code portion of
the instruction and (1.3) executing the operations designated
or called for by the instruction. The execution action
associated with certain instructions defined in the above
architectural references includes the setting of a condition
code as suggested at 1.3.1.
PO9-76-017 -6-
.
109Z714
1 Between '~he terminal Gperation (END OP) of the execution
2 of one instruction (position 1.3.2 in FIG. 1) and the fetching
3 of thl~ next instruction (position 1~1 in FIG. 1) the sequence
4 controls of the system may be enabled to operate independent
of the program currently in control to accept interruption
6 (position 1.4, FIG. 1). The controls determine whether the
7 system is enabled at this particular time (in its existing
8 program state) for accepting interruptions (position 1.4.1).
9 If the system is not enabled the next instruction is fetched
(action 1.1). If the system is enabled the controls test for
11 the existence cf unmasked interruption requests (position
12 1.4.2, FIG. 1). If no unmasked interruption requests are pend-
13 ing the controls again pass directly to the fetching of the next
14 instruction at 1.1. On the other hand, if at least one un-
masked request for interruption is pending the controls perform
16 the operations 1.4.3 associated with acceptance of interruption.
17 If more than one request is pending a priority selection
18 is made of one request (operation 1.4.3.1, FIG. 1) and that
19 request i9 cleared (1.4.3.2). If only one request is pending
that request is cleared. Clearance of the request means that
21 the indication manifesting the request is terminated. An
22 interruption code associated with the selected request is
23 stored (operation 1.4.3.3) and environmental information is
24 exchanged (operation 1.4.3.4) to transfer control from the
program associated with the last-executed instruction to a
26 program for handling the interruption designated by the
27 selected request. These operations are fully described in the
28 foregoing architectural references and in above-referenced
29 U`. S. Patent 3,400,371.
- PO9-76-017 -7-
~092714
1 In this exchange a "new" PSW (program status word)
2 assoclated with the interruption handli~ program i3 retrieved
3 from storage and an "old" PSW associated with the interrupted
4 program (i.e. the program containing the last executed instru-
ction) is stored for future reference. The sequence controls
6 then pass to the action 1.1 for fetching the first instruction
7 of a supervisory program for interruption handling (IH).
8 The subject instruction (TPI) is intended to be used to
9 initiate recursive action within interruption handling programs
of such environmental systems. As shown in FIG. 2 the subject
11 instruction (indicated at 2.1) contains an eight-bit operation
12 code (OP Code) shown at 2.1.1 and an eight-bit field 2.1.2 which
13 is either unused or may be used as described below to distinguish
14 the class of interruption requests which may be "tested" by
the instruction. The system sequence controls 2.2 for decoding
16 instructions are provided with an extra decoding point 2.2.1
17 uniquely associated with the subject instruction. As indicated
18 in FIG. 2 with the exception of line 2.2.1 (and the code
19 recognition logic associated with said line) the controls 2.2
are essentially identical with the controls 1.2 of FIG. 1 and
21 in response to OP Codes other than that at 2.1.1 provide outputs
22 to the "normal" execution controls 1.3 of FIG. 1.
23 With the marking of TPI line 2.2.1 action is taken to
24 determine the class of interruptions associated with the
interruption handling program containing the TPI instruction
26 which has just been decoded. The logic for making this deter-
27 mination is indicated schematically at 203 and 2.4 in FIG. 2.
28 Class information distinguishing the class of interruption
29 currently being handled (e.g. I/O interruption, external
PO9-76-017 -8-
10927~4
1 interruption, program interruption, etc.) may be used to
2 enable corre~ponding AN~ circuits (2.3.1 for I/O interruption,
3 2.3.2 for external interruption, 2.3.3 for program interruption,
4 etc.). one of which is thereby prepared to produce output
S excitation when line 2.2.1 is excited. The class information
6 may be prepared in a register by the program. As an alternative
7 the operation code 2.1.1 of the instruction may be used to
8 distinguish class by having a different operation code for each
9 class. Another alternative would be to use space 2.1.2 of
the instruction to distinguish the class. Furthermore it should
11 be obvious that if the TPI instruction were to be employed
12 only relative to one class (e.g. I/O interruptions) then the
13 foregoing class distinction would not be required and the
14 logic indicated at 2.3 and 2.4 would not be required.
Taking the class of I/O interruptions as representative
16 the action of execution of the associated TPI instruction
17 proceeds as follows (after action 2.3.1). At 2.5 the execution
18 sequence controls determine whether an interruption in the
19 respective class (i.e. I/O interruption class) is pending
currently. Obviously this action is a subset of the action
21 shown at 1.4.2 in FIG. 1 and may be adapted in the environmental
22 system using a subset of the associated logic. If no active
23 request is pending in the associated class the condition code
24 is set to 0 as shown at 2.6 and the execution sequence termi-
nates at 2.7 with the usual terminal operation of instruction
26 execution (END OP); i.e. the point 1.3.2 in FIG. 1 at which
27 the controls pass to the action 1.4 for general acceptance
28 of unscheduled interruption in non-specific classes.
PO9-76-017 -9-
1092'71~
1 On the ~ther hand if at te~t 2.5 an active interruption
2 request is pending in the associated class the controls for
3 exec~lting the TP.I instruction perform operations 2.8 consisting
4 of the setting of the condition code to state 1 (2.8.1), selec-
tion of one active request in the specific class (I/O Inter-
6 ruption) according to a predetermined priority schedule (2.8.2),
7 the clearance of the selected request (2.8.3) and the storage
8 of the interruption code associat~d with the selected request
9 (2.8.4). The actions of request selection, request clearance
and interruption code storage constitute a subset of the actions
11 shown at 1.4.3 in FIG. 1 (excluding the PSW exchange) and may
12 be implemented by similar logic or by using the existing logic
13 associated with actions 1.4.3 through re-entrant microprogramming.
14 Upon completing the actions 2.8 the controls pass via
terminal operation 2.7/1.3.2 (END OP) to the conventional
16 sequence 1.4 for conditional acceptance of interruptions in
17 nonspecific classes.
18 The application of the ~ubject instruction in a super-
19 visory program for ~andling I/O interruption is indicated in
FIG. 3. A comparative presentation of prior art recursive
21 handling is presented in FIG. 4. An arbitrary program X
22 (shown at 3.1 in FIG. 3 and 4.1 in FIG. 4) is presumed to be
23 interrupted by acceptance of an I/O interruption request (at
24 3.2 in FIG. 3; 4.2 in FIG. 4) in accordance with actions 1.4
in FIG. 1. Individual program instruction actions are
26 indicated schematically by horizontal lines; as shown for
27 instance at 3.1.1.
28 In the initial stage of programmed interruption handling
29 after acceptance ~first level interruption handling or FLIH),
P09-76-017 -10-.
10~714
1 indicated at 3.3 in FIG. 3 and 4.3 in FIG. 4, the supervisory
2 program for interruption handling determines 'he cause of
3 interruption and stores any additional environmental information
4 which may b~ required relative to the further handling of said
interruption. In an advanced stage of interruption handling
6 (second level interruption handling or SLIH), shown at 3.4
7 in FIG. 3 and 4.4 in FIG. 4, the program performs actions
8 required to service the interruption. In the case of I/O
9 interruption such actions may i~volve for instance storage
displacement of channel status word (CSW) information relative
11 to a specific I/0 channel.
12 Instruction 3.4.2 in the second level sequence 3.4 is
13 executed initially later than the first instruction 3.4.1 in
14 the same sequence and represents an initial point of recursive
entry uniquely associated with the execution of a TPI instruction
16 as described below. As indicated at 3.5 execution of TPI sets
17 a condition code 0 or 1 as described previously. A branch
18 instruction shown at 3.6 tests this code.
19 If condition code 0 is set the program is sequenced by
the branch instruction to a Load PSW (LPSW) instruction shown
21 at 3.7. This loads the "old" PSW into the system registers
22 and effectively returns control of the system to the interrupted
23 program (X); at the instruction 3.8 which would have been
24 executed next if interruption had not been accepted at 3.2.
If condition code 1 is set by the TPI instruction branch
26 instruction 3.6 branches the program as suggested at 3.6.1
27 into its recursive entry point 3.4.2. From this point the
28 program 3.4 proceeds to perform only operations associated with
29 the handling of the interruption request cleared by the TPI
PO9-76-017 -11-
lOgZ7~4
1 exeeution actior, as set forth previously. Since the TPI
2 instruction and its associated branch instruction are located
3 at a "final`' position in the interruption handling program
4 (just prior to the return of control to the interrupted
program X), and ~ince the TPI instruction invariably selects
6 an interruption in the same class as the interruption just
7 handled, it may be appreciated that there is no need to
8 displace status or environmental information upon or in
g association with TPI execution. Furthermore since the TPI
instruction is provided explicitly at such final position in
11 the interruption handling program the program "knows" implicit-
12 ly that all actions relative to the handling of the previous
13 interruption have been completed and that the interruption
14 request which must be serviced is identified by the currently
stored interruption code (i.e. the code overwritten by TPI
16 execution). Therefore a status exchange is not required and
17 a minimal program routine may be u9ed to complete the handling
18 Of the interruption "taken" by the action of TPI execution.
19 By way of contrast the first level interruption handling
sequence at 4.3 in FIG. 4 includes a preparational subsequence
21 shown at 4.3.1 which is not needed when TPI i8 used. The
22 preparational sequence moves the program status information
23 associated with program X temporarily to a backup storage
24 position in anticipation of a further program status exchange
described below and further conditions the program to be able
26 to "skip" over unnecessary program steps during recursive .
27 interruption handling as described below.
28 In the second level interruption handling sequence 4.4,
29 at a point 4.4.1 which is reached after all actions relative
PO9-76-017 -12-
~09Z7~4
1 to the interruption accepted at 4.2 have been performed, the
2 program contains an instruction for setting an enabling bit
3 in the program status word which is currently in control of
4 the system. This enables the system for recur~ive acceptance
of interruption at 4.6 in the class (I/O) associated with the
6 interruption accepted at 4.2. If no requests are pending in
7 said class the program advances to instruction 4.5.1 in
8 segment 4.5 of the second level program for interruption
9 handling. Instruction 4.5.1 resets the enabling bit in the
PSW to a disabling condition and the program proceeds at 4.7
11 to restore the environment which existed in the system prior
12 to the preparational sequence 4.3.1. When this is accomplished
13 the Load PSW instruction 4.8 is executed to return control to
14 interrupted program X at 4.9.
If an I/O interruption request is accepted at 4.6 the PSW
16 exchange 1.4.3.4 and other actions 1.4 of FIG. 1 are carried
17 out at 4.6. The "new" PSW contains the address of instruction
18 4.3.2 entered via recursive entry path 4.6.1 at an initial
19 stage of first level interruption handling program 4.3. By
virtue of the preparation performed at 4.3.1 the interruption
21 handling program proceeds to perform the requisite operations
22 but skips many of the steps which are performed ordinarily
23 during a first pass through the program from acceptance stage
24 4.2. Eventually the program returns to enablement stage 4.4.1
and, if no further interruptions are accepted at 4.6, to the
26 disablement stage 4.5.1. The environmental restoration opera-
27 tions 4.7.1 place the program in the state prior to preparation
28 operations 4.3.1 after which the interrupted program X is
29 returned to control by Load PSW 4.8. Quite clearly considering
PO9-76-017 -13-
10~ 4
1 FIGS. 3 and 4 comparatively it becomes evident that with the
2 TPI instruction the program status exchange at 4.6 ~s avoided
3 and the preparational actions 4.3.1 and restorative actions
4 4.7.1 may be eliminated thereby shortening the interruption
handling program.
6 While the invention has been particularly shown and
7 described with reference to preferred embodiments thereof, it
8 will be understood by those skilled in the art that the above
9 and other changes in form and details may be made therein
without departing from the spirit and scope of the invention.
PO9-76-017
12/21/76
RL:ehc
