Language enhancements (was CF spec)

["James W. Kilgore" <qappdsn@xxxxxxx>]

Hi all,

I've been watching this thread on RPG400-L about the CF
enhancement to RPG and there was discussion of other
enhancements that are also desired, like improving CL.

Since this post is not really related to RPG specifically,
I've echoed it to the midrange-L list.

But DDS is still the common method for display file
definition used by RPG, so I thought I would throw in my 2
cents on an enhancement I would like to see.  Maybe we can
hash out some of the particulars and the powers that be can
let us know if it's viable.

I would like to see a new field level keyword in DDS: VCP
(Validity Checking Program).

I was out puttering around in the garden this past weekend
and thought that something like this would really allow for
some incredible modularity.  A trigger works when a file is
written to, this needs to be done upon display file read.

This would allow for a display file to automatically call a
program which can do a code lookup (or whatever) for valid
values instead of hardcoding them into a display file or
data dictionary.  And just like hardcoded validity checking
rules, this is performed before the program receives the
record.

I imagine a record level system-to-program field for VCP
pass/fail would be needed so the record would automatically
be redisplayed if errors existed. (Just like the validity
checking keywords work now)  Possibly with the name of the
error message subfile in use to display any error messages
created by the VCP.  If not, the same method used to display
the "Value not valid" generic message that now appears.  Oh,
having PC (Position Cursor) as a field level variable would
help and eliminate any need for passing indicator arrays.
(We reverse image, position cursor invalid fields along with
a subfile error message as a shop standard)

Naturally, the VCP would need to know the job/user/job
number, display file name, record name, or maybe the entire
(via API) WORKSTN file feedback data structure and/or
requesting program status data structure.

Up to this point I don't see where this would be extremely
difficult.  Sort of like allowing for exit points.

The tricky part, to make this work really well, would be to
make available the entire display record.  Often times one
would need to know the value of other variables beyond the
one being tested in order to perform a proper validity
check.  Like I would need to know the sales order type to
properly qualify payment terms.  Throw in some
appropriateness testing above mere hit/no hit on code
lookup.

I would be content to specifically code order type as a
"also pass" variable to the terms code VCP.

But then again, I have to leave something for RPG to do ;-)

Something like this, IMHO, would be a great candidate for a
user written service program to enforce data entry rules.
Preemptive instead of reactive like a trigger.

Any thoughts?



+---
| 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
+---