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
