Hi, You should be able to MOVE your character field to your binary field. You'll need to check that you don't have any invalid data before you do the move. Regards, Martin Gilbert. -------------------------------------------------------------------------------- Just to expand on Martin's idea a little bit. The following (as is pointed out in his answer) will work: <pre> fBinKeyFileif e k disk dAlphaKey s 10 inz('0000000002') c move AlphaKey Key c Key chain BinKeyFile 01 c *in01 ifeq *off c Data dsply c else c 'Not Found' dsply c endif c move '1' *inlr c return </pre> where BinKeyFile is defined as: <pre> R RECORD KEY 9B 0 DATA 50 K KEY </pre> BUT there is an assumption being made here, namely that your alphanumeric 10 byte field is using leading zeroes as in the sample program. If, on the other hand, the key value comes into your program as '2 ' then MOVE will toss the '2' due to how 9B 0 fields are implemented. There are ways around this but I won't go into them on the assumption that your field is formatted as above. To test add a record to BinKeyFile with a key of 2. Using inz('0000000002') as above the record is found on the chain operation. Using inz('2') the record is not found on the chain operation. Bruce Vining ==================================================== Here's an alternative that uses the atoi() C runtime function:<pre> H debug H DftActGrp(*No) H ActGrp(*Caller) H BndDir('QC2LE') D atoi pr 10i 0 extproc( 'atoi' ) D * options( *string ) value D wrkAlpha s 10 inz( ' 12345 ' ) D atoiInt1 s 5u 0 inz( 0 ) D atoiInt2 s 10i 0 inz( 0 ) C eval atoiInt1 = atoi( wrkAlpha ) C eval atoiInt2 = atoi( wrkAlpha ) c dump C seton lr C return</pre> It should compile and run as is. It can be useful for some strings of characters. Leading/trailing blanks are ignored. Leading zeros aren't required. The example returns a 2-byte unsigned integer first, then a 4-byte signed integer. If a RPG 'B' field is needed, it won't be a problem. Tom

Hi, You should be able to MOVE your character field to your binary field. You'll need to check that you don't have any invalid data before you do the move. Regards, Martin Gilbert. -------------------------------------------------------------------------------- Just to expand on Martin's idea a little bit. The following (as is pointed out in his answer) will work: <pre> fBinKeyFileif e k disk dAlphaKey s 10 inz('0000000002') c move AlphaKey Key c Key chain BinKeyFile 01 c *in01 ifeq *off c Data dsply c else c 'Not Found' dsply c endif c move '1' *inlr c return </pre> where BinKeyFile is defined as: <pre> R RECORD KEY 9B 0 DATA 50 K KEY </pre> BUT there is an assumption being made here, namely that your alphanumeric 10 byte field is using leading zeroes as in the sample program. If, on the other hand, the key value comes into your program as '2 ' then MOVE will toss the '2' due to how 9B 0 fields are implemented. There are ways around this but I won't go into them on the assumption that your field is formatted as above. To test add a record to BinKeyFile with a key of 2. Using inz('0000000002') as above the record is found on the chain operation. Using inz('2') the record is not found on the chain operation. Bruce Vining ==================================================== Here's an alternative that uses the atoi() C runtime function:<pre> H debug H DftActGrp(*No) H ActGrp(*Caller) H BndDir('QC2LE') D atoi pr 10i 0 extproc( 'atoi' ) D * options( *string ) value D wrkAlpha s 10 inz( ' 12345 ' ) D atoiInt1 s 5u 0 inz( 0 ) D atoiInt2 s 10i 0 inz( 0 ) C eval atoiInt1 = atoi( wrkAlpha ) C eval atoiInt2 = atoi( wrkAlpha ) c dump C seton lr C return</pre> It should compile and run as is. It can be useful for some strings of characters. Leading/trailing blanks are ignored. Leading zeros aren't required. The example returns a 2-byte unsigned integer first, then a 4-byte signed integer. If a RPG 'B' field is needed, it won't be a problem. Tom