IBM Mainframe Forum

by **Mike1304** » Mon Apr 25, 2011 11:54 am

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

by **BillyBoyo** » Mon Apr 25, 2011 9:48 pm

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

by **Mike1304** » Tue Apr 26, 2011 12:47 am

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

by **Robert Sample** » Tue Apr 26, 2011 1:01 am

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).

by **Mike1304** » Tue Apr 26, 2011 1:37 am

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

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

by **Robert Sample** » Tue Apr 26, 2011 2:50 am

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?

by **steve-myers** » Tue Apr 26, 2011 9:01 am

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.

by **Mike1304** » Tue Apr 26, 2011 6:58 pm

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!

IBM Mainframe Forum

User 4088 reason 63

User 4088 reason 63

Re: User 4088 reason 63

Re: User 4088 reason 63

Re: User 4088 reason 63

Re: User 4088 reason 63

Re: User 4088 reason 63

Re: User 4088 reason 63

Re: User 4088 reason 63