I have a few hundred RM files that consist of various fields (comp, signed strings, etc) I'd like to convert the files to MF format and remove all the comp fields (space is not really a concern anymore) I had a look at the utility which made all my files inaccessible. I can view the files with the Classic File Data tool but when I try to access them through a program, I get error 36 and when I run recover1 I get "corrupt KiB".
If I have to write programs to convert from Rm to MF format that's fine but I'd like to hear opinions or alternative solutions to this.
- Does "a few hundred" refer to unique file definitions, or is there a small number of file definitions but a large number of physical files?
- There would be no need at all to go through a data type conversion as you convert the files, as Visual COBOL should support all the data types you have in RM. I do understand, however, that this might be a convenient time to make the data type conversion.
- I deduce from your post that you are attempting to do this conversion on the RM files, before moving them to Visual COBOL. What utility does "a look at the utility" refer to? I am not aware of a data type changing utility on the RM side.
If there are are large number of file definitions involved, it might be useful to create an automated way to derive the new file definitions from the old, as well as a fully formed RM COBOL file conversion program for each file. For some consultants (!) this would not be a very difficult issue. Note, however, that there would need to be some intervention in situations where a file definition contains multiple record types or other REDEFINES. But it remains that a significant part of the process can be automated on the RM side.
1. If I understand your question correctly, I have a few hundred files, each with its own unique file descriptor.
2. I would like to remove the comp from the pic 9 fields.
3. The utility I referred to is in the visual cobol sample program list, its called "RM to MF data conversion" under the "Convert ACU and Rm to MF" section. It doesn't change the data types (and in this case was useless for me)
Here's a plan I had (applies to only indexed files),
copy all file descriptors and rename.
remove all the comp fields
write and run a program that reads all the rm files and outputs as a sequential file. (this program would use the directive $set filetype"21"
write and run another program (with no file type directive) using the new file descriptors to create new indexed files.
And, MOVE CORRESPONDING has no advantage over individual MOVE statements in terms of compiler or runtime efficiency.
An automated tool can correctly identify situations that need the developer to resolve. In fact, the automation can provide inline comments and a skeletal IF statement with all of the necessary MOVE statements so that the developers job is merely to identify record type information or other situations to resolve which 'leg' of a REDEFINES to use.
Herrfrofro has identified a situation - hundreds of unique FDs to be processed - that will almost certainly demonstrate a large variety of the twists and turns that can show up in record layouts. COBOL developers have been very clever at times to impose their will on the COBOL language. I've been at this for quite a few years, and have seen a lot...
When an automated tool is generating the code (as I have proposed above), "less lines to code" doesn't carry much benefit.
To review, I suggest a tool (and have actually implemented one) which does the following:
Using a standard, syntactically correct RM/COBOL program containing the file definition, generate a copybook with the new file definition (the SELECT sentence will not change) and an annotated program (in my actual instance) or programs (to fit HerrFroFro's scenario) that does the file conversion. The annotations will direct the developer, using a text editor, to situations where automation cannot determine which variation of a redefined region to MOVE.
I understand the lure of MOVE/ADD/SUBTRACT CORRESPONDING, but my recommendation is to confine its use to small groups with no subordinate groups, rather than 01-level. This caution is due to the limitations imposed by REDEFINES and OCCURS which can lead to hard-to-find bugs. (A programmer, reading a MOVE CORRESPONDING statement, may impute to that statement MOVEs that the compiler does not actually create.) I have worked in shops that ban the use of CORRESPONDING for this very reason.
By the way, my actual instance uses XML Extensions to do the work. No need to write code to scan a COBOL program when you have a compiler to do the heavy lifting!