• Re: Newbie Cobol85 problem - "** Error 189 ** 01 or 77 level dataitem t

    From Kerry Liles@1:2320/100 to comp.lang.cobol on Tue Nov 29 17:35:51 2016
    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 Shiggy Diggy@1:2320/100 to comp.lang.cobol on Tue Nov 29 14:53:41 2016
    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 Shiggy Diggy@1:2320/100 to comp.lang.cobol on Tue Nov 29 18:34:35 2016
    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 docdwarf@1:2320/100 to comp.lang.cobol on Wed Nov 30 14:09:28 2016
    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 Shiggy Diggy@1:2320/100 to comp.lang.cobol on Wed Nov 30 19:07:17 2016
    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 docdwarf@1:2320/100 to comp.lang.cobol on Thu Dec 1 13:38:25 2016
    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 Bill Woodger@1:2320/100 to comp.lang.cobol on Mon Dec 5 04:45:35 2016
    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 Shiggy Diggy@1:2320/100 to comp.lang.cobol on Mon Dec 5 17:03:48 2016
    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 Arnold Trembley@1:2320/100 to comp.lang.cobol on Sat Dec 10 03:21:35 2016
    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 docdwarf@1:2320/100 to comp.lang.cobol on Mon Dec 12 17:42:32 2016
    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