Following error on the Job log with of our SQLBlockFetches Receiver value too small to hold result. Program NY2HMEF in library NYSSEPGM ended abnormally.
Originally created with Plex 6.1 without memoryleakfix --> thery run succesfully.
Upgraded to Plex 71. same function with or without memoryleakfix fails with error message: Receiver value too small to hold result
Two issues here, Runtime vs Compile time. The problem could exist in both.
So compare the source of plex6.1 and plex7.1. What are the differences in the source?
The runtime is little more diffcult and after checking Plex710_GA_PTF.doc it doesn't look like any changes would create the MCH1210 error like Generating RPGLE at 8.0
There seems to be lot of changes to code generation. Even runtime program changes YOBCASTN changed to YOBCASTNE and so on.....
but will try and get my hands on 7.1 and see the source difference...can you post 6.1 vs 7.1 for me to have a look
Here we go.
F0001B tested with manual change to 4B no affect
Are you able to see the actual line number that is causing this, or is the program just ending?
Can you debug NY2HMEF to see where the code is failing?
The code will be failing on one of the Eval statements (there are 26 of them in the program).
I suspect that the issue is with the SQL Pattern and that it is only expecting to handle numeric fields of lengths up to 30.9, whereas Plex is now handling 63.21.
If you look at the following code -
* Cast Sql<Sql.NumericField>, SqlTemp<Sql.TextField>
C CALL 'YOBCASTNEX' 99
C PARM F0001I ZZTXT 65
C PARM *ZEROS ZZNBR 6321
C Z-ADD ZZNBR F00019
* API Call Source code: _SQL_RPGSource.ToPackedDecimal
C Z-ADD 0 $PREC 19 1
C Eval $PREC = SQLLEN-256*(%DIV(SQLLEN:256))
C Eval $PREC = 10**$PREC
C Eval F00019 = F00019/$PREC
$PREC is defined as 19 1. I wonder if 21 decimal places is too much.
ZZNBR is now defined as 63.21 but F00019 is defined as 30.5 (the old Plex Limitation is size). So there are more issues here.
That's just a couple of potential issues I see in this code. The SQLBlockFetch pattern needs to be updated to use the new lengths support in Plex.
Hope that helps some...
You were on a correct path.
Sql.NumericField (F00019) defined as 63.21 in model
$PREC defined as 63.21 in ToPackedDecimal source code
Sql.SqlType defined as 4 in model.
VOILA!! Not it works smoothly with Plex 7.1
Modifications in attachment.
Thanks Crispin & George for your assistance to sort out the problem
With further testing noticed that decimals missing.
Sql.NumericField (F00019) defined to original 30.9; decimals OK
Hi George Jeffcock.
I just released a new version of the BlockFetchSql pattern. Can you try this new version of the pattern in Plex 7.1 or 7.2 for me. We have not yet upgraded to Plex 7.2.
Arni Freyr Jonsson, Applicon,
Would have loved to but don't have a job and access to an ibm i. And I think my days of helping the community are over.
Hi, KariIt seems same issue we had when moving to Plex 7.2...it was a generator change: SqlType field , a binary 2, was generated as is, while previously it was generated as b4. When a three digits value was passed, program failed.We opened an issue at CA.
By the way, we solved it changing b2 to b4. Note that generator changed source code at 6.1