Re: STEPLIB problems - was: PDSE

[Shmuel Metz (Seymour J.)]

In
,
on 01/26/2012
   at 08:47 AM, John Gilmore  said:

>conspicuously omits ATTACHes.  Is this significant?

No. Read the entire sentence, then read the description of TASKLIB in
ATTACH.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: STEPLIB problems - was: PDSE

[Binyamin Dissen]

On Thu, 26 Jan 2012 08:02:36 -0500 Peter Relson  wrote:

:>>However LIBDEF for ISPLLIB usually doesn't work because it does not 
:>>support the use of LINK, LOAD,  ATTACH or XCTL. 

:>I was given the following information some time ago by the ISPF team:

:>An ISPF application that needs their LINKs, LOADs, ATTACHes and XCTLs to 
:>search the ISPLLIB should be started via SELECT CMD(youprog) rather than 
:>SELECT PGM(yourprog).  With the CMD approach, the program runs with a 
:>TASKLIB of ISPLLIB and any LINKs, LOADs, and XCTLs done under that task 
:>will thus search ISPLLIB. 

There are two ISPLLIBs in this context. The DDNAME ISPLLIB when ISPF starts
and the LIBDEF ISPLLIB.

The DDNAME is always a TASKLIB and will be searched for LOAD, ATTACH, LINK,
etc.

The LIBDEF is NOT a TASKLIB unless SELECT CMD is used, and is then available
for LOAD, ATTACH, LINK, etc. If SELECT PGM is used, the only documented was to
determine the library is by using  QLIBDEF and building the DCB, etc. You can
use SELECT PGM to LINK to another program as well.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: STEPLIB problems - was: PDSE

[John Gilmore]

The 'youprog' instead of 'yourprog' in Peter Relson 's post is an
innocuous typo, but

| . . . any LINKs, LOADs, and XCTLs done under that task will
| thus search ISPLLIB.

conspicuously omits ATTACHes.  Is this significant?  I.e., is
ATTACHing subtasks unsupported or problematic?  I suspect not, but
explicit clarification would be helpful.

--jg

On 1/26/12, Peter Relson  wrote:
>>However LIBDEF for ISPLLIB usually doesn't work because it does not
>>support the use of LINK, LOAD,  ATTACH or XCTL.
>
> I was given the following information some time ago by the ISPF team:
>
> An ISPF application that needs their LINKs, LOADs, ATTACHes and XCTLs to
> search the ISPLLIB should be started via SELECT CMD(youprog) rather than
> SELECT PGM(yourprog).  With the CMD approach, the program runs with a
> TASKLIB of ISPLLIB and any LINKs, LOADs, and XCTLs done under that task
> will thus search ISPLLIB.
>
> Peter Relson
> z/OS Core Technology Design
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

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

Re: STEPLIB problems - was: PDSE

[Peter Relson]

>However LIBDEF for ISPLLIB usually doesn't work because it does not 
>support the use of LINK, LOAD,  ATTACH or XCTL. 

I was given the following information some time ago by the ISPF team:

An ISPF application that needs their LINKs, LOADs, ATTACHes and XCTLs to 
search the ISPLLIB should be started via SELECT CMD(youprog) rather than 
SELECT PGM(yourprog).  With the CMD approach, the program runs with a 
TASKLIB of ISPLLIB and any LINKs, LOADs, and XCTLs done under that task 
will thus search ISPLLIB. 
 
Peter Relson
z/OS Core Technology Design

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

Re: STEPLIB problems - was: PDSE

[Shmuel Metz (Seymour J.)]

In <8579683301631927.wa.markmzelden@bama.ua.edu>, on 01/25/2012
   at 07:36 AM, Mark Zelden  said:

>Most support ISPLLIB

The easy fix for those that don't is to include a TSOLIB in the
startup clist or rexx.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: STEPLIB problems - was: PDSE

[Shmuel Metz (Seymour J.)]

In
,
on 01/25/2012
   at 01:54 PM, "Schumacher, Otto"  said:

>We used a product that dynamically allocates the steplib in the tso
>logon proc.

Why not use TSOLIB?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: STEPLIB problems - was: PDSE

[Pinnacle]

On 1/25/2012 6:31 AM, Vernooij, CP - SPLXM wrote:

I see what you mean. What are 'dynamic steplib functions from outside IBM'? 
Some third party product?

Our TSO users select the 'environment' they like to work in, i.e. DEVL/PROD, 
DB2ID etc. and during logon we allocate to the different ISP* ddnames the 
libraries required for that envrionment. At least 'dynamic' during logon, not 
during the life of the session.

Kees.




Kees,

There is an excellent free Dynamic STEPLIB program on FILE452 available 
at www.cbttape.org.  It will give all the function you really require, 
and it's FREE!!


Regards,
Tom Conley

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

Re: STEPLIB problems - was: PDSE

[Mark Zelden]

