Shared Systems Processor (SSP) DLP

The SSP DLP provides a centralized lock manager for up to four loosely-coupled shared disk systems.

The SSP DLP was physically a Large Systems NSP (Network Support Processor) DLP with different firmware, providing a much different interface and function to the host system.

SSP I/O Descriptors

Operation SYS OP MLI OP S L1 L2 L3 Addresses Used?
READ 40 8
Status * 1 0 0 A and B ?
Memory Dump * 2 v 0 Required ?
Report Long * 3 0 0 Yes
Report Short * 4 0 0 Yes
Report Quick * 5 0 0 Yes
Buffer * F U 0
WRITE 42 4
Load Firmware * 1 v 0 A and B Addresses Yes
Set Time * 2 0 0 Required ?
Check * 3 0 0 Yes
Lock * 4 0 0 Yes
Unlock Single * 5 0 m Yes
Clear Single * 6 0 m Yes
Buffer * F 0 0
TEST 44 2
Unlock All * 1 0 0 Yes
Clear All * 2 0 0 Yes
ID * C 0 0 ?
ECHO 48 1
Echo * 0 0 0

v defines operation type, bit 1 = 1 indicates a first operation. Bit 2 = 1 indicates a continuation operation. If a first operation is in progress and another first operation is received, the current operation is aborted. The new operation is then indicated. If a continuation operation is received while no first operation is in progress, the continuation is rejected and the SSP returns an incorrect state R/D.

m defines host mask field as follows:

  • Bit 8 Host #3
  • Bit 4 Host #2
  • Bit 2 Host #1
  • Bit 1 Host #0

SSP DLP Result Descriptor Word 1

A B C D
8 ZERO EARLY
TERM-
INATION
INCORRECT
STATE
INVALID
HOST
NUMBER
4 DESCRIPTOR
ERROR
ZERO ZERO ZERO
2 VERTICAL
PARITY ERROR
(MLI)
ZERO DATA
ERROR
ZERO
1 LONGITUDINAL
PARITY
ERROR
(MLI)
INVALID
INFORMATION
ZERO EXCEPTION
A B C D
8 LOAD
MARK
MISMATCH
ZERO NO
ENTRY
ZERO
4 LOAD CODE
FILE
TOO LARGE
ZERO SSP FULL ZERO
2 INVALID
CHECKSUM
ZERO LOCKED
BEFORE
OPERATION
ZERO
1 SEQUENCE COMPLETE DIFFERENT
HOST
ZERO ZERO

SSP DLP TEST/ID Result Descriptor Word 2

A B C D
8 0 1 X X
4 1 0 X X
2 0 0 X X
1 0 0 X X

X - field installed jumpers (not used for medium systems)

Each SSP DLP can be jumpered with a specific code. This code is not used by the V Series MCP and is typically left unjumpered, returning a value of 00. (This feature was implemeted for the Large Systems MCP, however Large Systems never used the SSP DLP.)

Operation

The SSP unit is shared between 2 to 4 host computer systems. These systems share one or more disk or diskpack drives through an exchange or multi-host controller. Allowing multiple hosts to write to a disk requires some coordination to prevent data corruption from duplicate updates and out of order writes. The SSP provides this coordination.

When the MCP is informed that a given disk or pack is “shared”, it will use the SSP to provide locking for critical operations. All MCP disk directory activities inherently contain a locking protocol designed to insure that the disk structures are updated in a safe manner, and that data corruption or loss cannot occur. A user program can also use locking when accessing data in a disk file that is potentially shared with other systems, or even other programs on the same system.

In addition to the normal READ and WRITE commands to a disk file, a shared file has several additional commands:

  • LOCK
  • READ
  • READ WITH LOCK
  • WRITE
  • WRITE WITHOUT UNLOCK
  • UNLOCK

Typically a user program that plans on updating a record in the disk file would do a READ WITH LOCK on the record. The record address will be translated to a disk sector addresss, and a LOCK command will be sent to the SSP for that disk address.

The SSP will check to see if the address is already in its table. If not, it will be entered and marked as locked by the requesting host, and the SSP will return a good R/D. The MCP will now fire thr READ request to the diskpack and pass the data to the user program.

If the SSP finds that the address already exists, it will check to see if it is also marked as locked. If it is, the LOCK I/O request will fail, reporting LOCKED BY OTHER HOST in the result descriptor. The MCP will note this, and add the address to a list of contended addresses. It will block further program execution, as the READ can not be performed until the LOCK succeeds.

Usually there is a fairly continuous stream of I/O activity to the SSP. Result descriptors for other unrelated operations will note if there are internal status changes that the MCP should know about. When the MCP sees such an R/D, it will request a REPORT from the SSP. The SSP will return a buffer containing addresses which were previously contended, but the contention has been released, and the lock is now owned by this host. When such an address matches a disk address that was marked as waiting for lock, the address will be marked locked, and the READ will proceed.

In some circumstances there will be very little disk activity. If there are any contended addresses in such a case, the MCP will poll the SSP fairly frequently to note when an address becomes available. When such a status is noted a report will be requested, and the flow will continue as described above.

Once the user has a record locked and read, the user proggram can update it and write it back to the disk file. By default, a WRITE implicitly unlocks the record if it is locked. This is reasonable since most record updates consist of the sequence lock-read-write-unlock. In some cases the user may need to update the record but not release the lock. The WRITE WITHOUT UNLOCK can be used in this case to update the record but leave the lock record inthe SSP.

There are also times that a user (or the MCP) may need to lock a particular record on disk, but doesn't need to read it first. In this case the LOCK command can be used. This will make a lock record in the SSP as described above, but will not attempt to read the record from disk if the lock succeeds.

The normal operation sequence from any host to the SSP is either LOCK-(read-write)-UNLOCK if the address is not contended, or LOCK-(POLL)-REPORT-(read-write)-UNLOCK if the address is contended. The (read-write) in the above sequences is not directoed to the SSP, but to the disk record that is being locked and unlocked.

It is possible that a program may obtain one or more locked records and then die or otherwise terminate, leaving the records locked. As this would almost certinaly result in an eventual deadlock, some mthod must be used to remove the locked records. The CLEAR operation, in one of its forms, can be used to do this.

dlps/ssp.txt · Last modified: 2009/05/06 18:12 by lwilton
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki