This accounting type distinguishes between DEFINE-SHOW mode (see also "DEFINE-SHOW mode") and the action statements:
DEFINE-SHOW mode
There is no new accounting procedure for DEFINE-SHOW mode, as the resources used are already calculated in the current BS2000 accounting procedure.
Action statements
For action statements (requests), special new accounting records are written to the accounting file. These accounting records contain information about the HSMS user, the CPU time used and the number of inputs/outputs. They also log the date and time of the request for which the accounting records are written.
The accounting records are written for all activities which result in a request. These are:
backup/restore for DMS and UFS runs
archival/restore for DMS and UFS runs
migration/recall for DMS runs
export/import for DMS runs
copying of save files for DMS and UFS runs
updating of backups (UPDATE-EXPORT-SAVE-FILE statement) for DMS runs
all administrative activities which involve a server task
(REPAIR-CATALOG-BY-RESTORE and REPAIR-SAVE-FILE-BY-RESTORE statements)
The accounting values for the following four tasks are measured separately for each request:
the user task
the server task
the ARCHIVE subtasks
the communication task
At the beginning and end of each task, an accounting record is written. The accounting record contains the values measured at the start and end of the task. To obtain the amount of resources currently being consumed for a particular task, you must calculate the difference between the values in the first and second accounting records.
The number of accounting records written for each request depends on the type of the request:
For each individual “normal” HSMS request, at least six accounting records are written:
2 for the user task
2 for the server task
2 for each generated ARCHIVE subtask.
The accounting records are identified by the user ID of the user who issued the request, the TSN and the account number of the user task.
For a collector request, the following accounting records are written:
2 for each request in the user task
2 for the total collector request in the server task, and
2 for each generated ARCHIVE subtask.
All requests are processed independently of each other in the user task. Therefore the accounting records are identified by the user ID of the user who issued the request, the TSN and the account number of the user task.
The resources used by a server task affect several collector requests and therefore often various users also. They are registered under the TSOS user ID. Accounting records for a server task are identified by the TSOS user ID, the TSN of the server task and the account numbers for server tasks specified in the HSMS parameters. If this account number is not defined, “ADMINSTR” is used.
To enable the resources used by each collector request in the server task to be calculated correctly, the accounting records for the server task contain an additional extension. This extension contains the user IDs, the account numbers and the TSNs and account numbers of the collector requests. The resources consumed by the server task are distributed equally among all collector requests and included in the accounting for the affected collector user IDs. Two accounting records for each catalog ID and user ID processed are written to the ARCHIVE subtasks.
The accounting records of node requests which come from a workstation are identified by the SYSHSMS user ID, the TSN and the account number of the communication subtask.
For requests which affect the objects on a shared pubset and which are processed on the master host, one accounting record is created on the slave host and one on the master host.
For implicit recall requests that are sent to a master host, the request date and time are not entered, as no request is generated on the slave host.
With a RESTART-REQUESTS statement that restarts several requests, the following accounting records are written:
only 2 for all requests in the user task, whereby the request date and time are not entered
2 for restarted requests in the server task
2 for a generated ARCHIVE subtask
A RESTART-REQUESTS statement which only affects one request is processed like a single “normal” request (see number 1).
Format of the HSMS accounting record:
(A) Record description (length: 20 bytes)
Field no. | Distance | Length (byte) | Format | Meaning | |
hex | dec | ||||
1 | 00 | 0 | 4 | A | ID of the accounting record: “HSMS” |
2 | 04 | 4 | 8 | B2 | Timestamp of the TOD system clock |
3 | 0C | 12 | 2 | B | Length of the identification section |
4 | 0E | 14 | 2 | B | Length of the basic information |
5 | 10 | 16 | 4 | B | – reserved – |
(B) User identification (length: 28 bytes)
Field no. | Distance | Length (byte) | Format | Meaning | |
hex | dec | ||||
1 | 14 | 20 | 8 | A | User ID |
2 | 1C | 28 | 8 | A | Account number |
3 | 24 | 36 | 4 | A | Task sequence number (TSN) |
4 | 28 | 40 | 8 | A | Group name |
(C) Basic information (length: 40 bytes)
Field no. | Distance | Length (byte) | Format | Meaning | |
hex | dec | ||||
1 | 30 | 48 | 4+4 | B2 | Task CPU time (TU and TPR) 1) |
2 | 38 | 56 | 4 | B | Number of inputs/outputs 2) |
3 | 3C | 60 | 17 | A | Timestamp of the request 3) |
4 | 4D | 77 | 4 | A | ID of the task type 4) |
5 | 51 | 81 | 4 | A | TSN of the executing task |
6 | 55 | 85 | 1 | A | Record index 5) |
7 | 56 | 86 | 2 | B | – reserved – |
Note | |||
1) | The task CPU time includes the CPU time used by the user programs in TU status and the CPU time used in TPR status for processing SVC calls, program errors and commands. The first word contains the full seconds and the second word contains the remaining fraction in nanoseconds. | ||
2) | Here this means inputs and outputs to local, peripheral devices in as far as they are supported by the DMS access methods (SAM, ISAM, UPAM, BTAM, PPAM) or by the SYSFILE management. The terminal and paging inputs and outputs are not counted. | ||
3) | The request timestamp has the format “yy-mm-dd hh-mm-ss” | ||
4) | ID of the task type:
| ||
5) | Record index: | ||
(D) Variable information (length: 8 bytes)
The variable information of the HSMS accounting record contains a record extension.
Field no. | Distance | Length (byte) | Format | Meaning | |
hex | dec | ||||
1 | 58 | 88 | 2 | B | Number of the extension 1 |
2 | 5A | 90 | 2 | B | Distance to the first extension |
3 | 5C | 92 | 2 | B | Distance to the second extension |
4 | 5E | 94 | 2 | B | Distance to the third extension |
1 The number of extensions is always 3. If there is no third extension, the distance to the third extension is shown as 0.
1st extension (maximum length: 12 bytes)
Field no. | Distance | Length (byte) | Format | Meaning | |
hex | dec | ||||
1 | 00 | 00 | 2 | A | Extension ID “ID” |
2 | 02 | 02 | 1 | B | X’00’ |
3 | 03 | 03 | 1 | B | Length of accounting ID |
4 | 04 | 04 | L 1 | C/X | Accounting ID |
1 | The accounting ID may be a maximum of 8 bytes in length. It corresponds to the user ID which is a maximum of 8 bytes in length as entered by the user with the AREC macro (ID operand). If no user ID was specified for request processing, this field is filled with X’FFFFFFFFFFFFFFFF’. |
2nd extension (length: 24 bytes)
Field no. | Distance | Length (byte) | Format | Meaning | |
hex | dec | ||||
1 | 00 | 00 | 2 | A | Extension ID “IO” |
2 | 02 | 02 | 1 | B | Number of elements (X'01') |
3 | 03 | 03 | 1 | B | Length of element (X'14') |
4 | 04 | 04 | 4 | B | Number of I/Os per device for pubsets |
5 | 08 | 8 | 4 | B | Number of I/Os per device for shared private disks |
6 | EC | 12 | 4 | B | Number of I/Os per device for exclusive private disks |
7 | 10 | 16 | 4 | B | Number of I/Os per device for magnetic tape cartridges |
8 | 14 | 20 | 4 | B | Number of I/Os per device for Unit Record Devices |
3rd extension
Field no. | Distance | Length (byte) | Format | Meaning | |
hex | dec | ||||
1 | 00 | 00 | 2 | A | Extension ID “CO” |
2 | 02 | 02 | 1 | B | Number of elements (X'xx') |
3 | 03 | 03 | 1 | B | Length of element (X'20') |
4 | 04 | 04 | 8 | A | User ID |
5 | 0C | 12 | 8 | A | Account number |
6 | 14 | 20 | 4 | A | Task sequence number (TSN) |
7 | 18 | 24 | 4 | A | Length of accounting numbers for collector requests |
8 | 1C | 28 | 8 | A | Accounting numbers for collector requests |
| |||||
In the 3rd extension the number of elements is variable (X’xx’).
The maximum length of an accounting record with the extension “IO”, which is always present, is 132 bytes.
The minimum length of an accounting record with the extension “CO” (only present for collector requests) is 132 bytes + 36 bytes (complete extension: ID, length, information on the 1st collector user) + 32 bytes (only information on the next collector user).
As an accounting record can be a maximum of 496 bytes long, it is only possible to output information on up to 11 collector users. If more collector users are included in this request they are ignored in the accounting record.