JDE DD modification - best practices

I've been requested to increase standard JDE DD field SRL1 from 30 to 31 char but I have pushed it back because I think there'll be a lot at stake if we change a standard JDE DD field length.

Question is, if I do have to change a length of standard JDE DD, then what is the best practice to do it. I've already checked through xref the tables/views/dstr/bsfn/etc that are using this field, but I am not sure if there are any sub-functions/local variables etc that may be expecting 30 char instead of 31 char value, then how would those behave and what ramifications would that hold.

But anyhow, is there anyone out there who has done it successfully? Can you share your success story with us?

Thanks,

There are only very few exceptions where you would ever change a DD item. This is something you don't want to do with the data item suggested. You are talking about changing the table size not just the display(such in changing the number of display decimals in a quantity DD). I can explain how you would do this, but please don't. If you absolutley must have 31 char I would look into create a tag table to hold it or another table/data item that would hold the data.

Best practices are to not do it.

I completely agree to your post. I am also against changing standard JDE DD. But I was more interested in what are the best practices if we ever have to do it. What are the areas we need to check.

For example, numeric fields are easier to change because at the database level, these are set as "numeric" with no limitation of size. However string fields have a specific size limitation at the data base level, so that makes it more complicated.

Noor,

Best Practice is to NEVER change size or data type of a standard JDE DD item.

Changing size/data type is equivalent to pointing a gun at your head and pulling the trigger.

In addition, I don't think you or your client understands the true scope of what you want to do. SLR1 is only one of several DD Items used for Serial Numbers. SLR1 only appears in 1 table. LOTN appears in ~ 200 tables. SERN is used in 25 tables. And there are MORE of these DD items.

Its not just tables that are affected.
Applications would be affected. Data structures would be affected. 'C' Business functions would be affected. etc, etc

Despite what the Salesman said JDE is not sophisticated enough to blow changes like this down through the trees of application and database objects.

Hi,

Changing your vanilla DD items is a fast highway to Hell.

If I were you, I'd try either to accomodate your 31 bytes
data into any of the "vacant" user fields of your
vanilla tables.

Most of them have names beginning with U and descriptions
like UserDefinedDateField1, UserDefinedCharField4, etc.

If no field is large enough, then you'll have to create
a new (custom) table, a custom DD item (as long as
you want) and then write all the corresponding logic
to link this new table with the existing ones.

Just so that you guys know, we did change a custom data dictionary field length from 60 to 250 and successfully promoted to PD. It was used in 7 different custom tables, 8 applications, 4 reports and 3 business functions and data structures.

Following are the steps we did to accomplish:
1. Change the field length
2. Rebuild DD specs (R92TAM)
3. Build full pkg and copied the 4 DD spec files and deployed package to build machine
4. On pkg build machine:
i. generated header files of all 7 tables and manually copied those files to deployment server pkg folder and path code/include folder
ii. generated typedef of data structures and copied those over to .h files of bsfns
5. Rebuild full pkg and glbl table specs (R98CRTGL)and copied those files to pkg and path code folder on deployment server
6. Ran alter table commands on database to change field size on related tables in each environment because we didn't want to regenerate tables as it wipes out data.
7. Deployed package to other fat client, citrix and enterprise servers

We didn't have to touch applications, reports, Processing Options etc at all.

As this is a custom DD, so we new which files/bsfns etc had those changes and we knew the impact of such a change. However, with std DD of JDE, the impact is not clearly defined that's why we are hesitant changing it.

noor,

Custom DD objects are one thing, while DD objects supplied by JDE are a totally different beast. The former you have control and supposedly the knowledge of how and where they are used. JDE-supplied DD objects, however, should NEVER have their size changed. Even if you were to change one, it would very possibly be overwritten during your next upgrade, resulting in needless confusion during the already stressful time of an upgrade.

So obviously you know what you're doing and what's involved in a DD item change. Biggest issue being what's hiding in the 'C' code.

So what are you fishing for? More ammo to tell the users no? You got it - its doable but hideously expensive and extreme high risk of introducing system instability.

