Lessons Learned from users upgrading from WebSphere Data Interchange V3.2 to V3.3 on zOS
MichaelGlenn 1200004UQ7 Visits (2920)
The End of Service date for WebSphere Data Interchange version 3.2 on z/OS was April 26, 2010, and I have seen a number of problem records dealing with the upgrade. I thought I would share some of the Lessons Learned that users have experienced while migrating to the new version of WebSphere Data Interchange version 3.3 on z/OS.
The following are a few of the Lessons Learned that users have encountered while going through the steps outlined in the WebSphere Installation Guide for z/OS. This guide can be downloaded from the WebSphere Data Interchange publications and manuals site.
Step 16: Import Default Data
If EDIJDAT1 encounters ABEND S0C1, the likely cause would be from using SEDILMD2. Change it back to EDI.
If EDIJDAT1 encounters ABEND S0C4 in EDIIOS, remove EDI.V3R3M0.SEDILMD1 from APF or apply PTF UK43744 to 3.3.
To check APF authorization:
If EDIJDAT1 fails with: Program failed attempting to initialize the Service Director. Return code = 4. Extended return code = 12
If DB2 errors are not present in joblog, then the likely cause is that INSERT statements were not run successfully from EDISDB2 (Step 11)
Step 17 -- EDIJXPAD
If EDIJXPAD encounters ABEND S0C1, the likely cause would be from using EDI.V3R3M0.SEDILMD1 in the Joblib. Change it back to your 3.2 or 3.1 version of SEDILMD1.
If EDIJXPAD fails with: Program failed attempting to initialize the Service Director. Return code = 4. Extended return code = 12 and if DB2 errors are not present in joblog, then the likely cause would be from incorrect PARM data, for example a comma in PARM('ENU,DIENU'). The correct parm format is PARM('ENU DIENU'), where DIENU is the SYSID.
If PTF UK47190 is not applied to your 3.2 system, CTLFILE might be incomplete for translation tables and code lists, and this would lead to missing tables on 3.3.
If STEP003 export of a specific ADF hangs, or is looping, then apply PTF UK39721 to 3.2 and edit the steplib in STEP003 of EDIJEXPD to comment-out the SEDIV3R2 lib
If STEP003 export of maps do not include Comments -- apply PTF UK27714 to 3.2 and edit the steplib in STEP003 of EDIJEXPD to comment-out the SEDIV3R2 lib
If STEP003 encounters B37 out-of-space ABEND and the following error against EDIEITBL dd, then apply UK12324 to 3.2:
Step 18 -- EDIJEXPD Import
If STEP004 import of standard fails with EI0025 error, then apply PTF UK24746 to 3.3.
STEP005 Data format Record ID Information objects that are not tied to an existing data format dictionary are not migrated, but implies they are not currently in use anyway, this is a limitation of export, and there is no fix available.
STEP006 control strings that are not tied to an existing map are not migrated. This is a limitation of export. Previous release migrations used DB2 unload/load utilities, that would have carried forward any "detached" control strings.
If STEP006 import of 3.1 map hangs, or is looping, then apply PTF UK33664 to 3.3.
If STEP008 import of validation tables (code lists) fails with:
STEP008 import of validation tables (code lists) encounters the following messages:
The latent EI0025 error (on import) is the result of the KEYLN value being incorrect in EDIPSTD on the source system (3.2 or 3.1) for validation table "103X" ending with "nnn", where "nnn" represents the version of the standard.
The incorrect KEYLN on the source system is causing export processing to generate a duplicate entry, thereby encountering the latent error on import.
To resolve the problem, update the DB2 table on the source system such that KEYLN matches the needed value.
Note: do not assume this same KEYLN setting of 3 pertains to any other EDI code lists besides those for X12 data element 103
Note2: if you no longer require this particular validation table, then an alternative is to remove the associated record from the export control file or delete the old table from the source system.
Step 21: Migrating Operational Data
Resolution: Apply PTF UK42684 to 3.3 or, since the SQL 100 is a normal condition, it can be ignored.
I hope this information makes the migration process a little easier. As I mentioned, I've seen these type of problem a few times lately and thought it would be a good idea to get the word out, in case anyone else out there was having the same experience. For more information on upgrading, please refer to technote 1419338. You might also be interested in this Webcast replay: WebSphere Data Interchange V3.3 - Lessons Learned from Support.