I've got a customer getting IRX0159E The run time processor EAGRTPRC is not
available for a compiled program running in NON-TSO BATCH. He says that
hlq.xxx.SEAGALT has been added to the LPA. I'm a development guy, not an
ops/sysprog guy, so please forgive me if these questions are not phrased
perfe
My theory is that you should STEPLIB to xxx.SEAGALT. This is based upon
reading TSO/E Customization, as well as IBMLink entries for MSGIRX0159E,
and my observation that xxx.SEAGALT ships with its own version of IRXCMPTM -
presumably customized to tell TSO/E REXX to call the Rexx compiler.
Brian
-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Brian Peterson
Sent: Friday, November 04, 2005 12:20 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Rexx compiler runtime question
My theory is that you should STEPLIB to xxx.SEAGALT. This is based upon
reading TSO/E
On Behalf
>Of Brian Peterson
>Sent: Friday, November 04, 2005 12:20 PM
>To: IBM-MAIN@BAMA.UA.EDU
>Subject: Re: Rexx compiler runtime question
>
>
>My theory is that you should STEPLIB to xxx.SEAGALT. This is based upon
>reading TSO/E Customization, as well as IBMLink entrie
So what will STEPLIBing do if SEAGALT is (correctly) in LPA and it
doesn't work? Perhaps there is another IRXCMPTM being used via
STEPLIB that isn't the one from SEAGALT.
BTW, SEAGALT is in the LPA for us because of ISV product(s) that need
the customized IRXCMPTM that is supplied.
Mark
--
Mark
What did you do with the default IRXCMPTM in SYS1.LINKLIB provided by TSO/E?
Brian
On Fri, 4 Nov 2005 13:03:07 -0600, Mark Zelden <[EMAIL PROTECTED]>
wrote:
>So what will STEPLIBing do if SEAGALT is (correctly) in LPA and it
>doesn't work? Perhaps there is another IRXCMPTM being used via
>STEPL
On Fri, 4 Nov 2005 13:04:34 -0600, Brian Peterson
<[EMAIL PROTECTED]> wrote:
>What did you do with the default IRXCMPTM in SYS1.LINKLIB provided by
TSO/E?
>
>Brian
>
Nothing. LPA is searched before the LNKLST.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North
This just goes to show the dangers of my trying to comment on something I
really don't know anything about. Lesson learned
Brian
On Fri, 4 Nov 2005 13:10:57 -0600, Mark Zelden <[EMAIL PROTECTED]>
wrote:
>On Fri, 4 Nov 2005 13:04:34 -0600, Brian Peterson
><[EMAIL PROTECTED]> wrote:
>
>>What
The customer does not license the compiler. So there is no matter of
installing the compiler. This is all about the alternate library. He has it
installed, but apparently in the wrong place.
I think I am starting to understand this. IBM supplies a "null" IRXCMPTM in
SYS1.LINKLIB. To use the altern
On Fri, 4 Nov 2005 14:20:52 -0500, Charles Mills <[EMAIL PROTECTED]> wrote:
>
>I guess the LPA is searched ahead of SYS1.LINKLIB but the LinkList is not?
>Or is it the other way around? (Again, forgive my confusion, I don't
pretend
>to be a sysprog.)
>
LPA before SYS1.LINKLIB (and LNKLST which S
I don't like to depend on the coincidental search order of libraries that
IBM supplies. We modify IRXCMPTM with an SMPE usermod. It goes on each new
release with some simple MCS updates. The module goes into SYS1.LINKLIB.
BTW This is the right way to handle lots of customization. We have 70 - 80
u
On Fri, 4 Nov 2005 13:34:16 -0800, Skip Robinson <[EMAIL PROTECTED]>
wrote:
>I don't like to depend on the coincidental search order of libraries that
>IBM supplies.
This isn't coincidental, it is planned. The order doesn't matter as
long as SEAGALT is in LPALSTxx.
>We modify IRXCMPTM with an SM
I say 'coincidental' because load module components can move from release
to release. IBM might decide, for example, to put something into
SYS1.LPALIB for performance.
As for whether a usermod is a true 'modification', that's a matter of
terminology. We have several 'mods' that just turn a SAMPLIB
On Nov 4, 2005, at 7:35 PM, Skip Robinson wrote:
As for the other examples (SDSF parms, LE parms), we install those
with
SMPE usermods also. Quick and dirty is high on speed, low on hygiene.
Cleaner may mean quicker down the long road.
.SNIP
Look at the documentation for PARMLIB CEEPRMxx, CEE= in IEASYSxx, SET
CEE= in z/OS R7. You can now have your LE options stored in PARMLIB.
There was a nice summary on the back page of the last Hot Topics
newsletter.
http://publibz.boulder.ibm.com/epubs/pdf/e0z2n160.pdf
Best Regards,
On Fri, 4 Nov 2005 17:35:37 -0800, Skip Robinson <[EMAIL PROTECTED]>
wrote:
>I say 'coincidental' because load module components can move from release
>to release. IBM might decide, for example, to put something into
>SYS1.LPALIB for performance.
>
I guess you could have that issue with any modul
On Fri, 4 Nov 2005 13:32:54 -0600 Mark Zelden <[EMAIL PROTECTED]>
wrote:
:>SYS1.LINKLIB is at the top of the LNKLST unless replaced by a
:>site library (VIA SYSLIB LINKLIB statement in PROGxx) and then
:>it must be specifically included in the LNKLST search order.
:>I've never seen any shop not pu
On Sat, 5 Nov 2005 19:32:27 +0200, Binyamin Dissen
<[EMAIL PROTECTED]> wrote:
>
>I thought with LLA hashing, that if there are identical names in different
>linklist libraries that it was unpredictable which one would be used.
>
I've never heard that before and I don't see how it can be true.
I'v
On Nov 5, 2005, at 4:54 AM, Knutson, Sam wrote:
Look at the documentation for PARMLIB CEEPRMxx, CEE= in IEASYSxx, SET
CEE= in z/OS R7. You can now have your LE options stored in PARMLIB.
There was a nice summary on the back page of the last Hot Topics
newsletter.
http://publibz.boulder.ibm.co
IBM Mainframe Discussion List wrote on 11/05/2005
12:32:27 PM:
> On Fri, 4 Nov 2005 13:32:54 -0600 Mark Zelden <[EMAIL PROTECTED]>
> wrote:
>
> :>SYS1.LINKLIB is at the top of the LNKLST unless replaced by a
> :>site library (VIA SYSLIB LINKLIB statement in PROGxx) and then
> :>it must be speci
In <[EMAIL PROTECTED]>, on 11/04/2005
at 02:20 PM, Charles Mills <[EMAIL PROTECTED]> said:
>The problem appears to be that the customer's job is finding the
>original IRXCMPTM in SYS1.LINKLIB rather than the alias for the one
>in SEAGALT because it's in the wrong library or list (see previous
>
rame Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Sunday, November 06, 2005 12:27 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Rexx compiler runtime question
In <[EMAIL PROTECTED]>, on 11/04/2005
at 02:20 PM, Charles Mills <[EMAIL PROTECTED]> said:
Perhaps you haven't been paying attention. You can put all the
system-wide Language Environment run-time options in parmlib
effective with z/OS R7, and the application run-time options in a
data set or file pointed to by a DD statement. No more usermods
required. No more assemble-and-bind ap
On Nov 7, 2005, at 7:34 AM, John Eells wrote:
Perhaps you haven't been paying attention. You can put all the
system-wide Language Environment run-time options in parmlib
effective with z/OS R7, and the application run-time options in a
data set or file pointed to by a DD statement. No mor
24 matches
Mail list logo
