HP3000-L Archives

June 2001, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Tue, 19 Jun 2001 11:42:26 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
X-no-Archive:yes
I bet the folks on Interex's COBOL list would enjoy discussing this one.

As Ken points out, PIC 9 (implicitly USAGE DISPLAY), while one byte, cannot
be more than 9, at least not without a USAGE clause for binary / comp, or
packed decimal / comp-3. All the values you give work for binary, and 0x72
is the hex equivalent of decimal 113, so it doesn't look like you have to
worry about it being packed decimal, at least.

Without playing with this, I'm not sure off the top of my head what COBOL is
doing here. I would guess that it is not performing any type conversion, so
that 0x72 is being treated as a string, and so is represented by ASCII "q",
and is less than the string "113", in its collating sequence.

If you could briefly state the goal (and consider cross-posting to
[log in to unmask]) of your processing, folks ought to be able to give you
some good ideas, how to accomplish it. I can see more than one way to do it,
but there is probably one way that makes the most sense, depending on the
goal.

I would state that instead of redefining as a bunch of one-byte fields, you
might want to redefine as a indexed table with OCCURS. Then you could put
the processing inside a PERFORM VARYING INDEX FROM 1 BY 1 loop, instead of
having to code for n fields.

Greg Stigers
http://www.cgiusa.com

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2