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
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:
> "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
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 academic so I hesitate to
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
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
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
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 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
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
> 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
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
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
-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
>
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
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 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
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
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
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
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
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
> 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.
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
> (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
> 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?
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:
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
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
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
41 matches
Mail list logo
