Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

pic x(2) to hex

Status
Not open for further replies.
melimae

melimae

ISP
Jul 29, 2005
16
US
I have a text file as input to a cobol program with a 2 character field that is suppose to be hexadecimal, the file will have 00 in the field when it should actually be x'00'. How can I pull this filed into my program in a pic x(2) field and then have it represent a hex x'00'?
 
Sort by date Sort by votes
Maybe I didn't explain very well. What if the value in the input field was 02 and I want it to actually be x'02'? I want it to be generic. The two character in the input field can be anything and I want to store it as x'input'.
 
Upvote 0 Downvote
No, the input file is a text file with the value of 02 or 00 or 01 in the field. I have to take that 2 character field from the input file and store it as a one byte field of x'02' or x'00' or x'01' respectivly, depending on what was in the input field. So if the input is the characters 02 then I would store x'02' in a one byte field, but these two characters could be anything.
 
Upvote 0 Downvote
if I got it correctly you will have values from X"00" to X"FF".

If so then create a program similar to the following.

01 hex-group.
05 pic x(2) value "00".
05 pic x(2) value "01".
..... similar records
05 pic x(2) value "FE".
05 pic x(2) value "FF".

01 hex-group-r redefines hex-group
05 hex-pair pic x(2) occurs 256.

This bit now depends on your compiler vendor and on the options used.

