Re: ISC 601

[Efim]

Hello !
Try this:
isc6:23:once:/opt/IBM/ISC/PortalServer/bin/startISC.sh ISC_Portal 
ISCUSER ISCPASS


if you want try to run without restart server

1. change line:
isc6:a:once:/opt/IBM/ISC/PortalServer/bin/startISC.sh ISC_Portal ISCUSER 
ISCPASS

2. run "telinit a"
3. if all ok , change line back:
isc6:23:once:/opt/IBM/ISC/PortalServer/bin/startISC.sh ISC_Portal 
ISCUSER ISCPASS


Efim


* Murugan_Pachamallayan <[EMAIL PROTECTED]> [Mon, 18 Sep 
2006 10:29:19 +0530]:

Dear list,



I have installed ISC 601 on the AIX 5.3 machine. But I 

could
not able to start the services. How can I start the services on the 

AIX

machine.



Regards,

Murugan









DISCLAIMER:
This email (including any attachments) is intended for the sole use of
the intended recipient/s and may contain material that is CONFIDENTIAL
AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or
copying or distribution or forwarding of any or all of the contents in
this message is STRICTLY PROHIBITED. If you are not the intended
recipient, please contact the sender by email and delete all copies;
your cooperation in this regard is appreciated.


--
Efim.

Re: TDPO for 64-bit Solaris error message: ANS0236E (RC2032) On dsmInit

[Richard Sims]

On Sep 18, 2006, at 1:20 AM, Reeves, Damion wrote:


...
09/18/06   11:28:50 ANS0236E On dsmInit, the owner is not allowed to
establish a session when PASSWORDACCESS=generate.
...


That message tells me that your TDPO is misconfigured.  I would
advise completely reviewing your TDPO client options, to assure
proper operation, particularly noting what the manual says about
Passswordaccess.

   Richard Sims

Re: 3584 library sharing followup

[Kathleen M Hallahan]

Thanks to both of you for your information!



_

Kathleen Hallahan
Freddie Mac





   William Boyer <[EMAIL PROTECTED]>
   Sent by: "ADSM: Dist Stor Manager" 
   09/16/2006 01:02 PM
   Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: 3584 library sharing followup






The problem is that after "cloning" the existing database to the 2nd
instance, they BOTH have the same volume information. When you
do the AUDIT LIBR on the library client, the library manager updates the
ownership of all the tapes known by that client. So if you
were to then run an AUDIT LIBR from the 2nd (cloned) instance, ALL the
same volumes would now be "owned" by the 2nd instance. The
library manager doesn't seem to enforce that if an instance already owns
the volume(s) that another instance just can't take
ownership away.

The TYPE=REMOTE entries in the library manager volhist table prevent you
from being able to check in a tape that has data on it as a
scratch volume. But if there's no TYPE=REMOTE entry for that tape, you can
check it in as scratch and another instance can actually
overwrite the data on that tape. So you need to be careful about keeping
track what tapes are still good for each instance.

Another thing I noticed, if client1 owns a tape and client2 calls for it
to be mounted...the library manager will mount the tape and
change the ownership over to client2. Maybe this is WAD, but I don't think
that the library manager should allow the ownership
change of a tape volume just because a client asks. I don't think that the
library manager should even allow a non-owner instance to
mount the tape. Ownership changes should be a manual process to get the
desired effect. Interesting that if on the library manager a
tape is checked in and owned by client1, you cannot issue the UPD LIBV
command to change ownership to client2. You must first check
out the volume and then check it back in so the library manager is listed
as the owner and private. Then you can issue the UPD LIBV
command to make client2 the owner.

So my current DB has both daily and monthly data, separate domains and
storage pools. I'll be "cloning" the database over to another
instance. Then:

On DAILY instance (current):
- update all the monthly volumes to ACC=UNAVAIL
- Lock all the monthly nodes.
- VARY OFF all the monthly disk volumes.

On the MONTHLY instance (cloned):
- Update all daily volumes to ACC=UNAVAIL
- Lock all daily nodes.
- VARY OFF the daily disk volumes.

On the library manager:
- Change ownership of all checked in MONTHLY tapes.
- Delete the TYPE-REMOTE entries for all the MONTHLY tapes.

At this point any monthly tapes not checked in to the library are not
known to the library manaager. So you could actually check
these tapes in as scratch. This is where you need to be careful. Also you
don't want to do an AUDIT LIBR on either of the clients at
this point. As it will change the ownership of all the tapes to that
client. Then you'll have to start all over again.

On the DAILY instance:
- DELETE all the monthly data/filespace/nodes/domains.

On the MONTHLY instance:
- Delete all the daily data/filespace/nodes/domains.

One thing I did notice is that if client1 owns the tape and client2
deletes that tape the library manager will report an error and
not change the status of the tape. So when you delete a DAILY tape from
the MONTHLY instance, ownership and status won't change.


