Tweet
On Tuesday, April 07, 1998, 09:25 AM, scott bernard wrote: I am having trouble copying a AS400 database file (create with DDS and CRTPF) using file members in OCL. OVRDBF FILE(FILE1) TOFILE(LIB1/FILE1) MBR(MBR1) // IFF ?F'A,FILE1'?/0 CPYF FROMFILE(LIB1/FILE1) TOFILE(LIB1/FILE2) FROMMBR(MBR1) TOMBR(MBR1) The numbers of records is always retrieved from the first member, ignoring the OVRDBF. Without testing for an empty file, the CPYF bombs if the file/member is empty. Can I CPYF a file/member in OCL without bombing? I was going to suggest using the OVRSCOPE on the OVRDBF command... but I just checked the code QEXCLEF and it does not honor overrides for the ,FILE request(s). If I remember correctly there is a similar function in OCL to OVRDBF for the S/36; can you use that instead.?.? Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.
-
-
Using CPYF for PF member in OCL
Hi Bill, Sorry it took some time to get back to you, but here we go! What I can do is to describe in general terms what activities my current S/36-conversion project has included. We're moving from a mixed environment; early S/36 applications living under the same roof as recently developed ILE/RPG-applications. Since they're all running against the same database, including flat S/36 files, part of the conversion had to do with externalizing these file descriptions, another part was source conversion; from OCL to CL, from RPG/II to RPG/III, from S/36 menus to native display file menus. Having defined the activities needed for the conversion and having analyzed the amount of programs, database- and display-files, menus, etc. that would be impacted by the task, I evaluated three tools that would automate the S/36-object and -sourceconversion to a certain degree; I finally chose Target/400 from EPI, which eventually did a very good job. Anyway here are the tasks involved in the project: 0. Analyze current applications. What and how many programs, files and other objects are involved. 1. Establish conversion- and test-environment. Creation of libraries, testuserprofiles, jobdescriptions and outputqueues, etc. 2. Externalize database All internal described files are externalized and data copied to new files. Logical files or OPNQRYF are created to replace S/36 sorts. Overrides are changed to reflect the new file names (if changed). 3. Conversion of OCL and RPG/II-programs. OCL-members converted to CL and compiled; DSPF36-members converted to DSPF and compiled, almost entirely done by conversion tool. RPG36- & RPT36-members converted to RPG and compiled, requiring some manual intervention due to various more or less appropriate S/36 coding techniques. 4. Externalization of RPG/III-programs Internal file and file references mapped to external filedescriptions using tool and carefully testing & correcting errors or tool-shortcommings. 5. Conversion of S/36 menus. S/36 menus converted to native display file menus, done entirely by tool. 6. User test. Users testing the converted applications in test-environment, and eventually against production data under very controlled circumstances. 7. User information. Information what is about to happen, when it will happen, and what has changed. 8. Change enviroment. QSPCENV systemvalue changed to *NONE, new production object- and datalibraries put ahead in user library list (system value and/or job descriptions). 9. Follow up. Correction of any problems caused by environment change and evaluation of project. I hope that the above is not to detailed or off track, if you need more information or other aspects of the project covered, please let me know. Best regards, Carsten
Comment