On 19 February 2011 13:04, Joe D'Alessandro <joseph.d'[email protected]> wrote:
> Last March we first installed zOS v1.11 onto our test sysplex and in the > course of testing I looked at a number of dumps. I noticed in a few cases a > s0c4 in the TCBCMP field of the INIT task. I did not see any LOGREC entry for > such an event so I noted it and moved onto the "real" problem I was supposed > to be addressing. > > Over the last 11 months, I have seen this s0c4 in the TCBCMP field many > times, on all of our sysplexes, even in asynchronous dumps from the console > for jobs in a wait (that is, which were not in any kind of apparent abterm). There are all sorts of situations where an S0C4 is caught and turned into a return code from a service routine. Normally the S0C4 is not seen, but if you have a SLIP set you will get a dump (or whatever ACTION you specified). Typically this is because of the ab initio MVS philosophy that a service routine (SVC, PC, etc.) should assume the caller's authority before attempting to store results into caller-supplied addresses, rather than try to test the address and potentially suffer from time-of-check-to-time-of-use and other exposures. If the store fails, the service routine may catch the abend and convert it into a return code. UNIX callable services show up very commonly, usually returning EFAULT or EINVALID, but there are non-UNIX services that do the same kind of thing. We had a problem some years ago with a customer who was encountering a rare failure in our code, so we had them run a tightly specified SLIP for some time. We got back many more dumps than expected, and all but one turned out to be S0C4s in the UNIX __console() service that were quietly converted into EFAULTs, which our code then handled properly. > Now, at this time I do not consider this a problem: I do not know what is > failing given that there are no dumps or LOGRECs, so I have not opened an > ETR. I did a few searches on IBMlink but I have not seen anything like this. If this is what's happening, it is indeed not a problem. Why it has increased in z/OS 1.11, if it truly has, rather then simply being observed more, I do not know. Tony H. ---------------------------------------------------------------------- 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
