IBM Mainframe Forum

I've not got the listing yet..
SYSUDUMP is listed but it is displayed in the archiving utility that we have from which I don't know how to get it in some txt file or some DSN. Let me try some options..

Sorry Billy. Couldn't check as I'm working with the support to have this fixed.

No problem, that is a good plan anyway.

When I say the start of the program has been overwritten, I don't mean the start of the Procedure Division, I mean the start of the code which gets the Cobol program running, the stuff right up at the front, physically before the Working Storage in a batch program. If you look at that x'FFFFFFB2' it is the OFFSET TO TIMESTAMP/VERSION INFO, which you will see if you get the pseudo-assembler listing right totwards the top, with the displacement around the BC offset. The stuff in front of that should not be spaces. If you get to see the SYSUDUMP, you may be able to track (by PF7) backwards to find out where the spaces come from.

I don't know if you are still looking at this, but:

durga_r82 wrote:IN both the environments it as SSRANGE. We checked all the compiler options and it looks the same. RMODE=ANY and AMODE=31 (in both env and both pgms).
Only difference in UAT was DASD SIZE (HEX) 00024000 (in Prog B) and DASD SIZE (HEX) 00015000 (prog A) in the Link edit MODULE ATTRIBUTES: that gets displayed below the MODULE MAP

Anything else we need to check in compiler options?

This is the space occupied on the disk for the modules. If all the options are the same, the space occupied should be the same. You don't say what the sizes are in your development, but if they are different it indicates something is different between the code/compile options/link options in the different environments. Any other occurences of 15000 are just an unlucky coincidence.

DSNECP10 just indicates you are using batch DB2. If there is any "dynamic sql" check that that is entirely correct, including lenghts embedded in fields. The displacement mentioned, X'32250' is pretty big, but I have no idea if that is usual or not.

The 160870BC address you refer to does not refer to the MOVE that you suggested. If that is displacement or line 1608 in the ProgB it is another unfortunate coincidence. How does it happen to point to bad code? Maybe there is a lot of bad code in ProgB.

CEEBXITA deals with some Language Environment run-time options. Are you using any?

Hi Billy, We're still looking at the issue.

1. For DASD, in the development region instead of going for compile JCL we did the compile in Endevor where the compile / link edit options are exactly the same but still couldn't recreate SOC4. So guess this could be ruled out.
3. For address, I took the address in 1608 and referred in the cross-reference where it had only one statement referring with it (MOVE). As you specified might be that there is lot of bad code in ProgB because we identified so many defects in ProgB during system testing which could have been possibly corrected in unit testing. So might be your point will be applicable.
4. In the programA / B We don use it (LE). Not sure about the other programs which is embedded in ProgB are using them.

When contacted the Support they also gave the information as Billy and Steve mentioned; the problem could be anywhere either in ProgA or ProgB or the embedded programs and Stored procedure of other applications. Still debugging on it.

We already tried with the load module (also suggested by DIck). When we tried last time we copied the load module / DBRMLIB of Prog A & ProgB to a DSN and did the bind. We were unable to create SOC4 with this.
Last friday since we've access to the testing environment DSN in development we maintained the same DSN for ProgA& ProgB and did the BIND alone to the development region and We were able to recreate SOC4. Donno why the DSN matters?
Then
1. we used the load of development region for ProgA and did the bind
2. We used the load of Testing region for ProgB and did the bind
& Viceversa of the above.
We were still able to create SOC4 for above so we're thinking that the problem should be in ProgB (in vice versa condition SOC4 didn't happen). Since we gave this info ProgB owner have agreed to look into the issue.

As we're in UAT no one is taking the responsibility of the defect and is getting back & forth Hopefully it would get resolved soon.

Billy,
Since we recreated the SOC4 in development I was able to get the dump in DSN. I'm afraid to post it here. I shall PM you and if anything seems to be fruitful then I shall copy paste that part of dump in the forum. Incase if you get any clue on it can you please help? Thanks.

Sorry Billy, Couldn't send the dump as it is huge.

What would be usefule would be the compille listting with the generated psedo-assembler (at least the first part of it, do to the first Cobol verb, ie from the very start of the generated code down to the first actual mention of a line of Cobol code.

For the dump, at the moment I'd be interested in the first part of ProgB which matches that of the compile listing with the pseudo-assembler.

I think it 99% will not be a problem (directly) in ProgA.

How many modules does ProgB call? What do they do? Has their linkage (CALL USING, PROCEDURE USING order, sizes) been checked?

Does anything do any dynamic sql?

wouldn ' t it be time to involve the local support ?

durga_r82 wrote:[...]I'm working with the support to have this fixed.

Already done. No joy there yet.

after 46 posts it' s easy to miss something