AW: ISPCFIGU - which one? [SOLVED - sort of]

2017-01-21 Thread Roland Schiradin 
Hi Robert, I try ISPVCALL on Sam's system and it works without any issue. Roland

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Robert Prins
Gesendet: Samstag, 21. Januar 2017 14:06
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: ISPCFIGU - which one? [SOLVED - sort of]


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 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPCFIGU - which one? [SOLVED - sort of]

2017-01-21 Thread Tom Conley 




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,

ISPVCALL should not hang and gobble CPU.  Something about ISPF in your 
environment is not right.  Four ISPCFIGU modules is a really bad idea. 
There should only be 1 in LINKLIST, and possibly 2 if you're testing 
your own with TSOLIB.  That's it.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPCFIGU - which one? [SOLVED - sort of]

2017-01-21 Thread Robert Prins 

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPCFIGU - which one?

2017-01-20 Thread Tom Conley 

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.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: ISPCFIGU - which one?

2017-01-20 Thread Robert Prins 

Hi Roland,

On 2017-01-20 15:10, Roland Schiradin wrote:

Hi Bob,


Please, please, please, don't call me Bob!


I'm also working on Sam system. I would try to rename the ISPCFIGU in the
linklist. Do a /F LLA,REFRESH. New logon and verify again. If it works
contact Sam and ask him.

You may also try my and Norbert Haas logon proc Procedure ===> SPFPROCS. It
invoke the REXX SYS1.LOGON.CLISTS(ISPFZRY).


That seems promising, and I really like the way you add datasets to the 
concatenation, it's more readable and easier to update than long line-spanning 
concatenations that I use in 'prino.rahp.exec(prino)'. However, asking Sam to 
create yet another logon proc invoking yet another exec or clist seems such an 
overkill, there should be just one, or maybe two with the second just containing 
the standard ISPF datasets.


The first should invoke just one exec that should allocate a standard set of 
libraries, but it should contain a defined exit. On "that" system, the standard 
logon exec has been changed by yours truly to contain the following:


 /*---+
   Find out if the user has specified a command on the command field
   of the LOGON panel - if they have this will be executed before any
   pushed commands. If the user specified command starts ISPF, any
   command pushed here will only be executed after ISPF is terminated.
   In this case, i.e. when a user-defined command is detected, we may
   assume that we are dealing with a smart user, one who can start
   ISPF all by themselves, and just exit this exec.
 */
 parse source v1 v2 v3 v4 v5 v6 v7 v8 v9

 if v5 \= '?' then
   do
 numeric digits 20

 psaold   = storage(224, 4)
 ascbasxb = storage(d2x(c2d(psaold) + 108), 4)
 asxblwa  = storage(d2x(c2d(ascbasxb) + 20), 4)
 lwalgcmd = storage(d2x(c2d(asxblwa) + 186), 80)

 if lwalgcmd \= '' then
   return 0

 /*
   Allow user to do some private pre-ISPF processing - if this
   fails it's their problem and they will end up at the READY
   prompt and will have to start ISPF manually.

   The user is allowed to use either a REXX exec or a CLIST to do
   the pre-ISPF processing.
 */
 uexit = userid()'.exec(#logon)'
 rc= sysdsn("'"uexit"'")
 if rc \= 'OK' then
   do
 uexit = userid()'.clist(#logon)'
 rc= sysdsn("'"uexit"'")
   end

 if rc = 'OK' then
   push "ex '"uexit"'"
   end

In other words, a real power-user can completely break out of the standard logon 
exec by specifying a command on the TSO/E LOGON screen, others who feel like it, 
can do some pre-processing via an exec or clist using a standard member in a 
private exec or clist library, and for everybody else this exec just runs it 
course - there's obviously scope to combine the SYSDSN() approach with your 
method to add datasets to the various DDNAMEs, so that 'userid().ispXlib' 
datasets can automagically be included should that be required.



Good luck Roland


Maybe tomorrow, if my wife lets me, now really time to go to bed.

Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPCFIGU - which one?

2017-01-20 Thread Robert Prins 

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
--
Robert AH Prins
robert.ah.prins(a)gmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPCFIGU - which one?

2017-01-20 Thread Tom Conley 

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.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPCFIGU - which one?

2017-01-20 Thread Tom Marchant 
On Fri, 20 Jan 2017 16:11:13 +0100, Roland Schiradin wrote:

>I would try to rename the ISPCFIGU in the linklist.

That is not necessary. The search order is 
TASKLIB (ISPLLIB)
STEPLIB/JOBLIB
LNKLST

It was loaded from ISPLLIB. The question is why it doesn't have the content he 
expected.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPCFIGU - which one?

2017-01-20 Thread Robert Prins 

On 2017-01-20 15:10, Tom Conley wrote:

On 1/20/2017 9:36 AM, Robert Prins wrote:

I've been given access to a z/OS 2.2 system (tanks Sam G), and one of the
first things I've been trying to do is to use several levels of command
tables - the system only seems to use ISRCMDS and ISPCMDS, and the latter
seems to be a version that's been carried forward ever since, which is a
friendly way of saying that it's out-of-date.

Copying the ISPCFIGU load module from a 1.10 system to ISPLLIB didn't do
the trick, so I reassembled and relinked it, with the same result, zilch.
An ISRDDN;LPA;M ISPCFIGU shows that there are five of them around:

- three in ISPLLIB. where my version is at the top,
- one in the LINKLIST, and
- one in the STEPLIB

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).


