E1 Upgrades - Changes to Record and Member names (AS400)

Noticed that in Xe the table F47046 has record format F47046 and member name F47046. When this table was upgraded it now has record format F470400001 and member F470400001.

Can anyone else confirm this for me?

This is not good in my EDI scenario where the software is setup to take the default of table F47046 having record format F47046 and member name F47046. Anyone else have this issue? Any suggested resolution?

Thanks,

Colin

<<Can anyone else confirm this for me?

Confirmed. We noticed that too. Seems the member name is the filename followed by 00001 for many of the tables we checked.

Grant

Is the F47046 table there alse, but your data is in the file with the new name? When you restore data to a library, if you restore a table that exists and has anything different about it, it will rename the old file to what you see and then download the new file.

Colin,

confirmed. This is due to the new table conversion IO engine as of release 8.9.

In previous releases, table conversions would:

1) create temporary table with new table structure
2) copy data from original table to new temporary table (tc)
3) drop original table
4) create new table (with new table structure)
5) copy data from temporary table to new table
6) drop temporary table

As of release 8.9, table conversions do the following:

1) create temporary table with new table structure
2) copy data from original table to new temporary table (tc)
3) drop original table
4) rename temporary table to original table

As an example, in step 1 the temporary table is called F47046tctemp and its member is called F470400001 bacause of the iSeries object naming limitation (more than 10 characters). The issue is caused by step 4 with the new releases because renaming an object does not change its member name. As a workaround, simpy rename F47046 to F47046#, regenerate F47046 via EnterpriseOne and then simply copy your data back from F47046# to F47046.

Thanks guys,

the other solution that someone found for me was using the R98403 to copy all Business Data to another datasource. Using the R98403 will correct the record format and member names. (also adds another few hours to go-live).

Thought I had escaped the R98403 - obviously not.

We have seen the same effect ... I was told that it does not affect the
operation of Oneworld and so learn to live with it or create a new
pristine library and "copy" the data over ... yeah right.

If its only particular files that are the problem then its a case of
saving the data then regenerating the file and loading the data .. at
8.11 you can't just copy the file from pristine as its already unicoded.
That isn't what you may need

I have had the "discussion" at least 3 times and lost ..

Thanks
George
Berri Limited

iSeries 825 , Xe SP23 Prod , 8.11 Sandpit,