Re: Rexx compiler runtime question

[Ed Gould]

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 more usermods  
required.  No more assemble-and-bind application-level options  
modules required.


This sort of thing is beyond ServerPac Development's control. Some  
things have to be done at the product level, and this is one of them.




John,

Yes I did miss that (as someone else said). Is there a STC that reads  
it abd updates a CB or does MVS do this?


Ed

--
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

Re: Rexx compiler runtime question

[John Eells]

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 application-level options 
modules required.


This sort of thing is beyond ServerPac Development's control. 
Some things have to be done at the product level, and this is one 
of them.


Ed Gould wrote:


SKIP,

JUST MAYBE ONE OF THESE DAYS THE LE PEOPLE WILL (sorry about the  caps) 
get their act together. Meanwhile this is a good example of IBM  not 
setting a product up that so you MUST have a usermod.


They have added/changed/deleted options at least 6-8 times (that I  can 
remember of). I thought that the SERVPAC concept was to get rid  (or at 
least miniumize) these usermods. Who know the SERVPAC might  have enough 
pull to stop this insanity.






--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]

--
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

Re: Rexx compiler runtime question

[Charles Mills]

The customer is apparently going to try that but is/was resistant to MLPA
for some reason. "Maintenance headache" or some such. I'm not a sysprog, and
I'm not the customer, so my ability to argue this position is limited.

Charles

-Original Message-
From: IBM Mainframe 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:

>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
>paragraph).

What happens if the customer loads the correct IRXCMPTM into MLPA?
 

--
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

Re: Rexx compiler runtime question

[Shmuel Metz (Seymour J.)]

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
>paragraph).

What happens if the customer loads the correct IRXCMPTM into MLPA?
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Rexx compiler runtime question

[Jim Mulder]

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 specifically included in the LNKLST search order.
> :>I've never seen any shop not put it as high up as they can,
> :>but it is not a requirement.
> 
> I thought with LLA hashing, that if there are identical names in 
different
> linklist libraries that it was unpredictable which one would be used.

  That is not correct.  The LNKLST search order is preserved by LLA. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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

Re: Rexx compiler runtime question

[Ed Gould]

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.com/epubs/pdf/e0z2n160.pdf

Best Regards,

Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office)  301.986.3574

===SNIP___

Sam,

Thanks.. That is good information.

Ed

--
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

Re: Rexx compiler runtime question

[Mark Zelden]

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've been at too many shops with "junk libraries" containing old
modules at or near the bottom of the LNKLST and the LNKLST is
automatically controlled by LLA.  I've also fixed problems via
dynamic LNKLST addition by putting a new library ahead of another
library that contained identically named modules.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html


 "Programming is like sex. One mistake and you have to support it
  for the rest of your life."   -   Michael Sinz

--
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

Re: Rexx compiler runtime question

[Binyamin Dissen]

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 put it as high up as they can,
:>but it is not a requirement.

I thought with LLA hashing, that if there are identical names in different
linklist libraries that it was unpredictable which one would be used.

--
Binyamin Dissen <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Rexx compiler runtime question

[Mark Zelden]

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 module or component when
os releases change, but I'm not sure how that is relelvent to this
discussion.

>
>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.
>

Your shop, your call.  I'm surprised you maintain something like SDSF
parms with a usermod (or do you use the assembled version still)?  We
still don't use RACF for SDSF security, so the parms get modified
fairly often.   I've tried to eliminate usermods wherever possible
to make installing new serverpacs easier.  LE options via parmlib
in z/OS 1.7 will mean a few less usermods.   PARMLIB members get
carried across from release to release so there is no danger of
regression.  It sounds like you would want to still maintain the
LE options vis usermod even though there is a parmlib alternative.

Another example of a usermod I eliminated was DFSORT ICEGENER customization.
Several of  our environments used the default options except for the
IEBGENER (OLDGENER) name.   Sometime in OS/390 (2.8?) IBM created an
alias of IEBGENR to IEBGENER in SYS1.LINKLIB. Now the only customization
required is to put SYS1.SORTLPA in the LPA list which replaces the
IEBGENER in SYS1.LINKLIB since the default "oldgener" name is IEBGENR.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
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

Re: Rexx compiler runtime question

