,-Example:
This example shows how a TRANSFER request may be coded. Note that direction of transfer and target memory had previously been loaded into registers R!SC2 and R!TM, respectively.
ILocation !Result
I I
I I TRANSFER
2.10 CLOCK FUNCTIONS
!Operand
I
IR!SC2,R!TM,R!CPU,R!CPL,R!SCO,R!SC1,R!LNl
The lOS real-time clock provides a system interrupt once every
millisecond. This fixed time interrupt allows the operating system to time out events (such as pending interrupts) as well as maintain the time of day.
2.10.1 REAL-TIME CLOCK INTERRUPT HANDLER
The real-time clock interrupt handler is given control when a real-time clock interrupt occurs. Its functions are to do the fOllowing:
• Clear the interrupt
• Increment the interval counter (%MSEC) by 1. When the interval counter (%MSEC) reaches 100, indicating a one-tenth second interval, the clock demon (CLOCK) is activated and the counter (%MSEC) is reset to
o.
2.10.2 CLOCK DEMON
The clock demon (CLOCK) is activated once every tenth of a second by the real-time clock interrupt handler. Its functions are as follows:
• Services the event timer. Decrement 1 from TMR@TM of each entry linked to the timer queue (RTCQUE). If the decrement results in a count of 0, a time-out is indicated and the following occurs:
The entry is unlinked from the timer queue. The TMR@RT field in the entry is checked for nonzero; if nonzero, a return jump to that address occurs, and the entry address in register R!EH is passed.
If TMR@RT is 0, the entry is assumed to be AD@P1 of an Activity Descriptor, and the following occurs:
The function code that caused the entry to be placed on the timer queue is checked for a POLL (AD@FU=F$POLL). If the function was a POLL, the DAL that was being polled is removed from the MIOP-mainframe poll queue (CPI@PO).
If the function was not a poll, AD@RC is checked for an event queue address. If i t is nonzero, the activity is removed from the event queue.
Finally, the time-out code (EC$TlME) is placed in the
activity return code (AD@RC) and the activity is reactivated.
• Increments the 1-second interval counter ('TENTHS). If the
counter has not reached 10, indicating a 1-second interval, CLOCK terminates.
• Resets the 1-second counter to O.
• Updates the idle time, Buffer Memory channel transfers, and 100-Mbyte channel transfers for the last second.
• Checks for MIOP-mainframe output channel time-out (CPO@TO#O). If the condition is found, activate the NOBEAT activity to display a message on the Kernel console.
• If 1 minute has expired (SECOND=O) in MIOP, sends a heart beat signal (M$SYNCH) to each configured lOP. Check to see if all lOPs signaled on the previous minute boundary have responded. If any were found to have not responded, activate the NOBEAT activity to display a message on the Kernel console.
• Updates the day clock in MIOP.
• If not running in MIOP, deselects inactive disks.
2.10.3 SYSTEM EVENT TIMER
The system event timer provides the means to regain control when an expected event does not occur within the expected time. It also allows an activity to give up control for a specified amount of time (see the PAUSE function earlier in this section).
The system event timer consists of the following elements:
Element QTIME
DQTIME
CLOCK DEMON
TIMER ENTRY
2.11 lOP DEADSTART
Description
A Kernel subroutine called to link entries to the timer queue (RTCQUE). The following parameters are passed:
• R!EH - Entry address
• R!EG - Time Quantum in tenths of a second
A Kernel subroutine called to remove an entry from the timer queue. The following parameter is passed:
• R!EH - Entry address
Activated every tenth of a second by the real-time clock interrupt handler. It is responsible for decrementing the time-out count for each entry
(TMR@TM) and processing any time-outs that occur (TMR@TM=O).
Any system routine wishing to use the event timer is responsible for the allocation and maintenance of its timer entry, including setting a time-out routine address in TMR@RT, calling QTIME to link the entry, and calling DQTIME to unlink the entry, if the event being timed occurs before the timer expires.
Activities using the service requests for timing events (TPUSH, PAUSE, and so on) do not need to know about the timer mechanisms. The timer entry for each activity is contained in its Activity Descriptor
(AD@Pl) and all maintenance is handled by the Kernel.
The original deadstart of the lOS occurs from either the Peripheral
Expander tape or Peripheral Expander disk. The Deadstart package is read directly into MIOP Local Memory, beginning at address 0 and continuing until complete.
Once this operation is complete, the MIOP can read and write from the channels attached to it. The MIOP initializes Buffer Memory and any common tables residing there.
Once Buffer Memory is established and the MIOP is running, the MIOP deadstarts the other lOPs in the configuration. This is accomplished by sending a special function across the accumulator channel that reads Buffer Memory into Local Memory. Once read, the special function starts the lOP at address
O.
Processors started in this way have access to tables and data in Buffer Memory that they can use to initialize their Local Memory.2.12 STATISTICS
The Kernel keeps statistics on important events within the operating environment. The statistics consist mainly of counts of the occurrence of various phenomena and may be useful in tuning the system to maximize throughput and efficiency. The following occurrences and events are monitored:
• Buffer Memory references, including both input and output
•
Disk channel references and the number of times error recovery is called, by channel•
Number of communications among lOPs•
Number of mainframe channel interrupts•
Number of 100-Mbyte channel transfers to or from Central Memory•
Number of 100-Mbyte channel transfers to or from SSD Memory2.13 COMMUNICATION AMONG lOPs
Communication among lOPs occurs across accumulator channels. One parcel (16 bits) of information can be passed through the accumulator through the interrupt mechanism.
The message can be either in the accumulator itself or in a portion of Buffer Memory specified in the accumulator. In the latter case, an address within the Buffer Memory communications area of the sending lOP and a function code telling what sort of action is being requested are specified in the accumulator. Some messages can require a packet of information in the Buffer Memory data area specified in the
accumulator. The data area indicated is an offset from the beginning of the communications area assigned to the sending lOP.
For a listing of the function codes and their meanings, see table 2-4.
Table 2-4. 1/0 Processor Intercommunication Function Codes
Function Code
o
Definition
The command code, contained in bits 4 through 15, is one of the fOllowing:
M$GO M$SYNCH
Initiate SYSDUMP processing Synchronize lOP software clock
No Buffer Memory data is associated with these codes.
1-3 Unused
4 The message is contained in the Buffer Memory message area of the MIOP at an address specified in the low-order 12 bits of the accumulator. Each message area consists of eight 64-bit words. To find the Buffer Memory
address, shift the accumulator left 3 bit positions and add the base address of the Buffer Memory message area for the MIOP. The message is intended for the BCOM overlay.
5
6
7
10
11
12
13
The message is in the area controlled by the BIOP for messages to the other processors. Otherwise, the protocol is the same as for function code 4. The message is routed to BCOM.
The message is in IOP-2 message area and is routed to BCOM.
The message is in IOP-3 message area and is routed to BCOM.
The message is in the MlOP message area and is routed to ACOM.
The message is in the BlOP message area and is routed to ACOM.
The message is in IOP-2 message area and is routed to ACOM.
The message is in lOP-3 message area and is routed to ACOM.
I
Table 2-4. IIO Processor Intercommunication Function Codes (continued)
Function Code
14
15
Definition
The message is in the lOP message area indicated in bits 4 and 5 of the accumulator. The low-order 10 bits
specify the Buffer Memory address. The message is intended for the ICOM overlay.
The message is in the lOP message area indicated in bits 4 and 5 of the accumulator. The low-order 10 bits
specify the Buffer Memory address. The message is intended for the HCOM overlay.
The sender of the message controls allocation and deal location of message areas within its own Buffer Memory space. The lOP receiving a message informs the sending lOP when the function is complete and the message area can be deallocated.
An accumulator message of the form
177nnn; nnn
is an error code, indicates a fatal error in the sending lOP and requests that thereceiving lOP terminate normal operations. Otherwise, the accumulator contains the octal function code in its first 4 bits and the address or command in its final 12 bits.