On Wed, 11 Mar 2020 15:52:50 -0700, Charles Mills wrote:
>
>But to the best of my knowledge Dallas ISV center customers are red-headed
>stepchildren and cannot open PMRs.
>
I was once in a situation as in in-house trans-department user
of our corporate computing center. I reported a bug which
On Wed, 11 Mar 2020 22:09:28 +, Jesse 1 Robinson wrote:
>APAR for failure to follow doc. Gotta be careful though. Could turn into a doc
>APAR. ;-(
>
When that happens, I truly wish I could see the unpublished design specs on
which both are based. Yes, I'm suspicious that they took the
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
Seems to me that should be reported as a bug. It's not technically an
enhancement to make the program conform to its documentation.
sas
On Wed, Mar 11, 2020 at 4:18 PM Charles Mills wrote:
> If anyone else wo
-
From: IBM Mainframe Discussion List On Behalf Of
Steve Smith
Sent: Wednesday, March 11, 2020 3:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Two related alias entry address questions
CAUTION EXTERNAL EMAIL
Seems to me that should be reported as a bug. It's not technically
rles Mills
> Sent: Monday, March 9, 2020 6:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Two related alias entry address questions
>
>
>
> My point below is relative only to IEBCOPY. IGG0nnnW messages are
> documented
> as resulting in a return code 4. IEBCO
-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Monday, March 9, 2020 6:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
My point below is relative only to IEBCOPY. IGG0nnnW messages are documented
as resulting in a return code 4. IEBCOPY is failing
Ah, the "return code 4" smoking gun. I'm with you now...
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
>IGG01557W
That's hardly a smoking gun, unless I am misunderstanding. Unless your
smoking gun is having utility messages within "system messages" and you
think that IBM will think it's worth
>IGG01557W
That's hardly a smoking gun, unless I am misunderstanding. Unless your
smoking gun is having utility messages within "system messages" and you
think that IBM will think it's worth the $$ to put them somewhere else
(let alone deal with a case about it). Maybe the rule is that
: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Saturday, March 7, 2020 5:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
>did you have an ENTRY BAR statement in the assembly?
I did not. I used the form
>did you have an ENTRY BAR statement in the assembly?
I did not. I used the form you and Gil showed of "BAR" on the "END" with
no entry statement (either in the assembly or the bind).
Grrr... But I've even complained of seeing a "I" suffix on messages
reporting JCL errors fatal from the
-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Friday, March 6, 2020 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
On Fri, 6 Mar 2020 16:44:09 -0500, Charles Mills wrote:
>> IEBCO
On Fri, 6 Mar 2020 16:44:09 -0500, Charles Mills wrote:
>> IEBCOPY did exactly what you told it to do, so the Return Code should be
>> zero!
>
>By that logic, every program should always return a zero. If I code
>
> LR 16,1
>
>then the assembler will generate a halfword of
Re: Two related alias entry address questions
On Fri, 6 Mar 2020 09:13:39 -0500, Charles Mills wrote:
>Third, with regard to IEBCOPY's failing and then exiting with return code
>zero, I can't find any documentation that specifies the >meaning of a zero
>return code, but issuing I
On Fri, 6 Mar 2020 09:13:39 -0500, Charles Mills wrote:
>Third, with regard to IEBCOPY's failing and then exiting with return code
>zero, I can't find any documentation that specifies the >meaning of a zero
>return code, but issuing IGW01557W MEMBER NOT COPIED and then exiting with
>return
-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, March 5, 2020 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
I was wrong about the
BAR DS 0D
...
END BAR
case. I had glossed over what
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Wednesday, March 4, 2020 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
Peter, thanks for the note. I'm on a small screen with fat fingers. I will
reply fully, tonight
On 3/3/2020 12:37 PM, Charles Mills wrote:
I will try COPYGRP and COPYGROUP. What's the difference? The description is
word for word the same.
The big difference (and reason it was invented) is COPYGROUP supports
member name masking whereas COPYGRP does not.
I was wrong about the
BAR DS 0D
...
END BAR
case. I had glossed over what "END BAR" meant.
I do agree with Charles and Gil from earlier:
If you have "END BAR" then the normal entry point for the module will
locate BAR, not offset 0
If you have "ALIAS BAR" then the alias will locate
) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Two
related alias entry address questions The COPYGROUP statement has the
same effect as the COPYGRP statement wheneither the input or the output data
set or both are partitioned format, that is eitherPDS or PDSEs. The function of
a COPYGROUP statement
On Wed, 4 Mar 2020 09:33:56 -0500, Peter Relson wrote:
>
>BAR DS 0D
>...
>END BAR
>
>If the entry point offset for BAR had been non-zero, then you did not have
>that case. If you did have that case, an alias of BAR would always have
>been 0 because BAR is not an external entry point. The
On Tue, 3 Mar 2020 18:51:24 -0600, Dale R. Smith wrote:
>COPYGROUP
>The COPYGROUP statement has the same effect as the COPYGRP statement when
>either the input or the output data set or both are partitioned format, that
>is either
>PDS or PDSEs. The function of a COPYGROUP statement differs from
The COPYGROUP statement has the same effect as the COPYGRP statement when
either the input or the output data set or both are partitioned format,
that is either
PDS or PDSEs. The function of a COPYGROUP statement differs from COPYGRP
only if both of the data sets are PDSs. COPYGROUP performs a
Subject: Re: Two related alias entry address questions
Got it! Not sure exactly what the key ingredient was but I suspect that the
problem was that I had @Gil's un-externally-named entry point:
BAR DS 0D
...
END BAR
I changed that to
BAR DS 0D
ENTRY BAR
END
My experimentation took
11:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Two related alias entry address questions
Shirley there is a better way to introduce new behavior in a compatible manner,
e.g., with a new PARM option. Having two keywords that look like they should be
synonyms but aren't is user
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, March 3, 2020 9:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
On Tue, 3 Mar 2020 17:23:19 -0800, Charles Mills
On Tue, 3 Mar 2020 17:23:19 -0800, Charles Mills wrote:
>...
>Makes my head spin. What was IBM thinking? It is beyond me why one would want
>to use one versus the other. I can envision a test case where they behave
>differently, but what is the situation where you would actively want to use
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Dale R. Smith
Sent: Tuesday, March 3, 2020 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
On Tue, 3 Mar 2020 12:37:31 -0800, Charles Mills wrote
On Tue, 3 Mar 2020 12:37:31 -0800, Charles Mills wrote:
>"Getting the aliases" is not an issue; getting the alias's entry point offset
>is the issue.
>
>I am copying to a PDS because the program objects are in a PDSE but what I
>want at the other end is a PDS.
>
>I will try COPYGRP and
@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
On Mar 3, 2020, at 3:14 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> Relink with INCLUDE -ATTR. Module by module. Ouch. I suspect
> this is used under-the-covers by IEBCOPY PDS<--&g
On Tue, 3 Mar 2020 22:23:08 +, Pew, Curtis G wrote:
>On Mar 3, 2020, at 3:14 PM, Paul Gilmartin wrote:
>>
>> Relink with INCLUDE -ATTR. Module by module. Ouch. I suspect
>> this is used under-the-covers by IEBCOPY PDS<-->PDSE.
>
>Yes, I think you are going to have to use the binder for
On Mar 3, 2020, at 3:14 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> Relink with INCLUDE -ATTR. Module by module. Ouch. I suspect
> this is used under-the-covers by IEBCOPY PDS<-->PDSE.
>
>
Yes, I think you are going to have to use the binder for this.
On Tue, 3 Mar 2020 13:26:53 -0800, Charles Mills wrote:
>Really! They even go so far as to say you can abbreviate COPYGRP as CG and
>COPYGROUP as CP. They could just have one section and list three abbreviations
>(in itself an excessive number).
>
Copy-and-paste of the paragraph is way easy
On Tue, 3 Mar 2020 13:32:30 -0800, Charles Mills wrote:
>COPYGRP produces exactly the same erroneous result.
>
I once relinked a program object into a UNIX directory.
IIRC, the aliases were created as directory links, but
there were no useful offsets. When I re-re-linked back
to a PDS(E), the
COPYGRP produces exactly the same erroneous result.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, March 3, 2020 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry
] On Behalf
Of Paul Gilmartin
Sent: Tuesday, March 3, 2020 1:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
On Tue, 3 Mar 2020 12:37:31 -0800, Charles Mills wrote:
>"Getting the aliases" is not an issue; getting the alias's entry point offset
On Tue, 3 Mar 2020 12:37:31 -0800, Charles Mills wrote:
>"Getting the aliases" is not an issue; getting the alias's entry point offset
>is the issue.
>
>I am copying to a PDS because the program objects are in a PDSE but what I
>want at the other end is a PDS.
>
Relink with INCLUDE -ATTR.
half Of Pew, Curtis G
> Sent: Tuesday, March 3, 2020 11:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Two related alias entry address questions
>
> On Mar 3, 2020, at 1:54 PM, Charles Mills wrote:
> >
> > Thanks. I had the same thought myself. Just tried it. N
ssion List on behalf of
Charles Mills
Sent: Tuesday, March 3, 2020 3:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
"Getting the aliases" is not an issue; getting the alias's entry point offset
is the issue.
I am copying to a PDS because
d for word the same.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Pew, Curtis G
Sent: Tuesday, March 3, 2020 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
On Mar 3, 2020, at 1:54 P
On Tue, 3 Mar 2020 11:35:02 -0800, Charles Mills wrote:
>1. Is there a way to display the entry point address of a load module member
>of a PDS? ISPF 3.1 shows Size, TTR, AM, RM, etc. but not the entry address.
>The member in question is actually an alias FWIW.
>
When I was younger and foolisher
On Mar 3, 2020, at 1:54 PM, Charles Mills wrote:
>
> Thanks. I had the same thought myself. Just tried it. No difference.
>
I’m to lazy to look it up, but I thought there was some control statement or
option in IEBCOPY to handle aliases.
But my first question was why you were copying to a
arch 3, 2020 11:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Two related alias entry address questions
>
> On Tue, 3 Mar 2020 11:35:02 -0800 Charles Mills wrote:
>
> :>1. Is there a way to display the entry point address of a load module
> member
> :>of a PDS
alias entry address questions
Use COPYMOD instead of COPY?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Subject: Two related alias entry address questions
1. Is there a way to display the entry point address of a load module member
of a PDS? ISPF 3.1 shows Size, TTR, AM, RM, etc. but not the entry address.
The member in question is actually an alias FWIW.
2. The reason I ask is that I am trying
entry point. Any way to
prevent that?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, March 3, 2020 11:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Two related alias entry address questions
1
n
Sent: Tuesday, March 3, 2020 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two related alias entry address questions
On Tue, 3 Mar 2020 11:35:02 -0800 Charles Mills wrote:
:>1. Is there a way to display the entry point address of a load module
member
:>of a PDS? ISPF 3.1 shows Size,
to
prevent that?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, March 3, 2020 11:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Two related alias entry address questions
1. Is there a way to display
On Tue, 3 Mar 2020 11:35:02 -0800 Charles Mills wrote:
:>1. Is there a way to display the entry point address of a load module member
:>of a PDS? ISPF 3.1 shows Size, TTR, AM, RM, etc. but not the entry address.
:>The member in question is actually an alias FWIW.
Use the binder API. For PDS, it
1. Is there a way to display the entry point address of a load module member
of a PDS? ISPF 3.1 shows Size, TTR, AM, RM, etc. but not the entry address.
The member in question is actually an alias FWIW.
2. The reason I ask is that I am trying to track down the following problem.
Perhaps someone
50 matches
Mail list logo
