ABM2
Explanation
No user data was supplied for this BMS request. That is, the address of a user data area was not found in either TCTTEDA or TCAMSIOA.
When a BMS macro level output request is issued, the user must have placed the address of the data to be passed to BMS in TCTTEDA or TCAMSIOA before issuing the macro. The choice is made on the following criteria:
-
If the data is to be passed in a TIOA by a terminal-oriented task, the address of this TIOA may be placed either at TCTTEDA, or in TCAMSIOA together with the setting of binary zeros into TCTTEDA.
-
If the data is being passed by a terminal-oriented task but not in a TIOA, the address of the TIOA-like area of this data must be placed in TCAMSIOA and binary zeros set into TCTTEDA.
-
If the data is being passed by a non-terminal-oriented task, the address of the TIOA-like area of this data must be placed in TCAMSIOA. TCTTEDA cannot be referenced, because there is no TCTTE associated with this task.
If a task attempts to pass addresses from both TCTTEDA and TCAMSIOA, the address in TCTTEDA is the one selected.
System action
The transaction is abnormally terminated with a CICS transaction dump.
User response
The programmer must place the address of the data into TCTTEDA or TCAMSIOA, whichever is appropriate.
Firstly, check that the user has loaded TCTTEDA or TCAMSIOA with the address of the user data, by checking the application listing and the contents of TCTTEDA and/or TCAMSIOA.
Next, check that the BMS request has been correctly decoded by CICS by referring to the OSPWA request bytes (OSPTR1-8) or decoding the last BMS entry in the trace table. See OSPIND01 to check correct decoding of PAGEBLD or TEXTBLD, and TCAFCI bit 7 to identify whether the task is terminal-oriented or not.
At the abend point, register 1 contains the user data address last loaded, and register 4 the address of OSPTIOA as an address of null data.
If a CICS error is suspected, concentrate initially on subroutine MCPFTIOA, because this is a simple piece of code that shows the data-fetch logic. ABM2 condition is trapped early in the CICS decoding of the DFHBMS request and involves module DFHMCP only.
Case/Register Label Description
R9=@OSPWA MCPMAP OSPTR4 has OSPTRM
(X'04') bit set for
TYPE=MAP.
R9=@OSPWA MCPPGBLD OSPTR5 has OSPTRB
(X'80') bit set and
BMS sets bit
OSPLMPB (X'08') in
OSPIND01 for
TYPE=PAGEBLD.
OSPTR4 has X'40',
X'80', or X'C0' set
for DATA=NO, ONLY,
or YES respectively,
so should be X'80'
or X'C0'.
R9=@OSPWA MCPTXBLD OSPTR7 has OSPTRX
(X'80') bit set and
BMS sets bit
OSPLMTB (X'04') in
OSPIND01 for
TYPE=PAGEBLD.
OSPTR4 has X'40',
X'80', or X'C0' set
for DATA=NO, ONLY,
or YES respectively,
so should be X'80'
or X'C0'.
R9=@OSPWA MCPMAPNG OSPTR3 has OSPTSN
(X'01'), OSPTSA
(X'02'), or OSPTMN
(X'04') bits set, or
OSPTR4 has OSPTMA
(X'10') bit set for
mapping.
OSPTR4 has X'04' or
X'80' or X'C0' set for
DATA=NO, ONLY, or YES
respectively, so should
be X'80' or X'C0'.
All R12=@TCA MCPFTIOA TCAFCI has
TCAFCTRM (X'01') bit
set if the task is
terminal-oriented.
All R11=@TCTTE MCPFTIOA TCTTEDA could point
to a use TIOA but does
not, thus causing the
abend.
All R12=@TCA MCPFTIOA TCAMSIOA could point
to a user data area
(TIOA or otherwise),
but does thus causing
the abend.
All R9=@OSPWA MCPNTOTM OSPTIOA contains the
address of the user
area found, so is
zero.
OSPSIOA points
to OSPIOA (which is
copied from TCAMSIOA)
as being the second-dry
data area sought by
BMS for data .
OSPIA (TCAMSIOA) was
also zero so causing
the abend.
Module
DFHMCPApplicable releases in Version 6
- beta
- 6.3
- 6.2
- 6.1