>>

>>? 18014398509481983 = 18014398509481984
>>

>>
>>returns .T., which is wrong, of course. That will give about 55 bits that can be stored as numeric values, but even those will require an external library to perform the calculations.
>>
>>By using string binary data to hold the flags, you won't need external tools and won't be limited to 64 bits (you could easily escalate to 128, 256, and so on).
>
>Which I did already, years ago, in a field of c(200) type, which held statuses for other fields in the same record. Used only two bits per byte, so there was room for expansion :). Luckily, the expansion never happened, it was already complicated as it was.

For all who have helped,

I drop the binary approach, and change to a string method. Instead of examining the bits of the numerical flags variable, I am scanning a comma delimited string for the existence for the flags name. If exist, consider the flag as set, otherwise unset. Not only does this overcome the binary limitation, but adds to the readability in my code.

Thanks for all help.