On 2017-01-20 23:28, Tom Conley wrote:
On 1/20/2017 6:00 PM, Robert Prins wrote:
On 2017-01-20 17:50, Tom Conley wrote:
On 1/20/2017 12:34 PM, Robert Prins wrote:
On 2017-01-20 15:10, Tom Conley wrote:
and the Pop-Up that appears after the search tells me
Robert,
I use TSOLIB from the READY prompt, and then enter ISPF. You can
verify the
options and the active ISPCFIGU either on the main menu for ISPCCONF,
or by
running TSO ISPVCALL twice. Google "Configuring ISPF for Fun and
Profit" to
grab my SHARE session on this.
Tom,
The double ISPVCALL you suggested has hung my session, with no clue how
to cancel it (other than sending an email to Sam).
Robert,
My best guess is that you have an outstanding reply because you don't
have a
volume to allocate the ISPVCALL trace dataset on.
Nope...
Sam's given me a second userid to cancel the first (and the other way
around). If I logon with either, don't do anything other than a double
ISPVCALL, everything is OK. However, if I go back to the READY prompt
and run the exec I run on two other systems, prepending my LOAD library
in front of what's already allocated to ISPLLIB, and then do a TSO
ISPVCALL, the session hangs, there are no outstanding replies, and CPU
of the PRINO session goes to 100% (ouch...)
The only difference is that the "standard" ISPVCALL dataset is
PRINO.S0W1.ISPVCALL.TRACE
whereas the one using my(?) ISPCFIGU load module is
PRINO.ISPVCALL.TRACE
I'm stumped, it's midnight and I need to get some sleep. :(
Will explore further tomorrow...
Robert,
The fact that you're getting a different ISPVCALL dataset name indicates a
different config module. When you say PREPEND, what do you mean? I'll again
suggest using TSOLIB for your LOADLIB (instead of whatever else you're doing to
"PREPEND"), which has always worked for me.
Prepend is concatenate them in front of what's there, append is at the back. ;)
I seem to have solved the problem by regenerating my private command tables from
scratch, rather than using the 1.10 & 1.6 versions that I had copied to the ISPF
profile dataset from my 1.10 system (and "that" system).
This part now works. However, ISPVCALL still hangs and gobbles up all the CPU it
can get. (So as a "solution" I won't use it for now)
I do however think that the current set-up, where there are already four
ISPCFIGU load modules present is not ideal, to put it mildly, but maybe some of
you more at home in these matters might have another opinion you could share.
Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