01 hex-num pic 9(4) binary.
05 pic x(1)
05 hex-char pic x(1).
01 my-input-field pic x(2) value "04".
01 w-i pic 9(4).
...
perform varying w-i from 1 by 1
until w-i > 256
or my-input-field = hex-pair(w-i)
continue
end-perform.
if w-i > 256
display "input field error. not a valid Hex string"
else
move w-i to hex-num
subtract 1 from hex-num
display hex-char (this now contains your hex string.
end-if.

Regards

Frederico Fonseca
SysSoft Integrated Ltd
 
Upvote 0 Downvote
What compiler are you using? There may be a really straightforward way of doing this based upon a compiler feature not in the COBOL standard.

Tom Morrison
 
Upvote 0 Downvote
I'm using the COBOL OS/390 compiler and the output file is sequential.
 
Upvote 0 Downvote
Melimae,

Does the two byte field always contain a valid hex number, a valid decimal number, or anything at all?

Marc
 
Upvote 0 Downvote
Don't know if this is what you need, but ...
Code: 
01  HEX-DIGITS   VALUE '0123456789ABCDEF'.
    05  HEX-DIGIT OCCURS 16 TIMES PIC X.

*  table to contain all 256 possible inputs
01  WS-2-BYTE-STRING.
    03  WS-2-BYTES OCCURS 256 TIMES
                   INDEXED BY WS-2-IDX
                   ASCENDING KEY WS-2-BYTE-ENTRY
        04  WS-2-BYTE-ENTRY.
            05  BYTE1             PIC X.
            05  BYTE2             PIC X.

01  WS-RESULT.
    05  WS-RESULT-N               PIC S9(4) COMP.
    05  REDEFINES WS-RESULT-N.
        10                        PIC X.
        10  WS-RESULT-X           PIC X.

*  Initialize table of possible results
SET WS-2-IDX                 TO 1
PERFORM VARYING J FROM 1 BY 1 UNTIL J>16
    PERFORM VARYING K FROM 1 BY 1 UNTIL K > 16
        MOVE HEX-DIGIT(J)    TO BYTE1(WS-2-IDX)
        MOVE HEX-DIGIT(K)    TO BYTE2(WS-2-IDX)
        SET WS-2-IDX         UP BY 1
    END-PERFORM
END-PERFORM
...
*  input 2 bytes in WS-INPUT-FIELD
*  result in 1 byte in WS-FINAL-RESULT-BYTE
SEARCH ALL WS-2-BYTES
    AT END DISPLAY "INVALID INPUT"
    WHEN WS-2-BYTE-ENTRY(WS-2-IDX) = WS-INPUT-FIELD
        SET WS-RESULT-N      TO WS-2-IDX
        SUBTRACT 1         FROM WS-RESULT-N
        MOVE WS-RESULT-X     TO WS-FINAL-RESULT-BYTE
END-SEARCH
I'm not sure there's not a faster/better way, but ... perhaps this will generate some discussion.

Regards.

Glenn

BTW - this has not been compiled or tested in any fashion and likely has some stupid COBOL syntax errors in it.
 
Upvote 0 Downvote
Hi melimae,

Something like this should work. The move to the packed fls will strip the hi-ord nibbles from the 2 bytes in your fld, leaving the 2 lo-ord nibbles in hex-fld.
Code: 
WS
05  wrk-fld.
    10  hld-fld  pic x(2).
    10  fil      pic x.
05  num-fld      redefines
    wrk-fld      pic 9(3).

05  packed-fld   pic 9(3) comp-3.
05  hex-fld      redefines
    packed-fld   pic x(1).

PD

move your-fld to hld-fld
move wrk-fld  to packed-fld 
display '>' hex-fld '<'
When you view your sysout in SDSF use SE not s. Then enter hex on in the cmd line. You should see the stripped field you moved between the ">nn<".



Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering
 
Upvote 0 Downvote
Jack -

I'm not sure your approach works. E.g. if the input field is "AA" (x'C1C1' representing 170), your move to the packed field results in x'11xx' which gives the result field a value of x'11', not x'AA'.

Perhaps one of us misunderstands the problem?

Glenn
 
Upvote 0 Downvote
melimae,

As you can see your question seems to have different interpretations. Be really specific.

For instance if you are saying your 2 byte input field is always numeric and contains a range of 00-99 and if your compiler allows 1 byte binary, then code such as:

move zeros to comp-field.
add input-field to comp-field.

would do the trick.


Clive
 
Upvote 0 Downvote
Hi Glenn,

I wanted to preface my suggestion w/the stmt: "I assume you mean that you have a 2 byte field X'F0F0' that you want to represent as X'00'." But I forgot (one of those senior moments I've heard about).

I'm guessing that those 2 byte fields that Melimae mentions are DISPLAY numeric fields, because you can't fit "MM" into a 1 byte field.

Maybe Melimae can enlighten us.

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering
 
Upvote 0 Downvote
I just reread the thread (what a novel idea!) and Melimae said:
No, the input file is a text file with the value of 02 or 00 or 01 in the field. I have to take that 2 character field from the input file and store it as a one byte field of x'02' or x'00' or x'01' respectivly, depending on what was in the input field. So if the input is the characters 02 then I would store x'02' in a one byte field, but these two characters could be anything.
Click to expand...

So my proposed solution should work for the 3 values 02, 00 or 01 (ie. X'F0F2', X'F0F0' OR X'F0F1') by changing them to X'02', X'00' OR X'01' respectively.

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering
 
Upvote 0 Downvote
Jack,
Last time Melimae logged in was on Friday 3rd. I'm still waiting for an answer to my question of that date. Clarification is needed I feel!
Marc
 
Upvote 0 Downvote
Wow, thank you to everyone for trying to help me out. I think slade has the right idea. The input value would be in the form x'F0F2' and I want it to be changed to x'02'for any valid "hex" value entered. The input will be checked before entering into the program to make sure that it contains a valid "hex" value.
 
Upvote 0 Downvote
Could just have a really long case statement.

if field-1 = 'A1' FIELD-2 = X'??'
else if field-1 = 'A2' field-2 = X'??'
where xx is the hexadecimal notation.
Padding is X'40' in my manual.

This just stores some possible symbol and/or control code in a field.

It might be possible to store a dangerous control code that could cause problems or unexpected results.

My mainframe book has this as a literal but I wonder if you could just load a table with all of your pic x values with the hex values preloaded and just look it up in the table. Once you loaded the table, it would be in memory. Seems like it could be accessed really fast. Some compilers may have other ways of dealing with this like using database fields.



If you do not like my post feel free to point out your opinion or my errors.
 
Upvote 0 Downvote
I think there is going to be a problem with slade's approach. You're relying on the technique of packing a number which saves the 'numeric' portion of the byte. That works good for input values such as '01' '02' etc where each of the characters is numeric. When you move this to your work field, you move the hex value F0 F1. You never initialized the third byte of the work field but let's assum it has low-values. So now your work field has the hex value 'F0 F1 00'. I think you intended to move the numeric redefinition to the packed field. Since they are unsigned, the compiler first strips any potential sign so your work field is 'F0 F1 F0'. Packing that into the 2-byte packed field yields '01 0F'. You reference the first byte and get your X'01' as you wanted.

But how about if you have an initial input value of 'FA'? That is a hex value of 'C6 C1'. Your work field now has 'C6 C1 00'. Moving that to the packed field yields '61 0F' and the first byte is X'61' when you wanted X'FA'.

Your technique works okay if the hex values you are converting have a digit 0-9 in both the zone and numeric portion. But any other values will not work.

I think either a large table or case statement with all the combinations of the 2 characters (256 entries) and the one byte hex would be the way to go.
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

klophockey
  • Locked
  • Question
How To Determine Encoding Of A File - And see the contents in Hex 1
Replies
3
Views
287
fredericofonseca
fredericofonseca
whoyou
  • Locked
  • Question
REALIA COBOL convert hebrew ansii (hex 80 - 9A) to cp862 (hex E0 - FA)
Replies
0
Views
97
whoyou
whoyou
AMCM
  • Locked
  • Question
COBOL SEQQUENTIAL FILE TO CSV 1
Replies
16
Views
501
AMCM
AMCM
AMCM
  • Locked
  • Question
COBOL ERROR : Transfering data from txt file to another 1
Replies
12
Views
331
AMCM
AMCM
Crox
  • Locked
  • Question
some pictures...
Replies
1
Views
122
Crox
Crox

Part and Inventory Search

Sponsor

Back
Top