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: 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


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  @ 

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