Cobol - Two interesting (IMHO) ANSI (J4) Documents

Author

Two interesting (IMHO) ANSI (J4) Documents

William M. Klein

2004-11-16, 6:44 pm

There are two (working) documents on the J4 (COBOL) web site that I think those
interested in "enhancements" to COBOL might be interested in - whether or not
their "vendor of choice" appears to be implementing the 2002 ISO COBOL
Standard - much less thinking about the (hoped for) 2008 COBOL Standard.

These both represent enhancements to the COBOL language that I can *imagine*
that vendors will implement whether or not they are implementing other new (or
proposed) features from the '02 (or theoretical '08) ISO Standards. Therefore,
I think those interested in COBOL may want to read about them now - and send
comments (if any) to J4 sooner than later. If interested, communicate to the J4
chair at:

Don.Schricker <at> microfocus.com

See:
"04-0198- Any-length elementary items"
at:
http://www.cobolportal.com/j4/files/04-0198.doc
Summary:
""D.2.7 Any-length elementary items

A truly any-length elementary item of unlimited size can be defined by coding
the following picture format:

05 notes PIC X ANY LENGTH.

If the item has a maximum length (n), ANY LENGTH LIMIT n is written or, if there
is no theoretical maximum length, ANY LENGTH is sufficient.

Any-length items may be national items, or bit items:
05 city-name PIC 1 ANY LENGTH.
05 customer-name PIC N ANY LENGTH.

When a new value is stored in an any-length elementary item, the item's length
is automatically adjusted, subject to any maximum length. For example,

MOVE "This product is no longer available" TO notes
...."

****

See:
"04-0197- Dynamic-capacity Tables"
at:
http://www.cobolportal.com/j4/files/04-0197.doc
Summary:
"D.2.6 Dynamic-capacity tables

A dynamic-capacity table (or "dynamic table") is a table whose physical size,
known as its "capacity", grows dynamically as you add more entries to it. Its
maximum capacity is limited only by the resources your implement_ation can make
available. Its capacity can also be reduced. To improve the description and
the planning of memory resources, you can optionally indicate a minimum capacity
and an expected capacity. If the expected capacity is reached, you receive a
warning in the form of a non-fatal exception but, unless you terminate the
process, further entries will continue to be added."

****

Personally, I suggest you start reading the documents from the "Concepts"
section and review the (already) resolved issues before communicating any (new)
concerns/issues to J4.

--
Bill Klein
wmklein <at> ix.netcom.com

James J. Gavan

2004-11-16, 6:44 pm

William M. Klein wrote:

>There are two (working) documents on the J4 (COBOL) web site that I think those
>interested in "enhancements" to COBOL might be interested in - whether or not
>
<snip>........

>See:
> "04-0197- Dynamic-capacity Tables"
>at:
> http://www.cobolportal.com/j4/files/04-0197.doc
>Summary:
> "D.2.6 Dynamic-capacity tables
>
>A dynamic-capacity table (or "dynamic table") is a table whose physical size,
>known as its "capacity", grows dynamically as you add more entries to it. Its
>maximum capacity is limited only by the resources your implement_ation can make
>available. Its capacity can also be reduced. To improve the description and
>the planning of memory resources, you can optionally indicate a minimum capacity
>and an expected capacity. If the expected capacity is reached, you receive a
>warning in the form of a non-fatal exception but, unless you terminate the
>process, further entries will continue to be added."
>
>
>
>
I was more than somewhat amused by your quote above. Seeing all the
effort John Piggott put into this..... - nudge, nudge - shouldn't
somebody have twigged the word *capacity* was completely missed from the
initial draft for Collections ? ("count" was substituted for "size" used
by both F/J and M/F).

Looks like J4 will have to be very specific about words/phrases -
'size', 'number of elements' and 'capacity' - so that there is no
ambiguity when switching between code for Dynamic Tables or Collections,
and that a given Procedural reserved word/OO method-name, executes code
in a parallel manner whether using D/Ts or Collections.

I will be commenting OO-wise.

Jimmy, Calgary AB

Frank Swarbrick

2004-11-17, 3:55 am

If I am reading the document correctly, then lets say I do something like
this:

FD CUSTOMER-FILE.
01 CUSTOMER-RECORD.
05 CR-KEY PIC X(9).
05 CR-LNAME PIC X ANY LENGTH PREFIXED BY BINARY-CHAR.
05 CR-FNAME PIC X ANY LENGTH PREFIXED BY BINARY-CHAR.
05 CR-MNAME PIC X ANY LENGTH PREFIXED BY BINARY-CHAR.