Once all the volumes/data has been deleted from the appropriate instances,
you can issue the AUDIT LIBR to update the library
manager for correct ownership.

This was a lot of trial and error and testing. I haven't split the
production database. That's planned for next month.

Bill


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
TSM_User
Sent: Saturday, September 16, 2006 1:13 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: 3584 library sharing followup

On one of the instance you will delete the library and then create a new
"shared" library.  When you run the audit library command
on a library client it updates the library manager updates it's volhist to
show that the volumes in its library are remote and not
belong to the other instnace.

  We had a server that we wanted to retire but it had been the library
manager. We simply made one of the other library clients the
manager.  Due to the fact that this new instance had no information about
any of the library clients we found we only had to run the
audit library command on all the library clients after they were pointed
to the new library manager.

  Seems like this same approch would work for you.

Kathleen M Hallahan <[EMAIL PROTECTED]> wrote:
  Last week, Bill Boyer posted a message (which I no longer have) about
splitting a database and library sharing. and ownership of
tapes. I saw one response suggesting exporting and importing the data, but
nothing else.

Did anyone ever come up with other ideas on this?

Re: Linux vs. Windows TSM servers

[Bruce Tamulis]

Can the upper management get any more vague with their request?
Throughput of what, data being backed up...data being restored...what?
Personally, my concerns lay in Disaster Recovery, because that's where
the rubber meets the road.  It also depends upon the size of your files
and whether your data is collocated, are you running older SCSI drives
or newer fiber drives?  It all makes a difference.

Sincerely,


Bruce A. Tamulis, CNA
LDS Support Tech III
616-752-6573
[EMAIL PROTECTED]

Start using HEAT Self Serve (HSS) Today!
Just click on the link below.
http://hss.trinity-health.org/
This message may contain confidential information protected by law
through attorney-client privilege or professional peer review/quality
evaluation privilege.  It is intended only for the individual or entity
named above.  It is prohibited for anyone else to disclose, copy,
distribute or use the contents of this message.  If you received this
message in error, please notify me immediately at the above number.

>>> [EMAIL PROTECTED] Tuesday, May 16, 2006 >>>
My upper management has asked that I compare the performance of a
Linux-based TSM server to a Windows-based one in terms of throughput.
We currently use Windows TSM servers.  Before I start doing any in depth

testing and research, has anyone else done this type of comparison and
if so, what were your findings?


Mel Dennis
Systems Engineer - IT743
Siemens Power Generation
4400 Alafaya Trail
Orlando, FL 32826
MC Q1-108
Tel:  (407) 736-2360
Win:  439-2360
Fax: (407) 243-0260
Email:  [EMAIL PROTECTED]

Re: migrate 32bit database -> 64bit TSM server?

[Paul Zarnowski]

We are considering moving our server from AIX to another unix OS
(probably Linux).  I was hoping that we could just restore a backup
of our DB to a Linux server and have it point to the same tapes.  But
the initial feedback I've gotten indicates that this is not
supported.  No one has told me that it won't work, just that it's not
supported.  Given how long it would take to export/import all of our
(archive) data, this leaves us with some difficult choices.  It sure
would be nice if TSM had a supported way of doing this more
efficiently than export/import.

The other problem with export/import is that all of our clients would
then have to change their config files to point to the new
server.  If we could simply restore the DB onto the new server, that
new server could inherit the same hostname and port numbers as the
old server, making the whole server migration transparent to our
hundreds of end users.

At 03:46 AM 9/17/2006, Mark Stapleton wrote:

You will not be able to move your TSM db from Windows to Linux (or from
any OS to any other dissimilar OS). The file structures are too different.

Your best bet to have both servers up. Use the new one for backups and use
the old one (as necessary) for restored of legacy information. If you're
using the original library for the new server, there are elements of
problems with this.

After a period of time determined by your business needs, just turn off
the old server.

Do not consider export/import choices for client data. Exports and imports
TAKE TOO #%^#^&[EMAIL PROTECTED] LONG! (Listening, Tivoli?)



--
Paul ZarnowskiPh: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801Em: [EMAIL PROTECTED]

unsuscribe

[Juan Jose Reale]

Please unsuscribe this email   thanks


This communication is for use by the intended recipient and contains 
information that may be privileged, confidential or copyrighted under law. If 
you are not the intended recipient, you are hereby formally notified that any 
use, copying or distribution of this e-Mail, in whole or in part, is strictly 
prohibited. Please notify the sender by return e-Mail and delete this e-Mail 
from your system. Unless explicitly and conspicuously stated in the subject 
matter of the above e-Mail, this e-Mail does not constitute a contract offer, a 
contract amendment, or an acceptance of a contract offer. This e-Mail does not 
constitute consent to the use of sender's contact information for direct 
marketing purposes or for transfers of data to third parties.

