Hmmm.  It it were not for the "multiple programs" and "always running"
restrictions, the networking software the Navy uses might make the list.  A
single job stream has run for over four straight months (a 32 bit integer
counter finally overflowed and it aborted) moving data around.  At the time
of the abort, the process tree (under the CI) consisted of five processes,
four of which had run only a few seconds short of the job stream elapsed
connect time.  By the way, some of their systems (series 70's that are over
a decade old and some Micro GX systems) are so reliable (and used only as
data movers, not for storage) that they generally are only backed up once
every few months.


At 05:40 PM 97/09/10 -0700, Stan Sieler wrote:
>Hi all,
>
>I'm wondering what's the longest time that a single task program
>has run on a 3000.  (STOREs that take 4 days because the operator
>left for the weekend don't count.)
>
>Let me define my question a bit, starting with background, and by
>providing some examples and non-examples.
>
>Background:
>
>   We are currently in the fourth day of running a single program
>   that is doing a single task: copying data from a DLT tape set
>   to a DDS tape set.     (Each DLT can hold about 40 GB, each
>   DDS about 2 GB.)  (We're actually running 2 multi-day programs;
>   on a second machine, we're running a multi-day VSTORE on the
>   output tapes.)
>
>   In the past, I've run CPU-intensive programs for a day or so,
>   doing various and sundry things (e.g., testing hash code).
>
>   So, it occurred to me to wonder: how long has the longest
>   single-task program taken on a 3000?
>
>Other examples:
>
>   I've heard of one or two day runs of a program.  (Indeed, I
>   once dialed into a friend's machine to perform open-heart surgery
>   on a file nearing EOF, so the program wouldn't crash after 2 days
>   of running.)
>
>   Steve Cooper told me of a client who sorted data via IMAGE.  They
>   had a program that created an IMAGE database with a single master dataset
>   and a single detail dataset with a sorted field.  They then
>   read a bunch of data from tape, DBPUT the data as it came in, and
>   and when they hit the end of the tape, got the data back in sorted order
>   by doing a chained DBGET of the entire dataset.
>   He said that at the start, it flew.  After a few hours, the tape drive
>   had slowed down somewhat.  By the afternoon, the tape drive was
>   barely moving :)
>
>Things that *aren't* candidates:
>
>   Steve told me of a client whose end-of-month accounting
>   took 27 days to run (yes, twenty-seven days!).  However, that was
>   composed of multiple runs of various programs, none of which took
>   more than a mere day or two.  (They're the site that did the,
>   ahem, "innovative" IMAGE-based sorting mentioned above.)
>
>   Always running jobs/sessions/programs (e.g., web server).
>
>   Tasks consisting of multiple programs.
>
>   Programs that aren't useful (e.g., while true do begin end).
>
>I guess this question sort of falls into the "what's the biggest IMAGE
>database out there" category.
>
>--
>Stan Sieler                                          [log in to unmask]
>                                     http://www.allegro.com/sieler.html
>
>
--------------------------------------------------------------
John Korb                            email: [log in to unmask]
Innovative Software Solutions, Inc.

The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.