This may be a long shot, but several things Tony mentioned reminded me
of a performance issue I've seen several times in COBOL programs with
large tables in Working-Storage.  The typical case is where you
initialize the table using VALUE clauses.  Look for a VALUE clause in a
data description that contains an OCCURS clause, or that is subordinate
to a data description containing an OCCURS clause.

The symptoms are an executable program file that is excessively large,
and that takes an excessively long time to load.  

What you should try if you see this is to remove the VALUE clause(s) on
the table, and then add the EXTERNAL clause to the table.  If the table
has to be initialized, do the initialization in the Procedure Division.

Following is a sample program, before and after.  Making the changes
suggested reduced the size of the executable from 390,736 sectors to 112
sectors and reduced the load time from 25 seconds to zero seconds.  It
also reduced the link time from 39 seconds to 3 seconds.

Walter  

Walter J. Murray

Original program:
-----cut here-----
$CONTROL STDWARN,POST85
 IDENTIFICATION DIVISION.
 PROGRAM-ID. TABLE-TEST.
 DATA DIVISION.
 WORKING-STORAGE SECTION.
 01  BIG-TABLE.
     02  TABLE-ELEMENT    OCCURS 20000000.
         03  TABLE-PART-A    PIC X(5)    VALUE SPACES.
 PROCEDURE DIVISION.
 MAIN.
     DISPLAY "BEGIN TABLE-TEST"
     DISPLAY FUNCTION CURRENT-DATE (1:16)
     DISPLAY FUNCTION CURRENT-DATE (1:16)
     DISPLAY "END TABLE-TEST"
     STOP RUN.
 END PROGRAM TABLE-TEST.
-----cut here-----

After changes:
-----cut here-----
$CONTROL STDWARN,POST85
 IDENTIFICATION DIVISION.
 PROGRAM-ID. TABLE-TEST.
 DATA DIVISION.
 WORKING-STORAGE SECTION.
 01  BIG-TABLE    EXTERNAL.
     02  TABLE-ELEMENT    OCCURS 20000000.
         03  TABLE-PART-A    PIC X(5).
 PROCEDURE DIVISION.
 MAIN.
     DISPLAY "BEGIN TABLE-TEST"
     DISPLAY FUNCTION CURRENT-DATE (1:16)
     INITIALIZE BIG-TABLE
     DISPLAY FUNCTION CURRENT-DATE (1:16)
     DISPLAY "END TABLE-TEST"
     STOP RUN.
 END PROGRAM TABLE-TEST.
-----cut here-----


-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Tony Summers
Sent: Tuesday, February 14, 2006 12:00 AM
To: [log in to unmask]
Subject: [HP3000-L] Memory usage on HP3000

Can anybody point me to papers on how we review whether our HP3000s are
suffering from memory shortages.  

[snip]


For example,  can you confirm how much
memory is being pre-allocated as a program is loaded by the run
statement ? 

I've certainly noticed that certain programs do appear to trigger the
performance problems - and they all seem to have large Working storage
tables - I demonstrated to my colleagues that by converting working
storage tables to KSAM files you can improve the performance of a
program - it also has the additional benefit that the application then
doesn't demand so much memory.    Many years ago (pre native mode
machines) I worked at one company where the HP3000 ran fine until one
particular application was loaded - even if that application wasn't
using CPU,  the machine ground to a halt !

[snip]

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *