Strange ISPF initialization problem
Ray Mullins
First, I’m doing fine…things have happened, but I’m back on my feet and I
found a very nice position with a small ISV. In addition to writing code,
I’m also the sysprog/sysadmin for our z9 development system. It’s been good
to get back into the sysprog game, and (usually) it doesn’t take up much of
my time.
But I’ve run into a strange inconsistent ISPF initialization problem.
Sometime in the past couple of months, I’ve 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 don’t see it, so I’m looking for some
pointers as where else to look.
I should first state that this is based on the standard ADCD environment
(although technically it’s no longer called ADCD in our case. J )
Here’s 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. I’ve logged on using the same proc and I’m fine. We have
several other users that use ISPFPROC and they don’t have any problems at
all, either. I’ve 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.
I’m 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 list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Lionel B Dyck
the sysproc/sysexec and the ispf libraries and verified that the dcb's are
correct?
Is it possible that these users could have a logon exec or clist being
executed that is changing the environment? I'm not familiar with the adcd
(or whatever) but some shops have modified the logon proc to execute a
clist or exec at logon time - worth checking.
Lionel B. Dyck, Consultant/Specialist
Enterprise Platform Services, Mainframe Engineering
KP-IT Enterprise Engineering
925-926-5332 (8-473-5332) | E-Mail: Lionel...@kp.org
AIM: lbdyck | Yahoo IM: lbdyck
Kaiser Service Credo: "Our cause is health. Our passion is service. We're
here to make lives better."
I never guess. It is a capital mistake to theorize before one has data.
Insensibly one begins to twist facts to suit theories, instead of theories
to suit facts.
- Sir Arthur Conan Doyle
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail,
you are prohibited from sharing, copying, or otherwise using or disclosing
its contents. If you have received this e-mail in error, please notify the
sender immediately by reply e-mail and permanently delete this e-mail and
any attachments without reading, forwarding or saving them. Thank you.
Lizette Koehler
What about terminal screen size? Are all users using the same 3270 device or are some reconfiged for a MOD3, MOD4, or MOD5?
One thing I would look at is the terminal size. Then I would look to see if maybe some have an ISPF concatenation process. The use of ISPF TEST might be helpful here.
Lizette
----------------------------------------------------------------------
Brian Peterson
a user who doesn't? Maybe the UNIT value is wrong...
LU userid NORACF TSO <-- to list the TSO segment
Brian
On Mon, 10 Nov 2008 12:21:24 -0800, Ray Mullins wrote:
>Hi everyone,
>
(snip)
>
>But I’ve run into a strange inconsistent ISPF initialization problem.
>Sometime in the past couple of months, I’ve 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 don’t see it, so I’m looking for some
>pointers as where else to look.
>
(snip)
Rob Scott
Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
rsc...@rs.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On Behalf Of Ray Mullins
Sent: 10 November 2008 20:21
To: IBM-...@BAMA.UA.EDU
Subject: Strange ISPF initialization problem
Hi everyone,
First, I'm doing fine.things have happened, but I'm back on my feet and I found a very nice position with a small ISV. In addition to writing code, I'm also the sysprog/sysadmin for our z9 development system. It's been good to get back into the sysprog game, and (usually) it doesn't take up much of my time.
Here's what happens
specified for attribute override.
***
Unrecoverable Error
* * * *
* * * *
* * * *
* * * *
* * * *
* * * *
* * * *
Then finally
READY
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.
Jakubek, Jan
Paul Gilmartin
>
>What about terminal screen size? Are all users using the same 3270 device or are some reconfiged for a MOD3, MOD4, or MOD5?
>
>One thing I would look at is the terminal size. Then I would look to see if maybe some have an ISPF concatenation process. The use of ISPF TEST might be helpful here.
>
Can they execute ISPF under the TMP in batch, with ISPPROF
allocated to a new temporary DSN? Does the same JCL work
or fail alike for other users?
-- gil
Chris Mason
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 <m...@LERCTR.ORG> wrote:
>Hi everyone,
>
>
>
>First, I’m doing fine…things have happened, but I’m back on my feet and I
>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é]
----------------------------------------------------------------------
Tony B.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On Behalf
Brian
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008
7:53 AM
Chris Mason
Well, perhaps I should have left well alone - not to be hoist with my own
petard!
It turns out that I misunderstood what the MVS System Codes manual meant
by "The system" when it said "Explanation: The system detected an internal
error. System Action: The system ends subcommand processing." I guessed -
how remiss[1]. Checking a little bit further - the curse of still having a little
time on my hands waiting for a colleague to finish some urgent work[2] - I
noticed that there were other codes leading up to code 999, that is 998, 997
etc., in the ISPF Messages and Codes manual but there were none of these in
the MVS System Codes. It turns out that code 999 as reported in the MVS
System Codes manual refers to the IPCS component - nothing whatsoever to
do with any old product like ISPF. Ho-hum!
Chris Mason
[1] The late actor Ian Richardson played the part of Dr Bell in a dramatisation
of Doyle early life. I can imagine the stare I would now receive so to have
strayed!
[2] It seems there's a holiday in the US tomorrow so some tests have to be
done now.
On Mon, 10 Nov 2008 12:21:24 -0800, Ray Mullins <m...@LERCTR.ORG> wrote:
>Hi everyone,
>
>
>
>First, I’m doing fine…things have happened, but I’m back on my feet and I
>found a very nice position with a small ISV. In addition to writing code,
>I’m also the sysprog/sysadmin for our z9 development system. It’s been good
>to get back into the sysprog game, and (usually) it doesn’t take up much of
>my time.
>
>
>
>But I’ve run into a strange inconsistent ISPF initialization problem.
>Sometime in the past couple of months, I’ve 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 don’t see it, so I’m looking for some
>pointers as where else to look.
>
>
>
Linda Mooney
By any chance are the failing users profile datasets full or very close to it?
Linda Mooney
> http://www.mrmullins.big-bear-city.ca.us/
>
> http://www.the-bus-stops-here.org/
Ray Mullins
I found it, thanks to an off-line note that at least pointed me in the right
direction.
I'm replying to the first note that mentioned the root cause, but all of
your notes were helpful, including the off-line ones.
I had done a lot of things already, such as comparing RACF profiles, procs,
checking for weird substitutions, checking the default allocation CLIST that
comes with the ADCD...but eventually that led me to the ISPF profile. And
that's where the problem lay.
Somehow the block size for these newer users with the problem was bad - not
a multiple of 80. Of course, that led to either an OPEN or an I/O error,
which eventually got masked by the U0999 abend. We have a CLIST that sets
up new users, and somehow there was a block size specified that got changed.
I've made some changes since then, so I'm not sure if I accidentally screwed
it up in other changes, or if someone else mucked it up, but anyway that
block size has been removed (yay SDB!), and so far a couple of users have
been able to get on.
I do appreciate everyone's help, and hopefully I can get back to
lurking/reading IBM-MAIN.
Later,
Ray
--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/
http://www.mrmullins.big-bear-city.ca.us/
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é]
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On Behalf
Of Rob Scott
Sent: Monday, 10 November, 2008 12:57
To: IBM-...@BAMA.UA.EDU
Subject: Re: Strange ISPF initialization problem