Good Luck,

Another hidden problem may be the use of the DD item in ER variables.

As others have pointed out changing a pritine DD item is incredibly perilous.

However I have been toying with another mod technique for this situation that I have been contemplating but have yet to do a proof of concept.

Example:
Store more than 30 chars in a pristine DD item with a size of 30

Requirements:
1. Must be on a Unicode compatible release.
2. Unicode support must be turned on at the database level.
3. Must only need to store non-unicode data (chars in the 1-255 range).

Note: #2 would rule out my install since we don't have Unicode turned on at the database level.


You probably see where I am going with this...


Create two function calls:
Pack
.....szIn[61]
.....szOut[31]

Unpack
.....szIn[31]
.....szOut[61]

The Pack function simply takes 60 unicode chars with only non-unicode values (1-255) in each char postion in szIn and puts them into each byte position of szOut. Unpack does the opposite.


Steps to implement:
1. On any entry FC or GC put a custom 60 char DD item and in the on change event call the Pack function to store the packed data in the hidden pristine DD item.

2. Any place where you need to display the data, again hide the pristine DD item and call the Unpack function to display the data in a custom 60 char DD item.


Potential Problems:
Obviously this will result in some character values in the pristine DD item field that are not true unicode chars (not in the unicode character set). Will the underlying database error or balk at this or do any type of conversion? Will any ER code balk at this? Will the hidden pristine FC and GC fields that store the packed data keep the same "values" or will some un-intended translation go on there as well if a character outide of the defined unicode char set pops up? I am pretty sure as far as any C code goes you are ok, since it is basically just using the sz[31] param as a BYTE[60] array and doesn't really care what is in there. The database and ER code are probably the main things the could kill this.

I have used a similiar techinque in C only in a BSFN call to use both byte positions of each unicode char in a string, but it was a very limited situation, no display, no persitence, no ER code.

Thoughts?

BTW, I started thinking about this when I missed some Unicode conversion stuff during our Xe to 9.0 upgrade and got a screen full of garbage.

This could work, but another risk is that the Unicode strings in JDE, as returned by the database layer, are unsigned short / UTF-16 in platform-native endian byte order, so you will have to account for the various platform's endianness (byte ordering) when packing/unpacking.

That may be the killer right there, or at least makes doing something like this almost more complex than its worth.

On the other hand shouldn't the JDEBASE layer account for endianness? I mean it has to for valid characters (unicode or not) correct?

So if I set:
sz[0] = _J('A'); //(dec=65)
or
sz[0] = U+038A; //(dec=906)

When retrieved from the DB sz[0] still needs to = 65 or 906.


So if I store the two characters 'A' and 'G' in sz[0] regardless of what the resulting decimal value of sz[0] is before saving to the database, (say 16711 for the sake of argument) I should still get 16711 back from the DB, correct?

This is one of those things that starts to make my brain hurt and until I actually try it and see it fail or work...



Just to add a little bit. If you think about it all I would be doing is essentially using the string param and the underlying field in the database as a fixed size BLOB, knowing that I have 60 bytes available for a 30 character field and encoding non-unicode chars into those 60 bytes.

Finally, I found something on Oracle that explains it all:



E1: DD: Impact of Changing the Size of a Standard Data Dictionary Item [ID 643221.1]
Modified 15-FEB-2012 Type BULLETIN Status PUBLISHED
In this Document
Purpose
Scope and Application
E1: DD: Impact of Changing the Size of a Standard Data Dictionary Item
Overview
Issues that Can Occur when Changing the Size of String Data Dictionary Alias DL01
Consequences of String Data Dictionary Size Change to Unit of Measure
References

Applies to:

JD Edwards EnterpriseOne Tools - Version: S23 and later [Release: S23 and later ]
JD Edwards EnterpriseOne Tools - Version: 8.93 and later [Release: 8.93 and later]
Information in this document applies to any platform.
Purpose

This document is part of an Information Center - to see other documents related to Data Dictionary, please use the links provided below:

