| |
NAME : HCPPPABK
DESCRIPTION: Point to Point Accounting Block.
DSECT : PPABK
FUNCTION : Contains accounting information for a point to
point virtual connection (virtual channel to channel
adapter, or an IUCV or APPC/VM connection.)
ocated by
VCTCA specific
- CACXPPA and CACYPPA: point to a shared PPABK
when 2 virtual ctc adapters are coupled.
IUCV & APPC/VM specific
- PDEPPA: When an IUCV or APPC/VM connection exists.
- IUCPPAS: A chain of PPABKs. See General Notes.
PPAFP1: Forward pointer for PPAUSR1 chain.
PPAFP2: Forward pointer for PPAUSR2 chain.
CREATED BY : For Virtual CTC adapters PPABKs are created by HCPCTVCP
when two virtual CTC devices are coupled.
For IUCV or APPC/VM connections PPABKs are created by
HCPIUBAC when two users establish a connection for the
first time.
DELETED BY : For Virtual CTC adapters PPABKs are deleted by subroutine
uncouple in HCPCTV when two virtual devices are uncoupled.
For IUCV and APPC/VM connections, PPABKs are deleted by
HCPACNPP when a retrieve buffer is done.
RELOCATION CONSIDERATIONS : None
REFERENCES : none.
SERIALIZED : For Virtual CTC adapter processing: fields in the
HCPPPABK are serialized by holding the shared adapter
for a pair of coupled adapters.
For IUCV and APPC/VM processing: fields in the HCPPPABK
are serialized by holding one or both user's IUCV lock.
Field Is serialized by
------ ***************-
PPAUSR1 Modified only when holding both IUCV locks.
PPAUSR2 Modified only when holding both IUCV locks.
PPAFP1 PPAUSR1's IUCV lock. (1)
PPAFP2 PPAUSR2's IUCV lock. (1)
PPAPWORK Modified only when holding both IUCV locks.
PPASENT PPAUSR2's IUCV lock. (2)
PPAREC PPAUSR2's IUCV lock. (2)
PPATSENT PPAUSR2's IUCV lock. (2)
PPATREC PPAUSR2's IUCV lock. (2)
PPANSENT PPAUSR2's IUCV lock. (2)
PPANREC PPAUSR2's IUCV lock. (2)
PPACTOD PPAUSR2's IUCV lock. (2)
The field IUCPPAS itself is serialized by holding the
user's IUCV lock.
1) This is done so that a user may run his chain without
having to get the second IUCV lock. If forced to get a
higher lock, he would have to release his, and this
would allow for the corruption of the chain while
waiting to get boths locks in the right order. These
fields are only modified when both locks are held, but
each user may reference his own forward pointer.
2) This is done so that a user may run his chain without
giving up his lock, and have access to all the data on
his chain. To do this get your own lock and go down the
chain. If you are "high" in the block, then you must
get the lower lock to access the data: but you can do
this without releasing your lock. If you are "low" in
the block, then you have access to the data without the
need for the other lock. In either case your chain will
remain stable as long as you hold your lock. (See
HCPACO implement this, and the General note on IUCV
Processing for more information.)
COMPATIBILITY AND MIGRATION CONCERNS : None.
GENERAL NOTES : Virtual Channel to Channel processing: No chains of
PPABKS exist in VCTCA processing.
IUCV Processing:
When an IUCV or APPC/VM connection is established
between two users (USERA and USERB) for the first time,
a PPABK is created and chained on each user's IUCVB
(IUCPPAS). A PPABK is created with PPAUSR1 equal to
the higher VMDBK address, and PPAUSR2 equal to the
lower VMDBK address. The PPABK is then chained
closest to the IUCPPAS for USR1 and after all the
PPABKS on USR2's chain that he is highest in. This
allows one to shortcut out of a search once you find
a PPABK that you are no longer high in. (I.E. All
PPABKs that a user is high in, comes first on that
user's IUCPPAS chain.)
| |