> I wrote: TSO has the alloc command which can easily be > used in clists. It
> exists because of MVS UNIX.
MVS UNIX has nothing to do with TSO ALLOC. When I moved the C FOPEN text, I
forgot to delete the MVS UNIX senstence. It's FOPEN dynamic alloc only exists
because of MVS Unix and is considered a production MVS security exposure. Most
production languages do not support dynalloc for this reason.
>> Charles wrote: De gustibus non est disputandam
> I wrote:I'm not disputing taste (or preferences). I'm saying that C
> programmers > are willing to fabricate facts to justify their choice is the
> undeniable winner. > E.g. 5 to 10 times more productive.
Can anyone give me any example that would justify C programmers belief that C
is significantly better than HLASM? To state extreme facts as truth is way
beyond taste or preference. Surprisingly, using blatant untruths for
justification is well documented and common (see
https://en.wikipedia.org/wiki/Motivated_reasoning ). Maybe I'm being unfair by
asking about someones specific implementation but I doubt it.
I wish that C / Unix programmers could get out of the motivated reasoning
mentality. They are often selfish because they want what they want and will do
anything to justify their choice. IBM concepts are great examples because they
are constantly being dismissed. Even we often dismiss their significance even
though they are extremely well thought out and insightful.
E.g. one of the best decisions was to force RECFM= (despised on Unix) rather
than UNIX streams. UNIX is struggling with what they call "big data" (any type
of data bottleneck). On Unix, when files get out of control, the only choice is
to convert to a database which means every program using this file must be
heavily modified and often rewritten. On the other hand, MVS has many choices
where databases are the last resort. First, the programmer actually thought
about how the records are organized and would have avoided some of the pitfalls
in the first place. Additionally, MVS has VSAM, record locking, shared buffers
and more that may alleviate the bottleneck. Even things like file positioning
become very relevant in a RECFM= environment as opposed to Unix streams.
As for HLASM macro's, anyone who does not add or modify them on a regular basis
is not being an effective assembler programmer. In all my years, the C code I
worked with would have been just as good as the C version because of macro's.
If C were to add the HLASM macro features, then I would definitely jump ship
from HLASM.
Thanks, Jon.
On Thursday, December 14, 2017 9:45 PM, Jon Perryman <jperr...@pacbell.net>
wrote:
Sorry for taking so long to respond. A little too busy.
>John Ehrman wrote: I agree that PL/I's macro preprocessor is indeed powerful;
>but it and > all other macro facilities I know of lack a key feature of
>HLASM's
> conditional assembly and macro facility:
John is being modest by hugely understating the value of this feature. The C
consortium should hire John to help them implement this feature. Charles seems
to doubt it's merits and believes he is 5 to 10 times as productive in C. Since
he mentioned his SMF product and logic, I'll provide a HLASM snippet below.
Charles, please show us how you are able to improve on the simplicity and
productivity. FYI, while this specific snippet is not real code, I do have real
code from a few years back that does something very similar. The basic logic
needed for this snippet definitely works.
C & C++ are fine languages and they definitely have their place. At times, they
are more productive.This is not meant to denigrate C. This is meant to show how
C programmers unjustly and falsely denigrating HLASM.
Charles, you have real C code doing this. How do I write something this elegant
in C++ or C? I've never come close. I'm very interested in knowing how to be
equally productive in C because it would greatly improve my life. I would be
thrilled to learn how to be 5 to 10 times more productive.
xxx CSECT ,
XML TYPE=PARSE,DD=PARMS
XML TYPE=ELEMENT,ID=SELECT
XML TYPE=ELEMENT,ID=ALL,PARENT=SELECT
#BITON TYPE21
#BITON TYPE22
XML TYPE=ELEMENT,ID=TYPE21,PARENT=SELECT
#BITON TYPE21
XML TYPE=ELEMENT,ID=TYPE22,PARENT=SELECT
#BITON TYPE22
XML TYPE=TEXT
--- code to handle data in this element
XML TYPE=ATTRIBUTE,ID=SUBTYPES
--- code to handle the subtype attribute
XML TYPE=ATTRIBUTE,ID=some_attr
--- code to handle this attribute
XML TYPE=ELEMENT,ID=JONWANTS,PARENT=SELECT
#BITON JONWANTS
XML TYPE=END
OPENQ ,
DO WHILE=(READQ,,,Z) Read file to end
SMFREC TYPE=21,DESC='smf rec 21',PRNTWHEN=(TYPE21,JONWANTS)
SMFFIELD SMF21ABC,DESC='an SMF 21 field'
SMFFIELD SMF21DEF,DESC='an SMF 21 flag
field',PRNTWHEN(?????),FLAGS=((smf21FL1,'flag desc'),(smf21FL2,'flag descc'))
SMFSUBT DESC='subt1',??? options to decode subtype SMFFIELD
SMF21SF1,....
SMFFIELD SMF21SF2,....
SMFSUBT DESC='subt2',??? options to decode subtype SMFFIELD
SMF21SF3,.... SMFFIELD SMF21SF4,....
SMFREC TYPE=22,DESC='smf rec 22',PRNTWHEN=(TYPE22) SMFFIELD
SMF22ABC,DESC='an SMF 22 field'
SMFREC TYPE=??,DESC='smf rec
??',PRNTWHEN=(--useropts-selecting-this-field) SMFFIELD
SMF??ABC,DESC='an SMF 21 field',PRNTWHEN=(--useropts-selecting-this-field)
SMFREC TYPE=END
ENDDO ,
CLOSEQ ,
END ,
