× 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, Rob:

Generally, IBM is pretty good about ensuring "upwards compatibility" from one release to the next. Even if an outfile layout changes, IBM always adds any new fields to the end of the record, so old programs will continue to work, though you probably will need to issue an OVRDBF with LVLCHK(*NO) or compile the program with a version of the file that has LVLCHK(*NO) specified.
Also, if you access the *OUTFILE as a table with embedded SQL statements, instead of "native I/O" then this notion of "level checks" does not even apply. With SQL, data type compatibility checking is done on a column-by-column basis, rather than for the entire row or record (as with native I/O). Also, IBM usually leaves any unused fields in place, and they will contain blanks or zeros after a new release that no longer uses those fields.

So, I am not sure why you "strongly recommend" against using commands with *OUTFILE support.

Thanks,

Mark S. Waterbury

> rob@xxxxxxxxx wrote:
Perhaps you and I come from different worlds. I am thinking "pc app" typically denotes a different developer than the person who traditionally develops the server applications. Thus your average pc app developer may be looking for something like you were looking for originally - a nice SYS* type of table (or view) that would return them a list of members. Thus the server developer's assignment would be to develop something that would either create that table, or, return result sets that the pc app developer could get via a stored procedure. Thus, I would try to do more of this on the server and not within the PC app.

Now, whichever method you use I strongly recommend that you do NOT use a DSPFD to an output file. Instead, search the various API's and use those instead. The reason that I am suggesting this is, when you upgrade your version of i5/os, do you really want to have to debug a client based application that is blowing up because the layout of the output file changed? And, do you want to support two versions - one for your test lpar on FutureVersion and your production lpar on CurrentVersion?

Rob Berendt

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.