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



James,

>I would like to see a new field level keyword in DDS: VCP

>I ... thought that something like this would really allow for
>some incredible modularity. 

>Any thoughts?

I think the "incredible modularity" goes out the window as soon as you
go beyond the field level stage.  If you have to deal with the entire
buffer, the VCP loses its modularity and you may as well code it in
the RPG (or other HLL) program.  

At the field (only) level, it has some possibilities but (IMHO) not
enough to make it worthwhile.  This is because, as you said, some
validity checks are dependent on other field contents.  Even if you
had some variant of a command's DEP clause to limit when the VCP was
called, I still don't think it would be capable enough to eliminate
some checks remaining at the record format level.

I prefer all the validity checks to be in one spot (the HLL code),
where I can process them consistently and return an error message
subfile in top-down order.  From a user perspective, I don't care for
some checks happening via the DDS and others via the HLL.  And I abhor
keyboard locks, though I understand you can circumvent those now by
using a system error message subfile.  The only thing worse than
keyboard locks on errors is having a 5251-11 type buzzer go off when
an error is detected.

I would also be concerned about the potential performance hit of the
VCP, especially with OPM programs.  Not only would you increase the
number of (potentially dynamic) calls, but I suspect you'd increase
the I/O besides.  Usually, when I have a field I am validating against
a table, I also display output-only field(s) with feedback to identify
it.  If the VCP couldn't populate these, then I'd have to redo the I/O
in the HLL.  

The bottom line is that I don't mind doing this stuff in the HLL.

Now, what I *really* would like to see is a record-format level
keyword to position the cursor by fieldname.  Like an inverse of the
RTNCSRLOC(*RECNAME ...) keyword.  With DSPATR(&fld) we can eliminate
indicators for attributes (Yeah!!) but cursor positioning is still a
bugger.  We either need to use indicators or something like QDFRTVFD
to get the coordinates to use with CSRLOC. If we had an option to do a
CSRLOC(*FLDNAME &fld) it would go a long way toward improving DDS.

Just my .02,
Doug
+---
| 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-Ups:
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.