|
Alternatively, you could do DSPFD *MBRLIST, and that gives you a one letter attribution of if it's source or not. Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 "i" comes before "p", "x" and "z" e gads Our system's had more names than Elizabeth Taylor! 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com http://www.as400connection.com vhamberg@comcast. net Sent by: To midrange-l-bounce Midrange Systems Technical s@xxxxxxxxxxxx Discussion <midrange-l@xxxxxxxxxxxx> cc 11/17/2006 05:01 PM Subject Re: Saving multiple source files to a single savf Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> ODOBAT has only whether it is PF or PF38 - the SRC part comes from the file description. Makes a weird kind of sense if I think hard enough!! -------------- Original message -------------- From: Wayne McAlpine <wayne.mcalpine@xxxxxxxxxxxxxxxxx>
There is a field ODOBAT in the output file that identifies that record as a source file. When your program reads the file, check that field and skip the save if it's not a source file. You will have to read every record in the file and save only the source files. fbocch2595@xxxxxxx wrote:I won't b/able to dspobjd to a file and then savobj all the entries
though
since some are not prefixed by Q.Thanks for your help -----Original Message----- From: rob@xxxxxxxxx To: midrange-l@xxxxxxxxxxxx Sent: Fri, 17 Nov 2006 4:00 PM Subject: Re: Saving multiple source files to a single savf I did mention doing the DSPOBJD to an output file, reading that,
searching
for ODOBAT = the designator for source physical file. Then construct
your
SAVOBJ command from that. However, it would be a disservice of me to not suggest a different alternative. The problem with using IBM output files is that they can, and do, often change with new releases of OS. Often I will use the
Object
APIs instead. After all, who wants a "record format level check" when you're already wrestling with other surprises resulting from an OS upgrade? Granted, one way to get around most record format level checks is to eschew the use of any F spec in RPG to open that file and to use
imbedded
SQL instead. Being careful NOT to use "select all from ...". Because selecting all from a file that has been updated to hold Y number of
fields
into an externally defined data structure that only had X fields at the
last compile is a fatal error. Once upon a time, several versions back,
it wasn't. You just hoped that they kept new fields at the end. 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.
-- 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.