I wrote a analyzer of DFHSM messages. Here, the most convient language is Natural. Which allowed me to generate the subroutine name base on the error message id. With an error handler to catch subroutines not yet written.
So, I could write the code to handle messages I cared about and let the error handler tell me about messages I hadn't written yet. In this case, there was no confusion about where the programmatically derived names where call, as they were all called from the same gateway routine > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Bernd Oppolzer > Sent: Saturday, September 24, 2022 10:13 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Assembler courses > > [EXTERNAL EMAIL] > > Sorry for this topic drift, but this is interesting, anyway. > > IMO, there are some really interesting use cases for such techniques, > for example > > - sort routines where the comparison functions is generic, that is, a > function pointer > - same for search routines > - same for dynamic arrays of structs, indexed by key structs (I > implemented one, using AVL trees) > - a function package which prints or plots other functions > > and so on. > > In C, I did this using function pointers. > In Pascal, I can pass procedures or functions to procedure parameters > (procedures passed as > parameters to other procedures), which is virtually the same as function > pointers, but IMO > looks nicer. This is from the 1960s. I never considered this as being > OO, but in fact, > all the above things, although implemented in procedural languages like > C and Pascal, > are TEMPLATES. > > If I really feel the need for such solutions (which I do sometimes), I > anyway like to stick > with procedural languages like, see above, Pascal and C, and I don't use > C++; > all the OO overhead makes me feel bad. > > See this video: > > Object-Oriented Programming is Embarrassing: 4 Short Examples - YouTube > <https://urldefense.com/v3/__https://www.youtube.com/watch?v=IRTfhki > AqPw__;!!JmPEgBY0HMszNaDT!s9tTUn_a7tgU7l_UQjPBgdsIbevvPpNynzvhic > 9sFjG3dkRDKnfRJXug7RowAIc4HD4Pxc0R1AZTDDBeXLllf-GwHYU$ > > > Kind regards > > Bernd > > > Am 24.09.2022 um 18:51 schrieb Tony Harminc: > > On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin < > > 0000042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > > > Far worse is the attempt to use OO techniques in non-OO languages. > >> "Where is this function called?" > >> "A pointer to it is saved in a struct." > >> After that, it's anyone's guess. > >> > > Years ago I inherited a good size (~200 kLOC) assembler program that had a > > lot of old-fashioned techniques. But at the same time it had a structured > > macro scheme that was quite advanced, and included an internal > subroutine > > call/stack mechanism. I updated the macros to generate symbols for the > > assembler xref/ADATA about what was being called and from where, and > only > > then discovered that the subcall macro had the option to load the "function > > pointer" (address) from a field in a "struct" (DSECT), thus making a > > complete static xref of calls impossible. The best that could be done > > (other than a complete control/data flow analysis) was to also log what > > updated those pointers in the struct, but correlating them was almost > > impossible. > > > > Bad code can be written using just about any programming paradigm in any > > language. > > > > Tony H. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