On Wed, 25 Jan 2012 06:10:44 -0600, Barbara Nitz  wrote:

>>Our TSO users select the 'environment' they like to work in, i.e. DEVL/PROD, 
>>DB2ID etc. and during logon we allocate to the different ISP* ddnames the 
>>libraries required for that envrionment. At least 'dynamic' during logon, not 
>>during the life of the session.
>
>That only works if the ISPF application supports ISPLLIB (see the dynamic 
>steplib discussion). If ISPLLIB is not supported, then the needed library must 
>be in STEPLIB. I think there was also some mention of ALTLIB (which I never 
>fully grasped) and which basically means a new logon in most installations.
>

Most support ISPLLIB - as long as it is allocated prior to ISPF invocation.   
However,
LIBDEF for ISPLLIB usually doesn't work because it does not support the use
of LINK, LOAD,  ATTACH or XCTL.

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: INFO IBM-MAIN

Re: STEPLIB problems - was: PDSE

[Schumacher, Otto]

We used a product that dynamically allocates the steplib in the tso logon proc. 
 This allows us to do what the ispllib does for the products that require us to 
use the steplib in the logon proc.  We were able to go from 90 logon procs to 
3. We use the ispllib where possible as well as the ispmlib, ispplib, ispslib 
for those products that support these TSO services.

Regards
Otto Schumacher
 
HP Enterprise Services
Infrastructure Specialist
Ahold Account
CICS & Capacity Technical Support
Ahold Building 
1200 Brookfiled Blvd.
2S-034
Greenville,  South Carolina, 29607
Cell: 864 569--5338
Tel: 864 987-1417
Fax: provide upon request
E-mail: otto.schumac...@hp.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Thomas Berg
Sent: Wednesday, January 25, 2012 8:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: SV: STEPLIB problems - was: PDSE

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
> Shmuel Metz (Seymour J.)
> Skickat: den 25 januari 2012 14:22
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: STEPLIB problems - was: PDSE
> 
> In
> ,
> on 01/25/2012
>at 11:43 AM, Thomas Berg  said:
> 
> >This happens when You must use conflicting software or software
> >versions.
> 
> For that case, why can't you set it up from the READY prompt prior to
> going into ISPF?

Because I need to use both at the "same time" (in ISPF). 


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

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

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

Re: STEPLIB problems - was: PDSE

[Shmuel Metz (Seymour J.)]

In
,
on 01/25/2012
   at 11:43 AM, Thomas Berg  said:

>This happens when You must use conflicting software or software
>versions.

For that case, why can't you set it up from the READY prompt prior to
going into ISPF?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: STEPLIB problems - was: PDSE

[Shmuel Metz (Seymour J.)]

In <3439818781451184.wa.nitzibmgmx@bama.ua.edu>, on 01/25/2012
   at 06:10 AM, Barbara Nitz  said:

>That only works if the ISPF application supports ISPLLIB (see the
>dynamic steplib discussion). If ISPLLIB is not supported, then the
>needed library must be in STEPLIB.

That hasn't been true for decades. TSO does have a dynamic steplib,
it's just that the restrictions limit its usefulness. It should work
fine in the case under discussion.

>I think there was also some mention of ALTLIB

TSOLIB?

>and which basically means a new logon in most installations.

Why? Note that the context is setting things up at the beginning of
the TSO session, not changing them after you're in ISPF, which is
stickier.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: STEPLIB problems - was: PDSE

[Elardus Engelbrecht]

Thomas Berg wrote:

>There are cases when putting steplib(s) in linklist simply do not work! 

Please elaborate on those cases. Is it about mixing of APF and non-APF 
libraries? Or is it something else?


>And where the alternative of putting it in the logon procedures is working 
>nearly as bad.

Having a ***tested*** logon proc with the minimum libraries (Base TO/ISPF, SDSF 
and RACF) never ever hurts. ;-D


>I have several times seen those cases luckily (= allowed by management) been 
>solved by dynamic steplib functions from outside IBM.

Please tell me more about this dynamic steplib functions?


>This happens when You must use conflicting software or software versions.  One 
>such case was when we were upgrading DB2 and during that period was the 
>different test/development DB2 systems on different release levels. 

Groan... This is why I always insist to 'them' to have two set of procs and 
logon procs. One with 'old' things and another one with 'new' things. But no, 
no-one listens to me and rather howls like a poor rejected doggy when the jobs 
fail... ;-D

;-D

Groete / Greetings
Elardus Engelbrecht

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

Re: STEPLIB problems - was: PDSE

[Barbara Nitz]

>Our TSO users select the 'environment' they like to work in, i.e. DEVL/PROD, 
>DB2ID etc. and during logon we allocate to the different ISP* ddnames the 
>libraries required for that envrionment. At least 'dynamic' during logon, not 
>during the life of the session.

That only works if the ISPF application supports ISPLLIB (see the dynamic 
steplib discussion). If ISPLLIB is not supported, then the needed library must 
be in STEPLIB. I think there was also some mention of ALTLIB (which I never 
fully grasped) and which basically means a new logon in most installations.

