I need to make a correction to my previous analysis: I originally based my assessment of the AOF entry offsets based on the TAOFNTRY macro in the source library. This macro appears to be wrong also, as the TABENTRY macro used in assembling the AOF TABLE inserts a "DC AL2(0)" (to indicate there is no action-text) before the POST flag byte. So it looks like the proper offset for the NI instruction in OSWAITRC would be 46, not 44 (or 42). Both OSWAIT and TSSOSS09 use the TAOFNTRY MACRO to generate their offsets, which yields an offset of 44, but that macro doesn't match the TABENTRY macro used to generate the table itself. However, since these two programs are using the same offsets, and that offset seems to point to a field that is otherwise un-used, they have been working, while OSWAITRC does not work. So, the proper fix for this would appear to be to correct the TAOFNTRY macro to generate the offsets properly, and then change OSWAITRC to use the macro rather than it's current hard-coded (incorrect) value. There is also the possibility that the TABENTRY macro is at fault for the offset mis-match between the two, since I don't know for sure if there is a need for the action-text field in a POST entry, and the TAOFNTRY macro seems to imply it shouldn't be there.
>>> Scott Rowe <[email protected]> 7/20/2010 9:24 AM >>> Two problems: 1) There are two cross memory POSTs in TSSOSS09 that have an ERRET=, neither of these appear to be proper ERRET routines. The way I read the doc in Auth Assem Services, the ERRET routine will receive control asynchronously, and the regs (particularly R12, the base reg) will not be valid. The second of these POSTs (FUN9POST) appears to have caused a branch to the PSA (resulting in a S0C1 in the HSM address space). This may never have happened if not for the next problem. 2) In OSWAITRC (the ESTAE for the OSWAIT TSO command), there is an NI instruction to reset the wait bit in an AOF entry. The offset into the AOF entry is hard-coded and looks to me to be incorrect, it is coded as 42, but I think it should be 44 (sometimes 42 isn't the ultimate answer). This causes the TSSO address space to think there is still an ECB waiting, when in fact the job was canceled. It also steps on the AOF entry, so that it cannot be waited on again in the future. We had a job that was canceled while waiting on an HSM message. Because of problem #2 not clearing the wait bit properly, an error occurred during the cross memory POST to a non-existent ECB, which caused the S0C1 abend in the HSM address space. I suspect that there is not much need for a formal ERRET routine, and pointing both POST ERRETs to a "BR 14" would suffice, but I haven't thought through every scenario. So, what do you think? CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
