IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

converting A-Z 0-9 to table index


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
David McCrina

New User


Joined: 11 Apr 2013
Posts: 6
Location: Atlanta, GA USA

PostPosted: Wed May 08, 2013 9:58 pm
Reply with quote

Hi...I have searched the forum and could not find an answer to this, if it has already been addressed I apologize.

Here is what I would like to do:

A one character field can have a value of A-Z, 0-9. I want to use that value as an index to a table position (A-Z = positions 1-26, 0-9 = positions 27-36 in the table).

I have looked at maybe using the INSPECT CONVERTING, but that seems to be a one-to-one correspondence...you have to convert to the same length as the field you are inspecting.

I have also thought about the NUMVAL function, but does that only convert an alpha field containing numerics to a numeric field, or does it convert the value A to a numeric equivalent (like hex C1)?

Any ideas how a can make that translation from A-Z, 0-9 to 1-36?

Thanks!
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Wed May 08, 2013 11:11 pm
Reply with quote

Method 1: use EVALUATE on the 1-byte variable
Method 2: use IF statements on the 1-byte variable
Method 3: use FUNCTION ORD in either EVALUATE or IF statements (this needs multiple uses since A to Z are not sequential in the collating sequence)
Back to top
View user's profile Send private message
David McCrina

New User


Joined: 11 Apr 2013
Posts: 6
Location: Atlanta, GA USA

PostPosted: Wed May 08, 2013 11:21 pm
Reply with quote

Thanks for the reply...I was hoping to avoid having to code 36 occurrences of either a WHEN condition or ELSE condition.

I was wondering if there was either a way to do it using a different COBOL verb or function, or a mathematical routine to make the translation.

I don't know if you could use the hex values (C1-C9, D1-D9, E2-E9, F0-F9) somehow.

I'll look at the ORD function.
Back to top
View user's profile Send private message
David McCrina

New User


Joined: 11 Apr 2013
Posts: 6
Location: Atlanta, GA USA

PostPosted: Wed May 08, 2013 11:31 pm
Reply with quote

Quick question...can you do something like:
INSPECT FIELD CONVERTING X'C1C2...F9' to X'0102...24'?
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Wed May 08, 2013 11:32 pm
Reply with quote

Is the performance of a PERFORM VARYING unacceptable?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed May 08, 2013 11:36 pm
Reply with quote

David,

Welcome to the forum.

Binary-Fullwords are your friend.

How about this -

Code:

03  WS-SUB PIC 9(08) BINARY.
03  WS-SUB-X REDEFINES WS-SUB PIC X(04).
03  WS-ARG PIC X(01).

MOVE ZERO TO WS-SUB.
MOVE 'A' TO WS-ARG.

INSPECT WS-ARG CONVERTING 'ABCDEFGHIJLKMNOPQRSTUVWXYZ0123456789'
TO X'0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F2021222324'.

MOVE WS-ARG TO WS-SUB-X (LENGTH OF WS-SUB-X:).

At this point, WS-SUB (can be used as a table-subscript) will be in the range of decimal 01 thru 36, with values of 01-26 representing letters 'A' thru 'Z' and values of 27-36 representing numerics '0' thru '9'.

Because you're using literals, the underlying INSPECT CONVERTING generates an In-Line Assembler "TR" (Translate) instruction (under the covers), so it's very efficient. The compiler will also build the "FROM" and "TO" translate-tables in its Dynamic-Storage.

Always define WS-SUB as a fullword and you'll stay out of trouble with COBOL idiosyncrasies and how it deals with halfwords. It's only two-bytes. icon_wink.gif

HTH....
Back to top
View user's profile Send private message
David McCrina

New User


Joined: 11 Apr 2013
Posts: 6
Location: Atlanta, GA USA

PostPosted: Wed May 08, 2013 11:36 pm
Reply with quote

Akatsukami wrote:
Is the performance of a PERFORM VARYING unacceptable?


I am not sure how the PERFORM VARYING would help, can you give the example?

Thanks
Back to top
View user's profile Send private message
David McCrina

New User


Joined: 11 Apr 2013
Posts: 6
Location: Atlanta, GA USA

PostPosted: Wed May 08, 2013 11:38 pm
Reply with quote

Bill...thanks, that looks like a good solution. I'll give it a shot!
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu May 09, 2013 3:53 am
Reply with quote

Table with 36 values, PERFORM VARYING to find equal for the one you want.

SEARCH. SEARCH ALL.

Various ways relying on the right-most half-byte and the entire byte in combination.

With the INSPECT, ensure that you cater for/have catered for processing a "character" that is not A-Z or 0-9.
Back to top
View user's profile Send private message
David McCrina

New User


Joined: 11 Apr 2013
Posts: 6
Location: Atlanta, GA USA

PostPosted: Thu May 09, 2013 8:32 am
Reply with quote

Thanks Bill...by the time the INSPECT will be done the value would have already been validated, so we're good there.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Issues Converting From ZD to Signed N... DFSORT/ICETOOL 4
No new posts Load new table with Old unload - DB2 DB2 6
No new posts Pulling a fixed number of records fro... DB2 2
No new posts Multiple table unload using INZUTILB DB2 2
No new posts Check data with Exception Table DB2 0
Search our Forums:

Back to Top