>
>>It is a number in string format. Given a record with optional fields, each bit in the binary string corresponds to a field in the record. For example, if the fifth field is included, the fifth bit in the binary number is set on. If the fifth field is not included, the fifth bit in the binary number is set off. This binary number is then converted to hex and sent at the beginning of the record. When I get a reply record back, I have to do the opposite...convert from hex to binary to determine which fields have been sent. I may not always have 16 bits...it depends on the record type that is sent. Different record types have a different number of fields.
>>
>>Craig

Craig,

I think Paul may have hit on something earlier with the mention of the BITSET() (or you could use BITOR()) function. Let me, however, see if I can summarize what's going on with the system. There are various tables in the system with different numbers of fields. When information is sent to the other application, a hex value is sent indicating what fields are to be used. Currently, a string is being built, which is a representation of the physical location of the field in the table. Bit 0 means field 1, bit 1 field 2, etc.

If this is correct, what Paul proposed was to skip building the string and simply set the bits in a numeric variable. This will allow you to do away with the overhead of building the string. You would only have to take the value and convert it to hex. The functions that I forwarded required that the the representation of the binary value, be converted to a numeric prior to determining the hex string. That's another layer of overhead that could be elminated.

To set the bits all you have to do is:

lnvalue = BITSET(lnvalue, fieldnum - 1)

or

lnvalue = BITOR(lnvalue, 2 ^ (fieldnum - 1))

Or have I missed something?

George