This email has been scanned for all viruses by the MessageLabs service.

Re: migrate 32bit database -> 64bit TSM server?

[Victoria Ortepio]

Hi Paul,



No, it cannot be done.  We've proved it here by taking a TSM data snapshot

and attempting to restore it a newly built TSM server on LINUX.  This is

the result.  Unfortunately, the EXPORT / IMPORT option is your only

alternative.  You may selectively choose what to export out to cut down

the conversion time.





Tivoli Storage Manager for Linux/i386

Version 5, Release 2, Level 7.0

Licensed Materials - Property of IBM

(C) Copyright IBM Corporation 1990, 2003. All rights reserved.

U.S. Government Users Restricted Rights - Use, duplication or disclosure

restricted by GSA ADP Schedule Contract with IBM Corporation.



ANR7800I DSMSERV generated at 01:59:13 on Dec  8 2005.

ANR7801I Subsystem process ID is 6806.

ANR0900I Processing options file /usr/tivoli/tsm/server/bin/dsmserv.opt.

ANR8200I TCP/IP driver ready for connection with clients on port 1500.

ANR0200I Recovery log assigned capacity is 5696 megabytes.

ANR0201I Database assigned capacity is 15888 megabytes.

ANR4621I Database backup device class TSM-DATABASE.

ANR4622I   Volume 1: /TSM03S/40709557.dbs.

ANR4632I Starting point-in-time database restore (no commit).

ANR8340I FILE volume /TSM03S/40709557.dbs mounted.

ANR1368W Input volume /TSM03S/40709557.dbs contains sequence number
16777216;

volume sequence number 1 is required.

[EMAIL PROTECTED] bin]#



Please refer to this website for info:



http://www-1.ibm.com/support/docview.wss?uid=swg21189573





Regards,



Vicki

Verizon Business

Piscataway, NJ





-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Paul Zarnowski
Sent: Monday, September 18, 2006 10:39 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] migrate 32bit database -> 64bit TSM server?



We are considering moving our server from AIX to another unix OS

(probably Linux).  I was hoping that we could just restore a backup

of our DB to a Linux server and have it point to the same tapes.  But

the initial feedback I've gotten indicates that this is not

supported.  No one has told me that it won't work, just that it's not

supported.  Given how long it would take to export/import all of our

(archive) data, this leaves us with some difficult choices.  It sure

would be nice if TSM had a supported way of doing this more

efficiently than export/import.



The other problem with export/import is that all of our clients would

then have to change their config files to point to the new

server.  If we could simply restore the DB onto the new server, that

new server could inherit the same hostname and port numbers as the

old server, making the whole server migration transparent to our

hundreds of end users.



At 03:46 AM 9/17/2006, Mark Stapleton wrote:

>You will not be able to move your TSM db from Windows to Linux (or from

>any OS to any other dissimilar OS). The file structures are too different.

>

>Your best bet to have both servers up. Use the new one for backups and use

>the old one (as necessary) for restored of legacy information. If you're

>using the original library for the new server, there are elements of

>problems with this.

>

>After a period of time determined by your business needs, just turn off

>the old server.

>

>Do not consider export/import choices for client data. Exports and imports

>TAKE TOO #%^#^&[EMAIL PROTECTED] LONG! (Listening, Tivoli?)





--

Paul ZarnowskiPh: 607-255-4757

Manager, Storage Services Fx: 607-255-8521

719 Rhodes Hall, Ithaca, NY 14853-3801Em: [EMAIL PROTECTED]

Anyone out there actually happy with the ORACLE agent behavior?

[Allen S. Rout]

Howdy, all.

We've got some ORACLE databases backed up to TSM and are plagued by
foolishness in the RMAN connection to TSM.  This has been discussed
periodically here for a long time, but in a nutshell, Oracle doesn't
clean up after itself, and active versions of the backup files
corresponding to some operations hang around forever.

I'm wondering if any of you with oracle shops feel like your backups
are being retained properly, and/or how you're dealing with the space?

We're dealing with it using two different nodes which we switch back
and forth occasionally, "-DB" and "-DB-OLD", and once -OLD has gotten
old enough, we blow away its' filespace.  Eugh.


- Allen S. Rout

Re: migrate 32bit database -> 64bit TSM server?

[Thomas Denier]

- Paul Zarnowski wrote: -

>We are considering moving our server from AIX to another unix OS
>(probably Linux).  I was hoping that we could just restore a backup
>of our DB to a Linux server and have it point to the same tapes.
>But the initial feedback I've gotten indicates that this is not
>supported. No one has told me that it won't work, just that it's
>not supported.  Given how long it would take to export/import all of
>our (archive) data, this leaves us with some difficult choices.  It
>sure would be nice if TSM had a supported way of doing this more
>efficiently than export/import.

