Automation in C++ vs HLAsm WAS: looking for limbo languages - how low can you go?

[Jon Perryman]

> On Wednesday, July 19, 2023 at 08:24:41 AM PDT, Chris Craddock <cras...@hotmail.com> wrote:
> I just delivered a brand new z/OS automation product that's about 40% HLASM and 60% C++.
> Yes really, it's IBM's C++ running APF authorized under LE in a z/OS STC. 

Hi Chris,

Sorry for the long delay, but things have now slowed down a bit for the next couple of weeks and I can put in some time if you are up for a little discussion.

Can we make a real world comparison of untenable in HLASM or in C / C++. A few years back, I too wrote a complete automation product but in HLAsm. I would love to make a comparison of our experiences to see what made major impacts the language made on coding ( faster, slower, reliability, pluses and minuses) and realizing you had the additional requirement of multi-platform. I've written code in many languages (including C / C++), each with pluses and minuses. I know how I would have written it in C / C++ but you actually wrote it most likely with the similar design. Congratulations on your delivery of a new automation product.

1. You said "C/C++ macro processor is pretty dumb compared to". This tells me you had free reign of C macro use. Many companies frown upon anything more than its very basic use. Google finds them so unacceptable that they intentionally omitted macro support when they rewrote C to create GO (GOLANG). What were your complicated uses of C macros? Out of curiosity, why didn't you use GO instead of C++ when it corrected some of the C / C++ flaws (at least by their interpretation - e.g. OOP) and is modern?

2. Because of macros in HLASM, I eliminated tedious, repetitive and error prone code of HLAsm. For instance, I easily implemented macros for the most important C++ functionality that I needed. Remember it doesn't need to be as C as long as it solves the problem. and eliminated a lot of the need for a great IDE (Interactive Development Environment).

     #CALC (R4)=PSATOLD>TCBFSAB>RSVNEXT>RSVR4>TMDSMD        Run pointer chain for SMD addr
     #CALC (R4)=PSATOLD>TCBFSAB@RSVNEXT        addr of RSVNEXT field
     #CALC (R4)=@PSA                   addr of PSA
     #CALC WRKPSA=@PSA                    Save PSA addr 
     #CALC WRKUSER=PSAAOLD>ASCBASXB>ASXBUSR8      Copy the userid

Capturing labels in a macro is simple using OPSYN for CSECT, DSECT, DC, DS and EQU.
@ is LA instruction, > is L, LH or ICM. +-*/ are the appropriate instructions according to the field attributes and length.
Logic is left to right instead of order of precedence but this is easy to work around.
Verified type compatibility (e.g. char to char and num to num) ensured field compatibility.
It doesn't need to do everything like C++ considering it took less than an hour to code and solved everything I needed. 

3.  HLAsm macros greatly simplified many coding processes at compile time rather than runtime. How did you implement things like messages, message doc and support NLS (languages)?

*======================================================================
00       #MSG  TYPE=MSG,MSGLEVEL=C,SRERC=NO,                           X
               'FREE CB ',char,'(',hex,') in ',char,                   X
               ' failed with header=',char,' trailer=',char
*======================================================================
::Explanation:
    An internal product error occurred. Program "ccc" tried to
    to free CB "aaa" located at storage address "bbb" but
    found either an invalid CB header "ddd" or the CB trailer
    "eee" did not match the CB header "ddd".
::System action:
    The storage is not freed. A storage creep may be
    occurring that could possibly lead to insufficient storage.
::Corrective action:
    Search the problem database for the solution to this error.
::MESSAGE_END

In HLASM, I created message modules and help modules. I find the C PRINTF a useful concept and built a more robust method to print messages. For NLS, copy the message source and translate messages into the appropriate language. The following is a sample message. Like C PRINTF, It's simple to make the call passing the message ID and each field required for the message. A message manual can easily be printed from message help modules. Messages help can easily be formatted for quickref distribution. Help for a message will be returned to the requester ( e.g. user terminal, console, web console, remote system, ...)  As for formatting help text like Help text explanation, the macro removed line ends allowing it to fit the device line size.

4. HLAsm macros provided simplified sentence syntax for complex actions thus greatly reducing the importance of a great IDE (Interactive Development Environment). How did you implement service requests passed between tasks that can have many optional options (e.g. SRE, receive msgs, wait, payload, ...)?  

         #SRESEND TASK=EXECMGR,          Send to exec manager             X
               TAG='EVENT',           Event exec / command             X
               USERTYPE=EVENT,        User from the specified event    X
               USER=0,                                                 X
               ERROR=SNDER010,       Request failed while sending     X
               MF=(E,WRKSEND)

