alphanumber to hex to decimal 1

[tgreer]

I'm very, very new to COBOL, but am an experienced developer. I work primarily with print streams (PostScript and PCL).

I'm writing a COBOL (Fujitsu COBOL, PC) program to... well, skip the details. Suffice it to say I have an alphanumeric field containing something like:

11120B1314040415041617181919180104041117

I need to chop that up into hex-pair values:

11
12
0B

and so on. Then I need to use the DECIMAL equivalent as an index to a TABLE.

My question is then, how to take an ALPHANUMERIC field, containing say "11" and turn it into a NUMERIC field with a value of "17"? A string "FF" into 256?

"11" in hex = "B" in decimal = 17

Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[tgreer]

I've solved the above problem by using table lookups.

So now I have code that will convert the alphanumeric "41", for example, to the decimal "65".

The next step is to convert the decimal 65 to the character "A".

Can I do that with a redefine?


Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[Glenn9999]

I fail to see where you are going with this, entirely. You are wanting to break up the character stream into 2 char pairs, and then convert it to ASCII characters?

If you are wanting a cross-reference I would suggest doing a lookup table with your original pair and your result.

01 Lookup-table.
04 lookup-items occurs 20 times indexed by lookup-ndx.
08 lookup-hexvalue pic xx.
08 lookup-charvalue pic x.

then use SEARCH (table not sorted) or SEARCH ALL (sorted table) in order to get where you are wanting to go.

 

[tgreer]

The situation is with a Windows-driver produced PostScript file, and TrueType fonts.

The way fonts work is they have an internal table that indexes decimal values to glyph names. "65" is indexed to "/A", for example. There is a second table that indexes glyph names to the code to draw the shape of the letter: /A to -code-.

If you have the string (A) in PostScript, that is actually the ASCII 65. 65 is tied to /A, /A is tied to code to draw an "A".

Windows and Truetype ruins that. If the letter "A" is the 35th character encountered, Windows will encode that as 35, which is ASCII "#" character. Instead of having a string containing "A", you'll have a hex-string containing "23". Decimal 35 = hex 23. It'll draw the shape of an A, but it won't BE an "A". Internally, it's a completely screwball, custom encoding. Thank you, Microsoft.

I have to extract address data from such a file for address correction and postal barcoding.

So I must:

1) read the PostScript code to extract all the driver-produced encoding statements to build a table of decimal values & glyph names. In other words, duplicate the screwball encoding.

2) read in the hexidecimal strings, converting each hex-pair to it's decimal equivalent

3) use that decimal equivalent to retreive the actual character intended, from the table I built in step 1.

Clear as mud?

Thanks for your help - you solution is exactly what I ended up coding for that portion of the job.

Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[k5tm]

Well, if it doesn't have to conform to some efficiency metric, but will allow brute force, you could do something like this for the conversion (assume things that look like they should be numeric, are):

    MOVE 0 to hi-order.
    INSPECT "0123456789ABCDEF" 
        TALLYING hi-order FOR CHARACTERS
        BEFORE INITIAL in-char (in-cursor:1)
    ADD 1 TO in-cursor.
* warning - next line contains a trick!
    MOVE 1 TO lo-order.
    INSPECT "0123456789ABCDEF" 
        TALLYING lo-order FOR CHARACTERS
        BEFORE INITIAL in-char (in-cursor:1)
    ADD 1 TO in-cursor.
    COMPUTE one-relative-index = 
        (hi-order * 16) + lo-order.

As for extracting a character from a table, one-relative-index would do that quite nicely when used as a subscript. or as an offset value in address modification.

Tom Morrison

http://www.liant.com

 

[tgreer]

I'm not sure why I got a purple star, but thanks!

A set of tables does the trick. One to hold a numeric value for a alpha-hex digit: "A" = 10. Use reference modification in a perform loop to divide the hex-string into pairs, and use the table to compute a decimal value.

That decimal value is the index to the table that was built to hold the character encodings.

Program complete!

Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[slade]

Hi Tom,

Here's a mainframe solution to create the index or subscript. Maybe you (or someone here) could modify it for your needs).

WS...

05  in-char        pic  x(001).

05  in-wrk         pic s9(002).

05  out-wrk.       
    10  out-packed pic s9(002) comp-3.
        10  wrk-idx    redefines   out-packed   
                   pic s9(004) comp.  
            



I won't code the loop here, just the conversion routine in pcode.

PD...

    if in-char            > 'F' ... error
    move in-char         to in-wrk(1:1)
    move in-wrk          to out-packed
    move out-packed(1:1) to out-packed(2:1)
    move x'00'           to out-packed(1:1)
    if in-char           is alphabetic
       add  +9           to out-packed      
    end-if 

Now you can
    move some-data to table-entry(wrk-idx)   
    .

Moving the proposed index to a packed field will remove the hi-order "nybble" provided that it is not the lo-order byte. That's the reason for moving it to the hi-order byte of in-wrk. If the ip fld is numeric no adjustment is required; but when it's alpha 9 must be added to the binary definition of the op field.

Cautionary note: Just theory at this point; not tested.




Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering

 

[slade]

Sorry, Tom. I solved for 1 byte. Of course, hex digits are represented by 2 char digits. Must still be on vacation time, + a bad trip back.

It's not that bad though. The basic idea is the same. You can make it a subroutine and perform it twice, then move the 2 halves to their proper places in the index field.

Sorry about the muck up.

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering

 

[WMK]

Sorry not to see this earlier. COBOL has a "build-in" intrinsic function to do EXACLTY what you are asking for.

Given
Inp-Field Pic X.
Out-Dec Pic 999.

Compute OUt-Dec = Function ORD (Inp-Field) - 1

***

You need to do the "- 1" because ORD starts at the decimal value "1" for X'00'.

Bill Klein

 

[slade]

Bill, if I'm not mistaken, his Inp-Field is a 2 byte A/N field (e.g. X'F1F1') that represents an X'11' or decimal 17. So he has to convert the X'F1F1' to an X'11'.

That's the way I interpreted it, although I don't know why he can't use the binary (comp) value as the table index. It should be more efficient.



Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering

 

[tgreer]

There are two issues. One is to convert a STRING REPRESENTATION of a HEX-PAIR, to an actual decimal value. I did that with a table that maps alpha characters "1" through "F" to decimal values. Basic string manip and compute did the rest.

The second issue is to convert that decimal value to an ASCII character, however, that character is not in standard ASCII encoding. Simply redefining a 4 digit binary field to an alpha field will do that.

The encoding is custom, and I build the custom encoding via a table. The decimal value I compute from the hex string is used as an index (offset) to that table.

As I mentioned in an earlier post "program done!". Thanks for all the messages.

Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[Crox]

Perhaps some old answers are interesting: thread209-54782