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.
- Re: Automation in C++ vs HLAsm WAS: looking for li... Chris Craddock
- Re: Automation in C++ vs HLAsm WAS: looking for li... Chris Craddock
- RES: Automation in C++ vs HLAsm WAS: looking f... João Reginato
- Re: RES: Automation in C++ vs HLAsm WAS: l... David Cole
- Re: RES: Automation in C++ vs HLAsm W... Chris Craddock
- Re: Automation in C++ vs HLAsm WAS: looking for limbo langu... Peter Relson
- Re: Automation in C++ vs HLAsm WAS: looking for limbo langu... Jon Perryman
- Re: Automation in C++ vs HLAsm WAS: looking for limbo langu... Jon Perryman
- Re: Automation in C++ vs HLAsm WAS: looking for limbo langu... Jon Perryman
- Re: Automation in C++ vs HLAsm WAS: looking for limbo langu... Jon Perryman
- Re: Automation in C++ vs HLAsm WAS: looking for limbo langu... Jon Perryman
- Re: Automation in C++ vs HLAsm WAS: looking for limbo langu... Jon Perryman
