Jason, your applications will be in for a big surprise if you follow this conversion path. For example, PIC 9(4) COMP is a binary numeric field which is BIG ENDIAN on mainframe, most (but not all) LUW and cloud systems are LITTLE ENDIAN. So you need to convert these fields, otherwise the numbers change dramatically. There are many other application specific data types that were possible -- you will have to examine all of the application programs for their field definitions and usage in order to determine the conversion rules needed to preserve application data.
For example, on your question about multiple copy books this means that different parts of the application have a different schema view of the database. You will have to understand the significance of this, for example a very common past technique is to have flag bytes which indicate which of the many copy books to use for mapping the specific IMS segment. So the same data, from the IMS database viewpoint, can look very different for the application. You will need to capture this logic in the conversion process, otherwise the data will be partly corrupted. Your questions indicate you are focusing on the easy part of the problem, and have not looked at the hard part at all. If you can't convert the data, then what happens to the applications? Is there a regulatory requirement? It may be cheaper to keep the old IMS system running as a data reference site and run ad hoc application exports using custom logic. Of course that requires understanding the applications in some depth. On Tue, May 21, 2024 at 7:08 PM Jason Cai <ibmm...@foxmail.com> wrote: > Dear Micael and all > > Thank you very much for your response and the valuable information > provided. Over the past few days, I discussed the DBD definitions with our > IMS DBA, and we have a similar setup > > where “The only fields that are required to be defined in a DBD are the > keys, indexed fields, and any other fields that the application wants to be > able to reference in Segment Search Arguments (SSAs). > > In the IMS system I work on, 99% of the segment fields are not defined in > the DBD.” > > We are considering moving away from the mainframe, and our historical > data is preserved on tape in IMS unload format and IMS IC. > > Initially, we wanted to convert the IMS database to a DB2 and then into a > MySQL database to facilitate the migration of backup data from the > mainframe to linux. > > Now, we are only planning to transcode the IMS unload files to make them > readable on the Linux platform. > > > We have all the necessary copybooks and are currently looking to convert > these IMS unload files from EBCDIC to UTF-8 encoding. > > Here are a few questions regarding the conversion process: > > 1.For fields in the copybook defined as PIC A, PIC X, and PIC 9, these > require conversion, but for numeric fields like PIC 9(4) COMP-1, no > conversion is needed, correct? > > 2 How do we handle the conversion if the database has multiple copybooks? > > 3 What is the process for converting variable-length fields? > > 4 If we choose not to convert anything, are there any tools available on > Linux that can read these IMS unload files in EBCDIC encoding? > > 5.Does the IMS unload file include information about segments, and how are > they encoded? > > Furthermore, we do not have access to Broadcom IMS tools or File > Manager. > > Could you please inform me if IBM has any utilities that can create the > unload format file from an image copy input? > > Any advice or suggestions you can provide would be greatly appreciated. > > Best regards， > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
