From Newsgroup: comp.lang.cobol

On 11/29/2016 5:16 PM, vleon101@gmail.com wrote:

Hi All,

This is my first time posting and I'm very new to Cobol. I've been teaching

myself Cobol85 for fun and as a rite of passage since June '16. I've written my
first program using Fuji Cobol Compiler. I'm sure it's not the most graceful example of Cobol programming. :)

The program works fine on my local desktop and my pretty report gets

generated locally.

However -- When I port the source to the Tandem, I get an error that appears

to indicate an array (table) is too big..? As you can see below, the table rows
are not high in bytes and it's less than 2000 rows table (array).

I am compiling the code on "NonStop Himalaya System" mainframe.

298 **************************
299 * DEFINE Card Prefix TABLE
300 **************************
301 01 CARD-PRFX-TABLE.
302 05 CARD-PRFX-TABLE-ROWS OCCURS 1943 TIMES
303 DESCENDING KEY IS CARD-PRFX-NBR
304 OF CARD-PRFX-TABLE
305 INDEXED BY CARD-PRFX-TABLE-INDEX.
306 10 CARD-PRFX-NBR PIC 9(11).
307 10 INST-FIID PIC X(04).
308 10 INST-NAME PIC X(35).
309 10 INST-REGN PIC X(04).

** Error 189 ** 01 or 77 level data item too large for section:

CARD-PRFX-TAB

310 01 CARD-PRFX-TABLE-MAX-ROWS PIC S9(05) BINARY VALUE +1943.

...
...
COBOL85 - T9257H01 - (15 MAR 09)
No object file produced
Number of compiler errors = 2
Number of compiler warnings = 0
Maximum symbol table size = 186530 bytes
Last message on page 17
Elapsed time - 00:00:00

When I change the number of rows from 1943 to 100 (for example) in lines 302

and 310 above, the program compiles on the Tandem without errors.

Object file \CTD4S.$MDC016.CESVIC.RDFISSU
TIMESTAMP 2016-11-29 00:09:00

13 Code pages

16 Primary data words
5894 Secondary data words
41 Data pages
0 Resident code pages
0 Extended data pages

5910 Top of stack location in words
1 Code segment

0 Binder Warnings
0 Binder Errors

COBOL85 - T9257H01 - (15 MAR 09)
The object file is executable on a NonStop Himalaya System
Number of compiler errors = 0
Number of compiler warnings = 0
Maximum symbol table size = 186530 bytes
Elapsed time - 00:00:01

The manual I have is titled "HP COBOL Manual for TNS and TNS/R Programs". It

indicates the following regarding error 189:

Cause. The size of a data item exceeds the maximum size permitted for the

Data

Division section in which it is defined.

I'm pretty sure Cobol can handle more than a 2000 row array so I'm wondering

if there is an environmental limitation I'm hitting?

Sorry if my questions seems rudimentary, I'm definitely trying to review all

available materials before asking a question.

Thanks for your time!

-Victor

It isn't a matter of how many rows in an array, rather the total size of
the array. I worked on Tandem back in the 80s (thanks for the
flashback...) It seems that the Tandem COBOL compiler has a limitation
on the total size of a single 01 item (various IBM compilers on IBM maintframes had similar issues back in the day). I seldom worry about
those limitations anymore, but clearly that is biting you. Your 01 level
is a size of 1943*(11+4+35+4)= 1943 * 54 = 104,922 bytes/characters. I'm
not sure what the Tandem compiler limit is - finding out by manipulating
the contents of each rows might be tedious (but could be an interesting
binary search type algorithm implemented by approximation by trying
increasing fewer rows until there is no error).

There *might* be a compiler option to allow larger array sizes (but I
doubt it?) - the other choice might be to implement the table in several separate 01 levels and deal with the fragmentation (not a pleasant
thought, but could be done)

Again, the problem is the total storage size (and therefore
addressability) of the entire 01 level array; you might be able to have
32,000 rows of 1 character but not 16,000 rows of 4 characters etc.

hope this helps

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

Thanks for your interesting feedback. I'm trying to find some documentation indicating a Tandem compiler limit but no luck yet. I probably will write a small program to find out my environmental limitations for this specific table out of curiosity.

Thanks again!

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

It looks like I may have come across a solution.

