These records have the following formats: Q!! £.Qlumn 1- 8
9-16
17-28
29-32 33-40 41-48
49-51
52-53
54-55
56-78 79-80 column -1- 8-
9-16
17-28
29-32 33-40 41-48
49-51
52-78 79-80 Q& column -,=a 9-16
17-28
29-32 33-40 41-48
49-51
52-53
54-55
56-78
79-80
contents USERID-specified on the command
Reserved for IBM use
Date and time of accounting (mmddyyhhmmss)
Terminal address
Invalid password USERID that issued the AUTOLOG command
Reserved for IBM use
Current invalid password count
Accounting record limit (JPSLOGAR) Reserved for IBM use
Accounting card identification code (04) contents usiiro-that issued the command
Account number
Date and time of accounting (mmddyyhhmmss)
Terminal address
Reserved for IBM use USERID of user that owns the minidisk
Minidisk address for which the LINK command was issued
Reserved for IBM use
Accounting card identification code (05) USERID that issued command
Account number
Date and time of accounting (mmddyyhhmmss)
Terminal address
Invalid password USERID of user that owns the minidisk Minidisk address for which the LINK command was issued
Invalid password count
Invalid password limit (JPSLNKAR)
Reserved for IBM use
Accounting card identification code (06) Accounting Records Created by the User
A virtual machine user can initiate the punching of an accounting card
that contains up to 70 bytes of information of his own choosing. To do
this, he issues a DIAGNOSE code X'4C' instruction with the following
operands: • The address of a data area in virtual storage containing the
information, in the actual format, that he wishes to have punched
into columns 9 through 78 of the card. • A hexadecimal func-tien e-od-e of X·I 10' • The length of the data area in bytes Part 2. Control Program (CP) 129

The information on the accounting card is as follows:
Column -,=s Contents Userid-- User formatted data 9-78 79-80 Accounting card identification code (CO) Fer infor.ation On uSing DIAGNOSE code X'4C' Instruction in a Virtual Machine" in this section. Operational Notes see """ ... ., ,.. ...... ",." "JJ.l.AUllV;;JJj If a punch is started for two classes with NOSEP specified, accounting
cards are not uniquely separated from data decks. If started with NOSEP specified, the operator is prompted when a user has a deck to be
punched. The operator can thus remove any accounting cards before
starting the punch. After data is through punching, accounting cards may
be punched.
If the amount of free storage (available page frames) is relatively small and the card punch is not periodically assigned to punch out CP's accounting cards, it is possible for cpts accounting routine to
progressively use up a significant percentage of the available page frames and cause a page thrashing condition to occur in VM/370. This is
because the accounting routine creates and updates accounting records in
real storage, and does not free that storage space until the accounting
records are punched out on the real system card punch. This situation
is further aggravated when the accounting option for a batch virtual
machine is in effect, due to the increased number of accounting records
generated.
To eliminate this problem, it is recommended that one punch pocket be
permanently dedicated to this accounting function, or, if that is not
feasible, to punch out all the accumulated accounting records every 1 to
2 hours.
User Accounting Options You may insert your own accounting procedures in the accounting
routines. See the "CP Conventions" section for information on CP coding
conventions and loadlist requirements. Operator responsibilities in
such cases should be defined by the installation making the additions. When designing such accounting procedures, you should understand that:
1. The accounting routines are designed to te expanded. The entry
point provided in the accounting module for installation use is
called DMKACON. If you want to perform additional accounting
functions, you should modify the following copy files:
ACCTON (account on) --for action at logon time. This is provided
as a null file. It can be expanded to provide additional functions
at logon time. The ACCTON routine can request the system to force
the user off by returning a nonzero value in SAVER2. However, if
the operator is automatically logged on during system
initialization, the nonzero return code has no effect. 130 IBM VM/370 System Programmer's Guide