BUG in MERGE, wrong control Maximum number of subscripts

line 254 of sr_port/op_merge.c

Konstantin:

Thank you for reporting this issue and identifying the line with the problem.

We will fix this in a future GT.M release.

Here is the draft release note (along with the tracking number):

MERGE into a local variable (lvn) target limits the number of target subscripts to the maximum number supported by GT.M (currently 31); previously MERGE could produce variables with 32 subscripts which could cause subsequent problems. (GTM-6793)

Thanks again,
Bill

Hi Bill !

I think this is an inaccurate description of the problem. My example gives a completely correct result in GT.M 6.0. It is:

^xxx2("test",1,2,3,4,5,6,7,8,9,10,11,15,16,17,18,19,20)="Test"

Target variable has 18 indexes, but in GT.M 6.2 - 6.3 we have %GTM-W-MERGEINCOMPL.
I think, the whole thing in the wrong algorithm pre-calculate the number of indexes in the target variable. if we do not use a variable gvn2subs in the calculation of the final amount of indexes, the more everything is handled correctly.

if (MAX_GVSUBSCRIPTS <= (gvn1subs + nsubs))

                                                                    Konstantin.

Konstantin:

Thank you for identifying the fix for the issue.

Based upon your feedback we have enhanced the release note:
MERGE permits its target to hold the maximum number of subscripts supported by GT.M (currently 31). Beginning with V6.1-000 the change associated with GTM-7867 could cause inappropriate MAXNRSUBSCRIPTS errors when both the source and the target were both global variables, most likely when the source had many subscripts. The workaround was to MERGE the source into a local variable and then MERGE from there to the actual target. (GTM-8583)

Thanks again,
Bill