On Wednesday, 01/02/2008 at 10:22 EST, Thomas Kern [EMAIL PROTECTED]
wrote:
And because of the pricing of z/OS cycles, some managers are beginning
to forget their blue tattoos and switch to brand X backup/restore
products when they see that the zlinux TSM is still not as fully
featured as
On Mon, 31 Dec 2007 13:06:47 -0700 Mark Post said:
On Thu, Dec 27, 2007 at 2:21 PM, in message
[EMAIL PROTECTED], Aria Bamdad
[EMAIL PROTECTED] wrote:=20
-snip-
Why is it that z/Linux can talk to a channel attached 3590 but TSM
can't?
According to one of my contacts, it's because there are
On Wed, Jan 2, 2008 at 10:41 AM, in message
[EMAIL PROTECTED], Aria Bamdad
[EMAIL PROTECTED] wrote:
-snip-
But I am not using FICON attached tape. I use an ESCON attached 3590
that is in reality a SCSI drive but connected to a ESCON attached
controller.
Same difference. The channel
On Wednesday, 01/02/2008 at 10:44 EST, Aria Bamdad
[EMAIL PROTECTED] wrote:
But I am not using FICON attached tape. I use an ESCON attached 3590
that is in reality a SCSI drive but connected to a ESCON attached
controller.
Whether ESCON or FICON, it doesn't matter. IBM likes to invent new
Further, TSM would have to change
You could have stopped here... 8-(.
to integrate tape management with
mainframe tape management systems. That is, it would need to use
something like the new eRMM APIs that can talk to z/OS tape managers.
Would be nice. Otherwise, I guess it's left as an
PM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: CMS TSM admin client
Further, TSM would have to change
You could have stopped here... 8-(.
to integrate tape management with
mainframe tape management systems
And because of the pricing of z/OS cycles, some managers are beginning
to forget their blue tattoos and switch to brand X backup/restore
products when they see that the zlinux TSM is still not as fully
featured as MAINFRAME software should be.
Tape management and shared drives have been such
On Thu, Dec 27, 2007 at 2:21 PM, in message
[EMAIL PROTECTED], Aria Bamdad
[EMAIL PROTECTED] wrote:
-snip-
Why is it that z/Linux can talk to a channel attached 3590 but TSM
can't?
According to one of my contacts, it's because there are some SCSI commands that
TSM uses, which are not
On Thu, Dec 27, 2007 at 3:19 PM, in message
[EMAIL PROTECTED], Aria Bamdad
[EMAIL PROTECTED] wrote:
-snip-
I never understand the marketing thinking behind Tivoli products.
You're making a rash assumption that thinking is involved at all.
Mark Post
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on
12/28/2007 09:40:22 AM:
On Thursday, 12/27/2007 at 04:18 EST, McKown, John
[EMAIL PROTECTED] wrote:
How about if IBM allowed a zIIP or zAAP to do this?
zIIPs and zAAPs are designed to reduce the software costs associated
On Thursday, 12/27/2007 at 04:18 EST, McKown, John
[EMAIL PROTECTED] wrote:
How about if IBM allowed a zIIP or zAAP to do this?
zIIPs and zAAPs are designed to reduce the software costs associated with
z/OS. You could get an IFL for the same price and use any left-over
cycles for Other
But I think I'd rather see the System z FCP adapter support being a
*target* WWPN+LUN. That would open up the moral equivalent of SAN
Volume
Controller (or maybe SVC itself!) on System z. The targeted device
driver
could emulate any kind of SCSI device it wanted to, hiding the backend
Hi,
I had occasion to attempt to use the TSM 3.1 admin client on CMS today.
With a few changes to DSM OPT, that admin client can talk quite nicely with
my TSM 5.4 server on z/Linux. I sure miss the CMS TSM server, but having a
CMS TSM admin client is quite handy.
Cheers,
Arty
I had occasion to attempt to use the TSM 3.1 admin client on CMS
today.
With a few changes to DSM OPT, that admin client can talk quite nicely
with
my TSM 5.4 server on z/Linux. I sure miss the CMS TSM server, but
having
a
CMS TSM admin client is quite handy.
Providing an iSCSI target
On Thu, 27 Dec 2007 13:35:54 -0500 David Boyes said:
I had occasion to attempt to use the TSM 3.1 admin client on CMS
today.
With a few changes to DSM OPT, that admin client can talk quite nicely
with
my TSM 5.4 server on z/Linux. I sure miss the CMS TSM server, but
having
a
CMS TSM
Providing an iSCSI target server virtual machine for CMS that
understood
channel-attached tape drives would cure a lot of my complaints about
losing the CMS TSM server. (The Linux TSM server understands iscsi
targets).
It also occurs to me that this approach would eliminate the need for the
Hi,
On Thu, 27 Dec 2007 14:31:10 -0500 David Boyes said:
It also occurs to me that this approach would eliminate the need for the
specialized Linux OCO device drivers entirely (assuming that you also
just require VM instead of supporting LPAR).
Would lin_tape (non-OCO, see
A downside for the iSCSI approach is that I don't think the packet
processing for VSWITCH traffic gets offloaded to the I/O
processors, so
you'd use up more CPU to drive tape operations. Of course, I've been
lobbying for a specialized network processor engine for a while;
this
would be
Would lin_tape (non-OCO, see
ftp://index.storsys.ibm.com/devdrvr/Linux)
help?
Nope. Lin_tape solves a different problem.
Lin_tape still remains device-specific (in terms of the actual end
device), and still doesn't allow the Linux guests to take advantage of a
common TMS (like VM:Tape or
19 matches
Mail list logo
