I have not followed all that has gone on before, but I have to defend John E. a 
little and make a small suggestion.

The basic syntax only says you can have a label followed by one or more blanks 
followed by an opcode followed by one or more blanks followed by an optional 
set of operands followed by one or more blanks followed by optional comments.  
If you want to continue a card, put a non-blank in 72 and continue the data 
starting in column 16.  This is not arcane, except for continuation situations. 
 Starting continuations in column 16 actually makes sense when looked at in the 
context that 16 was where operands normally went and that the most common thing 
continued was an operand.

Backwards compatibility is important.  Having been around since real 5081 cards 
were the norm, I can still take a program I wrote back then and assemble and 
run it today without changing a single keystroke.  The greatest thing about 
what started out as OS/360 is the fact that with all the changes, very little, 
if any, non-system code has been deprecated.

Now it would be nice to be able to indicate a new format by using 
RECFM=V/VB/VBS and that not allowing for a continuation, but a record as long 
as you need.  It could also allow for a tab character to be considered a 
'whitespace' or blank if it occurs outside of a quoted string.

Using consistent column locations for the opcode and operands and comments, 10, 
16 and 35 being the most common, makes for easier reading  of a program.  Even 
given a new format, I would still align my opcodes and operands.  Given long 
labels, I put them on a separate record and use a DS  0H so my opcodes and 
operands still line up. 

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803    
E: [email protected]

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On 
Behalf Of John McKown
Sent: Monday, March 23, 2015 2:23 PM
To: MVS List Server 2
Subject: Re: (Regular Expressions followup)

On Mon, Mar 23, 2015 at 1:06 PM, John Ehrman <[email protected]> wrote:
> Paul Gilmartin noted...
>> IMO, HLASM syntax is the most god-awful piece of clap-trap garbage I
> have
>> ever laid my eyes on.  Well, perhaps a close second to JCL.
>
> HLASM's syntax is a direct descendant of the assembler languages for a 
> great variety of earlier systems, including the IBM 650, 704, 709(x),
> System/360 etc.  The one novelty in the System/360 assembler language 
> was the introduction of a separate, distinct class of variable 
> symbols; previous assemblers used ordinary symbols as macro variable 
> symbols.  At the time the 360 was being developed, there were no 
> low-level high-level languages (PL/S and C came years later); what 
> else was available for building systems?  And you'd be truly repelled 
> by the language used on the early IAS machines; by comparison, HLASM's 
> is a model of simplicity and clarity.
>
> I'm not defending historical clap-trap, but perhaps we're living too 
> close to the present?

I know that I need to watch myself on that score. There is a big problem with 
the desire to advance versus the desire to continue to use what already works. 
As an example, look at some of the posts in IBM-MAIN about COBOL 5 requiring 
that the executable be in a PDSE and impossible to run from a PDS. Lots of 
people yelling like somebody ran over their pet dog. But, at the same time, 
others are yelling for 64 bit AMODE. Can't win for losing. I sometimes get that 
myself: "You can change anything you need to. So long as it does not impact 
anything."
Huh? Not just "negatively impact", but make any change that might be noticed 
and complained about by _anybody_. So I play with z/OS UNIX because I'm the 
only user. And I still cuss myself out. [grin].

The only enhancement that I, personally, would like would be for "free format" 
input into HLASM with _no_ line limits. Mainly because I keep my HLASM source 
in a UNIX file and, depending on "things", I use the "as" UNIX command to 
assemble it. I'm a bit of a UNIX partisan for "interactives". Being forced to 
use column alignment when I use a non-ISPF editor is a royal bother. Hum, it 
would also be nice if the tab character were a white space character outside of 
literals.

>
> John Ehrman



--
If you sent twitter messages while exploring, are you on a textpedition?

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

Reply via email to