Problems with ESTAE, ESTAEX, and IHASDWA

[John Ganci]

I recently submitted a fix for the MULTIPLY DECIMAL (MP) issue reported back in December. (RPI 2013; may make it in the next beta.) The assembler programs used to test the fix use ESTAE to trap S0C6, S0C7, and S0CB abends that were intentionally produced so that the ESTAE exit could exit with retry so that the test program could continue with the execution of other tests.

When the ESTAE exit was active, two issues were found.

1. The IHASDWA macro, which generates a DSECT for the SDWA, has a field with the wrong name:

    SDWAABSS DS    0BL4 COMPLETION CODE

should be

    SDWAABCC DS    0BL4 COMPLETION CODE

2. The value of SDWAABCC for S0C6 is X'000000C6'; it should be X'000C6000'. Same behavior for any S0Cx abend. (Some of the flag bits in the high order byte may need to be set as well; ignored for now but being investigated for later.)

The first is a typo; the second is a bug.

In the interest of time, the assembler test program was modified to get around these two issues; however, both should be fixed.

There are many other issues with ESTAE, ESTAEX processing that I have uncovered and am currently investigating.

For now, I would like to submit a fix for the two issues mentioned above: 1.Change SDWAABSS to SDWAABCC; 2. Move the system abend code to its proper position in the SDWAABCC word. Both changes affect users of ESTAE/ESTAEX exits and IHASDWA.

Does anyone use either of these? Any objections to changing them as indicated?

Regards,

John Ganci

[Abe Kornelis]

John,

my apologies for the (much) belated reply to your email.

I have created two RPIs:

RPI 2011	2021-03-02	Incorrect field name in IHASDWA.MAC. SDWAABSS should be SDWAABCC. See mail by John Ganci dd 2021-02-03 18:16
RPI 2012	2021-02-03	Incorrect bit pattern in SDWAABCC field. X'000000Cx' should be X'000Cx000'. See mail by John Ganci dd 2021-02-03 18:16

Don, do you think you can get these two issues fixed with the next release?

Kind regards and happy programming!
Abe
===

Op 03/02/2021 om 18:16 schreef John Ganci:

--
You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/z390/9bb06699-4bdb-4632-b1d6-761555e869f3n%40googlegroups.com.

[John Ganci]

Abe, There's no need to create any RPIs. The post was to see if there would be any impact if the proposed changes were made.  I've already sent Don RPI 2015 that changes the IHASDWA.MLC field name SDWAABSS to SDWAABCC. It will be in his next beta. I'm working on the second fix, setting SDWAABCC correctly for system completion codes, now. The fix will be more involved and will address several other ESTAE-related errors. I've reserved RPI 2016 for it.

If you recall, back when I started work on z390, you "assigned" a block of RPI numbers for me to use, beginning with 2000. I've been using them for recent work, continuing where I left off. RPIs 2011-2014 have already been used.

Regards, John Ganci

[d...@higgins.net]

Abe, John, Melvyn, all

 

I will plan to include RPI 2011, RPI 2012, and RPI 2229 in next z390_v1705b.  I’m still developing tests for RPI 2229 to support QSAM large blocks over 32k for use with zVSAM2.

 

Don Higgins

d...@higgins.net

www.donhiggins.org

To view this discussion on the web visit https://groups.google.com/d/msgid/z390/fb15dd3c-bbc1-7167-93d4-51ac2c60ddf9%40bixoft.nl.

[Abe Kornelis]

John,

thanks for the update.

Yes, I do remember we reserved a range of RPI numbers for your use.
That's why assigned numbers in that range, unaware they'd already been taken.

I'll modify my copy of the RPI list accordingly.

Kind regards,
Abe
===

Op 03/03/2021 om 19:44 schreef John Ganci:

To view this discussion on the web visit https://groups.google.com/d/msgid/z390/11c03159-56cb-40e5-bb01-3149c804b64an%40googlegroups.com.

[John Ganci]

Don,

RPI 2011 and RPI 2012 have already been used. RPI 2011, dated 2020-10-12, was in the pk01 for your beta 02.  It modified some perl scripts. RPI 2012, dated 2021-01-06, fixed a problem in sz390.java method bytes_to_hex for SNAP. Abe was unaware of these RPIs. At any rate, the fix I sent you on 2021-02-28, RPI 2015, corresponds to the RPI 2011 that Abe mentioned, so you already have that fix. The second fix Abe mentioned, his RPI 2012, is not yet complete and will not be ready for z390_V1705b. I am working on it. It will be RPI 2016, not RPI 2012. Moving the system completion code to its correct position in field SDWAABCC is not difficult, but when researching it I uncovered several other problems with ESTAE that I would like to fix and include in RPI 2016. That's why there will be a delay.

Summary.

RPI 2015, which you already have, corresponds to Abe's RPI 2011.

RPI 2016 corresponds to Abe's RPI 2012. It is very doubtful that it will be ready in time for v1705b.

Regards, John Ganci