We're all right, but not shedding a lot of light at this point.
I hope Nick finds a solution to his original problem.

Lindsay Morris
Principal
TSMworks
Tel. 1-859-539-9900
lindsay AT tsmworks DOT com


On Wed, Jan 6, 2010 at 7:08 AM, Schaub, Steve <steve_schaub AT bcbst DOT 
com>wrote:

> While we're "quibbling"...
> What I would like is a single install binary that I could throw at W2K3,
> W2K8, x86, x64 and have it automatically detect and install what it needs,
> rather than me having to create multiple install scripts.  While we're at
> it, having a central console to "push" new clients out in mass would be nice
> too.
>
> Steve Schaub
> Systems Engineer, Windows
> BlueCross BlueShield of Tennessee
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Wanda Prather
> Sent: Tuesday, January 05, 2010 9:37 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Disparate Client Options
>
> > I could quibble - they have to do all that anyway, right, across the
> > various
> > clients?
> >
> > I don't think so. Consider, how would you map an ACL for a UNIX file in
> say, an AIX DFS filesystem, to an ACL for a Windows file system?  The
> client
> is supposed to honor those ACL's, and restore them along with the data.  I
> don't see how that would work.
>
> And you can have things in non-text files that simply don't compute when
> moved from UNIX to Windows and vice-versa.  Moving a binary from UNIX to
> Windows won't make it executeable.  And there are file formats that have
> big-endian vs. little-endian issues  (for example, output from Fortran, for
> which there were UNIX compilers at one time, although I realize there are
> fewer and fewer such cases these days.).
>
> And Richard is correct, when restoring to Windows, TSM doesn't write the
> files; it calls NTFS to write the files.  I don't know that all the
> filesystem calls translate.  For instance, you can create an empty 2GB file
> in an NTFS filesystem; there is no such thing in a JFS.
>
> And there are at least 5 different filesystem types for AIX, at least 4
> that
> I know of for Red Hat, et cetera, et cetera.... many, many permutations.
>
> SO if you say well those aren't the files I'm interested in, I just want
> flat files...then I think what you are looking for is a different protocol
> altogether - maybe ask for a "bit stream restore", where TSM will restore
> the bits into a flat file across operating systems, ignoring all the
> conversion issues, and make you responsible for decoding the result.
>
> But I'm still not sure that's desirable from a security point of view, and
> most people will find it less work to restore the file back to its original
> O/S and FTP it, thereby taking the responsibility of stripping out the
> ACL's
> themselves...
>
> W
>
> >
> > Lindsay Morris
> > Principal
> > TSMworks
> > Tel. 1-859-539-9900
> > lindsay AT tsmworks DOT com
> >
> >
> > On Tue, Jan 5, 2010 at 2:22 PM, Richard Sims <rbs AT bu DOT edu> wrote:
> >
> > > On Jan 5, 2010, at 12:19 PM, Lindsay Morris wrote:
> > >
> > > > True, unix to unix works, and windows to windows too. Osx and netware
> > are
> > > oddballs, but not so common.
> > > >
> > > > But we build an appliance that wants to "dsmc restore" from ALL the
> > nodes
> > > on a TSM site, windows and unix both, to spot-check recoverability.
> Dsmc
> > > blocks cross-platfrm restores (windows vs unix at leadt), and for no
> good
> > > reason, AFAIK.
> > >
> > > Well...consider what's involved.  The good reason is that a fully
> > > cross-platform client architecture would have to include full
> programming
> > > for the universe of file system types accommodated on all the supported
> > > platforms - and additionally would have to adeptly provide a meta layer
> > of
> > > emulation of the wealth of system calls associated with the file system
> > > which is not native to the receiving platform.  That's an enormous
> amount
> > of
> > > development and testing and maintenance.  I'd rather that their
> energies
> > > went toward things like 64-bit clients, and administrative API, and
> > > long-overdue evolution of the terribly neglected CLI.
> > >
> > >   Richard Sims
> > >
> >
>
> -----------------------------------------------------
> Please see the following link for the BlueCross BlueShield of Tennessee
> E-mail disclaimer:  http://www.bcbst.com/email_disclaimer.shtm
>