Ray Perhaps fortunately for you I had some time on my hands with nothing better to do than check a thread I would not normally look into.
First I looked at the responses you had already received in case the answer was going to be offered - maybe. Then I thought to do what must surely be what you should always do when some component in the system is kind enough to produce an abend code. Yes - you know now what it is - look up the MVS System Codes manual. It's not obvious but, once you look up code 3E7, you discover it translate to decimal 999 - hm. The explanation is very short but it seems to be a convention that, when a product is feeling a bit lazy over explaining "what went wrong", MVS allows this abend code to be used - I'm not sure that was really a good "design decision"! I figured then that one possible explanation for the responses being of a "you might like to try this" nature was that the respondents already knew what sort of an abend X'3E7' was and knew that there appeared to be little hope in following up this abend code. However, it did seem to indicate - without actually saying so - that, if you know the product which reported the abend, maybe that product might have a better explanation of what it might mean. So here is what I found in the ISPF Messages and Codes manual: <quote> Abend code ---------- 999 (or X'3E7') This abend is issued for the following reasons: . No function pool is established for a command processor. For example, a command processor that uses ISPF services is invoked using option 6 or SELECT CMD, but the command processor does not have a function pool. The user needs to have an entry for the command processor in the ISPTCM with the X'40' flag set on. The X'40' flag indicates that the command requires a function pool. See z/OS ISPF Planning and Customizing for more information on customizing the ISPTCM. . An error occurs while another error is already being processed. ISPF issues the abend code 999 in this case to protect against an infinite loop. . An error occurred during ISPF initialization. For example: An I/O error occurred due to ISPF library allocations such as ISPSLIB, ISPPLIB, ISPMLIB, and so forth, containing inconsistent or incorrect DCB attributes. An ISPF library allocation does not contain the required ISPF libraries in its concatenation. For example, the ISPMLIB contains user product libraries but not ISPF libraries. </quote> You can take it from there. Incidentally, one of your respondents quotes Sir Arthur Doyle. It was a principle of medical diagnosis that Sir Arthur learned under his tutor Dr. Bell which he extended to the (fictional) diagnosis of crimes that you should study the evidence. In this case we know only that ISPF is involved and, under our magnifying glasses, we have only one scrap of evidence, the abend code, so we need to exploit it to the maximum. The quotation was all about not just guessing! In fact, it looks like the guess in this post it may have been a good guess - or alternatively, this Holmes just hadn't bothered to explain to the attendant Watsons that he actually had scrutinised the evidence and found the third bullet! "RACF", "screen sizes" - now those were guesses - Dr. Bell would not have approved! Chris Mason On Mon, 10 Nov 2008 12:21:24 -0800, Ray Mullins <[EMAIL PROTECTED]> wrote: >Hi everyone, > > > >First, Im doing fine things have happened, but Im back on my feet and I >found a very nice position with a small ISV. In addition to writing code, >Im also the sysprog/sysadmin for our z9 development system. Its been good >to get back into the sysprog game, and (usually) it doesnt take up much of >my time. > > > >But Ive run into a strange inconsistent ISPF initialization problem. >Sometime in the past couple of months, Ive set up a couple of users who, >for some strange reason, cannot get into ISPF. They are using the same TSO >logon proc as others, and those others can access ISPF without any problem. >I must be missing something, but I dont see it, so Im looking for some >pointers as where else to look. > > > >I should first state that this is based on the standard ADCD environment >(although technically its no longer called ADCD in our case. J ) > > > >Heres what happens > > > >User logs on, gets READY, types in ISPF. Then they get > > > > ISPP302 Panel 'ISPTERM' error - Invalid attribute keyword or value is > > specified for attribute override. > > *** > > > >Then they get the ISPTERM2 panel: > > > > Unrecoverable Error > > > > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > * * * * > > * * An error occurred within the error routine. * * > > * * No recovery is possible. * * > > * * * * > > * * * * > > * * * * > > * * * * > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > * * * * > > * * Press ENTER key. * * > > * * * * > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > > >Then finally > > > >ISPS014 - ** Logical screen request failed - abend 0003E7 ** > > ISPS015 - ** Contact your system programmer or dialog developer.** > > *** ISPF Main task abend *** > > IKJ56641I ISPF ENDED DUE TO ERROR+ > > READY > > > >U0999 is the ISPF prevent an ABEND loop abend. > > > >This is one of those times that I can say nothing has changed as far as the >proc and system data sets go. The user is using the ISPFPROC that comes >with the ADCD. Ive logged on using the same proc and Im fine. We have >several other users that use ISPFPROC and they dont have any problems at >all, either. Ive also tried DBSPROC (the DB2ish proc from the ADCD) and >ISPFLITE (ADCD bare-bones ISPF proc); no difference. > > > >ISPTERM is sitting in ISP.SISPPENU and it looks just fine. > > > >The only thing I can point to is that some users that were created sometime >after a general date (this summer) have the problem. Yet others who were >defined after this time do not have the problem; they can use ISPF just >fine. > > > >Im at a bit of a loss as to where to go next. Any/all pointers suggested. > > > >Oh, the one catch this particular environment is 1.7, which, as soon as I >can accumulate enough round tuits, will be upgraded. But this is one of >those gotta make it work now because of deadlines situations. > > > >Thanks in advance, > >Ray > > > >-- > >M. Ray Mullins > >Roseville, CA, USA > > <http://www.catherdersoftware.com/> http://www.catherdersoftware.com/ > > <http://www.mrmullins.big-bear-city.ca.us/> >http://www.mrmullins.big-bear-city.ca.us/ > > <http://www.the-bus-stops-here.org/> http://www.the-bus-stops- here.org/ > > > >German is essentially a form of assembly language consisting entirely of far >calls heavily accented with throaty guttural sounds. ---ilvi > >French is essentially German with messed-up pronunciation and spelling. --- >Robert B Wilson > >English is essentially French converted to 7-bit ASCII. ---Christophe >Pierret [for Alain LaBonté] ---------------------------------------------------------------------- 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
