I dont know what the above means. sorry.. I'm new to assembler.
Code:
000180 95+DFHEIUSR DS 0D
The issue is resolved now. Below is what i did to resolve the issue,
Note: In the below description, i am talking about only one ASM pgm..
- I ran an EDF and found which is the module throwing the violation. In my case it a Assembler-CICS module.
- In my program (ASM pgm) i saw a lot of address variables(pointers) in the comm area, i know that the value for these pointers are assigned in the transaction.
-The transaction goes through 100+ programs. I assumed that the violation happened in the area pointed by one the pointers in the ASM program. As we know the memory is valid till a freemain is issues in the transaction and the current ASM program has pointers which is pointing to
the memory area getmained in the transaction. So when a 'CICS return' is issued in the program. All the pointers go void as the pointers are not passed to the calling program which Link's (CICS LINK) to the ASM pgm am referring to. As all the pointers are not valid after the cics return from the current ASM program, i thought an implicit freemain will be issued and when a free main is issued, am SCZ check is done by CICS before the freemain. As there was a violation, SCZ check failed and a storage violation is thrown.
-The above was my assumption and this was the point where i assumed something and misdirected all the experts in this forum.
- I assumed that a freemain will be issued implicitly but i was wrong. A getmain is valid till the transaction is complete or an explicit freemain is issued.
- But from the CICS trace i found that the violation happens in a free main.
- Bill pointed out in one of his post that an implicit freemain is issued for dynamic assembler storage (i.e.) variables in DSECT.
- So, i started to suspect the DSECT variables in ASM pgm.
- When i checked there was a mismatch in variable length. A varaible of lenght 8192 is defined in the linkage of a cobol program and the address was assigned to a pointer. The address in this pointer is later pointed by a DSAECT in the ASM program i was referring to. But the lenght of the DSECT was 8191 (one byte short).
-The Dsect was followed by CSECT. As per the above, 8192 was assigned to 8191. Hence the violation.
- I Just put a 'CL1' in the DSECT of the assembler program. which makes the DSECT 8192 lenght and the issue was resolved.
If you are reader and if you have any question or need any clarifications about the about post, please feel free to disturb me... any updates to this post will trigger a mail to me.. i will try to help you if i can.
Eventhough the issue is resolved, I still have few unanswered questions...
If this one byte length difference was causing the violation, this violation must have occured a long time back. The ASM program i was referring to in the above post was last modified in 1984. Why was the program running for 25+ years without any issues.. but now abended??
Below are the comments from one of the experts .. he is experienced.. i dont actuelly understand what he is saying..
I wrote the below:
I told him that, there is a length difference in the load and i asked him if the production source is correct??
And also told him about the lenght difference and CL1 is told in the previous post..
I didn't do the below... hope this helps you..
He wrote:
Quote:
On Monday, I looked at the load modules for <ASM PGM> in PRODUCTION and TEST. The 8-byte difference in size(A70 vs A78) was due to a CICS stub, not your assembler program. The CSECT for <ASM PGM> was A2C in both load modules. I wouldn’t worry about the CICS stub, the old load module was assembled with an old release of CICS.
The thing to be concerned about are the DSECTS(normally implemented by copybooks, includes, etc.). These describe storage not yet acquired and will not impact the size of the generated load module. If you assemble a program with 2 different versions of a copybook, you will generate 2 load modules of the same size. But, the load module created using the wrong copybook will probably abend. What will change is the offset In the executable instruction, not the size of the load module.
I notice in your job out on SDSF(COMPLIE JOB43669) you used the NOALIGN assembler parameter. I would take out the CL1 and reassemble it with ALIGN. That should put <variable in DSECT> on a full word boundary.
