CompuServe Messages

… d2c() vs. CHR$() … Yes, function d2c() does indeed give you ASCII characters based on the value you supply in the parens. Try the following direct command: RX "say d2c(65)" .. you'll get upper case A, similarly: RX "chnum = 65 ; say d2c(chnum)" .. same thing. With a "typeless" language such as ARexx, it sometimes takes a moment to realize that a numeric variable can generally be assumed to be in decimal. Next step: RX >RAM:TEST "say d2c(65)d2c(10)" followed by TYPE HEX RAM:TEST. You'll see that three characters have been written (SAY automatically inserts a NewLine at the end, making two of them). By the way, you might feed more comfortable putting two vertical bars ahead of the second d2c(), but it works either way. If you use a value greater than 255, d2c() will generate more than one byte (unless you force it with a second parameter) .. in fact, you could go up to four bytes. This allows d2c() and c2d() to easily translate multi-byte addresses to and from their decimal equivalents. I doubt that you would need that feature for your telecomms coding, but it's there. You could try: RX "say d2c(1248814369)" .. to see this work. Where you want to code a fixed character (or string), you can bypass the d2c() function by just defining the characters directly; a command such as: RX "say '48 65 6C 6C 6F 21'x" .. will output the hex characters quite neatly. And you can omit the spaces for greater compactness and lower readability. I don't know function CVi2a, and can't find any reference to it in my ARexx guides. I speculate that it's from some library I haven't encountered or tried using. From the above, you may decide that you don't need to fuss with it. ARexx can use pointers if you really have to, typically with commands such as IMPORT or EXPORT. But again, I suspect you won't need to worry about them right now. –Jim