Maximum SCreen Fields

From 2EWiki

Jump to: navigation, search

Maximum fields in All Fusion 2E Functions -K.MD Bashirudeen



In some applications there are many information needs to be displayed in a screen as per requirement. But unfortunately the software/tools will not allow displaying all the information in a screen or in one page. It will allow only certain number of fields based on the limits of accommodation in the screen or maximum number of fields allowed in the software/tools/language. If we go beyond the limit it will be a problem.

The same case happens here in All Fusion (Advantage) 2E. There are 132 fields were hidden and 99 fields were output in a DSPRCD Screen. As the implantation user wants to add a field in that DSPRCD screen and by pressing the key F4 on that field should display the related information in another screen.


In any screen, Detail record format will only allow maximum of 99 fields of input or output or input and output combination. Hidden fields are not a problem. If we try to add one more new field in the screen which is already having 99 input/output fields, we will not be able to compile the program. It will stick with the GENSRC and if we see the JOBLOG the following message will be displayed.

Message . . . . : FIXEDOVERFLOW at statement 525 in YCBLCSRK1I. ONCODE 310. Cause . . . . . : The receiver operand is too small to hold the result. The number of digits of the intermediate result of a fixed point arithmetic operation exceeds the maximum number of digits allowed by AS/400 PL/I. The maximum for intermediate results is 15 or 31 (depending on whether the compiler option *EXDDEC is used) for decimal fixed-point values and 31 for ……

The problem here is, the screen is reached the maximum number of indicators i.e. 99.If we define an input or output field more than that the source will not get generated because there is no indicator available to assign for those fields. If we try to give “G” Generate source against this function it will come out from the model and we will get the following message “The receiver operand is too small to hold the result” Requirement:” .Here while generating the source, internal source is checking the validation and comparison in its internal All Fusion 2E (SYNON 2E) Code which is available in YCBLCSR program and related files.

For Hidden fields, this is not a problem since these fields are not at all considered hence there is no need of indicators.


But here the requirement is on the existing screen which is in production and it is a familiar screen for the business users. Because of one field, the client does not want to change the screen look (i.e. to go for another DSPRCD 2, or 3). If we go for DSPRCD 2 or 3 we need to split the fields in to across the screen. That will go for further implementation, and time consumption and also client needs the training on the new screen .Because the existing screen is there for a long time in production.

Requirement 1:

Add a field in DSPRCD screens and that will high light that the current record is having the new functionality say for example “T”-Test (Fig1 highlighted in Blue)

Requirement 2:

If “T” is displayed then user can take F4 and see the full details of Test in another screen.

Here adding input/output field is not allowing in screen due to compilation problem. We tried to concatenate some of the fields and we tried to add a field. This case compilation was not a problem but F4 was not working due to the indicator problem. How we can make a code for when F4 is pressed, since this also need an extra indicator (Code will generate an indicator for F4 pressed).So this solution also not helpful. So we will see how to solve this problem. Let us see in detail below.

DSPRCD for displaying al the information: Fig 1:

USer                	Test screen                		    HH:MM:SS 
Row1  666666666666666 666 Date1 66/66/66 Date2 Dt 66/66/66 Type  OO 
Row5: FLD2 O Field6 OOOOOOOOO FLD3OO Field7 66/66/66 FLD4 OOField8 666/666-666 
Row8 OOO FLD7 O FLD8 O FLD9 66/66/6666 Price   Tot1      Tot2      Tot3   
Row9  FLD10 66/66/66 FLD11 66/66/66    Cal1 6666666.66 6666666.66- 6666666.66- 
Row10: OO FLD12 OOOOOOOOOOOOOOOOOOOO 	Cal2 6666666.66 6666666.66- 6666666.66- 
Row11 OOOOOOOOOOOOOOOOOOOOOOO GenInd O Cal3 6666666.66 6666666.66- 6666666.66- 
Row12 OOOOOOOOOO FLD13 OOOOOOOOOOOOOO  Cal4 6666666.66 6666666.66- 6666666.66- 
Row13 66666 FLD14 66666666.666 FLD15OO Cal5 6666666.66 6666666.66- 6666666.66- 
Row14 666 FLD16 O FL1 O FL2 OOOOOOOOOO Cal6 6666666.66 6666666.66- 6666666.66- 
Row15 FL3 OO FLD16 OOOOOOOOOOO         Cal7 6666666.66 6666666.66- 6666666.66- 
Row16 FL4 OO FLD17 OOOOOOOOOOOOOOO     Cal8 6666666.66 6666666.66- 6666666.66- 
Row17 OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO Cal9 6666666.66 6666666.66- 6666666.66- 
Row18 FLD18 OO FLD19 OOOOOOOOOOOOOOOO Cal10 6666666.66 6666666.66- 6666666.66- 
Row19 O FL5 OOOOOOOOOOOOOOOOOOOOO     Cal11 6666666.66 6666666.66- 6666666.66- 



To avoid the Compilation problem and full fill the user requirement we added a constant field as “O” and we noted the Cursor position of the field in the screen (Cursor row and cursor column).

Now we added the code in the Action diagram as follows. And the new functionality is also worked as per the new requirement and there was no compilation problem. In this case the cursor row is = 21 and the cursor column is = 55

Anyhow there will not be any big change in the screen structure i.e. fields locations in the screen and screen looks etc, If any screen changes in future then we have to note down the cursor Row and Column and need to change in the action diagram if we did the code for F4 functionality based on the cursor row and cursor column.

Action diagram Code:

USER: validate detail fields


    IF *Cursor Row is Row (Defined as 21 is Row)
    IF *Cursor Column is Column (Defined as 55 is column)
/* Call the new functionality*/	

END Case


We can go and create a new screen or go for DSPRCD 2/3 and EDTRCD 2, 3 these all are the option .But nay existing screen and like the small one or two changes I feel this is a good method. IT will save the time /cost and no further training is needed for the End user or business user. Particularly some customers like our customer will not allow changing the new screen since they need time cost and need training for their clients.


Now we understand How the Constant Helped lot in the compilation problem and solved the new requirement. As discussed in the above cases we can use this constant technique to solve this kind of problems. We concatenate some text fields if they have any relations (Ex: First name, Second name ) then we can remove/Hide other field and we can insert a new field .But still if we have indicator problem like taking F4 we may need to go for constant technique.

Personal tools