August 26, 2018 00:19
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: IEATDUMP MF=L Can someone explain this?
I suppose the way one groups the letters would be influenced by one's own
habits. I would expect that experienced z/OS programmers would know that for
the past few decades, new m
) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re:
IEATDUMP MF=L Can someone explain this?
Me too. But remember, This is for NEW macros, the ones whose MF=E forms
start with something like XC 88(,1),0(1), and use MF=(L,xxx).
The older ones, that often have required data in the MF=L form, still
have
Me too. But remember, This is for NEW macros, the ones whose MF=E forms
start with something like XC 88(,1),0(1), and use MF=(L,xxx).
The older ones, that often have required data in the MF=L form, still
have to be copied first. Typically you would put those MF=L in static
storage, and
On 8/27/2018 4:45 AM, Charles Mills wrote:
Consider using the same list area for multiple services
Is that documented anywhere?
In other words, you are saying -- just to pick three macros that come to
mind -- I could issue an ATTACHX, an EXTRACT and a CLOSE and use the same
MF=L area for all
On 2018-08-27, at 06:20:40, Peter Relson wrote:
>
>> I've never had the slightest need to use the labels generated in the
> MF=L form. Who does? They're not documented. I'll grant that they can
> probably be considered self-documenting, but is there a reasonable
> guarantee the labels won't
On Mon, 27 Aug 2018 07:45:08 -0400, Charles Mills wrote:
>> making sure that you have allotted the maximum that any of them could need
>
>How would I make sure of that (other than by "hacking" the macros or by
>doing a test assembly)?
MF_L_AREA DS 0D
MACRO_1_L MACRO1 MF=L
ORG MF_L_AREA
> I've never had the slightest need to use the labels generated in the
MF=L form. Who does? They're not documented. I'll grant that they can
probably be considered self-documenting, but is there a reasonable
guarantee the labels won't be changed in a new release? The MF=E
expansions don't
ords except MF=L, and DS nD ?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Peter Relson
Sent: Sunday, August 26, 2018 9:23 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-26, at 19:22:54, Peter Relson wrote:
> Coding a CSECT for the MF=L "model" is, as Gil has pointed out, basically
> not helpful for those macros that begin by zeroing the entire area, which
>
I don't recall saying that. Perhaps credit Ed Jaffe?
> in turn will be those macros
Coding a CSECT for the MF=L "model" is, as Gil has pointed out, basically
not helpful for those macros that begin by zeroing the entire area, which
in turn will be those macros that support no keywords on the list form
other than PLISTVER. I'd also suggest that anyone doing a unique getmain
My guess is that DFSMS is SOOO LARGE it is Godzilla size
Lizette
> -Original Message-
> From: IBM Mainframe Assembler List On
> Behalf Of David Stokes
> Sent: Sunday, August 26, 2018 12:09 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: AW: IEATDUMP MF=L C
: Sonntag, 26. August 2018 20:53
An: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Betreff: Re: IEATDUMP MF=L Can someone explain this?
I hate censorware. Scunthorpe would pass muster in California either.
The prefix IEA goes all the way back to OS/360; it's Supervisor. The T, of
course, is Transaction.
Who thought
From: IBM Mainframe Assembler List on behalf
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Saturday, August 25, 2018 5:26 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-25, at 14:27:44, Charles
> Date: 08/26/2018 01:07 AM
> Subject: Re: IEATDUMP MF=L Can someone explain this?
> Sent by: "IBM Mainframe Assembler List"
> Who thinks up these macro names, anyway? That one wouldn't pass muster
> as a California vanity license plate.
On 2018-08-25, at 17:22:52, Charles Mills wrote:
>
>> I once tried to define a prototype with DCs;
>
> Briefly, here is what I do:
>
> - Code a separate CSECT for my "model" (as I call it)
> ...
Costs a base register, but only very briefly. Or is there now a SS
instruction where the source is
: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-25, at 14:27:44, Charles Mills wrote:
> +2
>
> Labels belong in column 1 where your eye can scan for them.
>
Who thinks up these macro names, anyway? That one wouldn't pass muster
as a Cal
On 2018-08-25, at 14:27:44, Charles Mills wrote:
> +2
>
> Labels belong in column 1 where your eye can scan for them.
>
Who thinks up these macro names, anyway? That one wouldn't pass muster
as a California vanity license plate.
> It's great that the new MF=L macros do not require
ays
use it.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Saturday, August 25, 2018 1:39 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-25
On 2018-08-25, at 11:20:42, Steve Smith wrote:
> Just in case anyone cares about my HO, I hate the "new" syntax, and think the
> list forms are hideous. While I agree they are documented adequately, putting
> the label as a required 2nd sub-operand of MF=L is terrible. Labels belong
> in
Just in case anyone cares about my HO, I hate the "new" syntax, and
think the list forms are hideous. While I agree they are documented
adequately, putting the label as a required 2nd sub-operand of MF=L is
terrible. Labels belong in column one (I am aware of the option to put
an alias
On 2018-08-25, at 07:06:30, Peter Relson wrote:
> The documentation seems quite clear to me. Almost every macro written in
> the last 20+ years has used this same syntax for the list form. We felt it
> best to have the syntax for list form be analogous to that for execute and
> modify forms.
>
On 8/25/2018 6:06 AM, Peter Relson wrote:
You mention a "DSECT". I cannot think of any case where a list form
builds a DSECT. You might put a list form within a DSECT. But that is your
DSECT.
Indeed. Putting the list form in a DSECT is the preferred approach these
days since (almost?) every
The documentation seems quite clear to me. Almost every macro written in
the last 20+ years has used this same syntax for the list form. We felt it
best to have the syntax for list form be analogous to that for execute and
modify forms.
The syntax diagram shows the valid format. As does the
On 2018-08-24, at 12:50:35, Steve Thompson wrote:
> Well, after looking at the code that is generated, I really do think that
> this was done this way for PLAX (or whatever it is today) users and NOT HLASM
> programmers.
>
> And the manual needs to explain this better. This is the label prefix
Well, after looking at the code that is generated, I really do
think that this was done this way for PLAX (or whatever it is
today) users and NOT HLASM programmers.
And the manual needs to explain this better. This is the label
prefix for all the labels that will be generated by this
We have the list form coded like this:
IEATDUMP PLISTVER=MAX,MF=(L,IEATDUMPL)
and the execute form coded like this:
IEATDUMP DSN=DUMPDSNL,HDR=DUMPTITL,
PLISTVER=MAX,
MF=(E,IEATDUMPL)
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
>
I have a program that I am fixing to be 31bit addressing.
I'm looking at an MNOTE out of IEATDUMP coded as follows:
IEATDUMP_L IEATDUMP PLISTVER=MAX,MF=L
The MNOTE,8 says:
For the "MF" key, positional ARG 2 is required.
So, here I am trying to define the List area, but the list area
needs
27 matches
Mail list logo