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.
Just to expand on Martin’s idea a little bit. The following (as is pointed out in his answer) will work:
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 ‘Not Found’ dsply
c move ’1′ *inlr
where BinKeyFile is defined as:
KEY 9B 0
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.
Here’s an alternative that uses the atoi() C runtime function:<pre>
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 seton lr
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.