To answer Lee's question, no, I don't think anyone at the site notifed
Orbit. I did not do it myself. As I wrote earlier, I did not go as far as
drawing the line between an HP and an Orbit problem.

Makes me think the subject of my original post has a typo. It should read
'SA -200', like in 'System abort minus two hundred', not SR -200.

Christian

-----Message d'origine-----
De:     Lee Gunter [SMTP:[log in to unmask]]
Date:   mardi 12 octobre 1999 19:05
A:      [log in to unmask]
Objet:  Re: SR -200. Possible dupe of 4701-144311

Did anyone notify Orbit of this?  Spoolfile handling in BACKUP+ restores
can be
troublesome -- we sometimes have problems restoring spoolfiles as part of a
larger restore (I don't recall the particulars).  They might be able to
advise
you.

We're currently on version 5.47H on all our systems(one test system has
5.48A to
evaluate the online module), and it's proven very stable, to-date.  Our
MPE/iX
versions are C.55.04 or C.55.07.

----
Lee Gunter                    The Regence Group
Supervisor, TRG HP/MPE Systems     503.375.4498
----
Opinions expressed are solely mine.



From: Christian Lheureux <[log in to unmask]> on 10/12/99 09:41 AM

Please respond to "[log in to unmask]" <[log in to unmask]>


To:   [log in to unmask]
cc:    (bcc: Lee Gunter/BCBSO/TBG)
Subject:  [HP3000-L] SR -200. Possible dupe of 4701-144311




Hello fellow listers !

Yesterday, I analyzed an MPE/iX dump taken after an SA -200. The dump shows
a spoolfile purged in /HPSPOOL/BACKUPPL group, and something that looks
like stack corruption, with label pointers leading to the WRONG data
structure, with the space id off by one unit.

The current process in the dump is BACKUPPL, Orbit's backup/restore
software. The current procedure (apart from system_abort, of course) is
hpfunlink_nm, called from program code. It's the one which has the space id
information off by one unit in [PSP-24].

In fact, I analyzed two dumps, each one showing "corruption" in the same
block of the label table. For me, they clearly both lead to one identical
cause for both failures.

It looks like this could be a duplicate of SR 4701-144311, but I would not
bet the farm on that. It's even premature to draw the line between an HP
problem (Posix directories ?) or an Orbit problem. A search against the
Knowledge DataBase on the ESC yielded just 4701-144311. Nothing much else
than the restore (using Orbit software) was happening at the time of the
SA.

BackupPlus version is 5.47D, MPE/iX is C.50.00, with possibly an express,
but no idea which one.

As a workaround, I had my customer purge all files in /HPSPOOL/BACKUPPL,
re-run the restore, and everything worked OK.

Anyone got hints ? Ideas ? Trails to pursue for further dump analysis ?

Thanks for the help,

Christian