Apparently there is something called "EXTENDED-STORAGE SECTION" on the Tandem compiler. I moved the array from WS to Extended storage and the program compiled without errors.

914 EXTENDED-STORAGE SECTION.
915 **************************
916 * DEFINE Card Prefix TABLE
917 **************************
918 01 CARD-PRFX-TABLE.
919 05 CARD-PRFX-TABLE-ROWS OCCURS 2000 TIMES
920 DESCENDING KEY IS CARD-PRFX-NBR
921 OF CARD-PRFX-TABLE
922 INDEXED BY CARD-PRFX-TABLE-INDEX.
923 10 CARD-PRFX-NBR PIC 9(11).
924 10 INST-FIID PIC X(04).
925 10 INST-NAME PIC X(35).
926 10 INST-REGN PIC X(04).
927 01 CARD-PRFX-TABLE-MAX-ROWS PIC S9(05) BINARY VALUE +2000.

PAGE 41 \CTD4S.$MDC016.CESVIC.RDFCALI Compaq COBOL85 for NonStop Himala


ENTRY POINT MAP BY NAME FOR FILE: \CTD4S.$MDC016.CESVIC.RDFISSU

SP PEP BASE LIMIT ENTRY ATTRS NAME DATE

00 002 000003 031643 001767 M RDFCALC 2016-11 PAGE 42 \CTD4S.$MDC016.CESVIC.RDFCALI Compaq COBOL85 for NonStop Himala


DATA BLOCK MAP BY NAME FOR FILE: \CTD4S.$MDC016.CESVIC.RDFISSU

BASE LIMIT TYPE MODE NAME DATE TI

000020 000053 SPECIAL WORD #ERUG 2016-11-29 19
000000 000017 SPECIAL WORD #G0 2016-11-29 19
102144 121222 SPECIAL WORD #HIGHBUF 2016-11-29 19
100000 100114 SPECIAL WORD #RUCB 2016-11-29 19
000054 006206 OWN STRING RDFCALC 2016-11-29 19
100115 102143 SPECIAL WORD RDFCALC# 2016-11-29 19
0001000000 0001151361 OWN STRING RDFCALC^
2016-11-29 19:09 COBOL85 \CTD4S.$MDC016.CESVIC.RDFCALI
PAGE 43 \CTD4S.$MDC016.CESVIC.RDFCALI STATISTICS


BINDER - OBJECT FILE BINDER - T9621H01 SYSTEM \CTD4S
Copyright Compaq Computers Corporation, 1988-2002

Object file \CTD4S.$MDC016.CESVIC.RDFISSU
TIMESTAMP 2016-11-29 19:09:26

13 Code pages

16 Primary data words
3191 Secondary data words
41 Data pages
0 Resident code pages
53 Extended data pages

3207 Top of stack location in words
1 Code segment

0 Binder Warnings
0 Binder Errors

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

[posted and emailed]

In article <463e1cb6-5d56-4936-87c8-3c27ff982efb@googlegroups.com>,
Shiggy Diggy <vleon101@gmail.com> wrote:

It looks like I may have come across a solution.

Apparently there is something called "EXTENDED-STORAGE SECTION" on the
Tandem compiler.

My compliments on your diligence. You stated the difficulty, showed your homework and announced your solution; this is Classic Form and encourages responses from those who are trained in such.

I've coded COBOL on IBM mai frames for... a few decades and I do not
recall ever encountering an EXTENDED-STORAGE SECTION... but my memory is, admittedly, porous. We would get around the design flaws that required WORKING-STORAGE tables larger than 32K by placing them in physical
sequence and using 'overrun' subscripts.

Those were dark times. If someone hands you specs which require curious details such as 'OCCURS 1943' you might want to write a memorandum saying 'This will blow up when The Company acquires another
region/section/division.'