[Knutson, Sam]

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,

Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office)  301.986.3574

I always avoid prophesying beforehand, because it is a much better
policy to prophesy after the event has already taken place. - Sir
Winston Leonard Spencer Churchill


-Original Message-
SKIP,

JUST MAYBE ONE OF THESE DAYS THE LE PEOPLE WILL (sorry about the
caps) get their act together. Meanwhile this is a good example of IBM
not setting a product up that so you MUST have a usermod.

They have added/changed/deleted options at least 6-8 times (that I can
remember of). I thought that the SERVPAC concept was to get rid (or at
least miniumize) these usermods. Who know the SERVPAC might have enough
pull to stop this insanity.

Ed
  
<>

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
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

Re: Rexx compiler runtime question

[Ed Gould]

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---


SKIP,

JUST MAYBE ONE OF THESE DAYS THE LE PEOPLE WILL (sorry about the  
caps) get their act together. Meanwhile this is a good example of IBM  
not setting a product up that so you MUST have a usermod.


They have added/changed/deleted options at least 6-8 times (that I  
can remember of). I thought that the SERVPAC concept was to get rid  
(or at least miniumize) these usermods. Who know the SERVPAC might  
have enough pull to stop this insanity.


Ed
 


--
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

Re: Rexx compiler runtime question

[Skip Robinson]

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 member into
MOD/LMOD elements. That way if the SAMPLIB member gets updated, then we
find out immediately.

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.

.
.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]

IBM Mainframe Discussion List  wrote on 11/04/2005
02:17:58 PM:

> 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 http://www.novaspace.com/AUTO/Giclee.html is in LPALSTxx.
>
> >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.
>
> Agree that modifications should be done with SMP/E usermods. But in
> this case, there is no modication - just a parmlib member.  It's
> simply a preference to have one less usermod as opposed to "the
> right way".  Not much different than using any PARMLIB member that
> replaces assembled options. For example, SDSF parms, LE parms in
> z/OS 1.7, etc.
>
> Regards,
>
> Mark

--
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

Re: Rexx compiler runtime question

[Mark Zelden]

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 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.

Agree that modifications should be done with SMP/E usermods. But in
this case, there is no modication - just a parmlib member.  It's
simply a preference to have one less usermod as opposed to "the
right way".  Not much different than using any PARMLIB member that
replaces assembled options. For example, SDSF parms, LE parms in
z/OS 1.7, etc.

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
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

Re: Rexx compiler runtime question

[Skip Robinson]

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
usermods for everything from ISPF panels to system exits. Once you've the
constructed the usermods, they're easy to maintain. You also have the
incomparable of advantage of learning--via SMPE conflict messages--when
something you've tailored is getting updated by IBM PTF, so you can go back
and revisit/rework your usermod.

.
.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]

IBM Mainframe Discussion List  wrote on 11/04/2005
11:20:52 AM:

> 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 alternate library, you have to get the one from
> SEAGALT ahead of the one in SYS1.LINKLIB in the search order.
>
> Putting SEAGALT in STEPLIB does that, but the customer does not want to
do
> that.
>
> 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.)
>
> 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 paragraph).
>
> Any one of you experts who would like to straighten out my confusion,
your
> assistance is welcome.

--
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

Re: Rexx compiler runtime question

[Mark Zelden]

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 SYS1.LINKLIB is part of).

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 put it as high up as they can,
but it is not a requirement.

As far as search order in general... can't say it better than
the expert:

http://bama.ua.edu/cgi-bin/wa?A2=ind9809&L=ibm-main&O=D&F=&S=&P=142568

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
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

Re: Rexx compiler runtime question

[Charles Mills]

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 alternate library, you have to get the one from
SEAGALT ahead of the one in SYS1.LINKLIB in the search order.

Putting SEAGALT in STEPLIB does that, but the customer does not want to do
that.

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.)

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 paragraph).

Any one of you experts who would like to straighten out my confusion, your
assistance is welcome.

Charles

--
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

Re: Rexx compiler runtime question

[Brian Peterson]

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 did you do with the default IRXCMPTM in SYS1.LINKLIB provided by
>TSO/E?
>>
>>Brian
>>
>
>Nothing.  LPA is searched before the LNKLST.
>
>Mark

--
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

Re: Rexx compiler runtime question

