f



Newbie Cobol85 problem - "** Error 189 ** 01 or 77 level data item too large for section"

Hi All,

This is my first time posting and I'm very new to Cobol.  I've been teachin=
g myself Cobol85 for fun and as a rite of passage since June '16. I've writ=
ten 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 genera=
ted locally.

However -- When I port the source to the Tandem, I get an error that appear=
s to indicate an array (table) is too big..? As you can see below, the tabl=
e rows are not high in bytes and it's less than 2000 rows table (array).
=20
I am compiling the code on "NonStop Himalaya System" mainframe.
=20
    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-INDE=
X.
    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).
   =20
  ** Error 189 **  01 or 77 level data item too large for section:  CARD-PR=
FX-TAB
   =20
    310          01  CARD-PRFX-TABLE-MAX-ROWS PIC S9(05) BINARY VALUE +1943=
..
 =20
 =20
  ...
  ...
  COBOL85 - T9257H01 - (15 MAR 09)
  No object file produced
  Number of compiler errors =3D 2
  Number of compiler warnings =3D 0
  Maximum symbol table size =3D 186530 bytes
  Last message on page 17
  Elapsed time - 00:00:00
 =20
 =20
When I change the number of rows from 1943 to 100 (for example) in lines 30=
2 and 310 above, the program compiles on the Tandem without errors.
 =20
Object file \CTD4S.$MDC016.CESVIC.RDFISSU
  TIMESTAMP  2016-11-29 00:09:00
   =20
        13  Code pages
 =20
        16  Primary data words
        5894  Secondary data words
          41  Data pages
           0  Resident code pages
           0  Extended data pages
  =20
      5910  Top of stack location in words
           1  Code segment
   =20
         0  Binder Warnings
           0  Binder Errors
 =20
 =20
  COBOL85 - T9257H01 - (15 MAR 09)
  The object file is executable on a NonStop Himalaya System
  Number of compiler errors =3D 0
  Number of compiler warnings =3D 0
  Maximum symbol table size =3D 186530 bytes
  Elapsed time - 00:00:01

The manual I have is titled "HP COBOL Manual for TNS and TNS/R Programs". I=
t indicates the following regarding error 189:

Cause. The size of a data item exceeds the maximum size permitted for the D=
ata
Division section in which it is defined.

I'm pretty sure Cobol can handle more than a 2000 row array so I'm wonderin=
g if there is an environmental limitation I'm hitting?

Sorry if my questions seems rudimentary, I'm definitely trying to review al=
l available materials before asking a question.

Thanks for your time!

-Victor
0
vleon101
11/29/2016 10:16:09 PM
comp.lang.cobol 4278 articles. 1 followers. Post Follow

12 Replies
388 Views

Similar Articles

