Paul Gilmartin wrote:
In a recent note, Tony Harminc said:
Date: Tue, 14 Nov 2006 18:25:40 -0500
On Thu 9 November, 2006 Paul Gilmartin wrote:
Ugh. How do you package a LMOD in a PTF? Inline with GIMDTS? (Doesn't
work.) Better with FROMNETWORK, which is relfile-friendly, even
In a recent note, John Eells said:
Date: Wed, 15 Nov 2006 08:35:43 -0500
From the SMP/E Reference:
The ++PROGRAM MCS describes a program element (a pre-built load
module or a program object).
I had forgotten about that; thanks. (I tend to forget things I
don't regularly use.)
On Mon, 13 Nov 2006 11:21:22 -0500, Shmuel Metz (Seymour J.) shmuel+ibm-
[EMAIL PROTECTED] wrote:
... So I changed all RELFILE references to TXLIB references,
added TXLIB DD statements to the APPLY JCL, and proceeded with the
RECEIVE and APPLY.
...
Why? If you had already done a RECEIVE then
On Thu 9 November, 2006 Paul Gilmartin wrote:
Ugh. How do you package a LMOD in a PTF? Inline with GIMDTS? (Doesn't
work.) Better with FROMNETWORK, which is relfile-friendly, even in
PTFs. (I know; it's theoretically possible to RELFILE-package a PTF,
but customers don't expect it.)
I'm
In a recent note, Tony Harminc said:
Date: Tue, 14 Nov 2006 18:25:40 -0500
On Thu 9 November, 2006 Paul Gilmartin wrote:
Ugh. How do you package a LMOD in a PTF? Inline with GIMDTS? (Doesn't
work.) Better with FROMNETWORK, which is relfile-friendly, even in
PTFs. (I know;
Seems to me that ++PROGRAM relieves at least some of these limitations.
Brian
On Tue, 14 Nov 2006 17:58:02 -0700, Paul Gilmartin wrote:
IIRC (it's fuzzy; subject to verification) several things:
o LMOD is not a deliverable element type.
o GIMDTS is permitted only for data elements; not for
In [EMAIL PROTECTED], on 11/09/2006
at 12:00 PM, Patrick O'Keefe [EMAIL PROTECTED] said:
Ok. No tapes, but all the MCS statements were in the system PTS,
all the RELFILE files had built their PDSs, etc. All the data was
there. So I changed all RELFILE references to TXLIB references,
added
(Seymour J.)
Sent: Monday, November 13, 2006 11:21 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: SMP/E - module attributes issue
In [EMAIL PROTECTED], on 11/09/2006
at 12:00 PM, Patrick O'Keefe [EMAIL PROTECTED] said:
Ok. No tapes, but all the MCS statements were in the system PTS,
all
There must be some sort of subtle difference between object modules located
in RELFILEs versus object modules located in TXLIBs.
Brian is onto it here. For MODs, packaging using TXLIB and inline (as
in a typical PTF) tells SMP/E the module is supplied as an object deck
that requires a link
On Fri, 10 Nov 2006 09:50:07 -0500, Kurt Quackenbush [EMAIL PROTECTED]
wrote:
... For MODs, packaging using TXLIB and inline (as
in a typical PTF) tells SMP/E the module is supplied as an object deck
that requires a link edit operation. SMP/E doesn't analyze the TXLIB,
so it makes no
On Fri, 2006-11-10 at 10:36 -0600, Patrick O'Keefe wrote:
I'm toast. I either start
over from scratch or wait for the newly reordered product tapes.
Or I can do a massive UCLIN to change the TXLIB to LKLIB on all MOD
elements in those linklibs. Than sounds like an enjoyable task. :-)
Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
Re: SMP/E - module attributes issue
On Fri, 10 Nov 2006 09:50:07 -0500, Kurt Quackenbush [EMAIL PROTECTED]
wrote:
... For MODs, packaging using TXLIB and inline (as
in a typical PTF) tells SMP/E the module
Nope. The starting point for this little adventure was FMIDs RECEIVEd but
not applied or accepted.
Bria
On Sat, 11 Nov 2006 02:41:07 +1000, Shane [EMAIL PROTECTED] wrote:
On Fri, 2006-11-10 at 10:36 -0600, Patrick O'Keefe wrote:
I'm toast. I either start
over from scratch or wait for the
On Fri, 10 Nov 2006 10:53:43 -0600, Brian Peterson
[EMAIL PROTECTED] wrote:
Nope. The starting point for this little adventure was FMIDs RECEIVEd but
...
BUILDMCS ???.
...
Actually, I could do a BUILDMCS now and see what I get, but since I had
the wrong thing (TXLIB instead of LKLIB) on the
On Fri, 10 Nov 2006 11:12:23 -0600, Patrick O'Keefe
[EMAIL PROTECTED] wrote:
On Fri, 10 Nov 2006 10:53:43 -0600, Brian Peterson
[EMAIL PROTECTED] wrote:
Nope. The starting point for this little adventure was FMIDs RECEIVEd but
...
BUILDMCS ???.
...
Actually, I could do a BUILDMCS now and see
I think I may have abused SMP and it has retaliated. Help would be
appreciated.
7 or 8 months ago our MVS team received a new release of NetView into our
main MVS SMP environment. They then decided they were too busy to do
anything with it. Last week I was givin permission to do the install
Talk about doing things the hard way!! Here's some ideas you might
consider. You probably already thought of them - if so, sorry!
1) Order a new copy of the product. Perform your own RECEIVE from the
original copy of the product. This is the start from scratch option.
2) Define new
On Thu, 9 Nov 2006 12:24:22 -0600, Brian Peterson
[EMAIL PROTECTED] wrote:
Talk about doing things the hard way!! Here's some ideas you might
consider. You probably already thought of them - if so, sorry!
...
One person's hard is another's fun. I haven't had a hands-on fight
with SMP for
In a recent note, Patrick O'Keefe said:
Date: Thu, 9 Nov 2006 16:30:46 -0600
2) Define new Target and DLIB SMP/E CSI and Target and DLIB data sets.
Attach this new, empty, Target and DLIB zone to the Global zone which has
the product RECEIVEd into. ...
Religious and political.
I admire your determination! Keep it up - that's what keeps all of us
young at heart!
As far as why you're getting a link edit operation doing things Pat's
way, I suspect the answer has to do with the complex process SMP/E uses to
build load modules - a process which has been enhanced over
On Thu, 9 Nov 2006 17:00:53 -0600, Brian Peterson
[EMAIL PROTECTED] wrote:
... Also, the way I think about JCLIN is that JCLIN describes a
product's *structure*, it does NOT describe a product's installation
process.
...
In general, you're right, but SMP processes JCLIN for link steps to get
On Thu, 9 Nov 2006 15:48:00 -0700, Paul Gilmartin
[EMAIL PROTECTED] wrote:
...
//
//** MVS utility IEBCOPY will be used to COPY these two LMODs **
//** from the installation tape into a Target Library.
In a recent note, Patrick O'Keefe said:
Date: Thu, 9 Nov 2006 17:58:04 -0600
I wonder how the Creator built them.
I wonder what happens if they ever need service.
I bet there's an interesting story there that will probably stay untold.
Obviously, someone linked it once. And
23 matches
Mail list logo
