Our customer is considering partition change from RDML->RDMLX. This is recommended by LANSA, and it is requirement for usage of many LANSA features.
There is problem with couple of files, which are using RPG code for virtual field derivation. For RDMLX, another C based OAM is created, not using this logic.
In documentation, there is noted - Technical reference 3.9.2:
• RPG or C code may be entered.
• C code must have the letter C as the first character of each line.
So the solution should be add a C code segment to file definition with the same functionality as RPG code.
Unfortunately, there is no one example, except mentioned note.
For example, it is not clear, if VC_USING clause should be used two times or only single time in the definition etc.
Could anybody from you show at least one simple example of both (RPG and C) code placed in this section?
C code for virtual field derivation - example ?
- Stewart Marshall
- Posts: 417
- Joined: Thu Nov 05, 2015 5:25 pm
Re: C code for virtual field derivation - example ?
Hi Jiri
If the file is enabled for RDMLX you can derive the virtual field using RDMLX
Regards
If the file is enabled for RDMLX you can derive the virtual field using RDMLX
Regards
Re: C code for virtual field derivation - example ?
Yes Stewart, I know it and I am using it on new projects.
But the affected files must stay RDML, because they are read by many RDML functions, which cannot be converted to RDMLX due to 5250 screens or report commands not alloved in RDMLX. And vice versa - RDMLX file cannot be directly read from RDML function.
Another option - place the logic into a trigger would affect performance.
It is only about 10 files from >200 used by application, but frequently used (key files)
The derivations are often very simple, for example:
virtual fileld ZJHDIDV, which formats string in real aplha field ZJHDID containing C1232015 to -> C123/2015 which is used on many screens for read/print only.
RPG calculation after input:
.....C* VC_USING FIELDS(ZJHDID (ZJHDIDV ZJXXXX))
.....C*
.....C MOVEL' /' ZJXXXX
.....C Z-ADD1 T 10
.....C 4 SUBSTZJHDID:T ZJXXXX
.....C Z-ADD5 T 10
.....C 4 SUBSTZJHDID:T XXXTMP 4
.....C MOVE XXXTMP ZJXXXX
C / * C code here ?? */
But the affected files must stay RDML, because they are read by many RDML functions, which cannot be converted to RDMLX due to 5250 screens or report commands not alloved in RDMLX. And vice versa - RDMLX file cannot be directly read from RDML function.
Another option - place the logic into a trigger would affect performance.
It is only about 10 files from >200 used by application, but frequently used (key files)
The derivations are often very simple, for example:
virtual fileld ZJHDIDV, which formats string in real aplha field ZJHDID containing C1232015 to -> C123/2015 which is used on many screens for read/print only.
RPG calculation after input:
.....C* VC_USING FIELDS(ZJHDID (ZJHDIDV ZJXXXX))
.....C*
.....C MOVEL' /' ZJXXXX
.....C Z-ADD1 T 10
.....C 4 SUBSTZJHDID:T ZJXXXX
.....C Z-ADD5 T 10
.....C 4 SUBSTZJHDID:T XXXTMP 4
.....C MOVE XXXTMP ZJXXXX
C / * C code here ?? */