Question & Answer
Question
After upgrading the CICS datasets used by our change management product to CICS TS V5.3, why are some of the applications that assembled successfully before now getting message ASMA307E assembly errors for DFHEAI0?
** ASMA307E No active USING for operand =V(DFHEAI0)
** ASMA435I Record 135 in CICS.PROD.SDFHMAC(DFHEIRET) on volume: CICXXX
Analysis shows that it might have to do with how the DFHEIENT and DFHEIRET macros generate their code when using the CODEREG=0 parameter. The new version of DFHEIRET decides it does not need to code an LTORG instruction because it is assumed that when using CODEREG=0 there are no literals being generated, when, in fact, DFHEIRET does generate a VCON literal and the LTORG is needed.
The old version of the DFHEIRET macro always generated the LTORG instruction.
Answer
The IBM CICS Change Team has researched this problem, here is what they found:
Firstly, DFHEIRET was changed to accommodate relative addressing, and if there is no base register then the macro expansion will no longer generate a LTORG. When you ran with the older version of the macro, a LTORG was generated. This resolved the outstanding VCON for the address of DFHEAIO in the expansion of DFHEIRET. Since your static register was established with an active using, this LTORG would map to an address from that.
Having picked up the new version of DFHEIRET, when the translator inserts DFHEIRET there is no longer a LTORG generated in the macro expansion to mop up the resolution of the VCON. However, what would normally happen is that when the END is reached, the assembler will generate an automatic LTORG to gather up remaining VCONs; this will be part of the first CSECT, and hence since there is still the static storage mapped and addressed by R12, it will be able to resolve the VCON and all will be well.
This is very likely the result of a subtlety in your source code, namely having DFHREGS ahead of the DFHEIENT line. This results in a private code CSECT at the start of the CSECT concatenation.
Normally this does no harm and is in fact benign. However, because it is the first CSECT in the module this means when the END statement is reached, the assembler reverts back to the first CSECT in order to resolve the end-stop literal pool. And since there is no base register for static in this PC CSECT, it cannot resolve the VCON.
As a general rule you should check assembler listings and see whether there is a PC like this and if there is, then get rid of it. The background to this is described in some detail within the HLASM language reference manual, chapter 3, under sections, elements and paths. There is detail about what sort of instructions can establish the first control section under heading "What will establish a private control section". In the book the PC is called the unnamed section.
Andre Clark, IBM CICS Level2 support (and Andy Wright from CICS Level3)
Product Synonym
CICS/TS CICSTS CICS TS CICS Transaction Server
Was this topic helpful?
Document Information
Modified date:
13 February 2017
UID
dwa1355866