|
Thanks all for the initial feedback on DDS validity checking enhancement. Maybe I should have thrown to the list the problems, instead of proposing a solution. So much for thinking out loud :) OK, here's a sample scenario: Installation in a 40+ year old company with multiple branch locations but they haven't changed since dirt and am told that no new expansion is in the future. So we have a branch location file with pertinent information and in our data dictionary we define a branch location code with a list of valid values. The PF and display files reference the data dictionary. All is good. I've been with this outfit for 22 years and hard coded validity checks for this worked. Now things start to change. They go on a buying spree. 8 new locations over a two year period of time. Now I can change the data dictionary, no problem. Until I can CPYF the PF (and all other files that contain a branch code), DFU fails Until I can get everyone out of the display files that have branch code, they fail. Sooooo, I was thinking that if I had a field level VCP, display files and things like DFU would work as soon as an entry was added to the branch location table. Now I wouldn't expect remote controllers to handle this, since some disk I/O would more than likely be involved. When the program finally receives the display record, even if it repeats the same I/O, this should not have too much of a negative impact since the record should still be in cache. So the VCP would be evoked after the existing validity functions are performed, but before returning the record to the calling HLL. I envision a user written VCP to have no more impact than a called program with LR off and the files left open. It should at least retain last key retrieved and compare this to the current request and if same, skip even trying any I/O, send back the same results. There were suggestions to use triggers, but, IMO, they are too late into the transaction cycle to be preemptive. If a single panel writes to two files, each containing the branch code I could write to one file, wait for the trigger feedback and error back to the user. It could work, but I would still have to perform the validity checks in my program to determine if I even -should- write to file one. Also, I imagine the VCP would be named in the data dictionary right along with column headings and edit codes, not in each display file DDS. Oh well, I'd settle for something to allow for position cursor without an indicator. Or even the ability to compile a display in use and have users run off of a copy in QRPLOBJ until they close the file. Like a program can be compiled while in use. Validity check changes don't trigger a level check. Thanks for hearing me out. +--- | 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-2025 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.