I had this type of thing happen to a Mac client. A win* 4.2.1.26 client
touched a mac node, it didn't even back anything up, just connected, but
it caused the mac client to say it was downlevel. So I got the 5.1 mac client
and installed it and it still said it was downlevel!
At this point I called a problem into Tivoli; the level 1 rep can give out a
procedure of show commands and other unsupported things to fix the
node record of the mac node to 'undownlevel' it. It has to do with unicode
(no surprize there).
I think the rep said it was a bug, I don't know what the resolution will be or
when.
So call Tivoli support and you can undownlevel your aix node.
Hope this helps,
Bill
At 03:43 PM 5/16/2002 +0200, you wrote:
>Eric,
>
>You are right about those statements. But the thing that scares me, is that
>it is at all possible to connect as an AIX node to TSM, using windows TSM
>client software, regardles of the version.
>You can train users to any extend, but you cannot always predict the actions
>they will take. What i would like to see, is that the TSM server prevents
>the update in the database for a specific node when the client platforms
>don't match, or when there is only read actions involved. Like queries or
>restores.
>
>
>
>Ilja G. Coolen
>
>
> _____
>
>ABP / USZO
>CIS / BS / TB / Storage Management
>Telefoon : +31(0)45 579 7938
>Fax : +31(0)45 579 3990
>Email : ilja.coolen AT abp DOT nl <mailto:ilja.coolen AT abp DOT nl>
>Intranet
> : Storage Web
><http://intranet/cis_bstb/html_content/sm/index_sm.htm>
>
> _____
>
>- Everybody has a photographic memory, some just don't have film. -
>
>
>-----Oorspronkelijk bericht-----
>Van: Loon, E.J. van - SPLXM [mailto:Eric-van.Loon AT KLM DOT COM]
>Verzonden: donderdag 16 mei 2002 13:31
>Aan: ADSM-L AT VM.MARIST DOT EDU
>Onderwerp: Re: Virtualnodename issue concerning Windows and AIX
>
>
>Hi Ilja!
>I don't think it's a filespace renaming problem. I think you are running
>into the fact that once you connect with a newer client version, you can't
>go back to an old version.
>This is stated in the readme:
>- Data that has been backed up or archived from a TSM V4.2 client using the
>encryption feature, or from any TSM V4.2 Windows client, cannot be restored
>or retrieved to any previous level client, regardless of the TSM server
>level. The data must be restored or retrieved by a V4.2.0 or higher level
>client.
>Personally I don't see this as a bug. One just should not connect to TSM
>pretending to be another user as long as you are using different client
>levels or OS.
>Kindest regards,
>Eric van Loon
>KLM Royal Dutch Airlines
>
>
>-----Original Message-----
>From: Ilja G. Coolen [mailto:ilja.coolen AT ABP DOT NL]
>Sent: Wednesday, May 15, 2002 17:08
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Virtualnodename issue concerning Windows and AIX
>
>
>Hello there,
>
>We stumbled onto the following problem, the hard way i may add.
>
>We have a mixed environment using AIX, Windows NT/2K and Sun Solaris.
>The Sun and NT boxes all run a very recent TSM client level.
>Some AIX boxes are running TSM client code by now as well, but most of the
>aren't on AIX 4.3.3 yet, so we can't upgrade them all.
>
>Our TSM server runs on AIX 4.3.3.x at level 4.2.1.9.
>
>Here comes the problem.
>One of our DBA's connected to TSM server using a windows tsm client,
>pretending to be a certain AIX node. Due to the optionsettings, the
>AUTOFSRENAME action kicked in, updating the FS information on that AIX box.
>
>The q node showed the following.
>
>tsm: ABPTSM1>q node rs6sv090*
>
>
>
>Node Name Platform Policy Domain Days Since
>Days Since Locked?
> Name Last Acce-
>Password
> ss
>Set
>------------------------- -------- -------------- ----------
>---------- -------
>RS6SV090 AIX DOMRS_TST <1
><1 No
>RS6SV090Z WinNT DOMRS_TST 1
>182 No
>
>
>The *Z node is the renamed version, so we could continue the backups to the
>original node name, being rs6sv090.
>As you can see, the *Z AIX box is shown as a NT box. Huh?!
>
>When connecting the original node from the AIX command line, we are told
>that the client is down-level, so we cannot connect.
>No backups or restores are possible using the original node. No backups or
>restores are possible from any AIX node, no mather which client code we run.
>
>To make the original data available, we exported the *Z data, and imported
>it into the original nodename, without updating the client information using
>the replacedefs=no option during the import. This took a while though.
>
>I think it's not such a good functionality, that we can use a windows tsm
>client to connect as an AIX box, rendering the AIX data unavailable.
>To me, this feels like a BUG.
>
>I'm working on the following questions:
>Did any of you run into such a problem too?
>Does anyone know of a way to prevent someone from performing the connect
>like this?
>Is this problem known to Tivoli? If yes, what is being done on this issue?
>
>Any comment is appreciated.
>
>
>kind regards.
>
>
>
>Ilja G. Coolen
>
>
>
>
>ABP / USZO
>CIS / BS / TB / Storage Management
>Telefoon: +31(0)45 579 7938
>Fax: +31(0)45 579 3990
>Email: ilja.coolen AT abp DOT nl
>Centrale Mailbox: Centrale Mailbox - Storage BS/TB (eumbx05)
>
>
>
>- Everybody has a photographic memory, some just don't have film. -
>
>
>**********************************************************************
>For information, services and offers, please visit our web site:
>http://www.klm.com. This e-mail and any attachment may contain confidential
>and privileged material intended for the addressee only. If you are not the
>addressee, you are notified that no part of the e-mail or any attachment may
>be disclosed, copied or distributed, and that any other action related to
>this e-mail or attachment is strictly prohibited, and may be unlawful. If
>you have received this e-mail by error, please notify the sender immediately
>by return e-mail, and delete this message. Koninklijke Luchtvaart
>Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be
>liable for the incorrect or incomplete transmission of this e-mail or any
>attachments, nor responsible for any delay in receipt.
>**********************************************************************
----------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge Ma.
|
