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 commented on my statement about C++ function overload for builtin > functions: My appologies. I really screwed up on that. The products I worked on have been C. My C++ experience has been limited to play time.. Outside that mistake, I stand by everything else. Things like "byte" are not technically correct, but it is clearly understood by this group as opposed to saying unsigned char. > I wrote: Imagine converting OPEN / DCB to C functions>> Charles replied: They > did. It's called fopen(), and has much of SVC 99 integrated in for good > measure. Charles, do you really stand by this statement about fopen()? IBM's solution is certainly the best but in what universe would any C programmer consider keyword parms such as fopen(recfm=fb)? Every product I worked on created several functions to generate this type of code. Do you stand by "SVC 99 for good measure"? Generally, products do not implement it for good reason. Irrelevant in CICS and IMS. In batch, it bypasses job scheduler, job restart, violates production control requirements, bypasses JES3 resource management and potentially poses a production security risk. TSO has the alloc command which can easily be used in clists. It exists because of MVS UNIX. > Charles wrote: De gustibus non est disputandam 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. If I'm wrong at the end of this discussion, I will have learned to be a better C programmer and learn why C is better. If you are wrong, you will have learned some new HLASM coding techniques. Either way, everyone will be winners because we will have learned about a very contentious subject. So lets get to some real substance and see if we can learn something new. > Charles wrote: I suspect I am 5 to 10 times more productive. This is a very common comment so where do C programmers come up with these numbers? I've never run into a situation where C / C++ is radically more productive than HLASM. Often it's far less productive. If I understood Charles correctly, his product transmit reformatted SMF records / fields according to options the user has specified. This is how I would implement this in 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 , DO and ENDO are real structured macro's from the HLASM toolkit. #BITON is a real macro that allows my programs to omit field names from flag bytes. It is part of a set of bit manipulation and testing macro's. XML is a real macro that parse XML data. Remember that I can easily call any C function needed. If additional logic is needed for any piece of the SMF record, then it can be easily added after the statement. And more important, there are many examples of this type of implementation (e.g. TSO parser implemented long ago with a far less flexible macro language). > My real HLASM code that does something very similar to this SMF code Some stats about my program that formats and displays any DSECT (not just SMF and automatically displayed all fields including long description of each flag being the flag label). It has been used successfully on over 200 DSECT's. 7 macro's (522 lines total minus comment lines = 327 lines) Each dsect add's 1 line Each field & flag add's 0 lines (I print all fields & flags).When a field or flag has an incorrect definition, then it must be added to a (exception) parm on the dsect line and must specify the correct formatting.Written in less than 1 day for initial version. Can't remember for sure but I think it was 3 hours.1 minute to add new DSECT.Macro error message when DSECT changes size. Modify size value and re-assemble to use new DSECT.Remember that I get 1 opcode per line vs multiple functions in C. > Charles wrote: When I look at the incredible machine code output by the > compiler > I doubt that a skilled assembler programmer would do as well. This is another common comment from C programmers that simply does stand up to the facts. Is anyone who is 5 to 10 times more effective at C actually qualified to say "incredible" and better than a skilled HLASM programmer? After looking at metal C, it looks like more than 90% of C is function calls that translate to simple calls. C produces consistent / repetitive code (not necessarily incredible code). IBM C is not open source nor free. IBM added machine instructions to make C (e.g. string instructions). IBM threw a huge amount of resources and extremely skilled developers at the problem. Maybe a fair comparison would be GCC.. C strongly encourages Unix programming techniques and practices. If you doubt this, then lets start a discussion on "big data" and "the cloud". Both of these were built into MVS languages back in the 70's. On the other hand, Unix style programming languages require a redesign.. > Charles wrote: C++ runtime overhead: I said C purists use runtime overhead as justification (not me). If you doubt that, then look at Google's GO (C variant) which after 8 years still lacks OOP.. They still refuse to include OOP. Anyone considering C++ should consider more robust languages because as you say, who cares about the overhead. HLASM is typically not a application programming language where as C encourages application programs. Charle's SMF product is an application which many shops would code in SAS. Regards, Jon. On Monday, December 11, 2017 5:27 PM, Charles Mills <[email protected]> wrote: Oh my gosh -- so many assumptions in there that I disagree with it is hard to know where to start. > it's [its] runtime overhead I find the "runtime overhead" of C++ to be very acceptable. "My" (my employer's, for which I am responsible) C++ product receives SMF records out of a queue. It selects SMF fields one at a time, in a kind of interpreted fashion, sort of like a report generator. It converts the selected funky SMF fields to character form (several variations, depending on customer options), often elaborately such as by expanding bit flags to character names, and then translates the whole shebang from EBCDIC to UTF-8, and pushes it out the TCP stack. How much CPU time per record? About 1/20000 of a second -- 50 CPU milliseconds -- on a 12/13/14, depending on complexity. I find that very acceptable. When I look at the incredible machine code output by the compiler I doubt that a skilled assembler programmer would do as well. > C++ could easily change these to a single function call but still require the > programmer to make the correct choice Not so, if I am understanding you correctly. The C++ compiler has incredibly good logic to pick the correct overload with no special programmer effort. Take a look at stream I/O (the >> style I/O) for an example. And you have not even touched on templates, which are like overloads on steroids. > Imagine converting OPEN / DCB to C functions They did. It's called fopen(), and has much of SVC 99 integrated in for good measure. > Byte or char are the only data types with a known length Really? For most modern, general purpose implementations of C/C++, a short is 16 bits, a long or int is 32 bits, and a long long is 64 bits. There is also int16_t, int32_t and int64_t if you want to specify the length for certain across multiple compilers. Not to mention bool and float and double. Also, FWIW, I have never encountered a C with a data type of byte. Where are you getting your information? If you are going to pick and choose a subset of C/C++ features, and then say "see, the subset I chose is a pretty feature-poor language" then yes, that will work every time. > High Level ASM is far more programmer friendly than C De gustibus non est disputandam. I respectfully hold the opposite opinion. (I have 20 years off and on, mostly on, in which assembler was my primary language, and now about eight with C++ as my primary language, so I have a basis for opinions on both.) HLASM has its place, and I still use it on a regular basis. But I suspect I am 5 to 10 times more productive (hours per function point from wish list to distribution) with C++ for the major functionality than I would be in assembler. Not to mention much more bug free: you never have one of those "oh crap, I forgot that I needed to preserve R2" type errors, nor one like I just had in my assembler code, where I coded an LH on what was actually a fullword field.
