|
If you have a few files to do quickly, create the
DDS with name same as s36 flat file, rename s36 file to something else, compile
DDS, then cpyf with *nochk optio to put data back. As long as DDS kept all the
positions/attributes the same, the s36 pgms newver know the difference. Any
future native pgms, qry, sql will be fine, unless you have decimal data errors
in fields (bad 36 code not intializing numeric fields, etc). There are several
S36 to native conversion tools available (check Search400.com) I have used
several, and if you have good F & I specs, either in seperate source, or in
RPG pgms, the DDS creation can be fairly automatic (like in hours, not months
(but I have not met a s36 system that didn't have some "exceptions")). I have
had several s36 to 400 conversions that went to native files first, then pgms
over the years. BTW there might be a way in a LF to substring the K000001
and F000001 fields in the flat file, but don't know what that would do with sql
& qry & decimal data problems. Besides, that's just as much work as
creating real DDS. If you need more details/experiences, send me an email. jim
franz
|
As an Amazon Associate we earn from qualifying purchases.
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.