I don't think such a restore would work. AIX uses big-endian byte
ordering, while Linux under Intel uses little-endian ordering. I
remember an earlier posting by someone who tried a cross-platform
database restore involving systems with opposite byte ordering
conventions. The restore failed with a message stating that the first
tape loaded had a volume sequence number of 16,777,216 rather than 1.
This is exactly the error one would expect if the system writing
the database backup used one byte ordering convention for the volume
sequence number and the system reading the backup expected theopposite byte
ordering.

Re: migrate 32bit database -> 64bit TSM server?

[Paul Zarnowski]

Thanks Victoria.

Ok, so now I know it won't work (in addition to not being supported).

Next questions:
 1. How hard would it be for IBM to do something to help users do this?
 2. How many TSM sites would actually want to do this?
 I.e., is there reason to submit a requirement for this, or are we just
   trying to do something that not many folks ever want to do?


At 11:32 AM 9/18/2006, Victoria Ortepio wrote:

Hi Paul,



No, it cannot be done.  We've proved it here by taking a TSM data snapshot

and attempting to restore it a newly built TSM server on LINUX.  This is

the result.  Unfortunately, the EXPORT / IMPORT option is your only

alternative.  You may selectively choose what to export out to cut down

the conversion time.





Tivoli Storage Manager for Linux/i386

Version 5, Release 2, Level 7.0

Licensed Materials - Property of IBM

(C) Copyright IBM Corporation 1990, 2003. All rights reserved.

U.S. Government Users Restricted Rights - Use, duplication or disclosure

restricted by GSA ADP Schedule Contract with IBM Corporation.



ANR7800I DSMSERV generated at 01:59:13 on Dec  8 2005.

ANR7801I Subsystem process ID is 6806.

ANR0900I Processing options file /usr/tivoli/tsm/server/bin/dsmserv.opt.

ANR8200I TCP/IP driver ready for connection with clients on port 1500.

ANR0200I Recovery log assigned capacity is 5696 megabytes.

ANR0201I Database assigned capacity is 15888 megabytes.

ANR4621I Database backup device class TSM-DATABASE.

ANR4622I   Volume 1: /TSM03S/40709557.dbs.

ANR4632I Starting point-in-time database restore (no commit).

ANR8340I FILE volume /TSM03S/40709557.dbs mounted.

ANR1368W Input volume /TSM03S/40709557.dbs contains sequence number
16777216;

volume sequence number 1 is required.

[EMAIL PROTECTED] bin]#



Please refer to this website for info:



http://www-1.ibm.com/support/docview.wss?uid=swg21189573





Regards,



Vicki

Verizon Business

Piscataway, NJ





-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Paul Zarnowski
Sent: Monday, September 18, 2006 10:39 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] migrate 32bit database -> 64bit TSM server?



We are considering moving our server from AIX to another unix OS

(probably Linux).  I was hoping that we could just restore a backup

of our DB to a Linux server and have it point to the same tapes.  But

the initial feedback I've gotten indicates that this is not

supported.  No one has told me that it won't work, just that it's not

supported.  Given how long it would take to export/import all of our

(archive) data, this leaves us with some difficult choices.  It sure

would be nice if TSM had a supported way of doing this more

efficiently than export/import.



The other problem with export/import is that all of our clients would

then have to change their config files to point to the new

server.  If we could simply restore the DB onto the new server, that

new server could inherit the same hostname and port numbers as the

old server, making the whole server migration transparent to our

hundreds of end users.



At 03:46 AM 9/17/2006, Mark Stapleton wrote:

>You will not be able to move your TSM db from Windows to Linux (or from

>any OS to any other dissimilar OS). The file structures are too different.

>

>Your best bet to have both servers up. Use the new one for backups and use

>the old one (as necessary) for restored of legacy information. If you're

>using the original library for the new server, there are elements of

>problems with this.

>

>After a period of time determined by your business needs, just turn off

>the old server.

>

>Do not consider export/import choices for client data. Exports and imports

>TAKE TOO #%^#^&[EMAIL PROTECTED] LONG! (Listening, Tivoli?)





--

Paul ZarnowskiPh: 607-255-4757

Manager, Storage Services Fx: 607-255-8521

719 Rhodes Hall, Ithaca, NY 14853-3801Em: [EMAIL PROTECTED]



--
Paul ZarnowskiPh: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801Em: [EMAIL PROTECTED]

Re: migrate 32bit database -> 64bit TSM server?

[Victoria Ortepio]

Hi Paul,
I am sure that there are many Tivoli customers that need this function,
just as we do.  Our migration to another platform is a cost reduction
requirement.

