On Fri, 22 Jul 2011 06:54:07 -0500, Juergen Keller 
<juergen.kel...@deutsche-boerse.com> wrote:

>hello Andy,
>but it does NOT work for us :-( If you use for example Connect:Direct (which 
>is now an IBM product) and you don't have defined a STEPLIB you will receive 
>S806. An ISPLLIB is also defined with LIBDEF but does not help. And there are 
>some more examples ...
>Juergen
>(sorry I've missed the "NOT")
>

Yes, LIBDEF doesn't work for LINK, XCTL, LOAD, & ATTACH.  

I think the CBT has an updated STEPLIB command.  But if you don't want to use 
it:

Easiest way around it is LNKLST, but you don't want to use that.  I'm not sure 
why.  Even if
only a small set of users need it, there is no performance impact.   You can 
protect
the execution with RACF program control if you want.   Unless you are running
into the 255 extent limit?   There is a performance benefit to being in LNKLST 
too
for those users that are using it.  

ISPLLIB within the logon proc should work (so the few users could use a 
different logon 
PROC).   Or STEPLIB for that matter. 

TSOLIB can be used, but it needs to be done prior to ISPF invocation.  Your 
LOGON 
CLIST / EXEC can look for specific userids or whatever and do the TSOLIB for 
those 
users that need it.

Someone mentioned ISPEXEC SELECT PGM() doesn't work.  But you may be able
to use ISPEXEC SELECT CMD() instead and that causes a daughter task to be 
created,
with the LIBDEF datasets as the tasklib. 

Search the archives of ISPF-L for more information as this subject comes up
fairly often.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS       
mailto:m...@mzelden.com                                        
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to