Re: members in a file

Check the outfile model files. Most (all?) specify LVLCHK(*NO) so no
worries about format changes. I'm in the habit of specifying the model file
in source for compiles, then using run-time redirection to the file created
on-the-fly.

On Dec 27, 2007 4:39 PM, Mark S. Waterbury <mark.s.waterbury@xxxxxxx> wrote:

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.