DFHZCQ handles all requests for the dynamic add and delete of terminal
control resources. It contains the following CSECTs:
DFHBSIB3 DFHBSSZM DFHBSTP3 DFHBSTZ1
DFHBSIZ1 DFHBSSZP DFHBSTS DFHBSTZ2
DFHBSIZ3 DFHBSSZR DFHBSTT DFHBSTZ3
DFHBSMIR DFHBSSZS DFHBSTZ DFHBSXGS
DFHBSMPP DFHBSSZ6 DFHBSTZA DFHBSZZ
DFHBSM61 DFHBST DFHBSTZB DFHBSZZS
DFHBSM62 DFHBSTB DFHBSTZC DFHBSZZV
DFHBSS DFHBSTBL DFHBSTZE DFHZCQCH
DFHBSSA DFHBSTB3 DFHBSTZH DFHZCQDL
DFHBSSF DFHBSTC DFHBSTZL DFHZCQIN
DFHBSSS DFHBSTD DFHBSTZO DFHZCQIQ
DFHBSSZ DFHBSTE DFHBSTZP DFHZCQIS
DFHBSSZB DFHBSTH DFHBSTZR DFHZCQIT
DFHBSSZG DFHBSTI DFHBSTZS DFHZCQRS
DFHBSSZI DFHBSTM DFHBSTZV DFHZCQRT
DFHBSSZL DFHBSTO DFHBSTZZ DFHZCQ00
Note:
The term "node" refers either to a TCTTE or to one
of its subsidiary parts, such as the NIB descriptor.
Subroutines that are found in the builders:
- BSEBUILD
- BUILD: Create the node. For example, obtain the shared storage for
the node.
- BSECON
- CONNECT: Connect the higher node to the lower. For example, make the
TCTTE point to the NIB descriptor.
- BSEDESTR
- DESTROY: Abolish a deleted node. For example, free the storage removed
from TMP’s chains.
- BSEFINDF
- FINDFIRST: Find the first subsidiary node of a higher node. For example,
BSFINDF(TCTTE) returns the NIBD being built.
- BSEFINDN
- FINDNEXT: Find the next subsidiary node of the one just found. For
example, return the address of the next model TCTTE.
- BSEFLAT
- FLATTEN: Build the catalog or log record segment for each part of the
TCTTE. This is passed back to the caller to create a complete "flattened"
TCTTE.
- BSEMAKEY
- MAKEKEY: Create a key that is used to write out the new node to the
global catalog.
- BSENQIRE
- ENQUIRE: The converse of BUILD, it creates a BPS from a TCTTE. The BPS
can then be shipped to another system.
- BSEREADY
- READY: Make a node ready to use. For example, add to TMP’s chains.
- BSERESET
- RESET: Build the TCTTE from the CICS® global catalog. (RESET is a cut-down
version of UNFLATTEN.)
- BSEUNFLA
- UNFLATTEN: Build the TCTTE from the CICS global catalog.
- BSEUNRDY
- UNREADY: Check that a node can be deleted. For example, ensure that
no AIDs are queued on a TCTTE before deleting.
Not all subroutines are found in all builders. Certain subroutines are
required, but do nothing other than return to the caller. The subroutine
names are the same in each builder.
Consider a module entry to be a router that does some housekeeping and
then branches to the appropriate subroutine:
- Enter the builder at offset X'18'.
- The first X'17' bytes are taken up by the standard DFHVM macro
expansion.
- Save DFHTBS’s registers (DFHTBS calls each builder).
- Save the first two entries in the parameter list:
- The address of LIFO storage
- The index number of the subroutine to call.
- Increase the value of register 1 by 8 to get past the first two entries.
- Branch to the appropriate subroutine of the builder using the index number
passed.
- Return from the builder subroutine.
- Restore registers.
- Return to DFHTBS.
- Register 1 points to the parameter list.
- Store Register 14 (return address) at Register 2 + X'nn' (varies
by entry point).
- Store the parameter list into Register 2 + X'nn' (varies by entry
point).
- The length of the parameter list varies.
- Exit from the subroutine only through an "official" exit point.
- The exit point is usually the end of the subroutine.
- The end of the subroutine is indicated with "*end; /*BUILD */".
- In some cases, the end of the subroutine branches back to the exit point
somewhere within the subroutine.
- Return (BR R14) from within the subroutine.
- Reload Register 14 from Register 2 + X'nn' and return to caller.
In DFHZCQRT, a series of patterns define the flow through the builder modules.
(See Figure 30.) For each kind of terminal, there is a different
pattern.
If installing, DFHZCQIS selects the pattern and calls DFHTBS (table builder
service). If deleting, DFHZCQDL does the selection.
DFHTBS interprets the pattern and calls each builder that the pattern calls
out. DFHTBS knows nothing about the terminal or whether you are installing
or deleting. It simply does what the pattern tells it to do.
DFHTBS passes a BPS as it calls each builder. The BPS allows one builder
to be used for many different kinds of terminals. For example, DFHBSTC obtains
the user area for all terminal types. The BPS contains the length to be obtained.
- DFHZCQRT contains a series of comments followed by the patterns. The
comment appears as:
/* * * * * * * * * * * * */
/* 3277 REMOTE */
/* * * * * * * * * * * * */
- Shortly afterwards is a Declare (DCL) followed by a level-1 name:
DCL 1 P145002 STATIC
This is the name of the pattern that drives the
build process for a 3277 remote terminal.
- Go to the cross-reference at the back of the dump and find where P145002
is defined in assembler language. Go to that address.
- This states that the first builder to be called is DFHBSTZ. This is the
main one.
- Drop down to the 2-byte fields that follow: these state the names of the
builders that are to be called, in sequence (18 should be listed).
- The first one is IAATZ1 which does not sound familiar:
- Go to the cross-reference at the back of the dump, look up IAATZ1, and
go to where it is defined.
- You see that this is DFHBSTZ1.
- You can also see a close resemblance between IAATZ1 and DFHBSTZ1, but
do not count on this to be always true.
- Now you know that the second builder to be called is DFHBSTZ1.
- The next two builders to be called are IAATCV (DFHBSTV) and IAATCB (DFHBSTB).
- The fifth builder to be called according to the pattern needs to be looked
at:
- The pattern says that IACTZ3 should be called.
- When you go to where IACTZ3 is defined, you find that this is DFHBSIZ3.
- You also see that DFHBSIZ3 calls IAATM.
- Look up IAATM and you see that it is DFHBSTM.
- This is a sub to a subpattern, and this is how nesting of builder calls
occurs.
- Thus, DFHBSIZ3 calls DFHBSTM when building a local 3277.
- DFHBSTM accounts for one of the "other" three mentioned in step
2.
- If you continue through this pattern, you can identify the names of the
22 builders that would be called to build a 3270 local TCTTE.
Here is the
complete list, in order, of the builders that are called:
1 DFHBSTZ 12 DFHBSTH
2 DFHBSTZ1 13 DFHBSTI
3 DFHBSTZV 14 DFHBSTS
4 DFHBSTZB 15 DFHBSTT
5 DFHBSIZ3 16 DFHBSTZA
6 DFHBSTM 17 DFHBSTP3
7 DFHBSTB 18 DFHBSZZ
8 DFHBSIB3 19 DFHBSTB3
9 DFHBSTO 20 DFHBSTZE
10 DFHBSTC 21 DFHBSZZV
11 DFHBSTE 22 DFHBSTZ3
A look at "Pattern Trace"
supports this flow. Note that the first ZCP TBSB(P) BUILD and its matching
return (the return has no builder suffix) should be ignored.
As each builder is called by DFHTBS, a parameter list is passed. Unique
data is passed to enable one builder module to be called for a variety of
terminal types. The length of the builder parameter list is fixed for each
kind of subroutine; for example, the parameter list passed to BSEBUILD is
always X'23' bytes long, regardless of the builder involved.
Subroutine Length of parameter list
(hexadecimal)
BSEBUILD 23
BSECON 13
BSEDESTR 7
BSEMAKEY B
BSEREADY 3
BSEUNRDY 17
BSEFINDF F
BSEFINDN B
BSEFLAT B
BSEUNFLA 27
BSENQIRE 7
Builders are called during:
- Cold start
- Warm start
- Emergency restart
- After emergency restart
- Autoinstall logon and logoff
- APPC autoinstall
- CEDA INSTALL
- EXEC CICS CREATE
- EXEC CICS DISCARD
- Transaction routing
- Non-immediate shutdown.
Cold start
- Read information from the CSD and call builders to build RDO-defined terminals.
- Load in DFHTCT for non-VTAM® terminals. Builders are not called.
Warm start
Note:
A warm start is identical to an emergency restart from the
builders perspective. The only difference is that Recovery Manager has no
forward-recovery records to pass to DFHAPRDR.
- Read information from the global catalog and call builders to restore
RDO-defined terminals.
- Load in DFHTCT for non-VTAM terminals. Builders are not called.
Emergency restart
- Read information from the global catalog and call builders to restore
RDO-defined terminals.
Note:
Auto-installed terminals will not have
a catalog entry if AIRDELAY=0
- Recovery Manager calls DFHAPRDR which calls the builders to restore in-flight
terminals installs from the system log.
- Load in DFHTCT for non-VTAM resources. Builders are not called.
After emergency restart
Delete autoinstalled terminals after the time period has expired as specified
in the AIRDELAY parameter (if the user has not logged back on before then).
APPC autoinstall
- Inquire on the model supplied by the autoinstall user program
- Install an APPC connection created from the above inquire.
Autoinstall logon and logoff
- Logon: Install terminal entry using model entry in the AMT.
- Logoff: Delete terminal entry.
CEDA INSTALL
Install VTAM terminal resources. (There is no builder process for CEDA
DEFINE or ALTER.)
EXEC CICS CREATE
Install VTAM terminal resources.
EXEC CICS DISCARD
Delete VTAM terminal resources.
Transaction routing
If a TCTTE is defined as shippable, its definition is shipped to the remote
system and installed there. The definition is obtained by an INQUIRE call
to the builders in the Terminal Owning Region and built with an INSTALL call
in the Application Owning Region.
Shutdown
Delete autoinstalled terminals from the catalog (if they had entries, and
are not LU6.2 parallel connections). On a warm start, therefore, autoinstalled
terminals are not recovered.
[[ Contents Previous Page | Next Page Index ]]