× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Coolest code you've ever written
  • From: dhandy@xxxxxxxxxxx (Douglas Handy)
  • Date: Fri, 17 Mar 2000 17:52:43 -0500

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

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.