Barbara

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

Re: STEPLIB problems - was: PDSE

[Don Poitras]

In article 
 you 
wrote:
> The original case by Juergen touches the main shortcoming of IBM's 
> STEPLIB-stance. 

> There are cases when putting steplib(s) in linklist simply do not work!  And 
> where the alternative of putting it in the logon procedures is working nearly 
> as bad.
> I have several times seen those cases luckily (= allowed by management) been 
> solved by dynamic steplib functions from outside IBM. 

> This happens when You must use conflicting software or software versions.  
> One such case was when we were upgrading DB2 and during that period was the 
> different test/development DB2 systems on different release levels.  Another 
> case was when we had different software (in the TSO development environments) 
> that relied on the same set of "SAS/C" modules for I/O and other things - but 
> of different releases of these modules.  (At least one of those SW was 
> IBM's.) And other cases. 

Did you try putting the then-current SAS/C release in linklist? If that didn't
work, you could have opened a problem report with SAS and we would have
tried to fix it. For the WSA (back when it was written in SAS/C), we actually
prefixed the library so that you could put two (or more) versions in
linklist without disrupting running programs.

> This experience coupled by some recent contacts with development labs at IBM 
> give me the impression that IBM lacks contact with "the reality" out here... 
> ;) 


> ?
> Regards, 
> Thomas Berg 
> _ 
> Thomas Berg?? Specialist?? A M?? SWEDBANK 

> > -Ursprungligt meddelande-
> > Fr?n: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] F?r
> > Juergen Keller
> > Skickat: den 25 januari 2012 09:51
> > Till: IBM-MAIN@bama.ua.edu
> > ?mne: Re: PDSE
> > 
> > Hello all,
> > thank you for your updates and hints. Lets bring the discussion to an end
> > ...
> > The "problem" started when we began to install z/OS 1.12 and my colleagues
> > did not want me to use dynamic steplib in the future (that was another
> > post some month ago). So we decided to bring this load library to LNKLST.
> > This worked fine for some weeks. No we wanted to install some maintenance
> > to this library and this did not work as expected. The library is PDSE and
> > from the posts I learned that we should not do what I wanted to do. So
> > finally we decided to remove it from LNKLST and define it as a STEPLIB to
> > the logon-procedure. That solves all the problems with lnklst and makes it
> > much more easier to install maintenance.

> 

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: STEPLIB problems - was: PDSE

[Vernooij, CP - SPLXM]

I see what you mean. What are 'dynamic steplib functions from outside IBM'? 
Some third party product?

Our TSO users select the 'environment' they like to work in, i.e. DEVL/PROD, 
DB2ID etc. and during logon we allocate to the different ISP* ddnames the 
libraries required for that envrionment. At least 'dynamic' during logon, not 
during the life of the session.

Kees.

"Thomas Berg"  wrote in message 
news:...
> The original case by Juergen touches the main shortcoming of IBM's 
> STEPLIB-stance. 
> 
> There are cases when putting steplib(s) in linklist simply do not work!  And 
> where the alternative of putting it in the logon procedures is working nearly 
> as bad.
> I have several times seen those cases luckily (= allowed by management) been 
> solved by dynamic steplib functions from outside IBM. 
> 
> This happens when You must use conflicting software or software versions.  
> One such case was when we were upgrading DB2 and during that period was the 
> different test/development DB2 systems on different release levels.  Another 
> case was when we had different software (in the TSO development environments) 
> that relied on the same set of "SAS/C" modules for I/O and other things - but 
> of different releases of these modules.  (At least one of those SW was 
> IBM's.) And other cases. 
> 
> This experience coupled by some recent contacts with development labs at IBM 
> give me the impression that IBM lacks contact with "the reality" out here... 
> ;) 
> 
> 
>  
> Regards, 
> Thomas Berg 
> _ 
> Thomas Berg   Specialist   A M   SWEDBANK 
> 
> > -Ursprungligt meddelande-
> > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
> > Juergen Keller
> > Skickat: den 25 januari 2012 09:51
> > Till: IBM-MAIN@bama.ua.edu
> > Ämne: Re: PDSE
> > 
> > Hello all,
> > thank you for your updates and hints. Lets bring the discussion to an end
> > ...
> > The "problem" started when we began to install z/OS 1.12 and my colleagues
> > did not want me to use dynamic steplib in the future (that was another
> > post some month ago). So we decided to bring this load library to LNKLST.
> > This worked fine for some weeks. No we wanted to install some maintenance
> > to this library and this did not work as expected. The library is PDSE and
> > from the posts I learned that we should not do what I wanted to do. So
> > finally we decided to remove it from LNKLST and define it as a STEPLIB to
> > the logon-procedure. That solves all the problems with lnklst and makes it
> > much more easier to install maintenance.
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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