You will see that there will be a cost increase just to perform the EXPORT.
You will require a clone of hardware on the receiving side to convert
your data.  So choose your EXPORTed data wisely.  We many just export out
all archive data, which still is a tremendous amount, and pick and choose
backup data.

FYI, the EXPORT does NOT export everything over to the new TSM server.
Manual in input is necessary. (i.e. Admin schedules, home grown command
scripts)




-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Paul Zarnowski
Sent: Monday, September 18, 2006 12:19 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] migrate 32bit database -> 64bit TSM server?

Thanks Victoria.

Ok, so now I know it won't work (in addition to not being supported).

Next questions:
  1. How hard would it be for IBM to do something to help users do this?
  2. How many TSM sites would actually want to do this?
  I.e., is there reason to submit a requirement for this, or are we just
trying to do something that not many folks ever want to do?


At 11:32 AM 9/18/2006, Victoria Ortepio wrote:
>Hi Paul,
>
>
>
>No, it cannot be done.  We've proved it here by taking a TSM data snapshot
>
>and attempting to restore it a newly built TSM server on LINUX.  This is
>
>the result.  Unfortunately, the EXPORT / IMPORT option is your only
>
>alternative.  You may selectively choose what to export out to cut down
>
>the conversion time.
>
>
>
>
>
>Tivoli Storage Manager for Linux/i386
>
>Version 5, Release 2, Level 7.0
>
>Licensed Materials - Property of IBM
>
>(C) Copyright IBM Corporation 1990, 2003. All rights reserved.
>
>U.S. Government Users Restricted Rights - Use, duplication or disclosure
>
>restricted by GSA ADP Schedule Contract with IBM Corporation.
>
>
>
>ANR7800I DSMSERV generated at 01:59:13 on Dec  8 2005.
>
>ANR7801I Subsystem process ID is 6806.
>
>ANR0900I Processing options file /usr/tivoli/tsm/server/bin/dsmserv.opt.
>
>ANR8200I TCP/IP driver ready for connection with clients on port 1500.
>
>ANR0200I Recovery log assigned capacity is 5696 megabytes.
>
>ANR0201I Database assigned capacity is 15888 megabytes.
>
>ANR4621I Database backup device class TSM-DATABASE.
>
>ANR4622I   Volume 1: /TSM03S/40709557.dbs.
>
>ANR4632I Starting point-in-time database restore (no commit).
>
>ANR8340I FILE volume /TSM03S/40709557.dbs mounted.
>
>ANR1368W Input volume /TSM03S/40709557.dbs contains sequence number
>16777216;
>
>volume sequence number 1 is required.
>
>[EMAIL PROTECTED] bin]#
>
>
>
>Please refer to this website for info:
>
>
>
>http://www-1.ibm.com/support/docview.wss?uid=swg21189573
>
>
>
>
>
>Regards,
>
>
>
>Vicki
>
>Verizon Business
>
>Piscataway, NJ
>
>
>
>
>
>-Original Message-
>From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
>Paul Zarnowski
>Sent: Monday, September 18, 2006 10:39 AM
>To: ADSM-L@VM.MARIST.EDU
>Subject: Re: [ADSM-L] migrate 32bit database -> 64bit TSM server?
>
>
>
>We are considering moving our server from AIX to another unix OS
>
>(probably Linux).  I was hoping that we could just restore a backup
>
>of our DB to a Linux server and have it point to the same tapes.  But
>
>the initial feedback I've gotten indicates that this is not
>
>supported.  No one has told me that it won't work, just that it's not
>
>supported.  Given how long it would take to export/import all of our
>
>(archive) data, this leaves us with some difficult choices.  It sure
>
>would be nice if TSM had a supported way of doing this more
>
>efficiently than export/import.
>
>
>
>The other problem with export/import is that all of our clients would
>
>then have to change their config files to point to the new
>
>server.  If we could simply restore the DB onto the new server, that
>
>new server could inherit the same hostname and port numbers as the
>
>old server, making the whole server migration transparent to our
>
>hundreds of end users.
>
>
>
>At 03:46 AM 9/17/2006, Mark Stapleton wrote:
>
> >You will not be able to move your TSM db from Windows to Linux (or from
>
> >any OS to any other dissimilar OS). The file structures are too
different.
>
> >
>
> >Your best bet to have both servers up. Use the new one for backups and
use
>
> >the old one (as necessary) for restored of legacy information. If you're
>
> >using the original library for the new server, there are elements of
>
> >problems with this.
>
> >
>
> >After a period of time determined by your business needs, just turn off
>
> >the old server.
>
> >
>
> >Do not consider export/import choices for client data. Exports and
imports
>
> >TAKE TOO #%^#^&[EMAIL PROTECTED] LONG! (Listening, Tivoli?)
>
>
>
>
>
>--
>
>Paul ZarnowskiPh: 607-255-4757
>
>Manager, Storage Services Fx: 607-255-8521
>
>719 Rhode

