I was debugging an HL7 import and it was choking on tab characters.

But while debugging, I encountered something I don't understand. When I ask YottaDB to zwrite the contents of my variable, TMGVALUE, is displays an extra ";*' at the end of the line.

I demonstrate below that the string does not seem to actually contain any characters after the $C(9)
-------------------------------
yottadb>ZWR TMGVALUE
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*

yottadb>F XX=1:1:$LENGTH(TMGVALUE) S XXX=$E(TMGVALUE,XX) W !,XXX," [",$ASCII(XXX
),"]"

H [72]
I [73]
V [86]
[32]
B [66]
e [101]
l [108]
o [111]
w [119]
[32]
L [76]
L [76]
o [111]
Q [81]
[32]
N [78]
o [111]
t [116]
e [101]
[32]
S [83]
E [69]
E [69]
[32]
B [66]
E [69]
L [76]
O [79]
W [87]
[9]
yottadb>ZWRITE TMGVALUE
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*

yottadb>W "[",TMGVALUE,"]"
[HIV Below LLoQ Note SEE BELOW ]
yottadb>

-------------------------------
I then wondered if this was the way it always works, so do a simple assignment and repeat. Now the ";*" is missing
-------------------------------

yottadb>set zz="hello"

yottadb>zwr zz
zz="hello"

yottadb>
-------------------------------

I then checked what would happen if I assign this variable to another. Note that after copying the variable, the ";*" is gone.

-------------------------------

yottadb>SET ZZ=TMGVALUE

yottadb>ZWR ZZ
ZZ="HIV Below LLoQ Note SEE BELOW"_$C(9)

yottadb>ZWR TMGVALUE
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*

yottadb>ZWR TMGVALUE,ZZ
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*
ZZ="HIV Below LLoQ Note SEE BELOW"_$C(9)

yottadb>ZWR ZZ,TMGVALUE
ZZ="HIV Below LLoQ Note SEE BELOW"_$C(9)
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*

yottadb>

-------------------------------

As far as I can tell, there does not actually seem to be any hidden character at the end of the string. I think this must be some weird display bug.

yottadb>w $ZVER
GT.M V6.3-008 Linux x86_64
yottadb>


Any thoughts??

Kevin T

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Kevin,

Look at alias variables in the documentation. Here is a link to the ``zwrite command output for alias variables, which
should help you understand. https://docs.yottadb.com/ProgrammersGuide/commands.html#zwrite-format-alias-vars
I hope that helps.

--
David Wicksell
Fourth Watch Software LC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, September 17, 2023 at 5:57:22 PM UTC-6, David Wicksell wrote:

Hi Kevin,

Look at alias variables in the documentation. Here is a link to the ``zwrite command output for alias variables, which
should help you understand. https://docs.yottadb.com/ProgrammersGuide/commands.html#zwrite-format-alias-vars
I hope that helps.

--
David Wicksell
Fourth Watch Software LC

https://docs.yottadb.com/ProgrammersGuide/langext.html#alias-variable-extensions

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, September 17, 2023 at 8:00:16 PM UTC-4, David Wicksell wrote:

On Sunday, September 17, 2023 at 5:57:22 PM UTC-6, David Wicksell wrote:

Hi Kevin,

Look at alias variables in the documentation. Here is a link to the ``zwrite command output for alias variables, which
should help you understand. https://docs.yottadb.com/ProgrammersGuide/commands.html#zwrite-format-alias-vars
I hope that helps.

--
David Wicksell
Fourth Watch Software LC

https://docs.yottadb.com/ProgrammersGuide/langext.html#alias-variable-extensions

David is correct, with a small caveat: This is a passed by referenced variable, which is a kind of alias variable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, September 18, 2023 at 8:32:43 AM UTC-4, Sam Habiel wrote:

On Sunday, September 17, 2023 at 8:00:16 PM UTC-4, David Wicksell wrote:

On Sunday, September 17, 2023 at 5:57:22 PM UTC-6, David Wicksell wrote:

Hi Kevin,

Look at alias variables in the documentation. Here is a link to the ``zwrite command output for alias variables, which
should help you understand. https://docs.yottadb.com/ProgrammersGuide/commands.html#zwrite-format-alias-vars
I hope that helps.

--
David Wicksell
Fourth Watch Software LC

https://docs.yottadb.com/ProgrammersGuide/langext.html#alias-variable-extensions

David is correct, with a small caveat: This is a passed by referenced variable, which is a kind of alias variable.

Thank you David and Sam,

It is weird how I can have been using gtm/Yottadb mumps for all this time and never realized that it is possible to have alias variables.

In the yottadb reference, that David gave, there is this:

kill A,B
set A=1,*B=A ; B & A are aliases
write B

1



