.
I think Richard is onto something, but I think it is more likely to be
the "Worst Stupid TSM User Trick", namely attempting to back up two
computers on one TSM nodename. Users try this all the time. When I catch
them, I send the pack of wolves to attack and devour them, because it
comprimises their ability to restore. (This has already caused one
impaired restore in our present ongoing fire disaster.) If they fail to
pay attention when I catch them and send them email, I threaten to lock
their email account. Sometimes I actually have to do that, and then they
come hat in hand begging and remorseful.

Scan the activity log for ANR1639I, and you'll find them. You kind of
have to ignore IP address changes reported by ANR1639I, because of DHCP.
(If you know your IP addresses, you can spot the DHCP changes and ignore
those.) GUID changes reported by ANR1639I are a much more reliable
indicator of abuse. You also have to ignore one-time changes due to the
happy event of upgrades. But upgrades are also the most likely scenario
for abuse, as they leave the scheduler running on their old computer.

I really wish there was a positive way to prevent this abuse. I've been
thinking of a Unix daemon that does ANR1639I --> LOCK NODE.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
                         If with your litter
                            you do disgrace
                         and spoil the beauty
                            of this place.
                         May indigestion
                            rack your chest
                         and ants invade your
                            pants and vest.
 --sign, Little Red Schoolhouse Nature Preserve, Palos, Cook County IL


On Thu, 31 Jan 2008, Richard Sims wrote:

>
>> 1/31/2008 3:30:37 AM ANR0536W Transaction failed for session 121443
>> for
>> node ROSE-OTS (WinNT) - downlevel client does not support format of
>> stored
>> files.
>
>Hi, Zoltan -
>
>That superficially sounds to me like the case of someone on the
>client end having experimented with a newer level of the TSM client,
>and then having dropped back to the prevailing older value, leaving
>the newly deposited data in the TSM storage pools with advanced
>control data and structures.  This might also happen when some other
>client, which happens to be at the higher level, poses as that other,
>older client, via -VIRTUALNodename.
>
>    what I can think of,  Richard Sims
>