Re: migrate 32bit database -> 64bit TSM server?

[Allen S. Rout]

>> On Mon, 18 Sep 2006 12:18:36 -0400, Paul Zarnowski <[EMAIL PROTECTED]> said:

>   2. How many TSM sites would actually want to do this?
>   I.e., is there reason to submit a requirement for this, or are we just
> trying to do something that not many folks ever want to do?


I think that it's a small minority who'd use such a facility, and
getting smaller all the time; especially with things like the TSM
Express stuff coming along.

Now, I'm _in_ that minority, and it might in fact be a majority of us
ADSM-L denizens.  But we already know we're the creme de la creme ;)


- Allen S. Rout
- Remember, tomorrow is Talk Like A Pirate Day! http://www.talklikeapirate.com/

Re: migrate 32bit database -> 64bit TSM server?

[Richard Rhodes]

While I'm not sure, I think the problem is deeper than just the database.
It might also be
byte ordering and other issues with you data on tape.  In other words, even
if IBM
came up with a way to export/import the db to a different type of server
(which they
could . . . .Oracle did it), it might still require a conversion of the
data on all your tapes.






 Paul Zarnowski
 <[EMAIL PROTECTED]
 >  To
 Sent by: "ADSM:   ADSM-L@VM.MARIST.EDU
 Dist Stor  cc
 Manager"
 <[EMAIL PROTECTED] Subject
 .EDU> Re: migrate 32bit database -> 64bit
   TSM server?

 09/18/2006 12:18
 PM


 Please respond to
 "ADSM: Dist Stor
 Manager"
 <[EMAIL PROTECTED]
   .EDU>






Thanks Victoria.

Ok, so now I know it won't work (in addition to not being supported).

Next questions:
  1. How hard would it be for IBM to do something to help users do this?
  2. How many TSM sites would actually want to do this?
  I.e., is there reason to submit a requirement for this, or are we just
trying to do something that not many folks ever want to do?


At 11:32 AM 9/18/2006, Victoria Ortepio wrote:
>Hi Paul,
>
>
>
>No, it cannot be done.  We've proved it here by taking a TSM data snapshot
>
>and attempting to restore it a newly built TSM server on LINUX.  This is
>
>the result.  Unfortunately, the EXPORT / IMPORT option is your only
>
>alternative.  You may selectively choose what to export out to cut down
>
>the conversion time.
>
>
>
>
>
>Tivoli Storage Manager for Linux/i386
>
>Version 5, Release 2, Level 7.0
>
>Licensed Materials - Property of IBM
>
>(C) Copyright IBM Corporation 1990, 2003. All rights reserved.
>
>U.S. Government Users Restricted Rights - Use, duplication or disclosure
>
>restricted by GSA ADP Schedule Contract with IBM Corporation.
>
>
>
>ANR7800I DSMSERV generated at 01:59:13 on Dec  8 2005.
>
>ANR7801I Subsystem process ID is 6806.
>
>ANR0900I Processing options file /usr/tivoli/tsm/server/bin/dsmserv.opt.
>
>ANR8200I TCP/IP driver ready for connection with clients on port 1500.
>
>ANR0200I Recovery log assigned capacity is 5696 megabytes.
>
>ANR0201I Database assigned capacity is 15888 megabytes.
>
>ANR4621I Database backup device class TSM-DATABASE.
>
>ANR4622I   Volume 1: /TSM03S/40709557.dbs.
>
>ANR4632I Starting point-in-time database restore (no commit).
>
>ANR8340I FILE volume /TSM03S/40709557.dbs mounted.
>
>ANR1368W Input volume /TSM03S/40709557.dbs contains sequence number
>16777216;
>
>volume sequence number 1 is required.
>
>[EMAIL PROTECTED] bin]#
>
>
>
>Please refer to this website for info:
>
>
>
>http://www-1.ibm.com/support/docview.wss?uid=swg21189573
>
>
>
>
>
>Regards,
>
>
>
>Vicki
>
>Verizon Business
>
>Piscataway, NJ
>
>
>
>
>
>-Original Message-
>From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
>Paul Zarnowski
>Sent: Monday, September 18, 2006 10:39 AM
>To: ADSM-L@VM.MARIST.EDU
>Subject: Re: [ADSM-L] migrate 32bit database -> 64bit TSM server?
>
>
>
>We are considering moving our server from AIX to another unix OS
>
>(probably Linux).  I was hoping that we could just restore a backup
>
>of our DB to a Linux server and have it point to the same tapes.  But
>
>the initial feedback I've gotten indicates that this is not
>
>supported.  No one has told me that it won't work, just that it's not
>
>supported.  Given how long it would take to export/import all of our
>
>(archive) data, this leaves us with some difficult choices.  It sure
>
>would be nice if TSM had a supported way of doing this more
>
>efficiently than export/import.
>
>
>
>The other problem with export/import is that all of our clients would
>
>then have to change their config files to point to the new
>
>server.  If we could simply restore the DB onto the new server, that
>
>new server could inherit the same hostname and port numbers as the
>
>old server, making the whole server migration transparent to our
>
>hundreds of end users.
>
>
>
>At 03:46 AM 9/17/2006, Mark Stapleton wrote:
>
> >You will not be able to move your TSM db from Windows to Linux (or from
>
> >any OS to any other dissimilar OS). The file structures are too
different.
>
> >
>
> >Your best bet to have both servers up. Use the new one for backups and
use
>
> >the old one (as necessary) for restored of legacy information. If you're
>
> >using the original library for the new server, there are elements of
>
> >problems with this.
>
> >
>
> >After a period of time determined by your business needs, just turn off
>
> >the old server.
>
> >
>
> >Do not consider export/import choices for client data. Exports and
imports
>
> >TAKE TOO #%^#^&[EMAIL PROTECTE

