I know the specific macro that caused (or rather, obscured) my
problem was IEFJFCBN, but there were at least two or three others with
the
same feature -- perhaps one was CVT.
I had presumed you were talking about non-mapping macros. IEFJFCBN and
CVT and many others simply default to LIST=NO
the offsets in some
DSECT.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Peter Relson
Sent: Wednesday, February 24, 2010 7:19 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IBM-caused needless aggravation for today
I know the specific
On 24 February 2010 11:52, Charles Mills charl...@mcn.org wrote:
What's the big deal? you say. Any experienced assembler programmer should
be able to figure that out. But that's only true if you have a clue where
the error might be. Here's the situation I was in: a whole bunch of brand
new
In ofaee62f43.70af0c31-on852576d4.004a6e5c-852576d4.00542...@us.ibm.com,
on 02/24/2010
at 10:19 AM, Peter Relson rel...@us.ibm.com said:
I had presumed you were talking about non-mapping macros. IEFJFCBN and
CVT and many others simply default to LIST=NO which is what many coders
desire.
In 01bb01cab42e$08768200$196386...@org, on 02/22/2010
at 06:15 PM, Charles Mills charl...@mcn.org said:
Perhaps someone else has a better justification or a better resolution?
Is there some reason to rule out the obvious justification: holding down
the size of the assembly listing? Of course,
On 2/22/2010 9:15 PM, Charles Mills wrote:
rant
Many of the IBM-supplied storage definition macros and copy members have
gained PRINT OFF statements over the years. As a result I had the
infuriating situation of having an assembly that was generating an RC=8 but
with no error messages in the
Yeah, give me my deserved grief for dropping the I in IBM from the
subject. Some day I'll learn how to cut paste...
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
...@bama.ua.edu] On Behalf
Of Gerhard Postpischil
Sent: Tuesday, February 23, 2010 1:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IBM-caused needless aggravation for today
On 2/22/2010 9:15 PM, Charles Mills wrote:
rant
Many of the IBM-supplied storage definition macros and copy members have
gained
ETR - Since it hides the error message, seems to be a problem that is
APARable.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Charles Mills
Sent: Monday, February 22, 2010 8:15 PM
To: IBM-MAIN@bama.ua.edu
Subject: IBM-caused needless
@bama.ua.edu
Subject: Re: IBM-caused needless aggravation for today
ETR - Since it hides the error message, seems to be a problem that is
APARable.
s/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions
The IEFJFCBN and CVT macros have had PRINT OFF at least as far back as
MVS 3.8, so for these macros the PRINT OFF was not gained over any very
recent years. In both macros, specifying LIST=YES avoids the PRINT OFF, as
you no doubt would have found if you had followed your inclination, which you
, February 23, 2010 8:43 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IBM-caused needless aggravation for today
The IEFJFCBN and CVT macros have had PRINT OFF at least as far back as
MVS 3.8, so for these macros the PRINT OFF was not gained over any very
recent years. In both macros, specifying LIST
: IBM-caused needless aggravation for today
The IEFJFCBN and CVT macros have had PRINT OFF at least as far back as
MVS 3.8, so for these macros the PRINT OFF was not gained over any very
recent years. In both macros, specifying LIST=YES avoids the PRINT OFF, as
you no doubt would have found if you had
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Bill Godfrey
Sent: Tuesday, February 23, 2010 9:43 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IBM-caused needless aggravation for today
I agree. You're preaching to the choir. My main point
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Charles Mills
Sent: Tuesday, February 23, 2010 11:17 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IBM-caused needless aggravation for today
What's wrong with PRINT NOGEN?
Inventing one's own
-snip---
Yeah, give me my deserved grief for dropping the I in IBM from the
subject. Some day I'll learn how to cut paste...
Peter Relson
z/OS Core Technology Design
to
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To
IBM-MAIN@bama.ua.edu
cc
Subject
Re: [IBM-MAIN] IBM-caused needless aggravation for today
-snip---
Yeah, give me my deserved grief for dropping the I in IBM from
rant
Many of the IBM-supplied storage definition macros and copy members have
gained PRINT OFF statements over the years. As a result I had the
infuriating situation of having an assembly that was generating an RC=8 but
with no error messages in the listing. I was getting more and more
On Mon, Feb 22, 2010 at 9:15 PM, Charles Mills charl...@mcn.org wrote:
rant
You're of course correct. Dunno if it will make you feel any better, but a
lot of Open Source stuff is worse: not just at compilation but *at startup*.
Postgres, for example, at least used to suppress all startup
19 matches
Mail list logo
