Tony,

This occurred while you were processing monthend, so you had Spectrum down.
Did you have RealTime down, as well, for example to run PRESET?  That is,
did you have any processes up that were WRITING to HISTRY, and do you have
multiple history databases?  If nothing was writing to HISTRY and your
RENAME job was running, WHILE the other process was running, it could have
been blown away in an operational job conflict.

MPEX cannot rename a file that is open for writing, which by default the
root file and GB file would be, by any process accessing the database.  The
remainder of the database could have been purged or renamed, with those two
files failing to process, such that when whatever was accessing HISTRY came
down, only the root file was left on the system?

If your monthend schedules/jobflow are questionable, a simple script can be
added to your system logon UDC that would append some telling information
into a log file to show you the status of your system as each jobs launches.
A similar thought would be to add calls to the SJ, SS and SLS UDCs (in an IF
NOT HPINTERACTIVE test) into the logon UDC to capture this information in
each STDLIST and show you what else is happening when jobs launch.  I
wouldn't recommend this as a permanent solution as it would make the STDLIST
much larger than they need to be for clean jobs running during the day,
but...  Something like this will help you track similar problems for next
monthend, but won't help find what happened that night.

Files don't "normally" disappear from 3000s.  Well, if you are having disc
drive problems it can occur, but you will usually get nasty messages on the
console about bad UFID's etc, when that happens.  I would first look for
something during your monthend process that conflicted with the job you know
was running when the database disappeared.  Do you have Maestro?  If so, is
it configured to log history (RUN LOGMAN during JNEXTDAY)?  Try a HISTOGRAM
report (see the Arranger Report screen) for that time period and see what
logged on while that process was running.

If you don't have Maestro, do you save STDLISTs (maybe with JobRescue), or
at least keep the spoolfiles until a weekly cleanup process like ASPOOLER
stores and removes them?  Check your console logs for something else logging
on while that process ran.  Unless you have loaded your 6.5 upgrade, you can
use LOGUTIL to look for console messages about job logons and logoffs, if
nothing else.

By the way, what was the process that you know WAS running?  And where in
the monthend process were you when this happened?  Can you recover the
history?  A repost of monthend would be UGLY.

HTH,
Rs~

Russ Smith, Systems Consultant
Problem Solved, Vacaville, CA
www.cu-help.com
r s m i t h @ c u - h e l p . c o m
h p 3 k - l @ e - 3 0 0 0 . n e t


----- Original Message -----
From: "Tony White" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, September 01, 2000 4:14 PM
Subject: [HP3000-L] TI Data Base dissapears


> Good people of the list,
>
> I have encountered an event and I need to make sure I have thought of all
> the reasons it could have happened.
>
> During our month end processing last night, one of our Turbo Image data
> bases disappeared except for the root file. The data base is fairly large:
>
> FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
> --DAYS--
>                   SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX   ACC
> MOD
>
> HISTRY  * PRIV    128W  FB          11         11   1       32  2  1
>
>                         current     16        17 readers, 12 writers
> HISTRY01* PRIV   1792W  FB        5435       5435   1    76096 10 32
>
>                                               17 readers, 12 writers
> HISTRY02* PRIV   1792W  FB         327        327   1     4592  1  6
>
>                                               17 readers, 12 writers
> HISTRY03* PRIV   1792W  FB          11         11   1      160  1  1
>
>                                               17 readers, 12 writers
> HISTRY04* PRIV   1792W  FB      173914     173914   1  2434800 14 32
>
>                                               17 readers, 12 writers
> HISTRY05* PRIV   1792W  FB       21740      21740   1   304368 10 32
>
>                                               17 readers, 12 writers
> HISTRY06* PRIV   1792W  FB           1          1   1       16  1  1
>
>                                               17 readers, 12 writers
> HISTRY07* PRIV   1792W  FB         193        193   1     2704  1  4
>
>                                               17 readers, 12 writers
> HISTRYGB* PRIV    128W  FB        1680       1681   1     1696  1  *
>
>                                               17 readers, 17 writers
>
> GROUP     TOTAL:     9 FILES      690 MEGABYTES        2824464 SECTORS
>
> At 4:11 a job finished that was both reading and writing to this db. At
4:12
> another job discovered that all the sets and the GB file were gone leaving
> only the root file.
>
> I have searched all the stdlists from today for "dbutil", "purge h",
"store
> " and "dbgenrl" and have found nothing to explain what happened.
>
> HP has examined logs and sent out a CE to do diagnostics with no hardware
> problem being found.
>
> I cannot think of a way for this data base to have been purged except by
> someone at the CI prompt.
>
> Am I missing anything?
>
> Thanks,
>
> Tony White
>