Sends the active service request (SRE) from this task to the exec manager with the specified attributes. Was your implementation the common solution using multiple methods with names beginning with "set" to make it a verb and the last method being SRESEND. On a side note, using MF=E is a habit (not necessity) that I could easily address but was a habit that never bothered me.

5. When you said "It would have been untenable to write the whole thing in HLASM" can you give us a couple of examples of things that were untenable?

6. You said "IBM's C++ running APF authorized under LE in a z/OS STC". My design very rarely runs authorized and could easily be written in any language. In your z/OS STC design, did you run authorized regularly? Init for SSI, PC routines, one CB in CSA, system exits and start tasks. PC routines do the AR mode code. No SRB. No updates to CSA. What are you running that runs authorized on a regular basis in your STC?

7. You said "The programming models are just different" but I find those differences cause me to make different design choices. I would never code large C / C++ applications without an IDE because of the complexity. While mouse hover in the IDE makes info convenient, it's just a little more effort to position the ISPF edit cursor and press a PF key. A simple ISPF edit macro can easily get the name under the cursor, find it in the macro libraries and view the member at the desired line in the macro. Does anyone think the IDE isn't doing this different?

8. You said "the C/C++ compiler and libraries exploit the living shit out of the z architecture instruction set". It was wrong for me to say 5% because it's obviously too low. What unexpected instructions did you see? I suspect the new instructions you saw were added specifically for the C/C++ compiler (e.g. string instructions) which makes sense.

Thanks, Jon.

[Peter Relson]

Jon Perryman wrote
<snip>

#CALC (R4)=@PSA addr of PSA

#CALC WRKPSA=@PSA Save PSA addr

</snip>

I'd guess that this is not a good way of doing this, if it means that this address will be used as a base register, since that is both unnecessary and (worse) results in a zero address detection event which will complicate your finding "real" ZAD problems (and it is highly encouraged to run with ZAD active in testing to look for unexpected ZAD events within your code since you would generally know which are expected and which not).

But I don't specifically know what "@PSA" is, so my guess could be wrong. The two CALC statements are likely too simplistic if you are trying to reference the PSA's of all processors (such as within a loop), due to the concepts of prefixing and reverse prefixing.

Peter Relson
z/OS Core Technology Design

[Jon Perryman]

Hi Chris,

