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




Hi Alan,

1. Lookup the field type and size in the MODATA file and hardcode. Ugly.

I just want to point out that the sizes of the fields doesn't HAVE TO match the external definition. External definitions are usually conservative in size because of the disk space issue. On the other hand, you can define a big honkin' field (that's the technical term) in your program and let SQL convert from the external field to yur big honkin one.

That way, if the size of the file in the file is expanded, your program doesn't have to be changed.

Personally, I prefer NOT to use the external definition so that when I want to change my record layout, I don't have to find every program that uses every affected field.

2. Define the file in the F specs but never open. Reference the field
from the dummy file. Real Ugly.

And pointless.  What would this gain you that a "E DS" wouldn't?


3. Define a qualified external data structure for MODATA and base it on
a pointer so it takes no storage. Reference the fields from the
qualified data structure. Not as ugly but fills up compile listing with
a ton of junk.

When I deliberately WANT to use the external definitions, this is the method I use. You can put it in a /COPY member so that it doesn't fill up the source member with "a ton of junk". In addition, you can put OPTION(*NOSHOWCPY) on the H-spec, and that "ton of junk" won't be in the compile listing or debug view, either.


4. Define am empty table for each data structure and reference as
external data structure. Really ugly.

I don't see how this gains you anything over option #3.

Again, I'd either just define some big fields ("bigger than you'll ever need") or I'd use an "E DS", qualified and based on a pointer.

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.