Information Center: Using Data Dictionary in the JD Edwards EnterpriseOne Tools and Technology Product > Doc ID 643221.1

This document details the impact of changing the size on a standard EnterpriseOne Data Dictionary data item. The document includes the impact and some examples of the results when making this type of change.
Scope and Application

This document is intended for the EnterpriseOne Data Dictionary Administrator
E1: DD: Impact of Changing the Size of a Standard Data Dictionary Item

Overview

Making a change to a standard EnterpriseOne data dictionary item is not recommended or supported. Tables, business views, applications and business functions are designed with the standard size of the data item and making a change to this size can result in errors within the applications and data integrity issues. If a data item size is changed, all tables using the data item would need to be generated, any data entered would need to be manually converted, all business functions that use the data item in their data structures would need the header files updated and business functions rebuilt, all business functions that reference tables that contain this data item would need to be rebuilt, and so forth. This is a widespread change that impacts all objects across the system that use the data item. In addition, this type of change is not supported in an upgrade.

NOTE: Based on the above implications of this type of change, we do not recommend making any changes to the size of standard EnterpriseOne data dictionary items. We recommend that the additional information be contained within another field, within a custom data dictionary item in a custom table or some other logic be used to achieve the needed results. By default, changing a Data Dictionary item affects all environments as the recommended configuration is to have one Data Dictionary F9210 in the Data Source 'Data Dictionary'

For additional information on the Data Dictionary, refer to Document 1267422.1 E1: DD: Overview of EnterpriseOne Data Dictionary.

Issues that Can Occur when Changing the Size of String Data Dictionary Alias DL01

In EnterpriseOne, thousands of objects including Tables, Business Views, Business Functions, Data Structures, etc. make use of the Data Dictionary item DL01 as a member, column, or parameter.
In EnterpriseOne (or any C Programming) a string value will be handled as 'Character Array' and it determines the end of array by reading NULL Character (Termination Character '\0'). In changing the size of a data dictionary item, if it is not properly applied, the allocated size of the array is different from the assigned size of the array which results in a typical memory violation scenario.
A business function, which contains DL01 as a member of its data structure, during compilation will assign memory. For this example, DL01 is 30 in size so it will be describe as szDescription01 [31] so JDE will assign 62 bytes to hold that information.
If the change has been made after implementation, there can be multiple ODBC/OCI errors. One possible example is that EnterpriseOne recognizes F0030.DL01 as 40 characters, but the database (metadata) determines it as 30 characters (31 bytes for non-unicode encoding and 62 bytes for Unicode encoding). When an EnterpriseOne application tries to insert or update 40 characters, the Database will only accept 30 characters. To overcome this, the standard requirement is to generate/truncate table(s) through Object Management Workbench (OMW) with a drop/create table. Alternatively we can alter the table (column size), but this will be risky and very tedious. Therefore, the generation of Tables and Business Views would be required.
The following are some discrepancies that can occur as a result of a size change of this standard DD item.
Synchronization of DD items between RDB and TAMSpec
Currently the change made through P92001 - Data Dictionary application will update RDB File F9210 and F92* series tables.
In running application it will read TAMSPEC (binary format file) which are dddict.xdb and ddb files.
In case synchronization was not done properly it will issue an error.
Synchronization between DD and Table Columns definition in Central Objects
Check individual tables whether the size of column DL01 is changed properly through xxx.h files in include folder.
During runtime glbltbl.xdb and ddb will be read to resolve the size. So if any of table information is not corrected/synchronized then error will come from ODBC.
Synchronization within a Business Function
EnterpriseOne holds cache data using a Data Structure.
A String value is handled through Character Array.
The end of string is recognized by NULL Character '\0'.
If the size of the individual character array is not updated, then it will cause overlapping in memory resulting in a Memory Violation.
Synchronization between two Business Functions
When Business Function A is calling Business Function B and DL01 is a member of the Data Structure of Business Function B and the size has not been changed properly, an error will occur and the process may fail to return to the calling Business Function A.
Synchronization between Application and Business Function
If the size of input or returned value of a Business Function are different from each other it will cause a memory error.
The specifications of the application (both Interactive Application and Batch Application) has to be synchronized with the change made.
Synchronization between E1 Logic and Database
Table Columns and Business View Columns must be synchronized.
The action has to be taken either through MANUAL alternation of the database or through Generation from JDE Object Management Workbench (OMW).

