OCONV(WK<1,E>,"MX MD0Z")

[peas]

Hi,

The following OCONV code is not understood by Cache: “MX MD0Z”, (eg:
CODE TRIM(OCONV(WK<1,E>,"MX MD0Z")) ) - but it is understood on
UniData.

What does this do ? (so I can look up the Cache equivalent)


Thanks

Steve

[Matt Stern]

Looks like it's trying to do an ASCII character to hex conversion (the
"MX" portion), then suppress it altogether if the result is a zero,
which it can't be (because a zero would be hex 30), then remove all
redundant spaces from the string.

For example, the string ABC becomes 414243

I've never seen two conversions in one like this on any other system, so
I'm not surprised that it doesn't work on Cache.

HTH

--
Matthew H. Stern, CDP CCE CCP
mst...@comprehensive.com

CCS Inc.
Increase your Profit by Managing IT (sm)
www.comprehensive.com
Since 1987

Phone: 631 755-2250, Fax 755-2254
169 Commack Road, Suite H-233
Commack, NY 11725

[peas]

Right,

So the issue is the double-conversion taking place, which can be
rewritten as follows:

PRINT OCONV(OCONV("10","MX"),"MD0Z")
A

PRINT OCONV(OCONV("0","MX"),"MD0Z")
<<< nothing


That's the same thing right ?
Steve

[tomh]

Hi,

This actually does work in Cache provided there is a value mark in
between the 2 convs, which leads me to think there is a value mark in
the original also? But maybe Unidata is more loose?

0004: A = "ABC"
0005: B = TRIM(OCONV(A,"MX]MD0Z")) <--- the ] is a value mark.
0006: *
0007: CRT B
0008: END

:run bp test.doubleoconv
414243

Tom Shrugs...

[Ed Clark]

I don't think that this actually works on unidata either. It may
appear to work because unidata ignores the part after the invalid space.
Multiple conversions in oconv/iconv or in a-type dictionary lines 7
and 8 or I/D-type dictionary line 3 always need to be separated with
value marks. Using a different pair of conversions:

0001 X='123abc'
0002 CRT OCONV(X,"MCA MCT")
0003 CRT OCONV(X,"MCA":@VM:"MCT")

unidata says:
abc
Abc

The second oconv with a value mark is correct, and the first with a
space fails on unidata.

Looking at the original conversion, "MX MD0Z":
On most multivalue platforms, MX converts a string to a text hex
equivalent, i.e:

OCONV(char(7):'0',"MX")

will return 0730. This is usefull for encoding a string with binary
characters. This works on unidata, but only if BASICTYPE is "P", not
in the default unidata emulation. On cache, you can use "MX0C" (also
works on unidata) or "MCAX" if this was the intention.

However, on unidata ideal, and on universe ideal, "MX" converts
numeric from decimal to hex. OCONV("12","MX") returns A; oconv
("1234","MX") returns 4D2. Note the difference here between this and
the other meaning of "MX". On d3/universe pick/unidata in basictype
"P", OCONV("1234","MX") returns 313233, converting each character to a
2-character hex equivalent. On unidata ideal, OCONV("1234","MX")
returns 4D2, converting a decimal number to hex. This second meaning
is probably what your code intends to do.

The second code, "MD0Z" trims leading zeros and rounds to 0 decimal
places. As far as I can tell, it's superfluous, because MX doesn't
return leading zeros, and truncates decimals.

Because MX is ambiguous, and MD0Z is superfluous, I'd suggest
replacing the conversion with "MCDX" which converts decimal to hex on
all platforms and emulations.

Isn't it nice the way Cache complains about invalid conversion codes
instead of just ignoring them like unidata?

> --
> You received this message because you are subscribed to the Google
> Groups "InterSystems: MV Community" group.
> To post to this group, send email to Cac...@googlegroups.com
> To unsubscribe from this group, send email to CacheMV-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/CacheMV?hl=en

[Jim Idle]

Avoid hard coding value marks in your code though. Use @VM etc instead.

Jim

> --
> You received this message because you are subscribed to the Google
> Groups "InterSystems: MV Community" group.
> To post to this group, send email to Cac...@googlegroups.com
> To unsubscribe from this group, send email to CacheMV-

> unsub...@googlegroups.com