I can simplify this with 3 simple questions. Realize I'm very pro-C/C++ with a couple of caveats. I would have preferred C++ for my product if it didn't create more problems than it solved. I'm curious about your experience as a new convert to C++. Unlike any other applications, z/OS automation has it's fingers in everything (most can't even imagine). I suspect that non-z/OS automation is still primitive in comparison even though you combined it with z/OS.

1. Can you name a couple of things that would have been untenable in HLAsm?
2. Can you name a couple of things that were untenable in C++ that required 40% HLAsm instead of C++ inline HLAsm?
3. Were there tenants of IBM philosophy you violated because of inconvenience or difficulty? I must admit, I am guilty of this because of influence of others.

HLAsm has a huge number of flaws many of which are painful. Registers which C/C++ solves wonderfully. HLASM macro language needs major improvements. IBM wrote PL/s for internal use. The list is far too long.

Every language has flaws. As developers in the IBM world, we have cardinal rules drilled into our heads. RAS, backwards compatibility and simplicity to name a few. I find these problematic in C/C++ but most typical C++ enthusiasts quietly ignore the problems.

We claim C/C++ is a portable language but ignore exceptions where IFDEF can't even solve the problem. I suspect that some of the 40% STC in HLASM could have been written in C++ with some inline HLAsm but you made the decision to write it in HLAsm.

C/C++ APIs can be problematic. IBM ported C/C++ to z/OS but they didn't use traditional solutions. For example, fopen( RECFM=) is a great solution but not typical. Most solve this with new functions so I would expect setFopenRecfm() or fopenIBM().

An example of RAS problems is message handling in C++. It's not compatible with all environments, isn't self-documenting and not a consistent implementation.

With the exception of macro language, C/C++ is by far a superior language compared to HLAsm. C++ can be unnecessarily too wordy at times. Even JavaScript can have a better API implementation compared to C++. For example, compare the implementation of charting in JavaScript versus C++.

[Chris Craddock]

Jon Perryman wrote (a lot!) I interspersed his thoughts and my answers but it got rejected because the post was too long.
So this is part 1 of the reply ...

Jon >> What were your complicated uses of C macros? Out of curiosity, why didn't you use GO instead of C++ when it corrected some
Jon >> of the C / C++ flaws (at least by their interpretation - e.g. OOP) and is modern?

I am very comfortable with C/C++ and it's available on z/OS so that was an easy choice. AFAIK none of the other "cool kid" languages
are on z/OS and I wouldn't use them anyway. WRT your question about macros, for those who don't know me, I have written literally
millions of lines of system-internals HLASM code for ISVs over the years. I'm guessing at least half of that was HLASM macro code
because most of my career has been spent building software infrastructure for other developers to use.

I wrote a lot of HLASM macro code for this project too, but I really didn't need macros in the C++ code. When I say the C/C++ model
is different, it's no biggie to just write a function to do whatever you want it to do. You can even use different signatures and the compiler
will figure it out. And before y'all pipe up with "but what about performance?..." once you've got the logic working, you let the compiler
do in-lining and other optimizations. It's more than fast enough.

I was using the IDE (JetBrains Clion) mainly for productivity but also to flag any code that would not have compiled. I did occasionally
compile some of that on my Mac, mostly I just SFTP'd the source to z/OS and compiled/assembled it there. There were quite a few quirks
in the IBM implementation, but aside from some colorful language, they were easy enough to overcome.

Jon >> 3. HLAsm macros greatly simplified many coding processes at compile time rather than runtime. How did you implement things
Jon >> like messages, message doc and support NLS (languages)?

For HLASM, I re-used some macros I wrote decades ago for composing and issuing MLWTOs. For C++, I used the built-in streams, but
I had to deal with the fact that cout << "write some text" << endl; isn't properly serialized. Left to its own devices, you'll get scrambled
messages when 2 or more threads are writing messages concurrently. To avoid that I wrote a message processor class that composes
message fragments as a string and then wraps the output stream calls in ENQ/DEQ. The class also allows you to have the message
delivered via WTO by setting a flag, or a message number. Most messages just go to the STC job log, but real error messages also go
to the syslog. It was so easy that I ended up writing A TON of diagnostic messages which saved my bacon later. No need for NLS either.

Jon >> When you said "It would have been untenable to write the whole thing in HLASM" can you give us a couple of examples of things
Jon >> that were untenable?

The product is almost 32,000 lines of code. There's really A TON of business logic which is all C++. I wouldn't write the TCP/IP code in
HLASM - BTDTGTS. I also didn't want to write all the HLASM ATTACH/DETACH/ETXR boilerplate and recovery code for a heavily
multi-threaded app. I could, but it would just be egregious.

I created a class that implemented a pthread and some event management code. Then the major components (SMF manager, SMF
workers, Agent manager, Agent workers etc.) were derived from that. It really was a lot easier and cleaner. Trust me, if I did it all in
HLASM it would be at least 3-5x more code and would have taken a lot longer.


CC

[Chris Craddock]

And here's the 2nd part of the Jon/Chris magnum-opus...

Jon >> 6. You said "IBM's C++ running APF authorized under LE in a z/OS STC". My design very rarely runs authorized and could easily
Jon >> be written in any language. In your z/OS STC design, did you run authorized regularly? Init for SSI, PC routines, one CB in CSA,
Jon >> system exits and start tasks. PC routines do the AR mode code. No SRB. No updates to CSA. What are you running that runs
Jon >> authorized on a regular basis in your STC?

The new "product" is a data server that does z/OS job-monitoring on behalf of an enterprise workload management product that is
hosted on Linux/Windows. The Linux "Master" (Java) manages the schedule and communicates (via TCP/IP) with a bunch of (Java)
agent/gateways that perform job management functions on target systems including z/OS. The Master asks a java agent to monitor
certain jobs. The agent asks the data servers on each z/OS image (also via TCP/IP) to monitor those jobs. The data server listens on
the IEFU84 SMF exit. When it sees an SMF 30 for an interesting job, it copies data over into the data server, which sends a message
(again via TCP/IP) to the Agent and thence to the Master.

I designed and wrote the whole data server on my own. We had a 2-man team and the other guy did all the Java Agent work for
z/OS. Other than needing to support the same external interface as the previous product, I had complete design freedom.

The STC is an ordinary z/OS started task, but the job step program is a C++ main linked AC=1. The STC therefore runs APF
authorized, but the C++ code runs entirely in key 8 and problem state under LE and with POSIX=ON. The C++ code is heavily
multi-threaded, with a real TCB per thread, but that's all hidden inside the pthreads library and the wrapper class I mentioned above.

When the C++ code needs to interact with low-level z/OS functions, it calls ordinary HLASM functions (also under LE) which do
whatever they need to do. I did not use any inline assembler in the C++ code. This is really a piece of systems software. It has
ECSA control blocks, stacking PCs, RESMGRS, Dynamic Exits, Xmemory AR-mode etc. Most of the HLASM code runs on my
own home-grown supervisor state runtime because LE can't handle that.

The entire server runs in 31-bit mode with standard linkage (yes, really) because I didn't need 64-bit and I didn't want to deal with
the <ahem> "awkwardness" of dealing with 64-bit C++. It's built to be blazing fast and it is. It's all reentrant and exploits knowledge
of z/Architecture cache behavior and memory consistency rules etc. to ensure data never ends up in the I-cache and also to eliminate
contention between worker threads etc. The worker threads never even touch the same cache line.

It's safe to say this isn't a typical C++ application.

Jon >> 8. You said "the C/C++ compiler and libraries exploit the living shit out of the z architecture instruction set".
Jon >> It was wrong for me to say 5% because it's obviously too low. What unexpected instructions did you see?
Jon >> I suspect the new instructions you saw were added specifically for the C/C++ compiler (e.g. string instructions) which makes sense.

The business case for "new" instructions is (probably always was) for compiler exploitation. Even the 31-bit non-XPLINK generated code
would look pretty alien to most HLASM programmers. You can see what it's doing, but between the obscurities of C++ classes and the
instructions the compiler emits, I mostly just went "ok, I'm not man enough to get deep into those weeds". Fortunately, I never really had
any problems other than gritting my teeth over some of their compiler/library implementation choices.

BTW> I used the z/XDC debugger with c/XDC for the C++ code. I'm still a Dave Cole fanboy. I couldn't have done it without XDC.

CC

[João Reginato]

Very well explained.
Congrats
João


-----Mensagem original-----
De: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> Em nome
de Chris Craddock
Enviada em: quarta-feira, 9 de agosto de 2023 11:34
Para: ASSEMBL...@LISTSERV.UGA.EDU
Assunto: Re: Automation in C++ vs HLAsm WAS: looking for limbo languages -
how low can you go?

[David Cole]

Thanks, Chris. We'be both been at this for a VERY long time. -Dave

>-----Mensagem original-----
>De: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> Em nome
>de Chris Craddock
>Enviada em: quarta-feira, 9 de agosto de 2023 11:34
>Para: ASSEMBL...@LISTSERV.UGA.EDU
>Assunto: Re: Automation in C++ vs HLAsm WAS: looking for limbo languages -
>how low can you go?
>

>[snip]

[Chris Craddock]

Indeed we have my friend.

Sent from my iPad-Pro (forgive typos)
Reach me by phone at 281-770-1950

> On Aug 9, 2023, at 10:50 AM, David Cole <dbc...@colesoft.com> wrote:
>
> Thanks, Chris. We'be both been at this for a VERY long time. -Dave

[Jon Perryman]

> Peter Relson wrote:

>> Jon Perryman wrote

>> #CALC (R4)=@PSA addr of PSA
>> #CALC WRKPSA=@PSA Save PSA addr

> I'd guess that this is not a good way of doing

Very true Peter. Very bad choice of example. In C, we have reference / dereference which I was trying to convey. The other examples showed pointers. Thanks for the correction.

[Jon Perryman]

> Chris Craddock wrote:

> The product is almost 32,000 lines of code.

> HLASM it would be at least 3-5x more code

I'm really surprised that yours is so much less than my 80,000 lines (asm & macros). 2.5X is very significant.

> AFAIK none of the other "cool kid" languages are on z/OS

GO is a popular business language that on average pays $10,000 more than C/C++ according to Statista. GO is available for Linux on z and z/OS but z/OS requires the addition of the IBM z/OS SDK. This is far from a "cool kid" language.

> SMF manager, SMF workers, Agent manager, Agent workers

This confuses me because all automation products are event handlers that don't use managers (e.g msgs, SSI, exits, SMF, CICS, IMS, ...). The 3 phases of event handling:

Phase 1. Point of event. Can't be C++ with libraries. You can change attributes (e.g. msg text or route codes). Take actions related to address space (for example, MLWTO from the STC creates an event that has the wrong PSAAOLD, PSATOLD, user and more).

Phase 2. I think you call this manager but there is very seldom something to do here that wasn't performed in phase 1.

Phase 3. User exec processing of the event. I suspect that you call this worker. All other automation products have REXX task or in my case another STC running multi-tasked TSO to run execs with event variables set.

> your question about macros
I asked "complicated uses of C macros". My first steps into C forced code changes because macro language was highly discouraged. I assume you used it for very little.

> it's no biggie to just write a function to do whatever you want it to do.
> You can even use different signatures and the compiler will figure it out.

While it's true that you can write another function and use signatures, it can easily get out of control. IBM didn't find that acceptable when they implemented fopen in C/C++. Instead, they added keyword support. From experience, this is problematic especially for external API's. Compare charting/graph implementation between Javascript and C/C++ which demonstrates there is a better alternative.

> before y'all pipe up with "but what about performance?

Anyone who balks at C/C++ performance doesn't understand the compiler. It does the tedious things we as humans will not do in HLAsm and we must put our faith in it until proven wrong. It's most obvious on RISC computers where you're dealing with single bytes. Realize that IBM solves this problem with microcode in fast memory (e.g. memory speed & micro code logic for MVCL versus RISC moving byte by byte).

> I wrote decades ago for composing and issuing MLWTOs

Creating messages is the easy part. Making messages and their help text convenient to the user is far more difficult. In today's z/OS automation world, console is only 1 possible destination for messages. The automation log, TSO, TCP and others can receive messages too. How useful is SYSLOG to the average user? How useful is your STC joblog and who will monitor it? We don't expect users to use message manuals. Instead, they use help directly from where they are viewing the message.

> I had to deal with the fact that cout << "write some text"

You have at least 2 implementations for messages. COUT is fine for everyone else but this is automation where you have fingers everywhere. Assuming messages only go to the console, COUT can't direct to a specific console, route codes and other MLWTO options.

> Most messages just go to the STC job log,
> but real error messages also go to the syslog

How often do you expect your customers to recycle your STC? Since you don't have an automation log, surely you implemented message throttling? Automation is the 1 product that can make a bad situation worse at a critical time and it will get blamed for everything. There's a reason we deal with a roomful when a disaster occurs. The largest I've dealt with is 35 screaming managers for a problem caused by another product.

> writing A TON of diagnostic messages

Fair point but automation can be the destroyer of worlds. A panicked user scrolling frantically through the job log calls you demanding help. Maybe your STC abends and the job automatically purges. You're not using an automation log that is specifically designed to hide debug messages, show messages related to specific jobs, show messages related to a specific CICS user or ...

> I wouldn't write the TCP/IP code in HLASM - BTDTGTS.

How is TCP untenable and egregious in HLAsm? I found it simple. I chose to use 1 task for all connections that dispatched received data to the appropriate task and sent data. Startup / shutdown was the same for all connections and handshaking/termination by the protocol handling task. E.g. TN3270 screen scraping, HTML server and server-to-server. It doesn't get much more simple.

> I also didn't want to write all the HLASM ATTACH/DETACH/ETXR

Untenable and egregious? This was simple compared to task management and service request. Realize I had a secondary address space running TSO for event processing execs.

[Jon Perryman]

Thanks Chris for answering so many questions. I should have read part 2 before answering part 1.

> Chris Cradock wrote:

> I used the z/XDC debugger with c/XDC for the C++ code. I'm still a Dave Cole fanboy. I couldn't have done it without XDC.

Anyone who doesn't express accolades for z/XDC has never used it properly. I couldn't afford it when writing my product which I found traumatizing after using it for so long. You can't say enough good things about z/XDC.

> The new "product" is a data server that does z/OS job-monitoring

It now makes sense that this isn't actually automation but workload management possibly with scheduling. Very intriguing but a very different concept to automation.

> It's safe to say this isn't a typical C++ application.

With 40% HLAsm despite C++, it is obviously not a typical application.

> It has ECSA control blocks, stacking PCs, RESMGRS, Dynamic Exits, Xmemory AR-mode etc.

For my product, everything privileged occurred during startup with the exception of PC routines. I was forced to use CSA because of 24 bit mode risk but it was only a few hundred bytes. Just needed PC routine number and SSCT entry. Probably unnecessary but I didn't want to risk it for so few bytes.

> between the obscurities of C++ classes and the instructions the compiler emits, I mostly just went "ok,

I did the same thing but on Intel and decided it was enough to know it worked.

Thanks, Jon.

[Jon Perryman]

I forgot to mention that in my case C++ would have forced me into difficult design choices for automation. While events rarely change on z/OS, the possibility still exists. C++ can extract attributes (fields) during runtime which I can use to dynamically build each event type but I risk unwittingly missing a change in size. In HLAsm, I extract the same information during compile and verify the length matches the number specified on the macro call. I get a compile error letting me know the control blocks have changed and I must verify compatibility between releases and update the number on the macro call.

[Jon Perryman]

I'd like to hear other opinions about this comparison of C/C++ and HLAsm. The comparison revealed some interesting insights between C/C++ and HLAsm but was not as helpful as I wished because the products solved very different problems. There is a lot of motivated reasoning used when discussing C/C++ that doesn't match reality. I'm not saying this is a bad thing because we all have our personal preferences and we need to validate those choices of which I too am guilty. In my opinion, if you feel more effective using HLAsm with macros and it meets all your requirements, then you should code in HLAsm. In my case, I lose more in C/C++ than I gain for the projects I've worked on.

Google did a complete rewrite of C/C++ and called it GOLANG because they refused to slap more lipstick on this pig. They did a great job which also included important HLAsm features that do not exist in C/C++. We underestimate IBM smart design and the role HLAsm played in making z/OS vastly superior to Unix. GOLANG is not a cool kids language. It is a business replacement for C/C++ albeit slow in converting because of GOLANG decisions.

I'm not advocating for any specific language but most people ignore the impact that programming languages have on our design decisions. MVS would not exist if IBM coded it in C instead of Ibm assembler macros. my 80,000 lines of HLAsm versus 32,000 lines of C++ code seems substantial until you realize that I dealt with more than 20 very unique events versus 3, several very unique user interfaces versus 1, an automation log versus joblog, 11,000 lines of msgs / msg doc versus less than 500 and I could go on. While we can't say with any certainty, we know the C++ version of automation would be far more than 32,000 lines making the HLAsm implementation less than double. I'm guessing around 1.5.

"Add another function call" mentality is normal in Unix instead of keyword parms. GOLANG dropped KEYWORD= support in function calls because no one (except IBM) ever used it. In C/C++, IBM completely deviated from the norm by extending OPEN(dsn, RECFM=FB, LRECL=100). GOLANG forced IBM somewhat closer to the norm with ZOSRECORDIO.OPEN(dsn, "RECFM=FB, LRECL=100") but anyone else would have required more than 1 function call.

"Add another function call" mentality encourages bad design. It's been said that HLAsm attach is egregious compared to C/C++ pthread but that ignores 1 ATTACH versus more than 50 pthread functions. It also ignores when and where pthread functions must be called (attached task / attacher task). GOLANG removed pthread altogether for good reason. GOROUTINES encourage multi-tasking mentality by providing the bare minimum suitable for most needs instead of all possible scenarios. With many business computers now exceeding 24 CPUs, multi-tasking simplicity is far more important (e.g. Kubernetes cloud containers).

Macro languages play a critical role in many programming languages. Evolving OS/VS1 to z/OS was only possible with the IBM assembler macro language regardless of the programming language being used. For example, consider the stagnation of file processing on OS's written in C. Unix files have not changed since 1969. z/OS files (DFSMS) documentation is now 50 manuals because of the DCB macro. DCB is not possible in C without thousands of functions.

C/C++ macro support was dropped from GOLANG because it served no useful purpose and caused bad programming practices. GOLANG chose to implement macro support consistent with other programming languages (Python, Java, JavaScript, Perl, PHP and more) which provide functionality similar to IBM HLAsm macro language but at runtime instead of compile time. Macro languages are now implemented as follows:

1. The macro language is the programming language thus no macro language documentation.
2. The macro language must be compiled and run. Everything is runtime. Nothing is compile time. You can't warn the programmer of problems during compile time. You can't eliminate overhead by moving logic into compile time.
3. These languages have "reflection" which is the ability to extract program information. In terms of an HLAsm macro, it can get field information (e.g. t'x or l'x) or instruction information using OPSYN to a macro. Reflection is far more advanced compared to HLAsm macros.
4. I disklike that in GOLANG, it's difficult to insert code like an HLAsm macro. Instead, you must design to build new source and compile. This somewhat complicates their use and takes time to become accustomed.

Most people ignore that C/C++ and HLAsm are very outdated languages. C/C++ is constantly upgraded but to no avail thus the need for GOLANG. HLAsm has been a stagnant language for years. HLAsm hasn't replaced its macro language despite REXX replacing runtime languages everywhere else. Despite the ability to create HLasm macros like my #CALC, IBM hasn't made the HLAsm toolkit more friendly and usable.