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 : [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >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:[EMAIL PROTECTED]] >Verzonden: donderdag 16 mei 2002 13:31 >Aan: [EMAIL PROTECTED] >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:[EMAIL PROTECTED]] >Sent: Wednesday, May 15, 2002 17:08 >To: [EMAIL PROTECTED] >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: [EMAIL PROTECTED] >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 C. S. Draper Lab Cambridge Ma.
