× 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: 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.

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

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.