Based on the above implications of this type of change, we do not recommend making any changes to the size of standard EnterpriseOne data dictionary items. We recommend that the additional information be contained within another field, within a custom data dictionary item in a custom table or some other logic be used to achieve the needed results. In case the existing size does not meet your legal requirement, then inquire with Oracle Global Support for further clarification

Consequences of String Data Dictionary Size Change to Unit of Measure

The following example shows the results of a string data dictionary size change. In this example, the size of the standard EnterpriseOne Data Dictionary item with DD Alias 'UOM1' UnitOfMeasurePrimary (Unit of Measure - Primary) was changed by a developer at the customer's site from a size of 2 to a size of 3.

Symptoms

After building a full package, multiple errors across EnterpriseOne are occurring.

Some examples of the errors are:
In clicking Find button 4310, it throws an error message "There was a problem with the server while running the business function GetPODetailShipmentNumber". After disabling Transportation Module through P99410, this error does not occur anymore but P4310 does not allow to add/update data
In finding existing BOM through P3002 it issues "Error: Y not found in User Defined Code 40 FL" though F4101.IMIFLA (ItemFlashMessage) is blank
In reviewing existing Routing through P3003 it issues error "Invalid Input Parameter"
Additional errors are occurring as well.
Cause

This issue is caused by the change of the standard EnterpriseOne string Data Dictionary item UOM1 from the shipped size of '2' to a size of '3' digits. This type of size change is NOT supported and results in widespread errors throughout the system.
Check OCM to determine whether there are more then 2 data sources for table F9210 - Data Field Specifications (OneWorld) for all the environments
Go to UTB and filter data through F9210.FRUPMJ (for example greater than last full package date)
Look for column F9210.FRDTAS - DataItemSize (Data Item Size)
And/Or Capture jdedebug.log (call object kernel log) and determine whether data structure item for output has odd value
For this example, jdedebug.log may read as below:

Calling Business function VerifyAndGetItemMaster
from Level 1 for UserID. Application Name [P3002], Version [ZJDE0001] (BSFNLevel = 1)
IN->[ 1] szPrimaryItemNumber [4418-0031-000]
IN->[ 2] szBranchPlant []
IN->[ 3] szDescription [ ]
IN->[ 4] szDescription2 [ ]
IN->[ 5] cSymbolidentifier [ ]
IN->[ 6] idF4101LongRowPtr [0]
IN->[ 7] mnShortItemNumber [0]
IN->[ 8] cErrorcode [ ]
IN->[ 9] szLanguagepreference [ ]
IN->[ 10] mnAddressnumber [0]
IN->[ 11] szSystemcode [ ]
IN->[ 12] szLongItemNumber [ ]
IN->[ 13] szThirdItemNumber [ ]
IN->[ 14] szItemFlashMsg [ ]
IN->[ 15] cReturnPtr [1]
...
Entering JDB_FetchKeyed
SELECT * FROM PRODDTA.F4101 WHERE ( IMLITM = '4418-0031-000' )
Fetched the record
OUT->[ 1] szPrimaryItemNumber [4418-0031-000 ]
OUT->[ 2] szBranchPlant []
OUT->[ 3] szDescription [D1 - FRAME ]
OUT->[ 4] szDescription2 [ ]
OUT->[ 5] cSymbolidentifier [2]
OUT->[ 6] idF4101LongRowPtr [1001]
OUT->[ 7] mnShortItemNumber [1517]
OUT->[ 8] cErrorcode [ ]
OUT->[ 9] szLanguagepreference [ ]
OUT->[ 10] mnAddressnumber [0]
OUT->[ 11] szSystemcode [ ]
OUT->[ 12] szLongItemNumber [4418-0031-000 ]
OUT->[ 13] szThirdItemNumber [AFC-FR-D1-001~999 ]
OUT->[ 14] szItemFlashMsg [Y 10 ]
OUT->[ 15] cReturnPtr [1]
...
Return value is 0 for VerifyAndGetItemMaster. (BSFNLevel = 1)