[Mark Zelden]

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 America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
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

Re: Rexx compiler runtime question

[Brian Peterson]

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
>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
>

--
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

Re: Rexx compiler runtime question

[Mark Zelden]

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 Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html




On Fri, 4 Nov 2005 11:19:34 -0600, Brian Peterson
<[EMAIL PROTECTED]> wrote:

>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
>
>On Fri, 4 Nov 2005 11:51:47 -0500, Charles Mills <[EMAIL PROTECTED]> wrote:
>
>>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
>>perfectly correctly. Questions:
>>
>>- Does what he is reporting seem right? Is it possible to get the EAGRTPRC
>>error if SEAGALT has been added properly to the LPA? Should he be looking
>>for some sort of failure to do his SMP/E stuff correctly in adding SEAGALT
>>to the LPA?
>>
>>- Is the Compiler Programming Table (CPT) IRXCMPTM relevant to NON-TSO
>BATCH
>>compiled Rexx, or only to Rexx programs running in a TSO environment?
>>
>>It's a customer system and I do not have access to it except through the
>>customer contact.
>>
>>Yes, I've RTFM and searched the archives.
>>
>>Thanks for your help,
>>Charles
>
>--
>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

--
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

Re: Rexx compiler runtime question

[Brian Peterson]

Then the customer must complete the installation instructions for making
the Rexx Compiler available on his system.  Specifically, he must update
IRXCMTPM in SYS1.LINKLIB to reflect the fact that the Rexx Compiler is
installed.

By STEPLIBing to xxx.SEAGALT, the customer would pick up the copy of
IRXCMPTM provided in that data set before the default one found in
SYS1.LINKLIB.  However, since the customer does not wish to STEPLIB to
xxx.SEAGALT, then they must update the version of IRXCMPTM in SYS1.LINKLIB.

One explanation for this process is in APAR PK02480 under heading
"6. Install the Compiler Programming Table (CPT)".  Another is presumably
in the installation documentation for the Rexx Compiler.

A generic version of this procedure is also found in TSO/E Customization,
topic 7.1.3  The Compiler Programming Table, which contains the following
text:

"The IRXCMPTM module that TSO/E provides in LINKLIB contains no entries,
which indicates to TSO/E that a compiler runtime processor is not
installed.  TSO/E provides source for a sample compiler programming table
in SYS1.SAMPLIB member IRXREXX4. IRXREXX4 is not intended to be used as
shipped in SYS1.SAMPLIB. Refer to your compiler's installation
documentation for the requirements for the IRXCMPTM module."

Brian

On Fri, 4 Nov 2005 12:45:22 -0500, Charles Mills <[EMAIL PROTECTED]> wrote:

>Thanks. The customer says its impractical for him to STEPLIB to SEAGALT
>(lots of jobs to modify) and he would like it linklisted or in the LPA or
>something like that which would not require a JOBLIB or STEPLIB. We vendors
>like to avoid arguing with the customer :-)
>
>Charles
>
>
>-Original Message-
>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 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.

--
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

Re: Rexx compiler runtime question

[Charles Mills]

Thanks. The customer says its impractical for him to STEPLIB to SEAGALT
(lots of jobs to modify) and he would like it linklisted or in the LPA or
something like that which would not require a JOBLIB or STEPLIB. We vendors
like to avoid arguing with the customer :-)

Charles


-Original Message-
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 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.

--
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

Re: Rexx compiler runtime question

[Brian Peterson]

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

On Fri, 4 Nov 2005 11:51:47 -0500, Charles Mills <[EMAIL PROTECTED]> wrote:

>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
>perfectly correctly. Questions:
>
>- Does what he is reporting seem right? Is it possible to get the EAGRTPRC
>error if SEAGALT has been added properly to the LPA? Should he be looking
>for some sort of failure to do his SMP/E stuff correctly in adding SEAGALT
>to the LPA?
>
>- Is the Compiler Programming Table (CPT) IRXCMPTM relevant to NON-TSO
BATCH
>compiled Rexx, or only to Rexx programs running in a TSO environment?
>
>It's a customer system and I do not have access to it except through the
>customer contact.
>
>Yes, I've RTFM and searched the archives.
>
>Thanks for your help,
>Charles

--
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