|
Don, My favorite project was a program generator I wrote back in '87. IBM had just published the SAA guidelines for display formatting, and I wanted to create standardized programs which I could easily enhance over time. I was tired of manually copying an existing program as a basis, then modifying it to fit the fields and editing/validation required by the new program. So much of the shell structure of a program could remain intact, and it seemed too much like busy work to just methodically modify sections of the code to fit a different set of files. I hate repetitive work -- that's what computers are for! So I designed my own little source language to define the fields to be displayed and the options to apply. The source did not define the screen layout or the actual code involved. The generator used the source and a data dictionary to manipulate any of a variety of "shells" which were like program templates with embedded commands to the program generator. This caused the generator to create a version of the shell customized to the fields/options desired. The generated source was then automatically compiled. For example, file maintenance type programs went through a shell which created (for the S/36 where this originated) the following: - OCL including optional PROMPTs and substitutions - $SFGR screens, laid out to SAA design specs by the generator - RPG II monolithic code to support the features requested The standard features included (for the S/36): - SAA compliant screen layout and interaction - Full DUP key support - Numeric fields shown with edit code/words (input too) - Optimistic record locking with record level checks for changes - Undo operation for record deletions - Auto increment fields/subfields, even with concurrent multi-users - Cursor sensitive prompts to subfile-lke scrolling displays for selecting values from all ancillary validation files - Batch accumulator support, auto-dup support, etc - Printed audit logs - Etc All the common field validations could just be coded as an option in my little source language. In those cases where they were not sufficient, you just coded C-specs following the field name and these were merged into the appropriate spot in the source. There were also exit points for inserting calcs at other strategic spots in the source. The net result was that you *never* had to modify the generated source. (If I found a case where that seemed necessary, I created a new exit point or option instead.) I could change my shells to add features or fix a discovered bug, and simply regen all programs by passing it through the generator again. Every program had the new feature or fix virtually overnight. Then I realized that the source contained enough information about the screens to have it create the bulk of the user documentation. So I had it generate help areas for every field on the screen, and tied them to "help tags" in a Revisable Format Text (RFT) document. It also autogenerated the RFT document complete with heading levels, bold/underline attributes, paragraph indenting, etc and inserted verbiage from the screen and described the field and valid contents. It put "stop codes" where it thought a programmer should follow-up with more explicit verbiage. It then inserted the document in a folder for customizing with DW/36. You'd just have to bring up the document, search for the next "stop code" and adjust as necessary. The vast majority of the text was already there. Then in '88 when I switched to the 400, I simply changed the shell to create DDS instead of $SFGR, a CLP instead of OCL, and RPG III instead of RPG II. Viola! The same simple source completely regenerated code which was now a fully "native" program, including using F3 instead of Cmd7, etc. Typical "source" members were 30-50 lines, and rarely exceeded 200 statements, but generated 4000-7000 lines of code to support it, plus a DW/36 or OV/400 base help document. Alas, I left that firm in 1990, and they retained rights to it since I was an employee when I wrote it. Doug +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.