Is the length of a picture string always equal to the length of the string DISPLAYed?

The context here is writing a tool to perform analysis on COBOL source
code. Assume that when I load the source code into memory, I do some
preprocessing so that picture strings like "X(6)" never occurs. For example,
perhaps I will always expand repeat-factors so in some earlier stage so that
the later analysis stages see "XXXXXX" instead of "X(6)".

Suppose you have a picture string like "$$,$$9.99" which contains 9
characters. Regardless of what data the item with this picture string
contains, when I try to DISPLAY it, the output displayed always consists of
9 characters as well, e.g. "  $128.00", where the space character is
inserted to pad the output string to the correct length.

Is this always true (assuming the COBOL compiler complies with the 85
standard), or does there exist a picture string that one could write where
the length of the output does not match the length of the string?  Again,
recall that the picture strings will never, at this point, contain
repeat-factors, so although "X(6)" is technically a picture string of length
4, the analysis module will actually see "XXXXXX", which is a picture string
of length 6, and its naive(?) algorithm of assuming that the picture length
is equal to the output length, and concluding that the output will be of
length 6 is correct.

- Oliver

On Tue, 14 Feb 2006 21:31:04 GMT, "Oliver Wong" <owong@castortech.com>
wrote:

>    Is this always true (assuming the COBOL compiler complies with the 85
>standard), or does there exist a picture string that one could write where
>the length of the output does not match the length of the string?  Again,
>recall that the picture strings will never, at this point, contain
>repeat-factors, so although "X(6)" is technically a picture string of lengt
h
>4, the analysis module will actually see "XXXXXX", which is a picture strin
g
>of length 6, and its naive(?) algorithm of assuming that the picture length
>is equal to the output length, and concluding that the output will be of
>length 6 is correct.

Why is it important that the picture is XXXXXX instead of X(6)?    The
answer in either case is the same.    It is always true.   We have to
jump through hoops to compress our output for export to programs that
expect delimited data.

"Howard Brazee" <howard@brazee.net> wrote in message
 news:6ij4v11u3rbh1dn38oebo64c2nkrasb5it@
4ax.com...
>
> Why is it important that the picture is XXXXXX instead of X(6)?

Because the string "X(6)" has 4 characters in it ('X', '(', '6', and
')'), and yet it will produce an output of length 6, which will cause the
naive formula of "length of output = length of picture string" to fail.

- Oliver

On Tue, 14 Feb 2006 21:52:12 GMT, "Oliver Wong" <owong@castortech.com>
wrote:
 
>
>    Because the string "X(6)" has 4 characters in it ('X', '(', '6', and
>')'), and yet it will produce an output of length 6, which will cause the
>naive formula of "length of output = length of picture string" to fail.

Then S9999v99 also fails.

"Howard Brazee" <howard@brazee.net> wrote in message
 news:ulk4v1h7igot6d4h91eolmahqiikc72co4@
4ax.com...
> On Tue, 14 Feb 2006 21:52:12 GMT, "Oliver Wong" <owong@castortech.com>
> wrote:
> 
>
> Then S9999v99 also fails.

Indeed it does. Thanks, this is exactly the kind of answer I was looking
for, and I now know that I need to refine my algorithm a bit. Is there
anything else that acts like 'V' in this manner?

- Oliver

S may or may not fail. (Some compilers show an "over-punch" and others show 
the
sign separately on a DISPLAY)

What a specific compiler does with P is another question.

Remember (extension) usages like COMP-1 and COMP-2 with NO picture clause.

I think (but an not certain) that some compilers will show "slack" bits/byte
s -
when SYNC or OCCURS causes these to "exist".

Note particluarly GR(1) of the DISPLAY statement in the '02 Standard (and th
is
has ALWAYS been true)

"Any conversion of data required between literal-1 or the data item referenc
ed
by identifier-1 and the hardware device is defined by the implementor."

The bottom-line is that this is NOT "portable" behavior (nor does it need to
be - to be ANSI/ISO conforming)

--
Bill Klein
wmklein <at> ix.netcom.com
"Oliver Wong" <owong@castortech.com> wrote in message
news:9FsIf.1252$n67.399@edtnps89...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
>  news:ulk4v1h7igot6d4h91eolmahqiikc72co4@
4ax.com... 
>
>    Indeed it does. Thanks, this is exactly the kind of answer I was lookin
g
> for, and I now know that I need to refine my algorithm a bit. Is there
> anything else that acts like 'V' in this manner?
>
>    - Oliver