Migrate Inactive Files Feature Proposal

[Orville Lantto]

I had an idea over the weekend and would like some comment on its feasibility.  
With the growing need for disk-to-disk-to-tape backup strategies, it would be 
very nice to be able to migrate ONLY inactive copies of files out of a storage 
pool.  I can come up with no reason that this should be difficult or impossible 
to be added as a TSM feature.
 
Any comments?
 
Orville L. Lantto
Glasshouse Technologies, Inc.
 

Re: Migrate Inactive Files Feature Proposal

[BEYERS Kurt]

Orville,
 
This feature will be available in one of the versions that will follow up TSM5.3
 
A look-a-like is listed already in the TSM 5.4 enhancenments, see 
http://tsmexpert.blogspot.com/2006/08/tsm-v54-enhancements_04.html under 
'collocation of active data'.
 
But as always it is up to IBM to make official statements when new features 
will become available.
 
best regards,
Kurt



Van: ADSM: Dist Stor Manager namens Orville Lantto
Verzonden: ma 18/09/2006 21:14
Aan: ADSM-L@VM.MARIST.EDU
Onderwerp: [ADSM-L] Migrate Inactive Files Feature Proposal



I had an idea over the weekend and would like some comment on its feasibility.  
With the growing need for disk-to-disk-to-tape backup strategies, it would be 
very nice to be able to migrate ONLY inactive copies of files out of a storage 
pool.  I can come up with no reason that this should be difficult or impossible 
to be added as a TSM feature.

Any comments?

Orville L. Lantto
Glasshouse Technologies, Inc.



*** Disclaimer ***

Vlaamse Radio- en Televisieomroep
Auguste Reyerslaan 52, 1043 Brussel

nv van publiek recht
BTW BE 0244.142.664
RPR Brussel
http://www.vrt.be/disclaimer
 

Re: Migrate Inactive Files Feature Proposal

[Thorneycroft, Doug]

I put out this idea a couple of years ago, It didn't 
generate a whole lot of interest then.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Orville Lantto
Sent: Monday, September 18, 2006 12:14 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Migrate Inactive Files Feature Proposal


I had an idea over the weekend and would like some comment on its feasibility.  
With the growing need for disk-to-disk-to-tape backup strategies, it would be 
very nice to be able to migrate ONLY inactive copies of files out of a storage 
pool.  I can come up with no reason that this should be difficult or impossible 
to be added as a TSM feature.
 
Any comments?
 
Orville L. Lantto
Glasshouse Technologies, Inc.
 

Re: migrate 32bit database -> 64bit TSM server?

[Richard Sims]

On Sep 18, 2006, at 1:24 PM, Richard Rhodes wrote:


While I'm not sure, I think the problem is deeper than just the
database.
It might also be byte ordering and other issues with you data on tape.
In other words, even if IBM came up with a way to export/import the db
to a different type of server (which they could . . . .Oracle did
it), it might
still require a conversion of the data on all your tapes.


TSM's Restore DB should remain a recovery vehicle, and I agree with
the consensus that there should be some kind of Migrate DB function.
Such a function gets "interesting" in areas with hardware
dependencies; but whereas the family of TSM servers constitutes a
superset of all the understanding needed, it should be do-able.

I don't see any need for conversion of storage pool data, given that
it is stored as the client sent it, regardless of its OS type or
machine architecture (or byte order, derived therefrom).  The server
only needs to know what volume a file is on, and its media index.
Keep in mind that it is the client which ultimately restores file
system data, not the server.

Richard Sims

Strange Reclamation Problem

[Andrew Carlson]