MOVE '000000001' TO CR-KEY
MOVE 'FRANCIS' TO CR-FNAME
MOVE 'JOHN' TO CR-MNAME
MOVE 'SWARBRICK' TO CR-LNAME
WRITE CUSTOMER-RECORD

It looks to me like I'd end up with a file with a 32 byte record like:
000000001~SWARBRICK~FRANCIS~JOHN

Where each tilde (~) represents a byte holding the length of the 05-level
item that follows. Or, for more compatibilty with C

FD CUSTOMER-FILE.
01 CUSTOMER-RECORD.
05 CR-KEY PIC X(9).
05 CR-LNAME PIC X ANY LENGTH DELIMITED BY X'00'.
05 CR-FNAME PIC X ANY LENGTH DELIMITED BY X'00'.
05 CR-MNAME PIC X ANY LENGTH DELIMITED BY X'00'.

And I'd end up with
000000001SWARBRICK#FRANCIS#JOHN#

Where each pound symbol (#) represents a byte of hex zeroes.

I've got to say that on the surface it looks quite appealing!

I see some reference to how MOVE works in item "25. Changes to 14.8.24 MOVE
statement", but it doesn't appear to answer a question I have. What if I
have the above as well as the following:

01 INPUT-FNAME PIC X(40).

ACCEPT INPUT-FNAME
MOVE INPUT-FNAME TO CR-FNAME

Will CR-FNAME now have a length of 40? Or (wish, wish) will it perhaps have
the length of the name entered *not including trailing spaces*? The latter
would be wonderful, but I don't see that the document you gave says anything
either way.

Hmm, I just read more and it looks like this is probably not the case, but I
would instead use the new TRIM function as follows:

MOVE FUNCTION TRIM(INPUT-FNAME) TO CR-FNAME.

In fact, that would even eliminate leading spaces as well. I like it!

I haven't read the whole document, but what I've read sounds great. Not
that I'll ever see this on my COBOL platform, but I can always dream.

Thanks for posting this, Bill!

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
[color=darkred]
There are two (working) documents on the J4 (COBOL) web site that I think
those
interested in "enhancements" to COBOL might be interested in - whether or
not
their "vendor of choice" appears to be implementing the 2002 ISO COBOL
Standard - much less thinking about the (hoped for) 2008 COBOL Standard.

These both represent enhancements to the COBOL language that I can *imagine*

that vendors will implement whether or not they are implementing other new
(or
proposed) features from the '02 (or theoretical '08) ISO Standards.
Therefore,
I think those interested in COBOL may want to read about them now - and send

comments (if any) to J4 sooner than later. If interested, communicate to
the J4
chair at:

Don.Schricker <at> microfocus.com

See:
"04-0198- Any-length elementary items"
at:
http://www.cobolportal.com/j4/files/04-0198.doc
Summary:
""D.2.7 Any-length elementary items

A truly any-length elementary item of unlimited size can be defined by
coding
the following picture format:

05 notes PIC X ANY LENGTH.

If the item has a maximum length (n), ANY LENGTH LIMIT n is written or, if
there
is no theoretical maximum length, ANY LENGTH is sufficient.

Any-length items may be national items, or bit items:
05 city-name PIC 1 ANY LENGTH.
05 customer-name PIC N ANY LENGTH.

When a new value is stored in an any-length elementary item, the item's
length
is automatically adjusted, subject to any maximum length. For example,

MOVE "This product is no longer available" TO notes
...."

****

See:
"04-0197- Dynamic-capacity Tables"
at:
http://www.cobolportal.com/j4/files/04-0197.doc
Summary:
"D.2.6 Dynamic-capacity tables

A dynamic-capacity table (or "dynamic table") is a table whose physical
size,
known as its "capacity", grows dynamically as you add more entries to it.
Its
maximum capacity is limited only by the resources your implement-ation can
make
available. Its capacity can also be reduced. To improve the description
and
the planning of memory resources, you can optionally indicate a minimum
capacity
and an expected capacity. If the expected capacity is reached, you receive
a
warning in the form of a non-fatal exception but, unless you terminate the
process, further entries will continue to be added."

****

Personally, I suggest you start reading the documents from the "Concepts"
section and review the (already) resolved issues before communicating any
(new)
concerns/issues to J4.

--
Bill Klein
wmklein <at> ix.netcom.com

Sponsored Links