home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!usc!snorkelwacker.mit.edu!hri.com!noc.near.net!ns.draper.com!news.draper.com!MVS.draper.com!SEB1525
- From: SEB1525@MVS.draper.com (Steve Bacher)
- Newsgroups: bit.listserv.ibm-main
- Subject: Re: ispf program lib search order?
- Message-ID: <19920819080535SEB1525@MVS.draper.com>
- Date: 19 Aug 92 13:05:00 GMT
- References: <IBM-MAIN%92081808453852@RICEVM1.RICE.EDU>
- Sender: MVS NNTP News Reader <NNMVS@MVS.draper.com>
- Organization: Draper Laboratory
- Lines: 26
- Nntp-Posting-Host: mvs.draper.com
-
- In article <IBM-MAIN%92081808453852@RICEVM1.RICE.EDU>,
- "BJ VanDewater" <bjvande@VNET.IBM.COM> writes:
-
- > If you are using ISPF services, such as SELECT PGM(xxxx), ISPLLIB
- >will be searched before STEPLIB. If you are using MVS services, such
- >as LINK, I believe that ISPLLIB is ignored.
-
- Not quite. Anything run under ISPF gets ISPLLIB (if it is allocated)
- as a task library. This means that MVS program fetch (LINK, LOAD,
- XCTL, ATTACH) will find stuff that's in ISPLLIB.
-
- HOWEVER... if the LIBDEF service is used to hook up an additional
- load library, this is seen only by ISPF services and is invisible
- to MVS program fetch. SHARE has pestered IBM to do something to
- get around this, and I think they've been doing something in this
- area, though I don't know any details.
-
- Also, the LPA is normally searched as part of the normal MVS search
- sequence - after tasklib/STEPLIB but before linklist - but in some of
- the environments mentioned above, this might not be done or might be
- done in a different order from how MVS program fetch does it. That
- could vary depending on your maintenance level of REXX or ISPF.
-
- --
- Steve Bacher (Batchman) Draper Laboratory
- Internet: seb@draper.com Cambridge, MA, USA
-