...@gmail.com]
Sent: Thursday, June 4, 2020 3:12 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Interesting definition of "profanity. In any case, still non-responsive.
But getting more amusing with each iteration, as the hole gets deeper.
BTW, Kerry,
muel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Kerry Liles [kerry.li...@gmail.com]
> Sent: Thursday, June 4, 2020 2:31 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: z
Actually, no, no one needed to ask. This is a technical discussion board,
and airing one's opinions about others' demeanor or perceived attitude are
completely out-of-line and a waste of bandwidth and every subscriber's time.
Everyone has opinions about the denizens of this list. There are a
@LISTSERV.UGA.EDU] on behalf
of Kerry Liles [kerry.li...@gmail.com]
Sent: Thursday, June 4, 2020 2:31 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
It seems the response was simply "PKB"
Not sure what that means ... unlikely to stand for "I'll
@gmail.com]
> > Sent: Thursday, June 4, 2020 1:36 PM
> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> > Subject: Re: z/OS HLASM: EQU for statement labels
> >
> > Somebody has to ask: Shmuel, why are you such a hostile prick? The
> smugness
> > and lack of comity you e
GA.EDU] on
> behalf of zMan [zedgarhoo...@gmail.com]
> Sent: Thursday, June 4, 2020 1:36 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: z/OS HLASM: EQU for statement labels
>
> Somebody has to ask: Shmuel, why are you such a hostile prick? The smugness
> and lack of comit
Somebody has to ask: Shmuel, why are you such a hostile prick? The smugness
and lack of comity you exhibit are at odds with the general tenor of this
forum, and your comments--while sometimes useful--are so often just showing
off and being difficult that, were I the list owner, I'd have you on
: Re: z/OS HLASM: EQU for statement labels
Somebody has to ask: Shmuel, why are you such a hostile prick? The smugness
and lack of comity you exhibit are at odds with the general tenor of this
forum, and your comments--while sometimes useful--are so often just showing
off and being difficult
[dwegsch...@sbcglobal.net]
Sent: Thursday, June 4, 2020 10:00 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
please be gentle with the person relatively inexperienced with S/360 assembler.
Why do they say not to use multiple base registers? cache/paging
please be gentle with the person relatively inexperienced with S/360 assembler.
Why do they say not to use multiple base registers? cache/paging/a sign that
your routine is too big to maintainable/something else?
On Thu, 4 Jun 2020 12:23:18 +, Seymour J Metz wrote:
>> The XPL compiler
IST@LISTSERV.UGA.EDU] on behalf
of Robin Vowels [robi...@dodo.com.au]
Sent: Wednesday, June 3, 2020 7:48 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
From: "Seymour J Metz"
To:
Sent: Wednesday, June 03, 2020 7:00 AM
> Paging? The convent
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Gary Weinhold [weinh...@dkl.com]
Sent: Wednesday, June 3, 2020 11:29 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Pot, kettle
On 2020-06
From: "Seymour J Metz"
To:
Sent: Wednesday, June 03, 2020 7:00 AM
Paging? The conventional wisdom has always been to stay within one base
register,
The XPL compiler used multiple base registers.
so for systems with 4K pages that isn't an issue. I tend to use LOCTR so that constants
Sent: Wednesday, June 3, 2020 11:07 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Metz scrawled:
(not writing much BAL any more).
I doubt that you ever were, or that you've even seen it.
O my. Are you subscribing to some arcane definition of Basic Assembler Lang
020 11:07 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Metz scrawled:
>> (not writing much BAL any more).
>I doubt that you ever were, or that you've even seen it.
O my. Are you subscribing to some arcane definition of Basic Assembler Languag
Metz scrawled:
>> (not writing much BAL any more).
>I doubt that you ever were, or that you've even seen it.
O my. Are you subscribing to some arcane definition of Basic Assembler Language
that requires hand-punching cards on a Jacquard loom or something? Give me a
break.
>> I was taught not
I was referring to CP routines calling other CP routines. It's true
that the CC also had to be set correctly when redispatching the code
running in a virtual machine after intercepting a privileged operation.
On 2020-06-02 10:54 p.m., Paul Gilmartin wrote (snipped):
On 2020-06-02, at 19:37:25,
: Re: Returning bool and similar values from subroutines (was z/OS
HLASM: EQU for statement labels)
Caution! This message was sent from outside your organization.
On 2020-06-02, at 19:37:25, Gary Weinhold wrote:
>
> I recall that VM/370 CP routines set CC before returning to the
> caller
IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu]
Sent: Tuesday, June 2, 2020 10:54 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Returning bool and similar values from subroutines (was z/OS
HLASM: EQU
As Mr. Gilmartin has reminded me, SPM was part of the original S/360
instruction set. (I actually did know that, but having been retired for almost
3 years now, I'm getting a little rusty ... thanks Gil for slapping me upside
the head.)
As Mr. Metz points out, there are countless ways of
On 2020-06-02, at 19:37:25, Gary Weinhold wrote:
>
> I recall that VM/370 CP routines set CC before returning to the caller;
> I don't have access to the source anymore (for the last 30 years or so)
> to verify this and what technique was used. I just remember thinking it
> was different and
I recall that VM/370 CP routines set CC before returning to the caller;
I don't have access to the source anymore (for the last 30 years or so)
to verify this and what technique was used. I just remember thinking it
was different and clever (coming from a VS1/MVS background).
On 2020-06-02 5:30
- Original Message -
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
To:
Sent: Wednesday, June 03, 2020 3:26 AM
Subject: Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 10:58:00, David Woolbright wrote:
I’’m just a humble academ
On
Behalf Of Steve Smith
Sent: Tuesday, June 2, 2020 5:01 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Caution! This message was sent from outside your organization.
Not bad. It's very useful for assembler programmers to understand the math
behind 2s-
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Dan Greiner [dan_grei...@att.net]
Sent: Tuesday, June 2, 2020 5:30 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Returning bool and similar values from subroutines (was z/OS
HLASM: EQU for statement labels
On 2020-06-02, at 15:53:34, Keven wrote:
>
> Are you suggesting the use SPM/IPM as an alternative to setting the
> actual condition code?
> K3n
>
I opposed it; its proponent outranked me.
> On Tue, Jun 2, 2020 at 4:45 PM -0500, "Paul Gilmartin"
>
> On 2020-06-02, at 15:30:33, Dan
Are you suggesting the use SPM/IPM as an alternative to setting the
actual condition code?
K3n
On Tue, Jun 2, 2020 at 4:45 PM -0500, "Paul Gilmartin"
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
On 2020-06-02, at
On 2020-06-02, at 15:30:33, Dan Greiner wrote:
>
> Using the indexed branch allows for many more possible actions -- not just
> binary true/false -- but may necessitate accommodating all possible branch
> cases following each return. I also agree that the indexed branch approach
> may be more
Although Seymour has pointed out the OS/360 convention of placing a return code
in GR15, there are numerous alternative approaches used elsewhere. Your example
of using "historical opcodes" (BAL 14,some_test / BE success) was used
extensively in the National Institute of Health (NIH) version of
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of MELVYN MALTZ [072265160664-dmarc-requ...@listserv.uga.edu]
Sent: Tuesday, June 2, 2020 4:01 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Hi Guys,
I
Not bad. It's very useful for assembler programmers to understand the math
behind 2s-complement (and how it nicely "complements" wrap-around
addressing) thoroughly enough to get that; besides understanding you
avoided changing the CC.
But for the record, that's a negative value in an index
On 2020-06-02, at 14:01:28, MELVYN MALTZ wrote:
>
> Labels...
> Even back in the 60's I was taught never to put a label on an instruction
> I only break that rule now for the subject of an EX (and its variants)
>
It's safer than
labelEQU *
> Returning CC from a subroutine...
> Have to
this in the VSAM TESTCB macro
Melvyn Maltz.
- Original Message -
From: "David Woolbright"
To:
Sent: Tuesday, June 02, 2020 5:58 PM
Subject: Re: z/OS HLASM: EQU for statement labels
I’’m just a humble academic so I hesitate to weigh in. I trained assembler
programmers for one large c
edu]
Sent: Tuesday, June 2, 2020 1:35 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 11:21:23, Seymour J Metz wrote:
>
> SIGNAL in PL/I is well behaved; in REXX, not so much.
>
> I like REXX, but it would have been much clea
On 2020-06-02, at 11:30:20, Schmitt, Michael wrote:
>
> I wrote an entire AVL tree based caching program using the HLASM Toolkit
> Feature Structured Programming macros, but then had to rewrite to remove the
> macros when the company decided to no longer pay for the feature.
>
> Now IBM is
On 2020-06-02, at 11:30:20, Schmitt, Michael wrote:
>
> I wrote an entire AVL tree based caching program using the HLASM Toolkit
> Feature Structured Programming macros, but then had to rewrite to remove the
> macros when the company decided to no longer pay for the feature.
>
I believe
On 2020-06-02, at 11:21:23, Seymour J Metz wrote:
>
> SIGNAL in PL/I is well behaved; in REXX, not so much.
>
> I like REXX, but it would have been much cleaner had iterate and leave used a
> label on the do rather than using the control variable.
>
Yes.
> It would also have been cleaner had
of Schmitt, Michael [michael.schm...@dxc.com]
Sent: Tuesday, June 2, 2020 1:30 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Seymour J Metz
Sent: Tuesday, June 02, 2020 12:25 PM
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Seymour J Metz
Sent: Tuesday, June 02, 2020 12:25 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Ah, I thought that you were using the macros from the HLASM Toolkit. BTW, I do
On 2020-06-02, at 10:58:00, David Woolbright wrote:
>
> I’’m just a humble academic so I hesitate to weigh in. I trained assembler
> programmers for one large credit card processing company for many years and
> their standard was to use EQU * as the target of all branches, mainly so new
>
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Schmitt, Michael [michael.schm...@dxc.com]
Sent: Tuesday, June 2, 2020 1:17 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 10:32:23, Seymour J Metz
-dmarc-requ...@listserv.uga.edu]
Sent: Tuesday, June 2, 2020 12:47 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 10:32:23, Seymour J Metz wrote:
>
> if x
>if y
> do a
> foo endif
On 2020-06-02, at 10:32:23, Seymour J Metz wrote:
>
> if x
>if y
> do a
> foo endif
> bar else
> do b
> endif
>
>> Then later if you want to insert more instructions immediately before the
>> ELSE, it is very clear where to put them
...@columbusstate.edu]
Sent: Tuesday, June 2, 2020 12:58 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
I’’m just a humble academic so I hesitate to weigh in. I trained assembler
programmers for one large credit card processing company for many years
problem of the condition code approach.
:>
:>Anyone have a great solution?
:>
:>Charles
:>
:>
:>-Original Message-
:>From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Phil Smith III
:>Sent: Tuesday, June 2, 2020 5:21 AM
:>To: ASSEM
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu]
> Sent: Tuesday, June 2, 2020 11:40 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
al Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Schmitt, Michael
Sent: Tuesday, June 2, 2020 9:18 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Thank you for your replies.
I too was originally taught
Thank you for your replies.
I too was originally taught to use DS 0H for a label statement, because it
guaranteed halfword instruction alignment. But I recently started using EQU *
because a) it seemed to be clearer as to the intent, and b) I figured that if
your instructions weren't aligned
not
synonymous with otiose.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Tuesday, June 2, 2020 8:40 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
On 2020-0
, June 2, 2020 11:58 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Returning bool and similar values from subroutines (was z/OS HLASM:
EQU for statement labels)
> using condition code as return value from subroutines that tested
I have never settled on a good scheme for returning what is effectiv
: Tuesday, June 2, 2020 8:21 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Charles Mills wrote:
>I use 0H if it is the beginning of a section of code and there might be
>an odd-length DC in front of it. But I use * when I am jumping around
>one in
SSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Charles Mills wrote:
>I use 0H if it is the beginning of a section of code and there might be
>an odd-length DC in front of it. But I use * when I am jumping around
>one instruction.
That's an interesting s
ent: Tuesday, June 2, 2020 11:40 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 09:33:48, Charles Mills wrote:
>
> I don't claim any benefit to the technique, it's just my habit. Actually I
> think the cleanest is a DS 0H follo
On 2020-06-02, at 09:33:48, Charles Mills wrote:
>
> I don't claim any benefit to the technique, it's just my habit. Actually I
> think the cleanest is a DS 0H followed by label EQU *. That clearly shows
> what is going on: re-establishing halfword alignment followed by mapping a
> label to an
Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Phil Smith III
Sent: Tuesday, June 2, 2020 5:21 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Charles Mills wrote:
>I use 0H if it is the beginning of a section of c
Charles Mills wrote:
>I use 0H if it is the beginning of a section of code and there might be
>an odd-length DC in front of it. But I use * when I am jumping around
>one instruction.
That's an interesting stylistic trick. I like it. Probably a bit late for me to
adopt it, alas (not writing much
> > I've been coding MVS assembler for 30 years and this is the first I've
heard
> of this guideline.
>
> Any decent text on the subject (dating from Struble's "Assembler Language
> Programming
> the IBM S/360" of the 1960s will point this out.
Some one was asking about books and Struble is
- Original Message -
From: "Charles Mills"
To:
Sent: Tuesday, June 02, 2020 7:07 AM
I use 0H if it is the beginning of a section of code and there might be an
odd-length DC
in front of it. But I use * when I am jumping around one instruction.
Revealing my age, I got in the
- Original Message -
From: "Schmitt, Michael"
Sent: Tuesday, June 02, 2020 6:43 AM
In John R. Ehrman's SHARE presentations on tips for modernizing
IBM z/Architecture assembler programs (such as
https://share.confex.com/share/120/webprogram/Handout/Session12522/modrnasm.pdf),
he says
nt: Monday, June 1, 2020 6:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
Am 01.06.2020 um 23:07 schrieb Charles Mills:
> I use 0H if it is the beginning of a section of code and there might be an
> odd-length DC in front of it. But I use * when I a
] on behalf
of Charles Mills [charl...@mcn.org]
Sent: Monday, June 1, 2020 6:22 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
> TS is your friend
My 029 didn't have a TS key.
Charles
-Original Message-
From: IBM Mainframe Assembler L
> TS is your friend
My 029 didn't have a TS key.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: Monday, June 1, 2020 2:45 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM:
Am 01.06.2020 um 23:07 schrieb Charles Mills:
I use 0H if it is the beginning of a section of code and there might be an
odd-length DC in front of it. But I use * when I am jumping around one
instruction.
Revealing my age, I got in the habit of using EQU rather than labeled machine
[michael.schm...@dxc.com]
Sent: Monday, June 1, 2020 4:43 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: z/OS HLASM: EQU for statement labels
In John R. Ehrman's SHARE presentations on tips for modernizing IBM
z/Architecture assembler programs (such as
https://secure-web.cisco.com/1MDmQPGPlhl
List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Charles Mills [charl...@mcn.org]
Sent: Monday, June 1, 2020 5:07 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
I use 0H if it is the beginning of a section of code and there might be an
odd-length DC
card to punch in Ye Olde Times.
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Charles Mills
Sent: Monday, June 1, 2020 5:08 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
I use 0H if it is the beginning of a section
On 2020-06-01, at 15:07:33, Charles Mills wrote:
>
> I use 0H if it is the beginning of a section of code and there might be an
> odd-length DC in front of it. But I use * when I am jumping around one
> instruction.
>
> Revealing my age, I got in the habit of using EQU rather than labeled
Sent: Monday, June 1, 2020 1:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z/OS HLASM: EQU for statement labels
I agree with Gerhard; I was taught and use
labelDS0H
for labels instead of EQU.
I agree with Gerhard; I was taught and use
labelDS0H
for labels instead of EQU.
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
On Mon, Jun 1, 2020 at 4:46 PM Gerhard adam wrote:
>
>
>
>
> Even though it may not happen often the EQU can point to an odd
> address and
Even though it may not happen often the EQU can point to an odd address
and cause the label to be referenced when it is filled with binary zeroes (S0C1)
The use of 0H always forces boundary alignment for instructions
Get Outlook for iOS
In John R. Ehrman's SHARE presentations on tips for modernizing IBM
z/Architecture assembler programs (such as
https://share.confex.com/share/120/webprogram/Handout/Session12522/modrnasm.pdf),
he says that important advice from experienced assembler programmers is to:
_Don't_ use EQU for
71 matches
Mail list logo
