$ZTRIGGER() and MUPIP TRIGGER accept subscripts with decimal points and treat as identical different descriptions of the same subscript
Final Release Note
$ZTRIGGER() and MUPIP TRIGGER load triggers with for numeric subscripts with a decimal point. Previously they raised parse errors that "." was an invalid character in the subscript. Additionally, trigger definitions for subscripted global variable references are better checked for equality. For example, trigger definitions for ^x(2), ^x(2.0) and ^x("2") are treated the same, as all 3 specifications map to the same node in the database file. Previously such specifications caused multiple triggers to be created, resulting in a single update of ^x(2) invoking multiple triggers, a potentially unintended consequence.
If you suspect that an existing application database has triggers defined with non-canonical numbers, or numbers specified as strings, or if you are not sure, after upgrading to r1.26, extract, delete, and reload all triggers. For example:
mupip trigger -select /tmp/triggers.define # extract the current trigger definitions
echo "-*" >/tmp/triggers.delete # create trigger file to delete all triggers
mupip trigger -triggerfile=/tmp/triggers.delete # delete triggers
mupip trigger -triggerfile=/tmp/triggers.define # reload trigger definitions
Description
YDB>write $ZTRIGGER("item","+^x(2) -commands=SET -xecute=""write 1,!""")
Added SET trigger on ^x named x#1
1
YDB>write $ZTRIGGER("item","+^x(2.2) -commands=SET -xecute=""write 1,!""")
Invalid character "." in subscript
"^x(2.2) -commands=SET -xecute=""write 1,!"""
0
Draft Release Note
$ZTRIGGER and MUPIP TRIGGER load triggers when presented with a trigger definition containing numeric subscripts which have a decimal point specified (i.e. are not whole integers). Previously it used to fail with a parse error saying "." is an invalid character in the subscript. Additionally, trigger definitions for subscripted global variable references are better checked for equality. For example, a trigger definition for ^x(2) is treated the same as that for ^x(2.0) or that for ^x("2") as all 3 specifications map to the exact same node in the database file. Previously these specifications used to cause multiple triggers to be created causing a single update of ^x(2) to invoke more than one trigger which could result in unintended consequences for the application.