Actual Data is written from F4101 as below,
imlitm
...
imuom1
...
imback
imifla
imtfla
4418-0031-000

EA

Y

10

szItemFlashMsg is defined for 2 digits character but from jdedebug.log which appears 6 in length. This is typical corruption of lpds of X4101 - VerifyAndGetItemMaster
Business Function VerifyAndGetItemMaster is returning pointer after reading F4101
Since imuom1 is 3 in size, column value 'Y' for imback is shifted to right (in array it only has index to identify start of string (or character array) and it has assigned value 6 following column value 10 is combined
As result, it shows 'Y 10 ' then Codes 'FL' is defined with Code Length 2 so DD validation for column F4101.IFLA tries to validate the 1st two characters 'Y ' which 40/FL does not have this value
To resolve this issue:

Restore the change made to the standard EnterpriseOne data dictionary item (change the size of string DD Alias 'UOM1' from 3 back to the shipped value of 2).
Verify that the value of F9210.FRDTAS appears as '2'. (Optional)
Delete dddict, glbltbl.xdb and *.ddb file across system (Enterprise Server, Deployment Server and where client is working).
Truncate table F989999 - Java Persistent Objects table.
Delete JDBj cache in JAS.
Build Full Package.
Full generation of serialized object (for performance reason) (Optional).


E1: DD: Impact of Changing the Size of a Standard Data Dictionary Item [ID 643221.1]
Modified 15-FEB-2012 Type BULLETIN Status PUBLISHED
In this Document
Purpose
Scope and Application
E1: DD: Impact of Changing the Size of a Standard Data Dictionary Item
Overview
Issues that Can Occur when Changing the Size of String Data Dictionary Alias DL01
Consequences of String Data Dictionary Size Change to Unit of Measure
References

Applies to:

JD Edwards EnterpriseOne Tools - Version: S23 and later [Release: S23 and later ]
JD Edwards EnterpriseOne Tools - Version: 8.93 and later [Release: 8.93 and later]
Information in this document applies to any platform.
Purpose

This document is part of an Information Center - to see other documents related to Data Dictionary, please use the links provided below:

Information Center: Using Data Dictionary in the JD Edwards EnterpriseOne Tools and Technology Product > Doc ID 643221.1

This document details the impact of changing the size on a standard EnterpriseOne Data Dictionary data item. The document includes the impact and some examples of the results when making this type of change.
Scope and Application

This document is intended for the EnterpriseOne Data Dictionary Administrator
E1: DD: Impact of Changing the Size of a Standard Data Dictionary Item

Overview

Making a change to a standard EnterpriseOne data dictionary item is not recommended or supported. Tables, business views, applications and business functions are designed with the standard size of the data item and making a change to this size can result in errors within the applications and data integrity issues. If a data item size is changed, all tables using the data item would need to be generated, any data entered would need to be manually converted, all business functions that use the data item in their data structures would need the header files updated and business functions rebuilt, all business functions that reference tables that contain this data item would need to be rebuilt, and so forth. This is a widespread change that impacts all objects across the system that use the data item. In addition, this type of change is not supported in an upgrade.

NOTE: Based on the above implications of this type of change, we do not recommend making any changes to the size of standard EnterpriseOne data dictionary items. We recommend that the additional information be contained within another field, within a custom data dictionary item in a custom table or some other logic be used to achieve the needed results. By default, changing a Data Dictionary item affects all environments as the recommended configuration is to have one Data Dictionary F9210 in the Data Source 'Data Dictionary'

For additional information on the Data Dictionary, refer to Document 1267422.1 E1: DD: Overview of EnterpriseOne Data Dictionary.

Issues that Can Occur when Changing the Size of String Data Dictionary Alias DL01

In EnterpriseOne, thousands of objects including Tables, Business Views, Business Functions, Data Structures, etc. make use of the Data Dictionary item DL01 as a member, column, or parameter.
In EnterpriseOne (or any C Programming) a string value will be handled as 'Character Array' and it determines the end of array by reading NULL Character (Termination Character '\0'). In changing the size of a data dictionary item, if it is not properly applied, the allocated size of the array is different from the assigned size of the array which results in a typical memory violation scenario.
A business function, which contains DL01 as a member of its data structure, during compilation will assign memory. For this example, DL01 is 30 in size so it will be describe as szDescription01 [31] so JDE will assign 62 bytes to hold that information.
If the change has been made after implementation, there can be multiple ODBC/OCI errors. One possible example is that EnterpriseOne recognizes F0030.DL01 as 40 characters, but the database (metadata) determines it as 30 characters (31 bytes for non-unicode encoding and 62 bytes for Unicode encoding). When an EnterpriseOne application tries to insert or update 40 characters, the Database will only accept 30 characters. To overcome this, the standard requirement is to generate/truncate table(s) through Object Management Workbench (OMW) with a drop/create table. Alternatively we can alter the table (column size), but this will be risky and very tedious. Therefore, the generation of Tables and Business Views would be required.
The following are some discrepancies that can occur as a result of a size change of this standard DD item.
Synchronization of DD items between RDB and TAMSpec
Currently the change made through P92001 - Data Dictionary application will update RDB File F9210 and F92* series tables.
In running application it will read TAMSPEC (binary format file) which are dddict.xdb and ddb files.
In case synchronization was not done properly it will issue an error.
Synchronization between DD and Table Columns definition in Central Objects
Check individual tables whether the size of column DL01 is changed properly through xxx.h files in include folder.
During runtime glbltbl.xdb and ddb will be read to resolve the size. So if any of table information is not corrected/synchronized then error will come from ODBC.
Synchronization within a Business Function
EnterpriseOne holds cache data using a Data Structure.
A String value is handled through Character Array.
The end of string is recognized by NULL Character '\0'.
If the size of the individual character array is not updated, then it will cause overlapping in memory resulting in a Memory Violation.
Synchronization between two Business Functions
When Business Function A is calling Business Function B and DL01 is a member of the Data Structure of Business Function B and the size has not been changed properly, an error will occur and the process may fail to return to the calling Business Function A.
Synchronization between Application and Business Function
If the size of input or returned value of a Business Function are different from each other it will cause a memory error.
The specifications of the application (both Interactive Application and Batch Application) has to be synchronized with the change made.
Synchronization between E1 Logic and Database
Table Columns and Business View Columns must be synchronized.
The action has to be taken either through MANUAL alternation of the database or through Generation from JDE Object Management Workbench (OMW).

Based on the above implications of this type of change, we do not recommend making any changes to the size of standard EnterpriseOne data dictionary items. We recommend that the additional information be contained within another field, within a custom data dictionary item in a custom table or some other logic be used to achieve the needed results. In case the existing size does not meet your legal requirement, then inquire with Oracle Global Support for further clarification

Consequences of String Data Dictionary Size Change to Unit of Measure

The following example shows the results of a string data dictionary size change. In this example, the size of the standard EnterpriseOne Data Dictionary item with DD Alias 'UOM1' UnitOfMeasurePrimary (Unit of Measure - Primary) was changed by a developer at the customer's site from a size of 2 to a size of 3.

Symptoms

After building a full package, multiple errors across EnterpriseOne are occurring.

Some examples of the errors are:
In clicking Find button 4310, it throws an error message "There was a problem with the server while running the business function GetPODetailShipmentNumber". After disabling Transportation Module through P99410, this error does not occur anymore but P4310 does not allow to add/update data
In finding existing BOM through P3002 it issues "Error: Y not found in User Defined Code 40 FL" though F4101.IMIFLA (ItemFlashMessage) is blank
In reviewing existing Routing through P3003 it issues error "Invalid Input Parameter"
Additional errors are occurring as well.
Cause

This issue is caused by the change of the standard EnterpriseOne string Data Dictionary item UOM1 from the shipped size of '2' to a size of '3' digits. This type of size change is NOT supported and results in widespread errors throughout the system.
Check OCM to determine whether there are more then 2 data sources for table F9210 - Data Field Specifications (OneWorld) for all the environments
Go to UTB and filter data through F9210.FRUPMJ (for example greater than last full package date)
Look for column F9210.FRDTAS - DataItemSize (Data Item Size)
And/Or Capture jdedebug.log (call object kernel log) and determine whether data structure item for output has odd value
For this example, jdedebug.log may read as below:

Calling Business function VerifyAndGetItemMaster
from Level 1 for UserID. Application Name [P3002], Version [ZJDE0001] (BSFNLevel = 1)
IN->[ 1] szPrimaryItemNumber [4418-0031-000]
IN->[ 2] szBranchPlant []
IN->[ 3] szDescription [ ]
IN->[ 4] szDescription2 [ ]
IN->[ 5] cSymbolidentifier [ ]
IN->[ 6] idF4101LongRowPtr [0]
IN->[ 7] mnShortItemNumber [0]
IN->[ 8] cErrorcode [ ]
IN->[ 9] szLanguagepreference [ ]
IN->[ 10] mnAddressnumber [0]
IN->[ 11] szSystemcode [ ]
IN->[ 12] szLongItemNumber [ ]
IN->[ 13] szThirdItemNumber [ ]
IN->[ 14] szItemFlashMsg [ ]
IN->[ 15] cReturnPtr [1]
...
Entering JDB_FetchKeyed
SELECT * FROM PRODDTA.F4101 WHERE ( IMLITM = '4418-0031-000' )
Fetched the record
OUT->[ 1] szPrimaryItemNumber [4418-0031-000 ]
OUT->[ 2] szBranchPlant []
OUT->[ 3] szDescription [D1 - FRAME ]
OUT->[ 4] szDescription2 [ ]
OUT->[ 5] cSymbolidentifier [2]
OUT->[ 6] idF4101LongRowPtr [1001]
OUT->[ 7] mnShortItemNumber [1517]
OUT->[ 8] cErrorcode [ ]
OUT->[ 9] szLanguagepreference [ ]
OUT->[ 10] mnAddressnumber [0]
OUT->[ 11] szSystemcode [ ]
OUT->[ 12] szLongItemNumber [4418-0031-000 ]
OUT->[ 13] szThirdItemNumber [AFC-FR-D1-001~999 ]
OUT->[ 14] szItemFlashMsg [Y 10 ]
OUT->[ 15] cReturnPtr [1]
...
Return value is 0 for VerifyAndGetItemMaster. (BSFNLevel = 1)


Actual Data is written from F4101 as below,
imlitm
...
imuom1
...
imback
imifla
imtfla
4418-0031-000

EA

Y

10

szItemFlashMsg is defined for 2 digits character but from jdedebug.log which appears 6 in length. This is typical corruption of lpds of X4101 - VerifyAndGetItemMaster
Business Function VerifyAndGetItemMaster is returning pointer after reading F4101
Since imuom1 is 3 in size, column value 'Y' for imback is shifted to right (in array it only has index to identify start of string (or character array) and it has assigned value 6 following column value 10 is combined
As result, it shows 'Y 10 ' then Codes 'FL' is defined with Code Length 2 so DD validation for column F4101.IFLA tries to validate the 1st two characters 'Y ' which 40/FL does not have this value
To resolve this issue:

Restore the change made to the standard EnterpriseOne data dictionary item (change the size of string DD Alias 'UOM1' from 3 back to the shipped value of 2).
Verify that the value of F9210.FRDTAS appears as '2'. (Optional)
Delete dddict, glbltbl.xdb and *.ddb file across system (Enterprise Server, Deployment Server and where client is working).
Truncate table F989999 - Java Persistent Objects table.
Delete JDBj cache in JAS.
Build Full Package.
Full generation of serialized object (for performance reason) (Optional).