On Tue, 24 Aug 2021, at 12:16, Bill Johnson wrote: > The hilarity continues. You say that length isn't a good measure > of complexity
I did, that's true. But in what I wrote below I also said that I wasn't claiming that my longest example was particularly complex. Probably the most complex code in what I did describe is in the general macro I wrote (which frontends Kedit's own menu support which is somewhat limited) to handle more complex menus. That's about 650 lines of code. You might be unfamiliar with Kedit; it's a PC version of IBM's Xedit, and it has lots of commands for setting/querying editor status & control parms, plus of course commands that directly edit data. Writing good Kedit macros is broadly comparable to writing Ispf edit macros. > and then search high and low for the longest REXX programs > you can find. That's because of that "40-line script" comment of yours which strongly implied you think that no-one writes larger execs. Incidentally I noticed I have an old copy of an IBM rexx exec here - ISPDTLC - which is 11,174 lines of code. It was written in 1989 so if the same thing still exists I would expect it might have grown a bit. I don't imagine it's trivial. Its purpose is to "Convert SAA Dialog Tag Language tags to ISPF source panels, message files, command tables, etc." Back in the early 1980s I wrote some long (& complex) COBOL programs. I wrote a compiler in COBOL for a document/data definition language I'd invented, then a sort of structured text editor that allowed a user to walk through a document that adhered to such a predefined structure adding, editing & removing text that complied with the definition, moving nodes (chapters, sections, pages ... whatever) around etc. It was, I think, a sort of precursor to a DTD-driven XML editor. It had to handle variable length snippets of text, so part of the editor implemented heap storage for those strings. The total amount of working storage the compiler supported was not enough to hold documents and all the control structures so I wrote a paging subsystem (still in COBOL) to move huge chunks of data in & out of working storage. Quite a lot of the data being moved was itself control tables for other parts of the data. When the thing was in debug mode one could follow the linked-lists that held the whole data-structure together, edit data and pointers & even trigger the program's garbage collector. COBOL was, of course, not the best language for this, but I was required to use an IBM-supported language that our installation had a licence for. It would have been a lot easier to use our Pascal compiler but that came from a German or Austrian university and was ruled out. -- Jeremy Nicoll - my opinions are my own. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
