top - download
⟦d6dd559c7⟧ Wang Wps File
Length: 24639 (0x603f)
Types: Wang Wps File
Notes: CPS/SDS/001
Names: »1359A «
Derivation
└─⟦27ec2f823⟧ Bits:30006056 8" Wang WCS floppy, CR 0088A
└─ ⟦this⟧ »1359A «
WangText
…02…CPS/SDS/001
…02…OKH/811020…02……02…
CAMPS SYSTEM DESIGN SPECIFICATION
…02…ISSUE 1.1…02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
4.6 CAMPS APPLICATION SUPPORT FUNCTIONS .. 230
4.6.1 Introduction ....................... 230
4.6.2 Message Management ................. 231
4.6.2.1 Message Storage ................ 231
4.6.2.2 Message Access Types ........... 232
4.6.2.3 Creation of Message Versions ... 235
4.6.2.4 Message Visibility ............. 237
4.6.2.5 Use of Message Control Block ... 238
4.6.2.6 Message View ................... 239
4.6.3 Queueing ........................... 239
4.6.3.1 Precedence Queues .............. 243
4.6.3.2 Combined Wait .................. 244
4.6.3.3 Queue Element Function Codes ... 245
4.6.3.4 Multiple Send. ................. 245
4.6.3.5 Queue Threshold ................ 246
4.6.4 Table Management ................... 246
4.6.4.1 System Parameters .............. 247
4.6.4.2 Global Number Series ........... 248
4.6.4.3 Tables ......................... 248
4.6.5 Time Management .................... 249
4.6.5.1 Time-Out in Wait Calls ......... 249
4.6.5.2 Time-Out on Queued Messages .... 249
4.6.5.3 Timer Driven Events ............ 250
4.6.5.4 Date and Time .................. 252
4.6 C̲A̲M̲P̲S̲ ̲A̲P̲P̲L̲I̲C̲A̲T̲I̲O̲N̲ ̲S̲U̲P̲P̲O̲R̲T̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
4.6.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
This section gives a general presentation of the application
support environment created by CSF and TMP. It does
not describe details of the various tools, but concentrates
on the intended use of them.
It may be helpful that the reader has a simple model
of an application module in mind. One such model is
that an application module has a single input queue
where it receives transactions from other modules.
The application module program is an endless loop
consisting of the following steps:
1) RECEIVE transaction from input queue.
2) PROCESS transaction.
3) SEND transaction to one or more destination queues.
It is obvious that this is too simple for most applications,
but the real cases can be thought of as variations
of this simple one.
The most important issues are covered in sections 4.6.2
and 4.6.3 describing how messages are stored, referenced
and manipulated on disk and how they are passed from
one application module to another by means of queues.
The remaining sections describe the following subjects:
a) T̲a̲b̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Describes tools for searching, displaying and updating
shared system tables.
b) T̲i̲m̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Describes time-out monitoring on expected events,
initiation of timer driven events and support for
date and time manipulation.
c) A̲u̲d̲i̲t̲i̲n̲g̲ ̲S̲u̲p̲p̲o̲r̲t̲
Describes tools for producing statistical, log,
and report information to be collected by appropriate
application modules.
d) P̲r̲o̲g̲r̲a̲m̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Describes mechanisms for sharing programs and routines,
for controlling paging or overlays and for invoking
background activities.
e) T̲e̲s̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Describes built-in functions for tracing application
module activities and for performance monitoring.
4.6.2 M̲e̲s̲s̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
4.6.2.1 M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
The general principle is that messages under processing
are stored in items of Short Term Storage on disk.
When an application module has to process a message,
it must transfer the appropriate parts to a buffer
within its memory data area.
Normally, the buffer will not be large enough to hold
the entire message, so it will have to be transferred
in smaller segments. The size of these segments depends
upon the particular type of task to be performed and
may differ widely among different application modules.
Transfer of messages between applications takes place
in form of queueing. The object in queue is a reference
to the message on disk. So memory buffers will normally
not be sent via queues.
For performance reasons, there may be exceptions to
this rule, but that fact will presumably in most cases
be hidden as much as possible from the applications.
The data transfers between disk item and user buffer
are performed by using the three I/O procedures:
1) READBYTES
2) APPENDBYTES
3) MODIFYBYTES
4.6.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲T̲y̲p̲e̲s̲
Message processing may be divided into steps, each
of which is one of the following types:
a) M̲e̲s̲s̲a̲g̲e̲ ̲I̲n̲p̲u̲t̲
Receives a message from an external source, such
as a message preparation terminal or an external
channel and stores it in an item as the received
version.
b) M̲e̲s̲s̲a̲g̲e̲ ̲E̲d̲i̲t̲i̲n̲g̲
Produces a new version of a message by reading
an existing version and transforming it into a
next version.
c) M̲e̲s̲s̲a̲g̲e̲ ̲U̲p̲d̲a̲t̲i̲n̲g̲
Modifies an existing message version by overwriting
part of it with a new contents.
d) M̲e̲s̲s̲a̲g̲e̲ ̲O̲u̲t̲p̲u̲t̲
Reads a message and outputs it to an external line.
These four operations and the I/O procedures used are
illustrated on the figures 4.6.2.2 (a), (b), (c), and
(d) overleaf.
Figure 4.6.2.2 (a)…01…M̲E̲S̲S̲A̲G̲E̲ ̲I̲N̲P̲U̲T̲ ̲P̲R̲O̲D̲U̲C̲I̲N̲G̲ ̲1̲s̲t̲.̲ ̲V̲E̲R̲S̲I̲O̲N̲
Figure 4.6.2.2 (b)…01…M̲E̲S̲S̲A̲G̲E̲ ̲E̲D̲I̲T̲I̲N̲G̲ ̲F̲R̲O̲M̲ ̲n̲t̲h̲ ̲T̲O̲ ̲(̲n̲+̲1̲)̲s̲t̲ ̲V̲E̲R̲S̲I̲O̲N̲
Figure 4.6.2.2 (c)…01…M̲E̲S̲S̲A̲G̲E̲ ̲U̲P̲D̲A̲T̲I̲N̲G̲
Figure 4.6.2.2 (d)…01…M̲E̲S̲S̲A̲G̲E̲ ̲O̲U̲T̲P̲U̲T̲
The input and output steps are to some extent given
by definition. In the intermediate processing however,
there will in each case be a choice between the editing
and updating approaches shown on figures 4.6.2.2 (b)
and (c) respectively. Performance considerations will
often point to the updating approach, but recovery
considerations may in many cases require that the editing
approach be used, as it does not change the source
version, which can then be restored in case of a system
failure.
4.6.2.3 C̲r̲e̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲V̲e̲r̲s̲i̲o̲n̲s̲
Creation of disk items for the initial and subsequent
versions are done by the application modules calling
Message Monitor procedures CREATE MESSAGE and CREATE
NEXT VERSION.
Before actually accessing the message items, they have
to be opened by calling the OPEN MESSAGE procedure.
When an application module has terminated its processing
of a message, it must call the CLOSE MESSAGE procedure.
Two typical sequences will be shown, one for message
input and one for message editing. By "messref" is
denoted a reference to the message used as parameter
in Message Monitor- and I/O procedures. The meaning
of "detect message start" depends upon the type of
line. It can for example be detection of the VZCZC
sequence on an external channel or the PRNM command
on a message preparation terminal.
a) M̲e̲s̲s̲a̲g̲e̲ ̲I̲n̲p̲u̲t̲ ̲s̲e̲q̲u̲e̲n̲c̲e̲
Detect message start.
CREATE MESSAGE (var:messref).
OPEN MESSAGE (messref).
REPEAT
Input a data block from line by READBYTES.
Inspect data block for message end detection.
Output the block to message item by APPENDBYTES.
UNTIL message end.
CLOSE MESSAGE (messref).
Dispose of message.
Dispose may for example mean sending it to the
next module in message processing sequence.
b) M̲e̲s̲s̲a̲g̲e̲ ̲E̲d̲i̲t̲i̲n̲g̲ ̲s̲e̲q̲u̲e̲n̲c̲e̲
The application module will edit the message identified
by messref-source into a new version identified
by messref-dest. Finally, the source message is
destroyed.
CREATE NEXT VERSION (messref-source,
var:messref-dest).
OPEN MESSAGE (messref-source).
OPEN MESSAGE (messref-dest).
REPEAT
Input a block from source by READBYTES.
Take editing instructions from somewhere.
Update block and output to destination by APPENDBYTES.
UNTIL end of source or edit instructions.
CLOSE MESSAGE (messref-source).
CLOSE MESSAGE (messref-dest).
DISMANTLE MESSAGE (messref-source).
Dispose of new message version.
The DISMANTLE MESSAGE function may destroy a message
version. This will take place if the calling module
is the only one "using" the message version. This will
often, but not always be the case for the previous
message version when generation of a new version has
been completed.
The "dispose of message" function terminating the two
sequences can mean different actions in the various
cases, but normally it consists of sending the message
to one or more destination queues for further processing
by other CAMPS modules. In particular this may be
done by the SEND MESSAGE function described in section
4.6.3.
4.6.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲V̲i̲s̲i̲b̲i̲l̲i̲t̲y̲
For an application module to access a message, it must
have a reference to the message. In general, there
are two types of message references:
a) Message Identification
b) Queue Element Reference (QER)
Reference by Message Identification is only legal for
the SAR. All other modules must use Queue Element
References.
A message is said to be v̲i̲s̲i̲b̲l̲e̲ to an application module
if it has a reference to the message. So all messages
in the system are in principle visible to SAR.
A message can become visible to an application module
in a number of ways such as:
1) The module has itself created the message and not
yet disposed of it.
2) The module has received the message from a queue,
that it has access to.
3) A special case is that the module has referenced
the message indirectly by a retrieval key to SAR.
After retrieval however, SAR will place the message
in a queue specified by the requesting module.
So this is covered by 2).
A QER is valid until the application module owning
it executes the Message Monitor function DISMANTLE
with QER as parameter or returns it to the queue by
the Queue Monitor function RETURN.
So the application may SEND the message to other queues
without losing the reference to the message.
This feature can be used by message preparation terminals
in the following way:
When the message is released, a DISMANTLE call finally
removes the message from the visibility of the terminal
module.
The SEND MULTIPLE procedure may implicitly call DISMANTLE
as described in 4.6.3.
4.6.2.5 U̲s̲e̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲l̲o̲c̲k̲
The memory resident Message Control Block will contain
the following types of information:
1) Message Type.
a) Incoming Message
b) Outgoing Message
c) Comment
etc.
2) Message State.
a) Queued for Coordination
b) Queued for Release
etc.
3) Recovery Information.
a) Queueing Information.
etc.
4) History Record.
a) Times of insertion into various queues.
b) Accummulated error counts.
etc.
It is assumed that application modules may use MCB
to transfer to each other information regarding the
message. For this purpose each application may have
its own field in MCB where it can place information.
MCB will reside in protected memory and thus only be
accessible via CSF system calls. It may be considered
however, to separate history record and user fields
from the real MCB and place them in shared user memory.
4.6.2.6 M̲e̲s̲s̲a̲g̲e̲ ̲V̲i̲e̲w̲
For reasons of protection, CAMPS applications will
be limited with respect to the parts of message which
they can read or update. The limits are defined by
the so called Message Views, which describe the fields
of a message accessible to each particular application.
As an example, a reception terminal application need
only see ACP127 format lines 5-13 together with distribution
list when an incoming message is delivered, and the
reception application has no need for update rights
to the message.
The message view will be derived from message type
and the queue from which the application has received
the message.
4.6.3 Q̲u̲e̲u̲e̲i̲n̲g̲
The messages in transition through CAMPS are processed
by a sequence of application modules, each of which
performs one step in the total processing of a message.
The transfer of messages between application modules
is done via queues.
The various ways to use queues in the message flow
can roughly be divided into four main groups, as shown
on figure 4.6.3.1.
a) Q̲u̲e̲u̲e̲ ̲I̲n̲ ̲-̲ ̲Q̲u̲e̲u̲e̲ ̲O̲u̲t̲
The application module is driven by a single designated
input queue, where it waits for messages to be
processed. A message is taken from the input queue,
processed and then sent to a number of destination
queues, which in turn serve as input queues for
other application modules.
b) S̲h̲a̲r̲e̲d̲ ̲I̲n̲p̲u̲t̲ ̲Q̲u̲e̲u̲e̲
In some cases, such as the MDCO assistance, a number
of application modules may take their input from
the same queue, which is then said to be shared
between the modules. After processing, the messages
are again sent to destination queue(s) or to external
lines. From the application's point of view, the
only special consideration about a shared queue
is that if a message is RETURN'ed to the queue,
another application may get it next time.
c) M̲e̲s̲s̲a̲g̲e̲ ̲I̲n̲p̲u̲t̲
A message is read (or prepared) from a line, processed
and then sent to one or more destination queues.
d) M̲e̲s̲s̲a̲g̲e̲ ̲O̲u̲t̲p̲u̲t̲
A message is received from a queue, processed and
then sent on a line.
The (a) and (c) cases may require special considerations
in which the SEND MESSAGE procedure may have to be
used for recovery reasons. This procedure specifies
that the message has been removed from input queue
and must be sent to all destination queues.
Figure 4.6.3.1 (a)…01…Q̲U̲E̲U̲E̲ ̲I̲N̲ ̲-̲ ̲Q̲U̲E̲U̲E̲ ̲O̲U̲T̲
Figure 4.6.3.1 (b)…01…S̲H̲A̲R̲E̲D̲ ̲I̲N̲P̲U̲T̲ ̲Q̲U̲E̲U̲E̲
Figure 4.6.3.1 (c)…01…M̲E̲S̲S̲A̲G̲E̲ ̲I̲N̲P̲U̲T̲
Figure 4.6.3.1 (d)…01…M̲E̲S̲S̲A̲G̲E̲ ̲O̲U̲T̲P̲U̲T̲
4.6.3.1 P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲Q̲u̲e̲u̲e̲s̲
The structuring of a queue as a main queue with a number
of sub-queues has among others the purpose of handling
precedence in a reasonable way. The sub-queues will
then in the simplest case correspond to precedence
levels in this way:
SUPER FLASH Sub-queue
FLASH Sub-queue
IMMEDIATE Sub-queue
M̲A̲I̲N̲ ̲Q̲U̲E̲U̲E̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SUPER PRIORITY Sub-queue
PRIORITY Sub-queue
ROUTINE Sub-queue
Figure 4.6.3.1.1…01…P̲R̲E̲C̲E̲D̲E̲N̲C̲E̲ ̲Q̲U̲E̲U̲E̲ ̲S̲T̲R̲U̲C̲T̲U̲R̲E̲
When sending to a queue, the subqueue must be supplied
as one of the parameters.Structured queues may be used
in a more general way by an application to wait for
a mixture of events such as messages, time-out, requests
from other packages etc. An example is the following,
where messages, time-out events and SSC commands are
received via the same queue. Time-out and SCC commands
are shown to have precedence over messages.
TIME-OUT and SSC
COMMANDS
SUPER FLASH Messages
FLASH Messages
M̲A̲I̲N̲ ̲Q̲U̲E̲U̲E̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
IMMEDIATE Messages
SUPER PRIORITY
Messages
PRIORITY Messages
ROUTINE Messages
Figure 4.6.3.1.2…01…G̲E̲N̲E̲R̲A̲L̲I̲Z̲E̲D̲ ̲U̲S̲E̲ ̲O̲F̲ ̲Q̲U̲E̲U̲E̲
When receiving from a queue, it is possible to exclude
one or more of the sub-queues. An excluded sub-queue
is not considered when the queue is scanned for waiting
queue elements. In the example above it will then
be possible to wait for time-out and SSC commands exclusively,
if appropriate.
4.6.3.2 C̲o̲m̲b̲i̲n̲e̲d̲ ̲W̲a̲i̲t̲
It should be noted that an application module may not
at a given moment wait for more than one input queue.
This means that packages which have several parallel
activities must be structured into application modules
in such a way that each module will have its m̲a̲i̲n̲ w̲a̲i̲t̲i̲n̲g̲
point associated with a single input queue.
4.6.3.3 Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲C̲o̲d̲e̲s̲
In addition to messages, a number of other events are
communicated between application modules by means of
queues. Examples are timer events and function requests.
For this reason the queue elements will contain a
function code, so that the receiving application can
distinguish between the types of functions received
at a queue.
4.6.3.4 M̲u̲l̲t̲i̲p̲l̲e̲ ̲S̲e̲n̲d̲
As recovery of messages mainly consists of rolling
them back to a previous queue, there is a need for
a function that can indivisibly remove a message from
one queue, insert it into one or more destination queues
and change the message state accordingly. This is
done by the procedure:
SEND MESSAGE
Input: QER to message
Boolean: Dismantle
Destination queue list
New message state
If the boolean "Dismantle" is true, the message will
be dismantled and thus invisible for the caller. The
SEND MESSAGE call includes a checkpoint recording the
new message state.
4.6.3.5 Q̲u̲e̲u̲e̲ ̲T̲h̲r̲e̲s̲h̲o̲l̲d̲
A queue may have an associated threshold value, telling
that queue length is not expected to grow beyond this
value.
There will be two effects of exceeding the threshold:
1) A threshold warning will be sent.
2) Subsequent sends to the queue will still be accepted,
but may result in an increased overhead because
disk overflow areas are used to keep oversized
queues.
Queue threshold is set by the procedure:
SET QUEUE THRESHOLD
Input: Queue
Threshold values
Threshold warnings are sent to a predefined report
queue.
The total number of queue elements in the system is
limited. If some queues have no threshold or if the
sum of thresholds exceeds this limit, queue elements
may be used up. This will also result in a warning,
and subsequent sends to any queue will result in increased
overhead.
4.6.4 T̲a̲b̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The data controlled by TMP may be divided into 3 different
groups:
1) S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
Examples are:
Security level which shall cause security interrogation.
2) G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲:
Examples are:
a) Printing document number series.
b) Release number series.
3) T̲a̲b̲l̲e̲s̲
Examples are:
a) Routing and distributing tables.
b) Operator profiles.
The three groups are characterized by the means of
accessing and updating the data. These mechanisms
will be described in general in this section, while
the actual organization of the data as well as their
inter-relationships will be described in 4.8.
4.6.4.1 S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
These are simple variables of type boolean or integer.
They will be organized in a single memory resident
record with a simple variable field representing each
system parameter.
System parameters are manipulated by means of two TMP
procedures:
1) GET SYSTEM PARAMETER,
which reads the value of a system parameter.
Input: System parameter name.
Output: System parameter value.
2) SET SYSTEM PARAMETER,
which assigns a value to a system parameter.
Input: System parameter name.
System parameter value.
4.6.4.2 G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
These are simple variables of type integer. They will
be organized into a single memory resident record with
a simple variable field representing each number series.
Global number series are manipulated by means of Get
and Set System Parameter together with the two TMP
procedures:
1) GET NEXT NUMBER,
which delivers the current value of a number series
and increments the number series.
Input: Number series name.
Output: Number series value.
2) SET NUMBER SERIES WRAPAROUND,
which defines the value at which wraparound takes
place.
Input: Number series name.
Wraparound value.
4.6.4.3 T̲a̲b̲l̲e̲s̲
The most important aspects of a table are the way to
specify a table record and the possible interrelationships
with other tables.
TMP will accept three ways of specifying a table record
for read or update:
a) Specify by a search key, which is part of the record.
b) Specify by table index, which is the sequence number
of the record within the table.
c) Specify indirectly via another table using predefined
table interrelationships.
In addition to read and update of single table records
or a set of interrelated records, table management
will have tools for specifying and reorganizing sets
of table records for display and print-out purposes.
Further details are TBD.
4.6.5 T̲i̲m̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
4.6.5.1 T̲i̲m̲e̲-̲O̲u̲t̲ ̲i̲n̲ ̲W̲a̲i̲t̲ ̲C̲a̲l̲l̲s̲
When a process is awaiting an external (relative to
the process itself) event, it may need to be activated
if no event happens within a given time. The events
in question may be completion of I/O or file operations,
that something arrives in a queue or a synchronization
element, or a combination of those events.
A time-out parameter may be specified in the following
system calls:
a) Queue Monitor: .................... RECEIVE
used to wait for operations to arrive into a queue.
b) Process Communication: ............ AWAIT
used to wait for information to arrive into one
or more synchronization elements.
c) I/O System: ....................... WAITOPERATIONS
used to wait for completion of one or more I/O
transfers. It may in addition act as a combination
of RECEIVE and AWAIT.
These calls have a time-out parameter, the function
of which is to specify that the calling process must
be activated if the awaited event(s) does not happen
within the time period specified.
4.6.5.2 T̲i̲m̲e̲-̲o̲u̲t̲ ̲o̲n̲ ̲Q̲u̲e̲u̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
It may be needed to monitor elements in queues, assuming
that elements are processed within a specified time.
The mechanism is the following.
A subqueue may have a timeout period and a disposal
queue associated with it. Each element in the subqueue
will then be monitored, and if an element has not been
received before the allowed period expires, it will
be sent to the disposal queue. The timeout period
is specified at system generation time.
4.6.5.3 T̲i̲m̲e̲r̲ ̲D̲r̲i̲v̲e̲n̲ ̲E̲v̲e̲n̲t̲s̲
If an application module has as one of its responsibilities
to initiate one or more types of timer driven events,
this may be managed in two ways.
a) The module may internally administrate a timer
queue and use the time-out parameter in wait calls
to ensure that it is activated at the right moments
relative to its responsibilities.
b) The module may use the CSF Timer Facility to initiate
events. Several events may be scheduled in parallel
by means of a TIMER REQUEST call for each event.
The way to manage this is illustrated on figure
4.6.5.3.-1.
FIGURE 4.6.5.3.1
When the time-out operation arrives in the answer queue,
the event id may be used to point out the local event
description defining the actions to be initiated.
There may be a number of outstanding Timer Requests
at a given time, referring to different events.
4.6.5.4 D̲a̲t̲e̲ ̲a̲n̲d̲ ̲T̲i̲m̲e̲
CSF Timer Management will have facilities for delivering
Date and Time in various formats required by application
modules. The facility is invoked by the function:
GET TIME
Input: Format Specification
Output: Date and time in specified format.
Accuracy of this function is 0.1 second.
The system clock may be reset by the function:
SET TIME
Input: YY, MM, DD, HH, MM, SS
As part of checkpoint generation, the system clock
value will regularly be transmitted to standby PU,
synchronizing date and time in the active and standby
PU.