I've downloaded your Dynamic ISPF ages ago (the date on the file oon my PC is 3 
May 2013) with the plan of implementing it on my own z/OS 1.10 system, but it's 
still on the to-do list, and the way things are going now, it's not coming off 
that list any time soon. :(


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: ISPCFIGU - which one?

2017-01-20 Thread Roland Schiradin 
Hi Bob, I'm also working on Sam system. I would try to rename the ISPCFIGU in 
the linklist. Do a /F LLA,REFRESH. New logon and verify again. 
If it works contact Sam and ask him.  

You may also try my and Norbert Haas logon proc Procedure ===> SPFPROCS. 
It invoke the REXX SYS1.LOGON.CLISTS(ISPFZRY). 

Good luck
Roland



-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Robert Prins
Gesendet: Freitag, 20. Januar 2017 15:37
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: ISPCFIGU - which one?

I've been given access to a z/OS 2.2 system (tanks Sam G), and one of the first 
things I've been trying to do is to use several levels of command tables - the 
system only seems to use ISRCMDS and ISPCMDS, and the latter seems to be a 
version that's been carried forward ever since, which is a friendly way of 
saying that it's out-of-date.

Copying the ISPCFIGU load module from a 1.10 system to ISPLLIB didn't do the 
trick, so I reassembled and relinked it, with the same result, zilch.
An ISRDDN;LPA;M ISPCFIGU shows that there are five of them around:

- three in ISPLLIB. where my version is at the top,
- one in the LINKLIST, and
- one in the STEPLIB

and the Pop-Up that appears after the search tells me

 CSVQUERY Results Command ===>
   More: +
Module ISPCFIGU was found to be already loaded. Note that invocations of this 
program name may pick up another copy from STEPLIB or a LIBDEF'ed data set or 
from a tasklib such as ISPLLIB.
Tab to a box and press enter to view the module in storage.
   +-+
   | Job pack area resident  |
   | Resident above 16 Meg   |
   | Loaded by program fetch |
   |  from ISPLLIB   (Lib 1) |
   | * Allocation changed|
   | Module address:1A21E068 |
   | Module size:   0F98 |
   | Reentrant   |
   | Serially reusable   |
   | Not loadable only   |
   | AMODE 31|
   | Not Authorized program  |
   +-+

which would indicate that my version is used, which obviously isn't the case.

Any clues how (or even *if*) I can make my copy the default one, at least for 
me?

Thanks,

Robert
--
Robert AH Prins
robert.ah.pr...@gmail.com
Some programming  @ <https://prino.neocities.org/zOS/zOS%20Tools.html>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPCFIGU - which one?

2017-01-20 Thread Tom Conley 

On 1/20/2017 9:36 AM, Robert Prins wrote:

I've been given access to a z/OS 2.2 system (tanks Sam G), and one of the
first things I've been trying to do is to use several levels of command
tables - the system only seems to use ISRCMDS and ISPCMDS, and the latter
seems to be a version that's been carried forward ever since, which is a
friendly way of saying that it's out-of-date.

Copying the ISPCFIGU load module from a 1.10 system to ISPLLIB didn't do
the trick, so I reassembled and relinked it, with the same result, zilch.
An ISRDDN;LPA;M ISPCFIGU shows that there are five of them around:

- three in ISPLLIB. where my version is at the top,
- one in the LINKLIST, and
- one in the STEPLIB

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.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPCFIGU - which one?

2017-01-20 Thread Tom Marchant 
On Fri, 20 Jan 2017 14:36:50 +, wrote:

>Any clues how (or even *if*) I can make my copy the default one, at least
>for me?

I do this, you should be able to do it too.

I use ispcconf to make mine and put into my ISPLLIB concatenation. It works 
fine for me.

You might use ispcconf option 7, Convert Configuration Table Loadmod to Keyword 
File to process your load module and see if it has what you think it has.

I don't remember if you have to logon again for an update to take effect.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

ISPCFIGU - which one?

2017-01-20 Thread Robert Prins 
I've been given access to a z/OS 2.2 system (tanks Sam G), and one of the
first things I've been trying to do is to use several levels of command
tables - the system only seems to use ISRCMDS and ISPCMDS, and the latter
seems to be a version that's been carried forward ever since, which is a
friendly way of saying that it's out-of-date.

Copying the ISPCFIGU load module from a 1.10 system to ISPLLIB didn't do
the trick, so I reassembled and relinked it, with the same result, zilch.
An ISRDDN;LPA;M ISPCFIGU shows that there are five of them around:

- three in ISPLLIB. where my version is at the top,
- one in the LINKLIST, and
- one in the STEPLIB

and the Pop-Up that appears after the search tells me

 CSVQUERY Results
Command ===>
   More: +
Module ISPCFIGU was found to be already loaded. Note that
invocations of this program name may pick up another copy from
STEPLIB or a LIBDEF'ed data set or from a tasklib such as ISPLLIB.
Tab to a box and press enter to view the module in storage.
   +-+
   | Job pack area resident  |
   | Resident above 16 Meg   |
   | Loaded by program fetch |
   |  from ISPLLIB   (Lib 1) |
   | * Allocation changed|
   | Module address:1A21E068 |
   | Module size:   0F98 |
   | Reentrant   |
   | Serially reusable   |
   | Not loadable only   |
   | AMODE 31|
   | Not Authorized program  |
   +-+

which would indicate that my version is used, which obviously isn't the
case.

Any clues how (or even *if*) I can make my copy the default one, at least
for me?

Thanks,

Robert
--
Robert AH Prins
robert.ah.pr...@gmail.com
Some programming  @ 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN