In <[EMAIL PROTECTED]>, on 10/11/2006
   at 03:38 PM, Charles Mills <[EMAIL PROTECTED]> said:

>I would like to be able to cause a load module executed with a CALL
>statement in TSO to "find" (with LINK or LOAD - don't know, it's not
>my code) a load module that is in a private load library. **Other
>than allocating the library at LOGON time, which my sysprog does not
>want to do for some private reason,

What gives you that idea? Perhaps from his perspective you are asking
him to do imprudent things for some private reason, perhaps even
things that he is prohibited from doing. Instead of casting aspersions
on his motives, it would be more productive to discuss your
requirements[1] with him. If you talk to him the way you talk about
him, he might be reluctant to help you more than he is required[2] to,
so I'd advise you to lose that chip.

>- I've tried TSOLIB and that does not seem to work. My reading of
>the manual is that TSO searches TSOLIB (presumably via DCB= on its
>LOADs) but subsequent LOADs from within the TSO command do not - is
>that correct?

No.

>- I saw a reference in the TSO commands manual to TASKLIB. At the
>risk of seeming ignorant, I have to say I am not familiar with
>TASKLIB.

Do you have access to the a/OS manuals on disk? Did you search them
for TASKLIB?


>I tried ALLOC FI(TASKLIB) DA('private.library') 

Why?

>- TSO seems not to let you do an ALLOC FI(STEPLIB).

It's not TSO that's stopping you, it's MVS.

>The documentation is pretty weak. Says "see the JCL manual" which 
>of course has little or nothing to do with the inside of the TSO 
>environment.

There is no "of course". When you log on, TSO submits a job calling
your logon proc and the system processes it essentially like a batch
job, including interpreting the JCL. The rules for STEPLIB have
nothing to do with TSO and apply equally well to batch jobs.

"It's not what you don't know that hurts you, it's what you know that
ain't so."

[1] Not your proposed solution.

[2] Some shops have rules about things that the SP is not supposed
    to do. Often there is some leeway. If you offend him, he will play
    it safe rather than approaching the edge to help you.
 
-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to