(not that this will help at all... but when it *does* go kerflooie you'll
have a response to 'Ehy didn't you tell us?'... but it'll make folks all
the angrier that you aren't a ready target... welcome to The World of Business)

DD

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

Thanks for the props! I'm going to update the code to use from "dynamic-ish" arrays instead of the very fixed one I used. I just wanted to be able to use the static array as an educational tool.

Learning by increment..

Cheers!

-Vic

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

In article <8721476a-8a48-44a6-9313-e6bbf0f35c16@googlegroups.com>,
Shiggy Diggy <vleon101@gmail.com> wrote:

Thanks for the props!

Credit where due.

I'm going to update the code to use from
"dynamic-ish" arrays instead of the very fixed one I used.

In the Oldene Dayse some were taught that using OCCURS DEPENDING ON
(sometimes referred to as ODO) did not generate enough savings to merit
the maintenance expenses it caused. Perhaps things have changed since
then.

I just wanted
to be able to use the static array as an educational tool.

'... wer einst fliegen lernen will, der muss erst stehn und gehn und
laufen und klettern und tanzen lernen: - man erfliegt das Fliegen nicht!'

Nietzsche, 'Also Sprach Zarathustra', Third Part (On the Spirit of Heaviness/Difficulty/Gravity/other possible translations)

(extemporaneous translation: 'he who desires one day to learn to fly, must first learn standing and walking and running and climbing and dancing: -
one flies not into flying!')

Learning by increment..

Revelation by thunderclap. Before Enlightenment, chop wood, carry water, after Enlightenment, chop wood, carry water.

DD

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

I don't know of a COBOL compiler where an ODO has implicit dynamic allocation. As far as storage is concerned, you'll get the amount for the "TO" value.

ODO limits things like SEARCH, SEARCH ALL, WRITE, INSPECT, STRING, UNSTRING.

EXTENDED STORAGE looks to be an Extension to COBOL due to "environment" limits on the compiler. I've never heard of it before. Very imlementation-specific.

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On Monday, December 5, 2016 at 6:45:37 AM UTC-6, Bill Woodger wrote:

I don't know of a COBOL compiler where an ODO has implicit dynamic

allocation. As far as storage is concerned, you'll get the amount for the "TO" value.

ODO limits things like SEARCH, SEARCH ALL, WRITE, INSPECT, STRING, UNSTRING.

EXTENDED STORAGE looks to be an Extension to COBOL due to "environment"

limits on the compiler. I've never heard of it before. Very imlementation-specific.
Yes I was reading yesterday that "Extended-Storage" appears to be specific to HP Tandem TNS TNS/R compilers (I forget which one) -- so in a way I got lucky with my implementation. But in the end I'm coding for the environment I have. I
guess if I had to I would have to have multiple tables or just search the file instead of an array to map the a number to an institution name / region.

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 12/1/2016 7:38 AM, docdwarf@panix.com wrote:

Learning by increment..

Revelation by thunderclap. Before Enlightenment, chop wood, carry water, after Enlightenment, chop wood, carry water.

DD

Hey Doc,

While looking at Xmas ads on the web I saw a children's card that you
might get a chuckle out of:

https://www.amazon.com/Unknown-GAM-160-01-Poopyhead-Card-Game/dp/B010Q1HMZ8

It seems there is also a board game called "Exploding Kittens". What is
the world coming to?

http://www.explodingkittens.com/

Perhaps you would be interested in a free COBOL compiler for Windows as
a Christmas gift?

http://www.arnoldtrembley.com/GnuCOBOL.htm

Cheers,

--
http://www.arnoldtrembley.com/

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

In article <P8KdnUpa9pq-VNbFnZ2dnUU7-T_NnZ2d@giganews.com>,
Arnold Trembley <arnold.trembley@att.net> wrote:

On 12/1/2016 7:38 AM, docdwarf@panix.com wrote:

Learning by increment..

Revelation by thunderclap. Before Enlightenment, chop wood, carry water,
after Enlightenment, chop wood, carry water.

Hey Doc,

While looking at Xmas ads on the web I saw a children's card that you
might get a chuckle out of:

https://www.amazon.com/Unknown-GAM-160-01-Poopyhead-Card-Game/dp/B010Q1HMZ8

Mr Trembley, you have no idea how much this has added to my existence.

It seems there is also a board game called "Exploding Kittens". What is
the world coming to?

http://www.explodingkittens.com/

Youngsters neither ask 'what is the world coming to?' nor follow it with
the nigh-mandatory 'in my day we used to'... and don't get me started on
what they're calling 'music', neither.

Perhaps you would be interested in a free COBOL compiler for Windows as
a Christmas gift?

http://www.arnoldtrembley.com/GnuCOBOL.htm

Most gracious of you... Season's Greets and suchlike.

DD

SEEN-BY: 154/30 2320/100 0 1 227/0