× 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: Validity checking in DDS
  • From: Rob Berendt <rob@xxxxxxxxx>
  • Date: Mon, 2 Aug 1999 10:18:01 -0500

I can see adding simple things in the DDS, like some of the existing 
keywords.  These can get downloaded into remote controllers, like 5294, 
5394, etc.  When these get an error it doesn't even come back to the 400.  
Increases response time.  A validity checking program might be a bit much 
for the remote controllers to handle.

Also, by using a trigger instead of a DDS keyword you are making the 
validity checking available across all methods of changing the data:  
your existing green screen application, DFU, and any GUI interface.  
Bigger bang for the buck.  Check into triggers.  They meet all of 
your concerns:  complete record and all.  However if you want some hook 
into green screen and validity checking programs, you could look at 
writing a custom command instead.  Really ugly for many data entry 
screens though, IMHO.







jimtowns@us.ibm.com on 08/02/99 09:00:44 AM
Please respond to MIDRANGE-L@midrange.com@Internet
To:     MIDRANGE-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        Re: Language enhancements (was CF spec)

I can't see the value in this type of change.
The reason being is you have to code (RPG) the program that will do the validity
checking and execute it on the system before returning control to the RPG
program anyway. I think this would add more overhead to the system
unnecessarily. As it is now, you would check for a changed field on the DDS and
if it did change call an external program from your RPG program to do the
validation. You could also do validation on all changed fields not just one in
one program cycle. Using this new function would require several program cycles
(several program calls.) to execute.

The advantage of using hard coded values in DDS is that the 5250 screen session
will do the editing without returning to the RPG program (no programming). This
was great in the early years when system performance on a 34 was not great and
the baud rates on leased lines was at best 9600.

I may have misunderstood your thought but that is how I see it.



Jim Townsend
AS/400 Specialist
CDI Professional Services
Telephone (USA) 802 769 8144
T/L 446-8144
E-Mail Jimtowns@us.ibm.com


"James W. Kilgore" <qappdsn@ibm.net> on 08-02-99 03:55:44 AM

Please respond to MIDRANGE-L@midrange.com

To:   rpg400-L@midrange.com, midrange-L@midrange.com
cc:
Subject:  Language enhancements (was CF spec)





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



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


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


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.