|
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 RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---END
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.