The Generated field, format or function name is blank in 2E
Article ID: 109635
Updated On:
Products
Issue/Introduction
When a model has exceeded the limit for DDS names of fields of a particular type, a blank field name will be generated instead of valid characters. The limit is ‘AA’ to ‘Z9’ (i.e., 936, DDS names for each field type, e.g., CDE, TXT, etc.)
If a field's DDS name is blank, the objects that use it will not successfully generate or compile. Similar problems will result when a model runs out of format names or function names. We can see messages such as The limit has been reached for the field type suffix, the limit has been reached for the generation type prefix, running out of Function Names, running out of Field Names, 2E Naming Allocation and running out of Format Names.
Environment
2E 8.7
All Supported IBM iSeries versions
Resolution
1. Running Out of Field Names - The limit has been reached for the field type suffix (i.e. ‘TX’ or ‘CD’)
Logic of Naming Allocation:
1) Check whether the YALCVNM is *YES... (that means we asked 2E to do automatic naming allocation)
2) Check whether the automatic naming allocation logic of 2E is overridden.
Do WRKOBJ on YALCFLDR1C and the YALCVNMR1R program objects, and check whether this logic was overridden.
3) If there is no override of 2E logic, then the typical naming convention is:
a) Log in to the model in designer mode.
b) Zoom into the "*FIELD ATTRIBUTE TYPES" file. Will go to the "DISPLAY FIELD TYPES" screen.
c) Take the particular object attribute, let us say "CDE"
d) Zoom into the object attribute. Will go to the "EDIT FIELD TYPE DEFAULTS" screen.
e) We can find the mnemonic code (in my example, it is CAA for CDE). We require the first two characters.
Alternatively, for example, the 'CDE' attribute:
SELECT substr( MNCCDE , 1 , 2 ) FROM yfldatrrfp where OBJATR =
'CDE'
f) Now query the YALCVNRFP and find Letter1 and Letter2 for the corresponding first two-letter mnemonic code.
For example, the 'CDE' attribute:
SELECT LET1, LET2 FROM yalcvnmrfp WHERE substr( OBJTYP , 1 , 2 ) in
(SELECT substr( MNCCDE , 1 , 2 ) FROM yfldatrrfp where OBJATR =
'CDE' )
g) Now, the next generated four-letter variable name will be
First letter—LET1 (LET1 of above query)
Second Letter—The next letter after LET2 (LET2 of the above query)
Third and Fourth Letters—The first two characters of the mnemonic code.
Problem: Ran out of generated names:
Single Model:
1) We aim to decide on a unique mnemonic, and it should never be used in the system.
2) Check all the mnemonics used so far in the model by the below query and write them to a notepad or Excel for our reference, and it will be useful in deciding the new suffix, which was not used before in the system:
SELECT DISTINCT substr( intddsvnm , 3 , 2 ) FROM yflddtarfp WHERE
@@fld > 1000 ORDER BY substr( intddsvnm , 3 , 2 )
3) Now decide on a mnemonic that is not in the above list.
4) Once you decide on a mnemonic, once again check that it was not used in the system by the following query:
Ex: Let us say you choose XY, then check the following query:
SELECT * FROM yflddtarfp WHERE @@fld > 1000 and substr( intddsvnm ,
3 , 2 ) = 'XY'
We should get zero records. That means we never used the XY or XY* mnemonic before for any field attributes. So we can safely use this mnemonic.
5) Now, log in to the model in designer mode
6) Zoom into the "*FIELD ATTRIBUTE TYPES" file. Will go to the "DISPLAY FIELD TYPES" screen.
7) Take the particular object attribute; let us say "CDE"
8) Zoom into the object attribute. Will go to the "EDIT FIELD TYPE DEFAULTS" screen.
9) Change the mnemonic to a new suffix. (in our example XY).
10) Now insert a record in YALCVNMRFP for the corresponding mnemonic using the query below:
INSERT INTO YALCVNMRFP VALUES('XY', 'A', 'A', ' ')
Now we are able to generate automatic naming allocation for the CDE attribute.
Multi-model:
1) We need to make sure, like in a multi-model environment, the YALCVNMRFP is shared across all models and placed in the common library rather than the model library. For that, set the library list of each model and do WRKOBJ on the YALCVNMRFP and check whether it is placed in the common library, and this library is placed higher in precedence than others (if any other library contains the YALCVNMRFP also).
Note down the common library in Notepad.
2) Our aim is to decide on a unique mnemonic, and it should never be used in the system in all models.
3) Check all the mnemonics used so far in all the models by the below query and write it to a notepad or Excel for our reference, and it will be useful in deciding the new suffix, which was not used before in the system in all models:
Note: Execute the query below in each model and collect all results in a notepad/Excel.
SELECT DISTINCT substr( intddsvnm , 3 , 2 ) FROM yflddtarfp WHERE
@@fld > 1000 ORDER BY substr( intddsvnm , 3 , 2 )
4) Now decide on a mnemonic that is not in the above list.
5) Once you decide on a mnemonic, once again check that it was not used in the system or any multi-models by the following query:
Ex: Let us say you choose XY, then check the following query in each model:
SELECT * FROM yflddtarfp WHERE @@fld > 1000 and substr( intddsvnm ,
3 , 2 ) = 'XY'
We should get zero records when executing in each model. That means we never used the XY or XY* mnemonic before for any field attributes in any model. So we can safely use this mnemonic.
6) Now, log in to each model in designer mode.
7) Zoom into the "*FIELD ATTRIBUTE TYPES" file. Will go to the "DISPLAY FIELD TYPES" screen.
8) Take the particular object attribute; let us say "CDE"
9) Zoom into the object attribute. Will go to the "EDIT FIELD TYPE DEFAULTS" screen.
10) Change the mnemonic to a new suffix. (in our example XY).
11) Execute from step 6 to step 10 for all models.
12) Now insert a record in YALCVNMRFP, which is in the common library, for the corresponding mnemonic using the query below:
INSERT INTO YALCVNMRFP VALUES('XY', 'A', 'A', ' ')
Now we are able to generate automatic naming allocation for the CDE attribute.
Note:
1) As per the naming allocation logic, to ensure the uniqueness of the field name across models, we need to modify the configuration in two places: one is in the common library file YALCVNMRFP, and another one is at each model level in *FIELD attributes Types". It is mandatory to change each model *FIELD attributes Types as described above.
2) In a multi-model environment, instead of the next mnemonic concept, it will always be good to follow the above steps whenever there is field exhaustion that happens. So that the field name will be unique across all models.
2. Running Out of Format Names - ,
To resolve the situation, another prefix needs to be defined for physical and logical files.
#1. Decide upon a new prefix for format names.
#2. In the appropriate model, enter a name for the format just allocated and include the new prefix.
#3. Set the entry for the FMT record in the YALCVNMRFP file in the model library, from ‘?’ to ‘AA’ using the YWRKF command.
#4. In the appropriate model, go to the Edit Generation Type panel (this can be done by entering a 10 for Display System Parameters from the Display Services Menu. Go to Display Name Allocation Values and press F10.). Change the Physical file format allocation character and the Logical file format allocation character to the new value chosen.
Multiple Models: If this situation has been reached within a multiple model environment, then step #3 should be applied to the AUTONAME library file and step #4 should be applied to all models.
_____________________________________________________________________________________
| Work with File - Multi record display |
| File. . . . : COREMDL/YALCVNMRFP Confirm: N |
| |
| Object Letter Letter |
| type 1 2 |
| SYS C O |
| FIL A R |
| CDE I A |
| TXT A 8 |
| FMT ? (Change to AA) |
------------------------------------------------------------------------------------------------------------------------------------------------
3. Running Out of Function Names
Defining a new prefix in the model value YOBJPFX will allow the naming programs to define new unique function names for the model.
#1. Decide upon a new 2-character object prefix for your model.
#2. Change the name of the function just allocated to include the new prefix.
#3. Set the entry for the MSG record in the YALCVNM00L file in the model library, from ‘?’ to ‘AA’ using the YWRKF command.
#4. In the appropriate model, change the model value YOBJPFX to the value you have chosen.
Multiple Models: If this situation has been reached within a multiple model environment, then step #3 should be applied to the AUTONAME library file and step #4 should be applied to all models.
Additional Information
Note: This workaround was developed to be compatible with the current release of 2E 8.7 within a specific environment. However slight, there exists a possibility that this workaround might not be appropriate to your situation or that it has been superseded. Do not attempt this procedure without confirmation from Broadcom Technical Support
We strongly recommend that you BACKUP your model before attempting this or any workaround. We cannot accept responsibility for improperly executed or outdated procedures.
Also, refer to the below KB on the prefix limit has reached and getting Y2V0215 error
https://knowledge.broadcom.com/external/article?articleNumber=432199
Feedback
