> > 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
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
Well, the conventional solution in OS/360 is to return a code in R15,
preferably a multiple of 4. But I've used both the condition code and branch
offset approaches for internal subroutines.
OTOH, when I write an assembler subroutine that is to be called from PL/I
programs, I indicate unusual
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 address.
Charles
-Original Message-
From: IBM
> Is this useful?
Only if you're a sadist.
--
Shmuel (Seymour J.) Metz
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:
> using condition code as return value from subroutines that tested
I have never settled on a good scheme for returning what is effectively a bool
value from an assembler subroutine that performs a test.
I have tried using the condition code: (all examples using "historical" opcodes)
BAL
> Is this useful?
I think it is at least consistent (and yes, I know ...). I think ORG behaves
the same way.
> is otiose
Nay, it "documents" that two functions are being performed: achieving
alignment and defining a label. "not the most compact representation" is not
synonymous with otiose.
> (not writing much BAL any more).
I doubt that you ever were, or that you've even seen it.
> I was taught not to put labels on instructions for the same reason, though it
> was because we were using CMS UPDATE at the time,
Non sequitor. There's nothing in UPDATE that interferes with using
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
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’’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
lines could be added easily. I’ve never had an odd address created
Ah, I thought that you were using the macros from the HLASM Toolkit. BTW, I do
use foo DS 0H in macros, with generated labels, when it's convenient, but
believes that it clutters the listing elsewhere.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
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: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
It was a (not the only) common coding technique "in the old days" to put the
fields referenced by a subroutine at the end of that subroutine. If the last
field were an odd length then if the next subroutine began with label EQU * you
ended up with the alignment problem referenced in these
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
>
> Imagine:
My eyes! I had a bad dream, Mommy!
That violates every precept of encapsulation and information hiding. A
subroutine should no be tinkering with the caller's environment except in very
structured ways, e.g., return codes, signals. Having code outside of a loop
dealing with the loop
There are several different issues here.
First, using foo EQU * instead of foo DS 0H will lead to alignment errors in
programs mixing instructions and data, which is a very bad practice. Mixing
LOCTR separated instructions and data, however, is a perfectly reasonable
practice.
Second, with
-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
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. It would also have been
cleaner had there been a proper GOTO so that people wouldn't shoot themselves
in
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
Use Concept 14 and you won't have to worry about licensing:
http://skycoast.us/pscott/software/mvs/concept14.html
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of
Hide the details in a macro.
INVOKE name,error=(list of labels)
SETERROR errorcode
On Tue, 2 Jun 2020 08:58:28 -0700 Charles Mills wrote:
:>> using condition code as return value from subroutines that tested
:>
:>I have never settled on a good scheme for returning what is effectively a
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
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
I might believe MILTEN.
Setting CC is not at all arcane
Z: CLI *,X'95'
H: CLI *,0
L: CLI *,255
O: TM *,1
I thought maybe the 360/67 had IPM for 32-bit mode, but, no, so XA it is.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
Hmmm...
"I had a tough time in code review. Reviewers called me naive for using a
negative value in a base register. No, the were ignorant; the code worked and
was correct."
Perhaps technically 'correct', in that it worked, but why run the risk of
having a customer stumble over the
- 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 academic so I hesitate to
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
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
Hi Guys,
I thought I would put my 2 cents worth in
I know that 55 years of Assembler coding doesn't count for much these days
:-)
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)
In the
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
Paging? The conventional wisdom has always been to stay within one base
register, so for systems with 4K pages that isn't an issue. I tend to use LOCTR
so that constants aren't always at the end of the source code. I normally put
labels on the same line as the instructions and inserting code
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 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
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
My apologies. I did not realize the context and rqmnts. were so well defined.
Mike
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: Tuesday, June 2, 2020 10:55 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject:
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
> "Mit der Dummheit kämpfen Götter selbst vergebens."
I thought that was what Mike was referring to. It, the swing and The Wizard of
Id should be on every programmer's door.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe
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
According to the HLASM Language Reference manual (SC26-4940), the START
statement may be used to create the first control section in an assembly and
define an expression that is used to set the initial location counter. For
example:
START X'1000'
BR14
END
should
41 matches
Mail list logo