HP3000-L Archives

December 1998, 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:
"Stigers, Greg [And]" <[log in to unmask]>
Reply To:
Stigers, Greg [And]
Date:
Thu, 17 Dec 1998 14:22:34 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (60 lines)
X-no-Archive:yes
The Interex COBOL mailing list ([log in to unmask]) likes to get
questions like this...

The three 'gotchas' that won't initialize properly (at least according to
the HP manuals and ANSI 85 COBOL) are elementary items that are part of a
REDEFINES, or are index data items, or are either FILLER or have no name
(which is implicitly FILLER). In testing on the 3000, it appeared to me that
the latter are not initialized, but fillers keep whatever contents they had.
This is the behavior expected by the ANSI standard.

If your WORKING STORAGE's 01 has none of these, you can INITIALIZE with no
worries, and we do this here. However, the day that someone adds one to this
record, they would break this initialization, unless they add an appropriate
MOVE after the INITIALIZE, which we also do here. It is a judgement call
whether or not having 'uninitialized' FILLER is a problem or not. As John
Backus mentioned, some shops use a standard name for all filler items, that
can be as simple as adding a number to FILLER, for FILLER-1, FILLER-2, etc,
with a PIC appropriate for the group it is in.

I am not aware of any issues with initializing (in the PROCEDURE DIVISION)
items declared in WORKING STORAGE, but Glenn Koster is correct that there is
no way to use this verb in WORKING STORAGE. Some shops do not allow programs
to depend on the VALUE clause for initialization or value on entry, because
programmers make mistakes... So that too is a judgement call. It can be
done, carefully.

I tested using the VALUE clause with FILLER, which works for PIC X VALUE
SPACE giving a space or LOW-VALUES giving an x00, and PIC 9 VALUE ZERO
giving a zero, but PIC 9 and LOW-VALUES gives a questionable err 184
"ILLEGAL LITERAL" when compiled. This might be permissible with BINARY or
PACKED-DECIMAL.

Moving LOW-VALUES to the 01 gave me an 01 filled with x00. Not everyone can
be expected to understand that this is what LOW-VALUES means, regardless of
the PIC, and can seriously waste someone's time when doing maintenance. This
gets confused with INITIALIZE, which does initialize according to the PIC.

> -----Original Message-----
> From: Cary A Marshall [SMTP:[log in to unmask]]
> Sent: Wednesday, December 16, 1998 7:07 PM
> To:   [log in to unmask]
> Subject:      01 Level Initialization in COBOL
>
> Hello Everyone,
>
> I'd like to initialize the working storage for a file area in a COBOL
> program which contains numeric and alphanumeric fields. It's been a while
> since I've worked with COBOL, but I thought that if you initialized the
> file
> at the 01 level, then values at the 02, 03, etc levels would be properly
> initialized.  Can this be done?  If so, how?  I've been told "no way", but
> I
> seem to remember doing so by moving low-values or spaces or .... to the 01
> level.
>
> TIA
>
> Cary Marshall

ATOM RSS1 RSS2