New post
Question
· Aug 9, 2021

Global names must be no more than 31 characters in IRIS, but OK in Ensemble 2018?

#Compiler #InterSystems IRIS for Health

We're upgrading to IRIS 2020.1 from Ensemble 2018.x.

I have a lookup table class that compiles fine in Ensemble but in IRIS causes the following compilation error: "ERROR #9101: Global name 'HH.LookupLabResultsToPhysiciansD' for 'IDLocation' is too long, must be no more than 31 characters in length."

Is this length limitation a new restriction or could I have done something years ago to increase the maximum character length.

Thanks,

Jim

Product version: IRIS 2020.1
Discussion (6)1
Log in or sign up to continue
Roger Merchberger · Aug 9, 2021

The 31-character limitation is there in 2018 (I'm using 2017 for this demonstration) - although anything longer doesn't technically error out, only the first 31 characters are recognized.

A quick demo I pulled from a test server:

NAME>s ^HH.LookupLabResultsToPhysiciansD(0)="fluffy"
 
NAME>zw ^HH.LookupLabResultsToPhysiciansD
^HH.LookupLabResultsToPhysicians(0)="fluffy"
 
NAME>s ^HH.LookupLabResultsToPhysiciansDoTryToDemonstrateLongGlobalNames(0)="More Fluffy"
 
NAME>zw ^HH.LookupLabResultsToPhysiciansDoNoFluffy
^HH.LookupLabResultsToPhysicians(0)="More Fluffy"

I underlined the characters that are 'ignored' - you can see on the ZWRITE command that the last 'D' (or anything after it) isn't displayed, and you can type all sorts of characters after that final 'D' and it still changes the 'base' 31-character global.

InterSystems probably put that check in because folks were using longer global names thinking all of the characters were significant, but some data was getting changed inadvertently.

Does that help?

0 0
Julius Kavay · Aug 10, 2021

With the global name lengths, there are two pitfalls,

- first, names could have arbitrary lengths, but only the first 31 characters are considered, but this was already mentioned  (Roger Merchberger)

- second, a global name can contain a period ("."), but the first (after the caret) or the last character must not be a period, where at "last" means, the period may not appear at the position 31.

The following short test shows this.

set glb="^abcdefghijklmnopqrstuvwxyz1234ABCDE.FG", @glb="myTest"
for i=37:-1:30 set $extract(glb,i-1,i)="."_$e(glb,i-1) try { write i,?4,glb," " write:$d(@glb)!1 $zr," ",$get(@glb),! } catch e { write e.Name,! }

the output is:

37  ^abcdefghijklmnopqrstuvwxyz1234ABCD.EFG ^abcdefghijklmnopqrstuvwxyz1234A myTest
36  ^abcdefghijklmnopqrstuvwxyz1234ABC.DEFG ^abcdefghijklmnopqrstuvwxyz1234A myTest
35  ^abcdefghijklmnopqrstuvwxyz1234AB.CDEFG ^abcdefghijklmnopqrstuvwxyz1234A myTest
34  ^abcdefghijklmnopqrstuvwxyz1234A.BCDEFG ^abcdefghijklmnopqrstuvwxyz1234A myTest
33  ^abcdefghijklmnopqrstuvwxyz1234.ABCDEFG <SYNTAX>
32  ^abcdefghijklmnopqrstuvwxyz123.4ABCDEFG ^abcdefghijklmnopqrstuvwxyz123.4
31  ^abcdefghijklmnopqrstuvwxyz12.34ABCDEFG ^abcdefghijklmnopqrstuvwxyz12.34
30  ^abcdefghijklmnopqrstuvwxyz1.234ABCDEFG ^abcdefghijklmnopqrstuvwxyz1.234

i = 34..37:  always the same global (^abcdefghijklmnopqrstuvwxyz1234A) hence, the same content

i = 33: the last character is a period, hence a syntax error

i = 30..32: different globals,

and the global name length is always 31 characters long.

By the way, if you start this example with

set glb = $name(^abcdefghijklmnopqrstuvwxyz1234ABCDE.FG)

which is the preferred method over 

set glb="^abcdefghijklmnopqrstuvwxyz1234ABCDE.FG"

the you end up with a cropped value in glb

^abcdefghijklmnopqrstuvwxyz1234A
0 0
Marykutty George · Aug 10, 2021

Hi @Jim Dolson , 

This was a feature introduced in 2018.1+

I believe this is something you can change using some setting but this was introduced to improve performance. 

Please see the documentation  for more deatils: http://ubuntu:52773/iris/csp/docbook/Doc.View.cls?KEY=GOBJ_persobj_intro... 

(tem server link : http://dreamymclean.intersystems.skytapdns.com:52773/csp/docbook/DocBook... ) 

Hope this helps. 

Regards,

Mary

0 0
Jon Willeke · Aug 10, 2021

This new error is indeed a breaking change in InterSystems IRIS 2019.3, as described in the 2020.1 release notes. Since I unfortunately can't link to them at the moment, I'll quote the relevant section from the upgrade compatibility checklist:

3.2.26 System — Class Compiler Validates Global Name Length Limit

This release adds compiler validation to ensure that the global names defined for DataLocation, IdLocation, IndexLocation, StreamLocation, CounterLocation, and VersionLocation are all within the global name length supported by the system (currently 31 characters). In previous releases, these global names were silently truncated to 31 characters. This could cause collisions between global names in the same class. These collisions would cause what appears to be references to separate globals to actually reference the same global.

During class compilation, an error will be reported if any of the global names used for the class are longer than the supported length. For example:

Compiling class %UnitTest.Result.TestInstance

ERROR #9101: Global name 'UnitTest.Result.TestInstanceStream' for 'StreamLocation' is too long, must be no more than 31 characters in length. [ConstructAddresses+60^%ocsExtentCache:BUILDSYS] > ERROR #5030: An error occurred while compiling class '%UnitTest.Result.TestInstance' [compile+59^%occClass:BUILDSYS]

This change will most likely result in classes that need to be modified upon upgrade. This more commonly occurs on systems that were converted from Caché or Ensemble using the in-place conversion if the classes were first defined using %CacheStorage and the class names were fairly long. (first in 2019.3)

I don't believe that you can disable this validation.

0 0