Am 23.03.2015 um 19:23 schrieb J.K.:
> On Mon, Mar 23, 2015 at 1:06 PM, J.E. wrote:
>> P.G. 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
>> 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.
There was an old ASSEMBLER on an old German mainframe computer in the 1970s (not
IBM compatible) that had free form input. Because commas were not part of the
syntax, they could be used as instructions separators. For IBM ASSEMBLER, the
comma is already used, but semicolon is still free, that is: it should or could
be possible to write multiple instructions in one line and seperate them with
semicolons; instructions without a label could start with a blank. Or: with the
old Telefunken ASSEMBLER, every label was terminated by a = character, so the
labels were recognized and distinguished from opcodes this way. This looked
Using ; as separator and = for the labels, a loop in IBM ASSEMBLER could be
written like this:
LA R5,10;LA R6,TAB;
LOOP=CLC 0(10,R6),TABX;JE FOUND;LA R6,10(R6);BCT R5,LOOP;
Of course, in the listing, the instructions should be printed on separate lines
(together with the resulting opcodes etc.); this is what the Telefunken
With this syntax, you may insert blanks whereever you like; the label can be
recognized anyway (it has the = char at the end). For the start of the comment
field there has to be another solution, for example, # like other ASSEMBLERs do
or // borrowed from C or C++. Even /* ... */ would be possible.
This would work IMO ... but I'm not sure if the ASSEMBLER programmers really
would like - and use - it.