"Oliver Wong" <owong@castortech.com> wrote in message
news:s_rIf.1245$n67.995@edtnps89...

>    Is this always true (assuming the COBOL compiler complies with the 85
> standard), or does there exist a picture string that one could write where
> the length of the output does not match the length of the string?

No, it is not always true.

Certainly for "P" the answer is "no", and the same is true for "V" (which
never occupies space in the datum).

Whether "S" takes up a character or not is dependent both on the presence or
absence of the SIGN SEPARATE clause and how the implementor represents signs
in that particular USAGE.

And in '02 COBOL, whether a currency-sign in the datum and a currency-symbol
in the PICTURE clause occupy the same space is dependent on whether they're
the same length.  You can declare, say, "L" as the currency SYMBOL denoting,
say, "GBP", and use "L" as a floating insertion editing symbol.  In this
case I'd suggest, presuming all the other characters in the PICTURE have a
one-to-one correspondence to the datum, the datum will be two characters
longer than the PICTURE.

So I would suggest that presuming it is Universally and Eternally True that
the PICTURE character string is the same length as the USAGE DISPLAY datum
it descrkbes is a presumption likely to get you into a fair amount of hot
water.

-Chuck Stevens

In article <9FsIf.1252$n67.399@edtnps89>,
Oliver Wong <owong@castortech.com> wrote:
>
>"Howard Brazee" <howard@brazee.net> wrote in message
> news:ulk4v1h7igot6d4h91eolmahqiikc72co4@
4ax.com... 
>
>    Indeed it does. Thanks, this is exactly the kind of answer I was lookin
g
>for, and I now know that I need to refine my algorithm a bit. Is there
>anything else that acts like 'V' in this manner?

I'm not sure if it 'acts like 'V' in this manner'... but how about
something like:

01  FLD1     PIC X(500)    VALUE SPACES.
01  STRTPOS  PIC 9(4) COMP VALUE 0.
01  LNGTH    PIC 9(4) COMP VALUE 0

...
IF condition
MOVE    stuff   TO FLD1
COMPUTE STRTPOS =  (computation01)
COMPUTE LNGTH   =  (computation02)
DISPLAY FLD1(STRTPOS:LNGTH)
END-IF.

DD

2/15/06

While not a factor at the elementary item level (where the PICTURE and USAGE
clauses are found) , the size of a group item can vary based on an OCCURS
DEPENDING ON and the presence/absence of an ODOSLIDE-like compiler
directive.

Hmm, come to think of it, USAGE can occur at the group-item level, affecting
all the elementary items therein. But this sounds like the only usage in
which you are interested is DISPLAY.

I have some old software available free at the flexus Download page at
http://www.flexus.com/download.html  which might help:

COBDATA.ZIP contains a tutorial on COBOL data types which gives the storage
requirements for most of the PICTURE/USAGE combinations available (both text
and - I believe - rich text).

COBFD.ZIP includes a piece of MS-DOS software which will scan a copylib or
source file and produce a report file (text) showing the size of every
elementary item found, right next to its PICTURE and USAGE. Maybe that would
help you identify other circumstances in which "actual-size NOT EQUAL
number-of-chars-in-picture"  (WARNING: This is really old; first posted in
1994, I have been threatening to update it since only about 1995).

MCM

On Tue, 14 Feb 2006 22:16:37 GMT, "Oliver Wong" <owong@castortech.com>
wrote:
 
>
>    Indeed it does. Thanks, this is exactly the kind of answer I was lookin
g
>for, and I now know that I need to refine my algorithm a bit. Is there
>anything else that acts like 'V' in this manner?

Here's some real code:

01  PASSED-DBCONV-RECORD.
02  PASSED-DBCONV-DISPLAY-DBKEY.
03  PASSED-DBCONV-PAGE     PIC X(08).
03  PASSED-DBCONV-PAGE-N   REDEFINES PASSED-DBCONV-PAGE

PIC 9(08).
03  PASSED-DBCONV-DASH     PIC X(01).
03  PASSED-DBCONV-POS      PIC X(03).
03  PASSED-DBCONV-POS-N    REDEFINES PASSED-DBCONV-POS

PIC 9(03).
02  PASSED-DBCONV-X.
03  FILLER                 PIC X(4).
03  PASSED-DBCONV-DBKEY    PIC S9(08) COMP.