I am running TSM 5.3.2.3 on an AIX (5.2.5) platform.  We recently finished 
migrating our onsite pool to disk only, and out offsite pool to directly 
attached 3592 drives in a 3584 silo.  We started getting multiple ANR1163I 
messages.  I started investigating this, and found an odd behaviour.  If I 
entered a move volume command for one of the volumes, it would move some data, 
then end, with no errors.  It appears to be moving the data of one node off the 
cart, then ending the process.  These are volumes that were previously not 
collocated.  If I update the volume to read-write (I forgot to mention I make 
them offsite so the TSM will read from the disk pool), and do the move volume 
tape-to-tape, it works fine.  It finishes the whole tape.  Any ideas?  I am 
going to open a PMR with IBM, but thought I would ask here first in case I 
missed something incredibly obvious.  Thanks.

ANR1040I Space reclamation started for volume 110021, storage pool COPY3592
(process number 1555).
ANR1040I Space reclamation started for volume 110482, storage pool COPY3592
(process number 1555).
ANR1040I Space reclamation started for volume 110436, storage pool COPY3592
(process number 1555).
ANR1040I Space reclamation started for volume 110268, storage pool COPY3592
(process number 1555).
ANR1040I Space reclamation started for volume 111027, storage pool COPY3592
(process number 1555).
ANR8468I 3592 volume 110192 dismounted from drive RMT5 (/dev/rmt5) in library
3584LIB.
ANR0409I Session 349997 ended for server TSMLIBM (AIX-RS/6000).
ANR1163W Offsite volume 110212 still contains files which could not be moved.
ANR1163W Offsite volume 110499 still contains files which could not be moved.
ANR1163W Offsite volume 110163 still contains files which could not be moved.
ANR1163W Offsite volume 110021 still contains files which could not be moved.
ANR1163W Offsite volume 110482 still contains files which could not be moved.
ANR1163W Offsite volume 110436 still contains files which could not be moved.
ANR1163W Offsite volume 110268 still contains files which could not be moved.
ANR1163W Offsite volume 111027 still contains files which could not be moved.
ANR4932I Reclamation process 1555 ended for storage pool COPY3592.
ANR0986I Process 1555 for SPACE RECLAMATION running in the BACKGROUND processed
6335 items for a total of 1,768,794,536 bytes with a completion state of
SUCCESS at 10:13:52.


Andy Carlson 
---
Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month,
The feeling of seeing the red box with the item you want in it:Priceless.

Re: Migrate Inactive Files Feature Proposal

[Allen S. Rout]

>> On Mon, 18 Sep 2006 12:34:04 -0700, "Thorneycroft, Doug" <[EMAIL PROTECTED]> 
>> said:


> I put out this idea a couple of years ago, It didn't
> generate a whole lot of interest then.

> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
> Orville Lantto
> Sent: Monday, September 18, 2006 12:14 PM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Migrate Inactive Files Feature Proposal


> I had an idea over the weekend and would like some comment on its
> feasibility.  With the growing need for disk-to-disk-to-tape backup
> strategies, it would be very nice to be able to migrate ONLY
> inactive copies of files out of a storage pool.  I can come up with
> no reason that this should be difficult or impossible to be added as
> a TSM feature.


They're discussing ways to get similar effects.  The reason it's
difficult is that the fundamental unit of storage insited TSM storage
volumes is not the "file", it's the "aggregate".  This is a group of
files and diperhaps metadata, where such doesn't fit in the TSM DB.
Statements about e.g. copy stgpool coverage are made on the aggregate
level.

COnsequently, breaking up these aggregates (rather than simply
removing parts of them) makes for databases growth and referential
integrity problems.


- Allen S. Rout

offtopic: AIX FTP/TELNET question

[Gill, Geoffrey L.]

Sorry for asking this on the ADSM list but I know a lot of folks using AIX
can help me with this. I'm having an FTP and Telnet issue and as far as I
can tell it is not AIX related.



I am trying to access 2 of my TSM servers in a fire walled off area. FTP and
telnet login screens were typically sub second screens but now are taking
right around 75 seconds when using reflections. Command line ftp fails so my
jobs are not working. Command line FTP eventually comes up and says
connected but then it also says the connection is closed by the remote host.
This happens right at 60 seconds. Reflections FTP takes 75 seconds but
allows me to log in and transfer files. Dos command line telnet also takes
75 seconds but works. Reflections Telnet work the same way.



This phenomenon started last week and, as typically happens, I'm told it's
my problem and nothing network related. Just so I don't go down and rip
someone's head off when I shouldn't, would some please tell me I'm wrong and
where to fix this if it actually is on my end? Is it possible it is having a
hard time trying to find a route or is this a setting on my side that can be
changed I'm not aware of?



Thanks,



Geoff Gill

TSM Administrator

PeopleSoft Sr. Systems Administrator

SAIC M/S-G1b

(858)826-4062

Email:   [EMAIL PROTECTED]