I don't think that is the remedy. On our systems, the ASSIGN that the Linux guest issues on its own behalf (after the fact that CP issued the ASSIGN [by default] with the ATTACH of the tape drive) does not fail ... it completes successfully.
JR (Steven) Imler CA Sr Sustaining Engineer Tel: +1-703-708-3479 steven.im...@ca.com -----Original Message----- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Brian Nielsen Sent: Thursday, April 28, 2011 01:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: 3590 assign problem If your Linux guest is trying to do an assign, then you need to make sure= VM doesn't do an assign during the Attach by using the NOASSIGN option of= the ATTACH command. Brian Nielsen On Thu, 28 Apr 2011 12:06:31 -0500, Neale Ferguson <ne...@sinenomine.net>= wrote: >X-posted - IBMVM & LINUX-390 > >When we attach a tape drive (3590) to a Linux guest, the tape driver >attempts to execute an assign operation on the device which is getting a= n >error: > >TRACE TYPE IO, CPU 0000 TIME 12:08:25.022913 >TRACEID = VMTAPE, TRACESET = TAPE, IODATA = 100 >USER = SLES10S2, I/O OLD PSW = 07041000 80000000 00000000 001352BE >DEVICE = 0585, SCSW = 00C04017 7FFDC448 0E000000 ** I/O ERROR ** >ESW = 00800000 >I/O PRIORITIES: CHANNEL = 0, CURRENT = 100, ORIGINAL = 100 >OUT-PRIORITIZED COUNT = 0 >-> CCW(1) = B740000B 7FFC6FA4, CCW ADDRESS = 7FFDC438 >DATA = 00000000 00000000 000000 *...........* >-> CCW(2) = 03040000 7FF8A058, CCW ADDRESS = 7FFDC440 ** IDA ** > >The subsequent sense reveals: >-> CCW(1) = 04200020 7FFEF810, CCW ADDRESS = 7FFEF7F0 >DATA = 804800C0 20122041 0003FF00 00000000 *................* >00000000 00000010 20040000 00001011 *................* > >On the linux side syslog shows: > >kernel: TAPE_STD: 0.0.0181: assign failed - device might be busy > >A search reveals a great candidate APAR for HCPTSS: VM63414, however, th= is >was a problem back in 2005 for z/VM 4.4 and we're on 5.4 RSU 0901. Before, I >go any further is this a problem anyone else has seen? If not, I'll go >through normal channels (actually I'll probably do it in parallel). > >Neale
