User 4088 reason 63

[Mike1304]

I have a 4088/63 because the DSA backchain is not ok for LE.

I know, that the assembler program which is calling my assembler program is called by dirty branches from other modules,
but it can handle this, it worksvery well and that assembler program is not my responsability and I can't change it.

When I call a Cobol Z/OS V3R4M1 program, it abends with 4088/63.
Same occurs, when I call another assembler program, which calls the Cobol programm.

It seams that LE checks before starting a Cobol program the DSA backchain.

My questions:
Is there a possibility to avoid this check for DSA backchain?
Can I do something, that LE thinks, the DSA backchain is ok?

best regards
Mike1304

[BillyBoyo]

Are you making your assembler routine, which is calling the Cobol, "LE Compliant"?

[Mike1304]

Many thanks for your answer!

No, are you sure that making it LE compatible have any effect to my problem?

The dump tells me, that the problem is not in my program, but in my caller!
And it occurs, when the first Cobol program is called.

And I think, if I change my program to LE, the problem will occur when my program is called instead of when the first Cobol program is called.

Mike1304

[Robert Sample]

If ANY assembler program in the calling sequence is not LE-compliant, a 4088 / 63 abend would be normal and expected when the call to an LE-compliant (Enterprise COBOL for example) COBOL module is made. And the message explanation in the manual makes clear that addressing mode could be an issue:

For instance, a 24-bit address that was obtained by using the BAL or BALR assembler instruction will contain the ILC, CC, and Program Mask in the uppermost byte of this address, thus making it an invalid address in 31-bit mode.

Resolution of this problem: (1) make all assembler programs in the calling sequence LE-compliant, or (2) don't call COBOL program from non-LE-compliant assembler programs (no matter how deeply nested).

[Mike1304]

I think my problem is the no longer valid FWD and this is not an AMODE problem:

Code: Select all

A B E N D - A I D                      PAGE   5
  **********************************************************************     
  * Program storage for CSECT I2DRRC01                                 *     
  * located in load module I2DRRC01                                    *     
  * Length is 000055E8                                                 *     
  * Language is HLASM                                                  *     
  **********************************************************************     
                                                                             
  **********************************************************************     
  * Save area used to call CSECT I2DRRC01                              *     
  *--------------------------------------------------------------------*     
  * Owned by CSECT DSNMTV02                                            *     
  * Located at:  00102C58  A(00102000) + 00000C58, PVT SP=088 ALLOC    *     
  **********************************************************************     
                                                                           
     Hex       Decimal         Description (based on 31-bit address)       
  WD1 00000000               0                                               
  BCK 0001A280         107,136  A(DFSBATWK) + 00000280                       
  FWD 00123208       1,192,456  POINTED TO FREED STORAGE AREA               
  R14 000A27D2         665,554  A(DSNMTV02) + 00000502                       
  R15 8011DA18  -2,146,313,704  A(I2DRRC01) + 00000000                       
  R0  00007438          29,752  A(DFSPRPX0) + 00000000                       
  R1  80007018  -2,147,454,952  A(PCBLIST ) + 00000018                                   
  R2  00102838       1,058,872  A(00102000) + 00000838, PVT SP=088 ALLOC                 
  R3  00102BB0       1,059,760  A(00102000) + 00000BB0, PVT SP=088 ALLOC                 
  R4  00102BFC       1,059,836  A(00102000) + 00000BFC, PVT SP=088 ALLOC                 
  R5  00007438          29,752  A(DFSPRPX0) + 00000000                                   
  R6  00017304          94,980  A(DSNMIN10) + 0000028C                                   
  R7  00017240          94,784  A(DSNMIN10) + 000001C8                                   
  R8  00000001               1                                                           
  R9  00017340          95,040  A(DSNMIN10) + 000002C8                                   
  R10 000172F0          94,960  A(DSNMIN10) + 00000278                                   
  R11 008FDDF8       9,428,472  A(008FC000) + 00001DF8, LSQA SP=255 ALLOC               
  R12 000A22D0         664,272  A(DSNMTV02) + 00000000

[Robert Sample]

Believe as you want to believe and fix your problem the way you think it needs to be fixed. The real question is, if you already knew what your problem was and its solution, why did you post anything here?

Also, did you notice that your Abend Aid display has register 15 using 31-bit addressing while all the other addresses are 24-bit?

[steve-myers]

I wish we could see the PSW.

FWIW, the BAL and BALR instructions executed in the 31-bit addressing mode behave exactly like the BAS and BASR instructions; the instruction length code, the condition code and program mask are not stored in the link register.

I first came across BAS and BASR in my model 20 days. While I realized they did not store the additional link information in the link register because there was not enough room, I was not quick enough to extend the idea to mainframes. I never did any Model 67 work, which had a 32-bit addressing mode, though I believe it was only used by TSS/360. Somewhat later I read they were RPQ instructions on a Model 168 so that TSS/370 (yes, /370, put together from the IBM base TSS/360 with a number of enhancements to make it run better) could run on a /168. Of course, when MVS/XA finally appeared BAS and BASR became standard.

While I'm hardly an LE expert, I'm certain the Mike1304 and Mr. Sample's analysis is correct. I also think Mr. Sample's proposal to make the Assembler program fully LE compliant is the best possible solution. Mike1304 will have to do some research. I'd start here.

[Mike1304]

My questions:
Is there a possibility to avoid this check for DSA backchain?

NO

Can I do something, that LE thinks, the DSA backchain is ok?

YES: restore the DSA backchain.

Solution:
The assembler program above me did some saves of access registers on an stack and changed the DSA chain.
Now it restores the original be for calling me.

Thanks to all for your tipps!