> 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.
