File Description Specifications - LSF9

Any custom files you defined in 8.0 using dbdef will need to be re-defined in 9.0. The definition data for files goes to the GEN data area and gets scattered to various tables like FILEDEF and DOCFILE.  This stays the same.

If you used SPLIT80 to create IO routines and file header copybooks, these will need to be moved to the IFS, in the new $LAWIDR/prodline/rpg folders. The source code itself does not change, only the location where the copybooks need to reside, and the /COPY statments that pull in the copybooks. 

There are some PDF docs from CUE that describe the IFS folders and what goes where. Let me know if you can't locate them and I will forward them to you.

 

 

 

Thanks for your reply.
We have the CUE pdf document titled: Managing Lawson Application Source Code in the Integrated File System (IFS) Directories LSF16. If there is another one that would be helpful we would appreciate your sending it.

We have created several files that we use in V8 that were created outside of Lawson in QDDSSRC. Created with CRTPF, not with dbdef. We could use dbdef to create these files in Lawson and then use Lawson I/O procedures to get rid of the F-Spec, but that would mean a lot of code changing. We were hoping there was a way to avoid putting them in dbdef and still accessing them from our programs in LID. In V8 we used F-Specs to access the file created with CRTPF and were hoping we could continue to, but are not sure how to do this in LSF9.

The document from CUE is the same one I'm using. Bob Geiger does a good job of listing all the options to consider. This is really new territory for iSeries users, and there are many directions you could take here.

Are your custom files in a MODLIB or your production Data Area?
How many Lawson and/or external programs access these files?
Are the custom files used by online and/or batch Lawson progams?
How is the data in these files used? Inbound or outbound transaction interfaces? Static custom setup data? Summary data for reporting?
Can you move your F-specs and native I/O to copybooks, or consolidate them as library routines?

You can still use F-specs, but maintenance is the real issue, as PTs are delivered to the IFS.  The iSeries concept of a MODLIB is still workable, but there are now additional steps for maintaining your code there.