I understand that variable B is the same as A. But I don't understand why BOTH are considered an alias. I would normally think of A as the normal variable and B to be the alias to A. But since both variables A and B are probably really pointers to the
same memory, then I guess they are both considered aliases? So I tested this:

yottadb>kill A,B
yottadb>set A=1
yottadb>zwr A
A=1 <----------------- not displayed as alias
yottadb>set *B=A
yottadb>zwr A
A=1 ;* <----------------- now IS displayed as alias
yottadb>zwr B
B=1 ;*

It looks like the status of A does change when an alias is created.


Thanks
Kevin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, September 17, 2023 at 6:43:20 PM UTC-4, kdtop wrote:

I was debugging an HL7 import and it was choking on tab characters.

But while debugging, I encountered something I don't understand. When I ask YottaDB to zwrite the contents of my variable, TMGVALUE, is displays an extra ";*' at the end of the line.

I demonstrate below that the string does not seem to actually contain any characters after the $C(9)
-------------------------------
yottadb>ZWR TMGVALUE
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*

yottadb>F XX=1:1:$LENGTH(TMGVALUE) S XXX=$E(TMGVALUE,XX) W !,XXX," [",$ASCII(XXX
),"]"

H [72]
I [73]
V [86]
[32]
B [66]
e [101]
l [108]
o [111]
w [119]
[32]
L [76]
L [76]
o [111]
Q [81]
[32]
N [78]
o [111]
t [116]
e [101]
[32]
S [83]
E [69]
E [69]
[32]
B [66]
E [69]
L [76]
O [79]
W [87]
[9]
yottadb>ZWRITE TMGVALUE
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*

yottadb>W "[",TMGVALUE,"]"
[HIV Below LLoQ Note SEE BELOW ]
yottadb>

-------------------------------
I then wondered if this was the way it always works, so do a simple assignment and repeat. Now the ";*" is missing
-------------------------------

yottadb>set zz="hello"

yottadb>zwr zz
zz="hello"

yottadb>
-------------------------------

I then checked what would happen if I assign this variable to another. Note that after copying the variable, the ";*" is gone.

-------------------------------

yottadb>SET ZZ=TMGVALUE

yottadb>ZWR ZZ
ZZ="HIV Below LLoQ Note SEE BELOW"_$C(9)

yottadb>ZWR TMGVALUE
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*

yottadb>ZWR TMGVALUE,ZZ
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*
ZZ="HIV Below LLoQ Note SEE BELOW"_$C(9)

yottadb>ZWR ZZ,TMGVALUE
ZZ="HIV Below LLoQ Note SEE BELOW"_$C(9)
TMGVALUE="HIV Below LLoQ Note SEE BELOW"_$C(9) ;*

yottadb>

-------------------------------

As far as I can tell, there does not actually seem to be any hidden character at the end of the string. I think this must be some weird display bug.

yottadb>w $ZVER
GT.M V6.3-008 Linux x86_64
yottadb>

Any thoughts??

Kevin T

Kevin,
Unless the lab has specified a different character set in the MSH segment, this should be reported to them as a bug. Default HL7 does not allow non-printable characters in the data. From the HL7 encoding rules in section 1.6.1 of version 2.31:

All data is represented as displayable characters from a selected character set. The ASCII displayable
character set (hexadecimal values between 20 and 7E, inclusive) is the default character set unless
modified in the MSH header segment. The field separator is required to be chosen from the ASCII
displayable character set. All the other special separators and other special characters are also displayable
characters, except that the segment separator is the ASCII Carriage Return character.

It's one of my pet peeves with reference labs in particular. As a lab vendor, I take a lot of pains to make sure the data we send in HL7 is both compliant and useable. Too many these days expect other systems to magically use the same character font
and kerning so their highly formatted canned text will display/print properly.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, September 18, 2023 at 3:40:13 PM UTC-4, OldMster wrote:
...

Unless the lab has specified a different character set in the MSH segment, this should be reported to them as a bug. Default HL7 does not allow non-printable characters in the data. From the HL7 encoding rules in section 1.6.1 of version 2.31:

All data is represented as displayable characters from a selected character set. The ASCII displayable
character set (hexadecimal values between 20 and 7E, inclusive) is the default character set unless
modified in the MSH header segment. The field separator is required to be chosen from the ASCII
displayable character set. All the other special separators and other special characters are also displayable
characters, except that the segment separator is the ASCII Carriage Return character.

It's one of my pet peeves with reference labs in particular. As a lab vendor, I take a lot of pains to make sure the data we send in HL7 is both compliant and useable. Too many these days expect other systems to magically use the same character font

and kerning so their highly formatted canned text will display/print properly.

Mark

Mark, I think this discussion would be better included in the discussion on Hardhats. I'll respond there.

Kevin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)