"Roger Bruce" <roger...@bendigobank.com.au> wrote in message
news:dff1bf2b.02043...@posting.google.com...
>Does anyone know how we can do an XOR function within rexx, if the
>function itself isnt supported by your rexx implementation?
Lot's of ways. The easiest way is probably Mark's suggestion to use
BITAND and BITOR. Alternatively, you could use c2b, add the binary,
translate "012" to "010" and use b2c, but that's the long way around.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2, Team OS/2, Team PL/I
Any unsolicited commercial junk E-mail will be subject to legal
action. I reserve the right to publicly post or ridicule any
abusive E-mail.
I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
According to Mark Yudkin in a posting to comp.lang.rexx:
>xor(a,b) = and(or(a,b),not(and(a,b)))
>"and" is written BITAND, "or" is written BITOR in REXX.
>For "not", consider that not(a) = xor(a,true) and solve the equations!
I don't think those equations are soluble...
The closest we might get is: not(a) = d2c(true - c2d(a))
(where true = x2d(copies('FF', length(a))) or something like that).
But that's rather ugly and one might rather end up with Mr Metz's
suggestion:
bitxor: procedure
parse arg a,b
abits = x2b(c2x(a))
bbits = x2b(c2x(b))
numeric digits max(length(abits),length(bbits))
axbbits = translate(abits+bbits,0,2)
return x2c(b2x(axbbits))
However, I note that BITXOR() is listed as a built-in function in the
Rexx Reference Summary Handbook (c.1994) so I'm not sure what all this
fuss is about. ;-)
(Also, Rexx has a "logical xor" operator, namely: &&).
--
---- Ian Collier : i...@comlab.ox.ac.uk : WWW page (including REXX section):
------ http://users.comlab.ox.ac.uk/ian.collier/imc.shtml
New to this group? Answers to frequently-asked questions can be had from
http://rexx.hursley.ibm.com/rexx/ .
CEMS100, btw, is the protocol use by Lieberts Air Handlers to
communicate with one another, and its all pretty much 'Hex speak'.
I'll try and do this without breaching the licence agreement on this
document.
Control Functions - a 5 byte message sent to the controller
Byte 1 - (Unit Number - 1) XOR f0h
eg f0h = unit1, f1h - unit 2 etc down to C2h = unit 51 etc onto 92h =
unit 99
Byte 2 - control request 11h
Byte 3 - Number of bytes to follow in this message (02h in this case)
Byte 4 - Control funtion Number 00h - 06h (wont say what they are)
Byte 5 - Checksum - the least significant byte of the binary sum of
bytes 1 to 4
There example is in basic, and noone I know has a memory that goes
back that far... But here it is anyway.
PRINT #1, CHR$ ((UNITNO-1)XOR 240); CHR$(17: CHR$(@); CHR$(TEMP);
CHKSUM = ((UNITNO-1)XOR 240) +17 +2 +TEMP
PRINT #1, CHR$(255 AND CHKSUM);
UNITNO is the unit number polled and TEMP is the control function
number.
How the heck do you do that in REXX?
>How the heck do you do that in REXX?
unitbyte = bitxor(d2c(unitno-1,1),'f0'x)
call charout , unitbyte || '1102'x || d2c(temp,1)
chksum = c2d(unitbyte) + 17 + 2 + temp
call charout , d2c(chksum,1)
Can anyone tell me what a good book is that goes into details on
'standard' functions available to REXX, like stream subcommands, OLE
stuff etc? I have the esteemed Mr Cowlishaw's Practical Approach to
programming : The REXX language, but it due to implementation
specific's, a lot of this stuff is missing. We are running, what CA
call 'ANSI REXX', which is a bit of a lie, because half the ansi
standard isnt included (!!) on an NT box.
>Can anyone tell me what a good book is that goes into details on
>'standard' functions available to REXX, like stream subcommands, OLE
>stuff etc?
OLE isn't standard. For STREAM, see the ANSI standard. For OS/2 I use
Dick Goran's REXX Reference Summary Handbook, but, again, a lot of the
important material is not standard.
>CA
>a bit of a lie
Redundant. Is there any reason to not run Regina or OREXX?
Unfortunately not. The standard just says that the third parameter of
STREAM(stream,"C",command) is passed to the configuration to perform
some action.
I would have liked to have seen some "recommendations" of standard
stream commands, but the committee felt that this couldn't be specified
because not all environments are guaranteed to have such concepts as
(for instance) opening or closing files.