*** Please use if needed****
This solution was provided to my client in 2005 and same was reviewed and publsihed in IBM.com and it is not there any more as 2E is part of CA
****
IntroductionIn some applications lots of information needs to be displayed on a screen. But unfortunately character-based ("green screen") 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 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.
ProblemIn 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 AllFusion 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.
RequirementsBut 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 1Add 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 2If “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 all the information: Fig 1:
*PROGRAM *PGMMOD OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO DD/MM/YY
User Test screen HH:MM:SS
Row1 666666666666666 666 Date1 66/66/66 Date2 Dt 66/66/66 Type OO
Row2 OOOOOO Field1 OOOOOOOOOO Field2 OOOOOOOOOOOOOOO Field3 OO
Row4: FLDl OO Field4 OOOOOOOOOOOOOOO Field5OOOOOOOOOOOOOOOOOOOOO Date666/66/66
Row5: FLD2 O Field6 OOOOOOOOO FLD3OO Field7 66/66/66 FLD4 OOField8 666/666-666
Row6 OOOOOOOOO Field9 OOOOOOOOOOOOOOO FLD5 OOOOOOOOOOOOOOO FLD6 OOOOOOOOOO
Row7 OOOOOOOOOOOOOOOOOOOO Field10 OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
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-
Row20 OOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO O O O O O O O O O
Row21OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
Row22OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
SolutionTo 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
Case DTL.CMDKEY is CF04
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 Note:
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.
ConclusionNow 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.
2EMDBASH
DR
USA
Subscribe to this
