All:
I need some help with SMP/E. I need to convert our software to use SMP/E. I
am not a SMP/E heavy. I have the following;
1. Linklib
2. Proclib
3. Parmlib
4. JCLLIB ( for install ) , this can be removed , because SMP/E will do it
5. Rexx Clistlib
I need a how to build a complete package and t
-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Scott Ford
Sent: Thursday, September 10, 2015 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMP/E Help
All:
I need some help with SMP/E. I need to convert our software to use SMP/E. I
am not a SMP/E heavy.
f Of Scott Ford
> Sent: Thursday, September 10, 2015 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMP/E Help
>
> All:
>
> I need some help with SMP/E. I need to convert our software to use SMP/E. I
> am not a SMP/E heavy. I have the following;
>
> 1. Linklib
>
On Thu, 10 Sep 2015 15:55:52 -0400, Scott Ford wrote:
>Rex,
>
>That's where I though about starting on my SMP/ E adventure, thanks my
>friend..
>
>On Thursday, September 10, 2015, Pommier, Rex wrote:
>
>> I know nothing about how to package items for SMP/E, but there is a book
>> in the SMP/E book
: SMP/E Help
Scott,
I know nothing about how to package items for SMP/E, but there is a book in the
SMP/E bookshelf called "Standard Packaging Rules for z/OS-Based Products" that
looks like it might give you what you need to know. 1.13 number is
SC
On 2015-09-10 12:13, Scott Ford wrote:
> All:
>
> I need some help with SMP/E. I need to convert our software to use SMP/E. I
> am not a SMP/E heavy. I have the following;
>
> 1. Linklib
> 2. Proclib
> 3. Parmlib
> 4. JCLLIB ( for install ) , this can be removed , because SMP/E will do it
> 5. R
In
,
on 09/10/2015
at 02:13 PM, Scott Ford said:
>I need to convert our software to use SMP/E.
Why? Unless you're going to package in a way that exploits SMP, you'll
just be putting lipstick on a pig.
>Does anyone have any suggests
Don't ship monolithic load modules or program objects; ship
I notice that you cp "//'SYS1.SAMPLIB(GIMSAMPU)'" /dev/fd/1 and then
pipe into sed as opposed to using cat. Is that because in the past cat
did not support MVS data sets?
On 11/09/2015 8:18 AM, Paul Gilmartin wrote:
On 2015-09-10 12:13, Scott Ford wrote:
All:
I need some help with SMP/E. I
> Why?
Because some customers demand it.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Thursday, September 10, 2015 7:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help
In
,
on 09
On Fri, 11 Sep 2015 11:22:25 +0800, David Crayford wrote:
>I notice that you cp "//'SYS1.SAMPLIB(GIMSAMPU)'" /dev/fd/1 and then
>pipe into sed as opposed to using cat. Is that because in the past cat
>did not support MVS data sets?
>
No, I'm using sed to tailor; replacing the substitutable symbols
On 11/09/2015 2:04 PM, Paul Gilmartin wrote:
On Fri, 11 Sep 2015 11:22:25 +0800, David Crayford wrote:
I notice that you cp "//'SYS1.SAMPLIB(GIMSAMPU)'" /dev/fd/1 and then
pipe into sed as opposed to using cat. Is that because in the past cat
did not support MVS data sets?
No, I'm using sed t
On Fri, 11 Sep 2015 14:57:44 +0800, David Crayford wrote:
>>>
>> No, I'm using sed to tailor; replacing the substitutable symbols in GIMSAMPU.
>
>Yes, I understand that. But wouldn't cat "//'SYS1.SAMPLIB(GIMSAMPU)'" |
>sed have worked?
>
I believe "cat" is absent from the few utilities listed in t
I need some help with SMP/E. I need to convert our software to use SMP/E.
I need a how to build a complete package and then how do I install it. I
want to use GIMZIP, I think this should work.
To clarify, "packaging" into SYSMOD format so that you can use SMP/E
RECEIVE, APPLY, ACCEPT to inst
, 2015 7:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help
> I need some help with SMP/E. I need to convert our software to use SMP/E.
> I need a how to build a complete package and then how do I install it.
> I want to use GIMZIP, I think this should work.
To clarify, "p
Technologies
Storage Management QA
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Friday, September 11, 2015 9:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help
Hey Kurt, how about some documentation that is N
I need some help with SMP/E. I need to convert our software to use SMP/E. I
am not a SMP/E heavy. I have the following;
1. Linklib
2. Proclib
3. Parmlib
4. JCLLIB ( for install ) , this can be removed , because SMP/E will do it
5. Rexx Clistlib
Further thoughts on the process of packaging your
ember 11, 2015 8:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help
> I need some help with SMP/E. I need to convert our software to use
> SMP/E. I am not a SMP/E heavy. I have the following;
>
> 1. Linklib
> 2. Proclib
> 3. Parmlib
> 4. JCLLIB ( for install ) , this ca
7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Friday, September 11, 2015 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help
> I assume one of t
On Fri, 11 Sep 2015 08:26:48 -0700, Charles Mills wrote:
>
>No, the motivation was customer requests. I said to a customer sysprog "I
>thought our IEBCOPY install was pretty good." He said "it's great, and SMP/E
>is a pain in the [butt], but it's a consistent pain in the [butt]. Every
>vendor's
livered that way.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-
m...@listserv.ua.edu] On Behalf Of Kurt Quackenbush
Sent: Friday, September 11, 2015 8:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help
I need some help with SMP/E. I need to convert ou
live and breathe it, and they want vendor
>> products delivered that way.
>>
>> Charles
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Kurt Quackenbush
>> Sent: Friday, September 11, 2015 8
> >> thought our IEBCOPY install was pretty good." He said "it's great, and
> >> SMP/E is a pain in the [butt], but it's a consistent pain in the [butt].
> >> Every vendor's IEBCOPY install is unique."
> >>
> >> Customers --
In <55f2ee76.4040...@us.ibm.com>, on 09/11/2015
at 11:08 AM, Kurt Quackenbush said:
>You can greatly simplify you and your customers' efforts if you can
>avoid MODs and JCLIN altogether.
BTDT,GTS. Level sets are evil. If a fix changes only one csect then
the PTF should not replace other cse
In <55f27b68.6070...@gmail.com>, on 09/11/2015
at 02:57 PM, David Crayford said:
>Yes, I understand that. But wouldn't cat "//'SYS1.SAMPLIB(GIMSAMPU)'"
>| sed have worked?
What about sed <"//'SYS1.SAMPLIB(GIMSAMPU)'"?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; s
On Sat, 12 Sep 2015 19:49:03 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>Yes, I understand that. But wouldn't cat "//'SYS1.SAMPLIB(GIMSAMPU)'"
>>| sed have worked?
>
Perhaps. But it's not documented as supported. At the price of an extra
line of code, I'll go with a supported construct.
>What a
On Sat, 12 Sep 2015 21:08:36 -0400, Shmuel Metz (Seymour J.) wrote:
> on 09/11/2015 at 11:08 AM, Kurt Quackenbush said:
>
>>You can greatly simplify you and your customers' efforts if you can
>>avoid MODs and JCLIN altogether.
>
>BTDT,GTS. Level sets are evil. If a fix changes only one csect the
On Sun, Sep 13, 2015 at 1:20 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> I supported that position. But I'll also speak from the other side of
> my mouth. For example, HLASM prints a PTF level in its signon page.
> This implies that every PTF is a level set: it SU
On Sep 13, 2015, at 8:16 AM, Mike Schwab wrote:
A minimal consistent set of patches would require: One member contains
the overall PTF level. Every PTF verifies for the previous PTF and
updates it. Instead of zapping all members with the PTF even if not
changed.
Mike Maybe you don't rememb
The individual csect idea is good when products are written in Assembler of
course. I wonder about products in C and C++ or COBOL. My initial question
was about packaging our COBOL based product with Assembler based
subroutines into a SMP/E package for delivery to the customer. My idea to
make the
On Sun, 13 Sep 2015 11:54:32 -0400, Scott Ford wrote:
>The individual csect idea is good when products are written in Assembler of
>course. I wonder about products in C and C++ or COBOL. My initial question
>was about packaging our COBOL based product with Assembler based
>subroutines into a SMP/E
In
,
on 09/13/2015
at 11:54 AM, Scott Ford said:
>The individual csect idea is good when products are written in
>Assembler
I works just as well for toher alnguages, except that you don't have
the ++SRC and ++SRC options. A separate ++MOD for each compilation.
--
Shmuel (Seymour J.) M
On Fri, 11 Sep 2015 11:08:38 -0400, Kurt Quackenbush wrote:
>It is link edit steps in
>JCLIN that tells SMP/E how to put the MODs together to create these load
>modules.
When you code your JCLIN, one thing to remember is that it is coded as
though the target element is created from the DLIB libr
On Mon, 14 Sep 2015 09:41:54 -0500, Tom Marchant wrote:
>
>When you code your JCLIN, one thing to remember is that it is coded as
>though the target element is created from the DLIB libraries. In most cases,
>SMP/E doesn't actually build the elements that way, but that's how you tell
>it what ne
On Mon, 14 Sep 2015 11:24:31 -0500, Paul Gilmartin wrote:
>On Mon, 14 Sep 2015 09:41:54 -0500, Tom Marchant wrote:
>>
>>CALLLIBS processing can be confusing at first, too
>>
>Never used CALLLIBS. I need to RTFM. I believe autocall abdicates control
>of load module content. Will any SMP/E L
t: Tuesday, September 15, 2015 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help
On Mon, 14 Sep 2015 11:24:31 -0500, Paul Gilmartin wrote:
>On Mon, 14 Sep 2015 09:41:54 -0500, Tom Marchant wrote:
>>
>>CALLLIBS processing can be confusing at first, too
>>
>Never
Another reason to go to SMP/E packaging from a customer perspective is that
SMP/E packaging underlies ZOSMF and CA MSM management of software and fixes.
We hadn't used ZOSMF before I semi-retired, but I had used MSM and there are
time savings among other advantages.
---
On 13 Sep 2015 08:54:44 -0700, in bit.listserv.ibm-main you wrote:
>The individual csect idea is good when products are written in Assembler of
>course. I wonder about products in C and C++ or COBOL. My initial question
>was about packaging our COBOL based product with Assembler based
>subroutines
On Sun, 13 Sep 2015 13:19:19 -0300, Clark Morris wrote:
>
>If you are only supplying load modules/program objects, it could work
>but if there are any source COBOL members I doubt SMP/E would work
>unless SMP/E has expanded to handle languages other than COBOL. ...
>
It hasn't. Is there a COBOL
you can send object code as IBM and other vendors does and let SMP link
it. Another option is to name the cobol source as Assembler, and replace
the assembler processor to IGYCRCTL. The only problem i see is the many
work files the Cobol compiler uses and wouldn't be allocated by the
"assembler",
On Sun, 13 Sep 2015 21:48:10 +0300, Itschak Mugzach wrote:
>you can send object code as IBM and other vendors does and let SMP link
>it. Another option is to name the cobol source as Assembler, and replace
>the assembler processor to IGYCRCTL.
>
Eek!
> ... The only problem i see is the many
>wor
On 13 Sep 2015 16:05:48 -0700, in bit.listserv.ibm-main you wrote:
>On Sun, 13 Sep 2015 21:48:10 +0300, Itschak Mugzach wrote:
>
>>?you can send object code as IBM and other vendors does and let SMP link
>>it. Another option is to name the cobol source as Assembler, and replace
>>the assembler pro
41 matches
Mail list logo
