MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 1999

Re: Language enhancements (was CF spec)


  • Subject: Re: Language enhancements (was CF spec)
  • From: "James W. Kilgore" <qappdsn@xxxxxxx>
  • Date: Mon, 02 Aug 1999 12:30:41 -0700
  • Organization: Progressive Data Systems, Inc.

fixed

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






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact