Resending my original Email because it was badly mangled. Sorry for the
inconvenience.
I find it amazing how C programmers believe in the superiority despite
overwhelming evidence to the contrary. Surprisingly, the psychological term for
this is "motivated reasoning" and I never believed it until now. Below actually
transpired yet they still believe that C is superior (even with an examples).
In another newsgroup, someone mentioned that C is THE GOTO system language
(specifically mentioning Windows) and that there is very little need for
assembler. C is the goto language for Unix. Windows has a lot of assembler
which requires their code be written in C#.
I also commented that C is a weak language compared to HLASM and gave some
examples that force bad coding techniques (e.g. XML parser). A C programmer
took offence because he had written an efficient XML parser in C. Below is
psuedo C logic and the assembler to do the same functionality. Realize the C
programmer felt C XML parsing needed less than 10 lines but those 10 lines
ended up being the first line in the pseudo code. He did not believe me until I
gave him the examples.
Another unhappy C programmer decided to give me an impossible challenge by
asking for a program where he could not replace a single line with efficient C
code. To be cheeky but technically correct, I responded IEFBR14.
More unhappy, he decided it must be a system program. I required that a C
programmer must be able to modify and maintain it once written in C. My choice
was IDCCDAL which contains the parser statements for TSO ALTER.
That wouldn't make him happy, so lets make it at least a little fair where at
least 10% must be in C and the assembler code must use the techniques we now
use. My choice would be all the TSO IDCAM commands.
I've always thought HLASM was good. I now realize It's extremely impressive
despite all it's warts. Without HLASM, we would not have z/OS, VSE and VM.
Imagine writing MVS in C (no SYS1.MACLIB capabilities or the other features). C
programmers are hampered by their choice of programming language. MVS would be
another flavor of Unix. Imagine the C version of TSO ALLOC DDN(mydd)
DSN(my.dataset) NEW CATLG CYL SPACE(5,5,10) (tso alloc -dmydd -fmy.dataset -n
-c -C -p5 -s5 -D10).
Unix programmers keep mentioning our programs aren't portable. That's true but
we could make them portable by implementing their machine architecture and
creating macro's to generate code supporting our machine instructions. How
arrogant when they think we can't possibly do this but they can write Hercules
and z390 that do exactly that? Truthfully it's a question of money and desire.
When would any of our programs be useful in their environment. We could leave
out all the environment specific code but then it wouldn't be near as useful to
us.
HLASM is dismissed as a proper language because it includes machine op codes.
Ignore the op codes and evaluate it on it's merits as a language (ease of use
and maintainability). I believe that Peter Relson said that HLASM macro's make
it impressive. While that is true, it has other important unnoticed (and often
unused) features that combine to make it truly impressive.
E.g. someone mentioned that most programmer code is NORENT assembler because
RENT requires initializing and addressing the work area. Coding the init area
in the CSECT causes USING problems. They don't realize another CSECT will avoid
the conflict.
macro ,
&l cballoc &cb,®=
aif ('&l' eq '').nolabel
&l EQU *
.nolabel anop ,
getmain r,lv=&cb.l,sp=1
lr ®,r1
USING &cb,® !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
LA R0,R1 mvcl destination
LA R1,&cb.l length to move
L R14,=A(&cb) mvcl source
LR R15,R1 length to move
MVCL (R0),(R14) init cb
MEND ,
WRK CSECT ,
anything thing you want in the CB
WRKL EQU *-WRK
MYPGM CSECT ,
CBALLOC WRK,R9
Assembler allows non-linear programming. LOCTR, CSECT, DSECT and more When
used in a macro, the programmer codes a single statement yet the macro
generates code in multiple locations. This feature is too often overlooked when
coding macro's.
Now for the code comparison. For those who don't know XML, the basics are very
simple. <a>data</a> allows you to associate 'data' as element 'a'. While 'data'
can be can be actual data, it can also include additional levels of more XML.
Basically it's multi-level data encapsulation.
<a><b>bbb<c>ccc</c></b><d>ddd</d><d>ddd</d>aaa</a>
Simplified assembler XML sample that could parse the XML above:
--- asm code before parsing ---
XMLPARSE BEGIN,XMLDATA=????
XMLPARSE ELEMENT=a
--- element a code ---
XMLPARSE ELEMENT=b,SUBELEM=a
--- element b code ---
XMLPARSE ELEMENT=c,SUBELEM=b
--- element c code ---
XMLPARSE ELEMENT=d,SUBELEM=a
--- element d code ---
XMLPARSE END
--- asm code after parsing ---
Pseudo code that shows C programming logic for the XMLPARSE above.
--- code before parsing ---
parse XML (element_start, element_data, element_end, XMLDATA=???)
--- code after parsing ---
function element_start **** called for each <???> (start of an element)
put flags onto stack
clear flags
if element = 'a' then
a_flag = true
else if element = 'b' & element[-1] = 'a' then
b_flag = true
else if element = 'c' & element[-1] = 'b' & element[-2] = 'a' then
c_flag = true
else if element = 'd' & element[-1] = 'a' then
d_flag = true
else
error invalid element
function element_data **** called for data between (not XML elements inside
this element)
if a_flag = true then
--- element a code ---
else if b_flag = true then
--- element b code ---
else if c_flag = true then
--- element c code ---
else if d_flag = true then
--- element d code ---
function element_end **** called for each </???> (end of the element)
restore flags from stack
----- end of pseudo code -----
If anyone tells you C is superior to HLASM, don't believe it. Have them
translate the DCB macro into acceptable functionality in C. By the way, they
will tell you it's unnecessary because you only need their concept of I/O
(streams).
Regards, Jon.
