HP3000-L Archives

October 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Christian Lheureux <[log in to unmask]>
Reply To:
Date:
Tue, 12 Oct 1999 18:41:11 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (35 lines)
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

ATOM RSS1 RSS2