V2 client issue - anyone seen this before?

It probably means that you are using a down level client to attempt to restore
data backed
up by a later level client.

 I see that you are using a version 2.6 client so is it possible that the data
was backed up with
 a newer version 3 client ?

Pete Tanenhaus
ADSM Client Development


---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 12/06/97
6/97
10:44 AM ---------------------------

        ADSM-L AT VM.MARIST DOT EDU
        12/05/97 03:38 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU @ internet

To: ADSM-L AT VM.MARIST DOT EDU @ internet
cc:
Subject: V2 client issue - anyone seen this before?

Hi list! I have a perplexing little problem that has recently shown up
on our HPUX boxes running ADSM.
The server is 2.6.0.16  and the clients are 2.1.0.6 (all platforms are
HPUX 10.20)

Recently, when running an incremental against directories /usr, /var,
and /users  we get a message:
 -------[snipped]-----------
  Server Version 2, Release 6, Level 0.16
  Data compression forced on by the server
  Server date/time: 12/05/1997 13:40:46   Last access: 12/05/1997
11:24:43

Incremental backup of file system: '/var'
ANS4245E Format unknown

Total number of objects inspected:        0
Total number of objects backed up:        0
Total number of objects updated:          0
Total number of objects rebound:          0
Total number of objects deleted:          0
Total number of objects failed:           0
Total number of bytes transferred:        0
Elapsed processing time:            0:00:55
dsmc>

Has anyone any idea as to why this is occurring? We have run successful
incrementals against these directories just fine every
day up until a week or so ago.   I checked the online help for this
message and it states that the file format is unknown!? It is a mounted
directory...  Anyway, all of our disks are LVM partitions and all of the
system filesystems (/, /usr, /var, /opt, /tmp) are vxfs (the basic vxfs
implementation provided by HP).  All other vxfs filesystems work just
fine, so that *shouldn't* be the problem... Any ideas?

How about any IBMers?? You seen this before?

Any info would be appreciated! Thanks in Advance!

 -Rob Alexander
ralexander AT shl DOT com