[PageSpeed] 25

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
0
Kerry
11/29/2016 10:35:51 PM
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!
0
Shiggy
11/29/2016 10:53:41 PM
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
0
Shiggy
11/30/2016 2:34:35 AM
[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
0
docdwarf
11/30/2016 2:09:28 PM
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
0
Shiggy
12/1/2016 3:07:17 AM
On Tue, 29 Nov 2016 14:16:09 -0800 (PST), 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!


The limits are defined in the manual you referenced.  Look in Chapter
20, "HP COBOL Limits".  The restrictions you're interested in are at
the top of page 20-4.

TNS is a rather odd environment, and programs are mostly limited to a
small collection of relatively small "segments" (in this case, no
single record ("01") can be bigger than 32767 bytes, which your table
is).  There are extensions, and a way to run "native" applications,
that can get you around some of those.
0
Robert
12/1/2016 8:58:04 AM
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
0
docdwarf
12/1/2016 1:38:25 PM
On Thursday, December 1, 2016 at 2:58:14 AM UTC-6, robert...@yahoo.com wrot=
e:
> On Tue, 29 Nov 2016 14:16:09 -0800 (PST),=20
>=20
> >Hi All,
> >
> >This is my first time posting and I'm very new to Cobol.  I've been teac=
hing myself Cobol85 for fun and as a rite of passage since June '16. I've w=
ritten my first program using Fuji Cobol Compiler.  I'm sure it's not the m=
ost graceful example of Cobol programming. :)
> >
> >The program works fine on my local desktop and my pretty report gets gen=
erated locally.
> >
> >However -- When I port the source to the Tandem, I get an error that app=
ears to indicate an array (table) is too big..? As you can see below, the t=
able rows are not high in bytes and it's less than 2000 rows table (array).
> >=20
> >I am compiling the code on "NonStop Himalaya System" mainframe.
> >=20
> >    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-I=
NDEX.
> >    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).
> >   =20
> >  ** Error 189 **  01 or 77 level data item too large for section:  CARD=
-PRFX-TAB
> >   =20
> >    310          01  CARD-PRFX-TABLE-MAX-ROWS PIC S9(05) BINARY VALUE +1=
943.
> > =20
> > =20
> >  ...
> >  ...
> >  COBOL85 - T9257H01 - (15 MAR 09)
> >  No object file produced
> >  Number of compiler errors =3D 2
> >  Number of compiler warnings =3D 0
> >  Maximum symbol table size =3D 186530 bytes
> >  Last message on page 17
> >  Elapsed time - 00:00:00
> > =20
> > =20
> >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.
> > =20
> >Object file \CTD4S.$MDC016.CESVIC.RDFISSU
> >  TIMESTAMP  2016-11-29 00:09:00
> >   =20
> >        13  Code pages
> > =20
> >        16  Primary data words
> >        5894  Secondary data words
> >          41  Data pages
> >           0  Resident code pages
> >           0  Extended data pages
> >  =20
> >      5910  Top of stack location in words
> >           1  Code segment
> >   =20
> >         0  Binder Warnings
> >           0  Binder Errors
> > =20
> > =20
> >  COBOL85 - T9257H01 - (15 MAR 09)
> >  The object file is executable on a NonStop Himalaya System
> >  Number of compiler errors =3D 0
> >  Number of compiler warnings =3D 0
> >  Maximum symbol table size =3D 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 th=
e Data
> >Division section in which it is defined.
> >
> >I'm pretty sure Cobol can handle more than a 2000 row array so I'm wonde=
ring 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!
>=20
>=20
> The limits are defined in the manual you referenced.  Look in Chapter
> 20, "HP COBOL Limits".  The restrictions you're interested in are at
> the top of page 20-4.
>=20
> TNS is a rather odd environment, and programs are mostly limited to a
> small collection of relatively small "segments" (in this case, no
> single record ("01") can be bigger than 32767 bytes, which your table
> is).  There are extensions, and a way to run "native" applications,
> that can get you around some of those.

I did finally find the Cobol limits in there thanks! It's where I learned a=
bout the "Extended Storage" section. It looks like that section is availabl=
e only on the TNS or TNS/R enabled compilers, which is a lucky coincidence =
for me.=20

I probably could have ultimately searched the file for values instead of th=
e array, but I just wanted to learn how to populate an array from a file.

0
Shiggy
12/1/2016 2:39:09 PM
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.
0
Bill
12/5/2016 12:45:35 PM
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 alloca=
tion. As far as storage is concerned, you'll get the amount for the "TO" va=
lue.
>=20
> ODO limits things like SEARCH, SEARCH ALL, WRITE, INSPECT, STRING, UNSTRI=
NG.
>=20
> EXTENDED STORAGE looks to be an Extension to COBOL due to "environment" l=
imits on the compiler. I've never heard of it before. Very imlementation-sp=
ecific.

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 s=
earch the file instead of an array to map the a number to an institution na=
me / region.
0
Shiggy
12/6/2016 1:03:48 AM
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/
0
Arnold
12/10/2016 9:21:35 AM
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
0
docdwarf
12/12/2016 5:42:32 PM
Reply: