Re: Problems with SCSI-over-FCP after machine upgrade

2015-06-04 Thread Scott Rohling
Use SET EDEV commands to delete all the paths defined over the FCP
subchannels... Then use SET EDEV to define them all back when done..
A simple EXEC to do one or the other or both will save your fingers if you
need to do this more then once.

Scott Rohling

On Thu, Jun 4, 2015 at 2:07 PM, kwg kw...@yahoo.co.uk wrote:

 There is no zoning. These are all development systems used only by the
 z/vm and its linux guests. It was a machine upgrade rather than a new
 machine and the NPIVs for the z/vm systems were preserved. I did check them
 and I will check again but all the linux systems did start ok initially.
 The physical WWPNs may have changed, especially if they are associated with
 the ficon cards, which were permitted during the upgrade.

 Btw can anyone tell me how I can stop the EDEV devices so that I can vary
 the Chris's offline without shutting down z/VM (which has some z/os guests).

 Keith




  On 4 Jun 2015, at 21:30, David Kreuter dkreu...@vm-resources.com
 wrote:
 
  Hi Keith: Check the zoning and the NPIVs. The NPIVs presented to SVC
  from the BC12 could have changed.
  David Kreuter
 
 
   Original Message 
  Subject: Problems with SCSI-over-FCP after machine upgrade
  From: Keith Gooding kw...@yahoo.co.uk
  Date: Thu, June 04, 2015 4:21 pm
  To: LINUX-390@VM.MARIST.EDU
 
  This may not be the proper forum but maybe someone can help.
  We have a small number of linux systems (32) under z/VM 6.3 which use
  SCSI connections to LUNs on a SAN Volume Controller via a couple of IBM
  SAN24B switches (the equivalent of Brocade 300). There are also some
  systems which use EDEVs on the same SVC. This had worked on z10 BC for
  about 5 years without problems.
  Last week the z10 was upgraded to a zBC12, retaining the same FICON
  cards (4Gbs), but not necessarily associated with the same CHPIDs. Since
  then a number of the LUN connections have been 'lost', cauing linux
  systems to fail. SCSIDISC displays eg HCPRXS975I Virtual FCP device
  1A05 ignored because the adapter was not able to connect to the fibre
  channel network. It is then not possible to rebot the linux system.
 
  Restarting 'everything' - ie SVC nodes, SAN switches, CHIPD vary off/on
  -  cleared the problem for a while.
  Any ideas where to start looking ?. I have discovered that we have  32
  FCP subchannels defined on the CHPID (but highest used unit address is
  1f, and there are only about a dozen in use). Also the switch has not
  been 'qualified' for use on z12 (but it appears that it was not
  qualified for z10 either).
  Any advice greatly appreciated !
 
 
  --
  For LINUX-390 subscribe / signoff / archive access instructions,
  send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
  visit
  http://www.marist.edu/htbin/wlvindex?LINUX-390
  --
  For more information on Linux on System z, visit
  http://wiki.linuxvm.org/
 
  --
  For LINUX-390 subscribe / signoff / archive access instructions,
  send email to lists...@vm.marist.edu with the message: INFO LINUX-390
 or visit
  http://www.marist.edu/htbin/wlvindex?LINUX-390
  --
  For more information on Linux on System z, visit
  http://wiki.linuxvm.org/

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Problems with SCSI-over-FCP after machine upgrade

2015-06-04 Thread kwg
There is no zoning. These are all development systems used only by the z/vm and 
its linux guests. It was a machine upgrade rather than a new machine and the 
NPIVs for the z/vm systems were preserved. I did check them and I will check 
again but all the linux systems did start ok initially. The physical WWPNs may 
have changed, especially if they are associated with the ficon cards, which 
were permitted during the upgrade.

Btw can anyone tell me how I can stop the EDEV devices so that I can vary the 
Chris's offline without shutting down z/VM (which has some z/os guests).

Keith




 On 4 Jun 2015, at 21:30, David Kreuter dkreu...@vm-resources.com wrote:
 
 Hi Keith: Check the zoning and the NPIVs. The NPIVs presented to SVC
 from the BC12 could have changed.
 David Kreuter
 
 
  Original Message 
 Subject: Problems with SCSI-over-FCP after machine upgrade
 From: Keith Gooding kw...@yahoo.co.uk
 Date: Thu, June 04, 2015 4:21 pm
 To: LINUX-390@VM.MARIST.EDU
 
 This may not be the proper forum but maybe someone can help.
 We have a small number of linux systems (32) under z/VM 6.3 which use
 SCSI connections to LUNs on a SAN Volume Controller via a couple of IBM
 SAN24B switches (the equivalent of Brocade 300). There are also some
 systems which use EDEVs on the same SVC. This had worked on z10 BC for
 about 5 years without problems.
 Last week the z10 was upgraded to a zBC12, retaining the same FICON
 cards (4Gbs), but not necessarily associated with the same CHPIDs. Since
 then a number of the LUN connections have been 'lost', cauing linux
 systems to fail. SCSIDISC displays eg HCPRXS975I Virtual FCP device
 1A05 ignored because the adapter was not able to connect to the fibre
 channel network. It is then not possible to rebot the linux system.
 
 Restarting 'everything' - ie SVC nodes, SAN switches, CHIPD vary off/on
 -  cleared the problem for a while.
 Any ideas where to start looking ?. I have discovered that we have  32
 FCP subchannels defined on the CHPID (but highest used unit address is
 1f, and there are only about a dozen in use). Also the switch has not
 been 'qualified' for use on z12 (but it appears that it was not
 qualified for z10 either).
 Any advice greatly appreciated !
 
 
 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/
 
 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Problems with SCSI-over-FCP after machine upgrade

2015-06-04 Thread Scott Rohling
I should have said you will probably need to use SET EDEV .. CLEAR to
delete the last path -- it may even remove them all - but as I've never
issued it myself - I'm not sure.  When I've messed with things it was to
vary off particular paths - not get rid of the whole device.   You can
DEFINE/DELETE EDEVICE --- but I'm fairly sure that with SET EDEV DELETE
PATH and CLEAR ---   and conversely, ADD PATH  ... you should be able to
release the subchannels without necessarily redefining the EDEVICE and just
dealing with the paths.

On Thu, Jun 4, 2015 at 2:13 PM, Scott Rohling scott.rohl...@gmail.com
wrote:

 Use SET EDEV commands to delete all the paths defined over the FCP
 subchannels... Then use SET EDEV to define them all back when done..
 A simple EXEC to do one or the other or both will save your fingers if you
 need to do this more then once.

 Scott Rohling

 On Thu, Jun 4, 2015 at 2:07 PM, kwg kw...@yahoo.co.uk wrote:

 There is no zoning. These are all development systems used only by the
 z/vm and its linux guests. It was a machine upgrade rather than a new
 machine and the NPIVs for the z/vm systems were preserved. I did check them
 and I will check again but all the linux systems did start ok initially.
 The physical WWPNs may have changed, especially if they are associated with
 the ficon cards, which were permitted during the upgrade.

 Btw can anyone tell me how I can stop the EDEV devices so that I can vary
 the Chris's offline without shutting down z/VM (which has some z/os guests).

 Keith




  On 4 Jun 2015, at 21:30, David Kreuter dkreu...@vm-resources.com
 wrote:
 
  Hi Keith: Check the zoning and the NPIVs. The NPIVs presented to SVC
  from the BC12 could have changed.
  David Kreuter
 
 
   Original Message 
  Subject: Problems with SCSI-over-FCP after machine upgrade
  From: Keith Gooding kw...@yahoo.co.uk
  Date: Thu, June 04, 2015 4:21 pm
  To: LINUX-390@VM.MARIST.EDU
 
  This may not be the proper forum but maybe someone can help.
  We have a small number of linux systems (32) under z/VM 6.3 which use
  SCSI connections to LUNs on a SAN Volume Controller via a couple of IBM
  SAN24B switches (the equivalent of Brocade 300). There are also some
  systems which use EDEVs on the same SVC. This had worked on z10 BC for
  about 5 years without problems.
  Last week the z10 was upgraded to a zBC12, retaining the same FICON
  cards (4Gbs), but not necessarily associated with the same CHPIDs. Since
  then a number of the LUN connections have been 'lost', cauing linux
  systems to fail. SCSIDISC displays eg HCPRXS975I Virtual FCP device
  1A05 ignored because the adapter was not able to connect to the fibre
  channel network. It is then not possible to rebot the linux system.
 
  Restarting 'everything' - ie SVC nodes, SAN switches, CHIPD vary off/on
  -  cleared the problem for a while.
  Any ideas where to start looking ?. I have discovered that we have  32
  FCP subchannels defined on the CHPID (but highest used unit address is
  1f, and there are only about a dozen in use). Also the switch has not
  been 'qualified' for use on z12 (but it appears that it was not
  qualified for z10 either).
  Any advice greatly appreciated !
 
 
  --
  For LINUX-390 subscribe / signoff / archive access instructions,
  send email to lists...@vm.marist.edu with the message: INFO LINUX-390
 or
  visit
  http://www.marist.edu/htbin/wlvindex?LINUX-390
  --
  For more information on Linux on System z, visit
  http://wiki.linuxvm.org/
 
  --
  For LINUX-390 subscribe / signoff / archive access instructions,
  send email to lists...@vm.marist.edu with the message: INFO LINUX-390
 or visit
  http://www.marist.edu/htbin/wlvindex?LINUX-390
  --
  For more information on Linux on System z, visit
  http://wiki.linuxvm.org/

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Problems with SCSI-over-FCP after machine upgrade

2015-06-04 Thread David Kreuter
Hi Keith: Check the zoning and the NPIVs. The NPIVs presented to SVC
from the BC12 could have changed.
David Kreuter


 Original Message 
Subject: Problems with SCSI-over-FCP after machine upgrade
From: Keith Gooding kw...@yahoo.co.uk
Date: Thu, June 04, 2015 4:21 pm
To: LINUX-390@VM.MARIST.EDU

This may not be the proper forum but maybe someone can help.
 We have a small number of linux systems (32) under z/VM 6.3 which use
SCSI connections to LUNs on a SAN Volume Controller via a couple of IBM
SAN24B switches (the equivalent of Brocade 300). There are also some
systems which use EDEVs on the same SVC. This had worked on z10 BC for
about 5 years without problems.
 Last week the z10 was upgraded to a zBC12, retaining the same FICON
cards (4Gbs), but not necessarily associated with the same CHPIDs. Since
then a number of the LUN connections have been 'lost', cauing linux
systems to fail. SCSIDISC displays eg HCPRXS975I Virtual FCP device
1A05 ignored because the adapter was not able to connect to the fibre
channel network. It is then not possible to rebot the linux system.

Restarting 'everything' - ie SVC nodes, SAN switches, CHIPD vary off/on
-  cleared the problem for a while.
Any ideas where to start looking ?. I have discovered that we have  32
FCP subchannels defined on the CHPID (but highest used unit address is
1f, and there are only about a dozen in use). Also the switch has not
been 'qualified' for use on z12 (but it appears that it was not
qualified for z10 either).
Any advice greatly appreciated !
 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: LINUX-390 Digest - 2 Jun 2015 to 3 Jun 2015 (#2015-104)

2015-06-04 Thread Rick Troth
On 06/04/2015 11:33 AM, Bonnie C Barthel wrote:
 am I supposed to be able to read this?  thanks, Bonnie

You set your subscription to digest mode for the LINUX-390 email list.

The list is handled by LISTSERV which can send you a summary. In the
summary you got last night, there were 9 messages and 2 topics. SOME of
the messages were sent in Base 64 format. _NO, you cannot read that.
Your complain is perfectly reasonable. _

I NEVER use digest mode because it is (for me) difficult to read. Some
people find that it helps them handle the volume of email traffic which
they get from the list. (I use other ways to cut down on that volume.)

YOU MIGHT get a better view of the conversations using the web interface
...

http://www2.marist.edu/htbin/wlvindex?LINUX-390


Hopefully this info helps.

-- Rick; 




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: LINUX-390 Digest - 2 Jun 2015 to 3 Jun 2015 (#2015-104)

2015-06-04 Thread Bonnie C Barthel
am I supposed to be able to read this?  thanks, Bonnie

Bonnie Barthel | z/OS Support |  IBM Strategic Outsourcing Delivery |
720.396.6755 |  pager: cobon...@vtext.com



From:   LINUX-390 automatic digest system lists...@vm.marist.edu
To: LINUX-390@VM.MARIST.EDU
Date:   06/03/2015 10:07 PM
Subject:LINUX-390 Digest - 2 Jun 2015 to 3 Jun 2015 (#2015-104)
Sent by:Linux on 390 Port LINUX-390@VM.MARIST.EDU



There are 9 messages totalling 516 lines in this issue.

Topics of the day:

  1. MMIO (5)
  2. RHEL Install zvm (4)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--

Date:Wed, 3 Jun 2015 18:06:42 +
From:Neale Ferguson ne...@sinenomine.net
Subject: MMIO

TG9va2luZyBhdCB0aGUgbGF0ZXN0IGRldmVsb3BlciB3b3JrcyBkcm9wIGZyb20gdGhlIEJvZWJs
aW5nZW4gZm9sa3MgSSBzZWUNCnRoaXMgbGluZSBpdGVtOg0KDQpPbiB6IFN5c3RlbXMsIGFjY2Vz
cyB0byBNTUlPIG1lbW9yeSByZXF1aXJlcyBwcml2aWxlZ2VkIGluc3RydWN0aW9ucy4gVGhpcw0K
cHJldmVudHMgYXBwbGljYXRpb25zIHRvIHVzZSBhcmJpdHJhcnkgbWVtb3J5IGFjY2VzcyBpbnN0
cnVjdGlvbnMgdG8gdXNlDQpNTUlPIGFzIG9uIG90aGVyIHBsYXRmb3Jtcy4gSW5zdGVhZCwgdGhp
cyBmZWF0dXJlIGludHJvZHVjZXMgdHdvIG5ldw0Kc3lzdGVtIGNhbGxzLCBzMzkwX3BjaV9tbWlv
X3JlYWQgYW5kIHMzOTBfcGNpX21taW9fd3JpdGUsIGFsbG93aW5nIE1NSU8NCmFjY2VzcyB0aHJv
dWdoIHRoZSB1c2Ugb2YgcHJpdmlsZWdlZCBpbnN0cnVjdGlvbnMgaW4gdGhlIGtlcm5lbC4NCkFw
cGxpY2F0aW9ucyB1c2luZyBNTUlPIG5lZWQgdG8gYmUgYWRhcHRlZCB0byBpbnZva2UgdGhlc2Ug
c3lzdGVtIGNhbGxzIHRvDQppbml0aWF0ZSBNTUlPIG9wZXJhdGlvbnMuDQoNCg0KRG9lcyB6QXJj
aGl0ZWN0dXJlIHN0aWxsIGhhdmUgc2VtaS1wcml2aWxlZ2VkIGluc3RydWN0aW9ucyAoSSB0aGlu
aw0KU1NLL0lTSyB3ZXJlIHN1Y2ggYmVhc3RzKT8gVGhlc2Ugd2VyZSBjb250cm9sbGVkIHZpYSBh
IGNvbnRyb2wgcmVnaXN0ZXINCndoaWNoIG1hZGUgdGhlIGluc3RydWN0aW9uIHVzYWJsZSBmcm9t
IHVzZXJsYW5kLiBJIHRob3VnaHQgdGhpcyBtaWdodCBiZSBhDQpiZXR0ZXIgb3B0aW9uIHRoYW4g
YW5vdGhlciBzeXNjYWxsIGFzIHRoZSBsYXN0IHNlbnRlbmNlIG1lYW5zIGFuIGFwcCBvbg0KeDg2
IHdpbGwgcmVxdWlyZSBtb3JlIHRoYW4ganVzdCByZWNvbXBpbGluZyB3aGVuIHBvcnRpbmcgdG8g
czM5MHguDQpIb3dldmVyLCBnaXZlbiB0aGF0IHotTU1JTyB1c2VzIHNwZWNpYWwgaW5zdHJ1Y3Rp
b25zIHRoYXQgcHJvYmFibHkgZG8gbm90DQpoYXZlIGFuYWxvZ3MgaW4gdGhlIG5vbi16IHdvcmxk
IHRoZSBwb2ludCBpcyBwcm9iYWJseSBtb290LiBBcmUgdGhlc2UNCmluc3RydWN0aW9ucyBkb2N1
bWVudGVkIG9yIGFyZSB0aGV5IGxlc3MgdGhhbiBvcGVuIChsaWtlIFNJR0EsIFNFUlZDLCBhbmQN
CmNvdXBsaW5nIGluc3RydWN0aW9ucyk/IA0KDQo=

--

Date:Wed, 3 Jun 2015 14:39:13 -0400
From:Dazzo, Matt mda...@pch.com
Subject: Re: RHEL Install zvm

SSBhbSBmb2xsb3dpbmcgdGhlIFZpcnQgQ29vayBib29rIGFuZCBoYXZpbmcgcHJvYmxlbXMgYXQg
c2VjdGlvbiA3LjguMiAnRm9ybWF0IHRoZSBMTlhNQUlOVCBNaW5pZGlza3MnLiANCg0KSSBhZGRl
ZCBMTlhNQUlOVCB0byB1c2VyIGRpcmVjdCANClVTRVIgTE5YTUFJTlQgTE5YTUFJTlQgNTEyTSA1
MTJNIEJFRyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogSU5D
TFVERSBUQ1BDTVNVICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIA0KIExJTksgVENQTUFJTlQgNTkyIDU5MiBSUiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiBNRElTSyAxOTEg
MzM5MCAwMDAxIDAwMjAgTE4yQzE3IE1SIFJFQUQgV1JJVEUgTVVMVElQTEUgICAgICAgICAgICAg
ICAgICAgICAgICAgDQogTURJU0sgMTkyIDMzOTAgMDAyMSAwOTgwIExOMkMxNyBNUiBSRUFEIFdS
SVRFIE1VTFRJUExFICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQpBY3RpdmF0ZSB0aGUgbmV3
IHVzZXIgZGlyZWN0DQoNClNpZ24gb250byBMTlhNQUlOVCB0aGVuIGhhdmluZyBwcm9ibGVtcyB3
aXRoIHRoZSBmb3JtYXQgcHJvY2Vzcy4gSSBkbyAoYXR0IHh4eCAqIDE5MSkgU3RhcnQgdGhlIGZv
cm1hdCwgdGhlIGZvcm1hdCBwcm9jZXNzIGZvcm1hdHMgdGhlIGVudGlyZSBkaXNrIG5vdCBqdXN0
IHRoZSBmaXJzdCAyMCBjeWwgb2YgMTkxLg0KDQpJcyB0aGlzIGJlY2F1c2Ugb2YgdGhlIHdheSBJ
IGFtIGRvaW5nIHRoZSBhdHRhY2g/IE9yIHNvbWV0aGluZz8NCg0KTE9HT04gTE5YTUFJTlQgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KSENQTE5NMTA4
RSBMTlhNQUlOVCAwMTkxIG5vdCBsaW5rZWQ7IHZvbGlkIExONDRBOSBub3QgbW91bnRlZCAgIA0K
SENQTE5NMTA4RSBMTlhNQUlOVCAwMTkyIG5vdCBsaW5rZWQ7IHZvbGlkIExONDRBOSBub3QgbW91
bnRlZCAgIA0Kei9WTSBWZXJzaW9uIDYgUmVsZWFzZSAzLjAsIFNlcnZpY2UgTGV2ZWwgMTUwMSAo
NjQtYml0KSwgICAgICAgIA0KYnVpbHQgb24gSUJNIFZpcnR1YWxpemF0aW9uIFRlY2hub2xvZ3kg
ICAgICAgICAgICAgICAgICAgICAgICAgIA0KVGhlcmUgaXMgbm8gbG9nbXNnIGRhdGEgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KRklMRVM6ICAgTk8gUkRSLCAgIE5P
IFBSVCwgICBOTyBQVU4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KTE9HT04gQVQgMTQ6
Mjk6NTggRURUIFdFRE5FU0RBWSAwNi8wMy8xNSAgICAgICAgICAgICAgICAgICAgICAgIA0Kei9W
TSBWNi4zLjAgICAgMjAxNS0wNi0wMSAxMjo0MSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIA0KRE1TQUNQMTEzUyBBKDE5MSkgbm90IGF0dGFjaGVkIG9yIGludmFsaWQg

Re: RHEL Install zvm

2015-06-04 Thread Dazzo, Matt
Pete, thank you. Got it. 

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Peter 
Webb, Toronto Transit Commission
Sent: Wednesday, June 03, 2015 3:36 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: RHEL Install zvm

Hi Matt,

You need to run a CP  QUERY DASD LN44A9 command on a class A user. If the 
volume does not exist, that is your problem. If it exists, but if it is not 
attached to SYSTEM, it is not available for minidisk use. (ATTACH  SYSTEM 
LN44A9)

Peter

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Dazzo, 
Matt
Sent: June 3, 2015 3:29 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: RHEL Install zvm

Here is the actual user direct, I pasted an old one into the email. I get the 
messages 191, 192 not linked and DMSACP113S A(191) not attached or invalid 
device address. Thanks Matt

USER LNXMAINT LNXMAINT 512M 512M BEG
 INCLUDE TCPCMSU
 LINK TCPMAINT 592 592 RR   
 MDISK 191 3390 0001 0020 LN44A9 MR READ WRITE MULTIPLE  MDISK 192 3390 0021 
1500 LN44A9 MR READ WRITE MULTIPLE

LOGON LNXMAINT
HCPLNM108E LNXMAINT 0191 not linked; volid LN44A9 not mounted 
HCPLNM108E LNXMAINT 0192 not linked; volid LN44A9 not mounted 
z/VM Version 6 Release 3.0, Service Level 1501 (64-bit),  
built on IBM Virtualization Technology
There is no logmsg data   
FILES:   NO RDR,   NO PRT,   NO PUN   
LOGON AT 15:28:11 EDT WEDNESDAY 06/03/15  
z/VM V6.3.02015-06-01 12:41   
  
DMSACP113S A(191) not attached or invalid device address  
Ready; T=0.01/0.01 15:29:07   

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale 
Ferguson
Sent: Wednesday, June 03, 2015 2:56 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: RHEL Install zvm



On 6/3/15, 2:39 PM, Dazzo, Matt mda...@pch.com wrote:

MDISK 191 3390 0001 0020 LN2C17 MR READ WRITE MULTIPLE

 MDISK 192 3390 0021 0980 LN2C17 MR READ WRITE MULTIPLE
  

Activate the new user direct

LOGON LNXMAINT
HCPLNM108E LNXMAINT 0191 not linked; volid LN44A9 not mounted 
HCPLNM108E LNXMAINT 0192 not linked; volid LN44A9 not mounted
Strange that your directory entry specifies volume LN2C17 but LNXMAINT is 
looking for volume LN44A9. Because it cannot find that volid, it cannot give 
you a 191 or 192 minidisk.


 I do (att xxx * 191) Start the format, the format process formats the 
entire disk not just the first 20 cyl of 191.


What are you attaching as 191 and why? The MDISK statements mean that when you 
logon to LNXMAINT it will (should) have a 191 and 192 disk there for you to 
format. However, the mismatch in VOLIDs is puzzling. On MAINT, what does #CP Q 
DA LN44A9 and #CP Q DA LN2C17 report?

Neale



The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material.  Any 
review retransmission dissemination or other use of or taking any action in 
reliance upon this information by persons or entities other than the intended 
recipient or delegate is strictly prohibited.  If you received this in error 
please contact the sender and delete the material from any computer.  The 
integrity and security of this message cannot be guaranteed on the Internet.  
The sender accepts no liability for the content of this e-mail or for the 
consequences of any actions taken on the basis of information provided.  The 
recipient should check this e-mail and any attachments for the presence of 
viruses.  The sender accepts no liability for any damage caused by any virus 
transmitted by this e-mail.  This disclaimer is property of the TTC and must 
not be altered or circumvented in any manner.


Problems with SCSI-over-FCP after machine upgrade

2015-06-04 Thread Keith Gooding
This may not be the proper forum but maybe someone can help.
 We have a small number of linux systems (32) under z/VM 6.3 which use SCSI 
connections to LUNs on a SAN Volume Controller via a couple of IBM SAN24B 
switches (the equivalent of Brocade 300). There are also some systems which use 
EDEVs on the same SVC. This had worked on z10 BC for about 5 years without 
problems.
 Last week the z10 was upgraded to a zBC12, retaining the same FICON cards 
(4Gbs), but not necessarily associated with the same CHPIDs. Since then a 
number of the LUN connections have been 'lost', cauing linux systems to fail. 
SCSIDISC displays eg HCPRXS975I Virtual FCP device 1A05 ignored because the 
adapter was not able to connect to the fibre channel network. It is then not 
possible to rebot the linux system.

Restarting 'everything' - ie SVC nodes, SAN switches, CHIPD vary off/on -  
cleared the problem for a while.
Any ideas where to start looking ?. I have discovered that we have  32 FCP 
subchannels defined on the CHPID (but highest used unit address is 1f, and 
there are only about a dozen in use). Also the switch has not been 'qualified' 
for use on z12 (but it appears that it was not qualified for z10 either).
Any advice greatly appreciated !
 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


semi-privileged mode

2015-06-04 Thread David Boyes
 (recall the initial UNIX model had ri= ngs of privileges or was that just 
 Dante and the Seven levels of hell?)

No, that was MULTICS. UNIX V6 and earlier always only had 1 privilege flag 
(superuser/general user) due to hardware I/D protection limitations on early 
model PDPs (pre-11), and we're still stuck with it decades later. The CTSS 
(later DEC's) PL/1 compiler also still sucks, lo these many years later -- I 
blame much of Unix on that fact. 

Now, MULTICS -- *that* had granular privileges; record level access control in 
some cases. I have an emulated Honeywell 680 system with a bootable Multics 
cloned from dockmaster.af.mil's boot packs (one of the last two production 
Multics systems -- the other one was at Credit Suisse, I think) years ago if 
you want to try it out. 

Still has the cryptic hodie natus frater est comment in the disk formatter 
code. 8-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: semi-privileged mode

2015-06-04 Thread Rick Troth
On 06/04/2015 08:42 AM, David Boyes wrote:
  (recall the initial UNIX model had ri= ngs of privileges or was that just 
  Dante and the Seven levels of hell?)
 No, that was MULTICS. UNIX V6 and earlier always only had 1 privilege flag 
 (superuser/general user) due to hardware I/D protection limitations on early 
 model PDPs (pre-11), and we're still stuck with it decades later. The CTSS 
 (later DEC's) PL/1 compiler also still sucks, lo these many years later -- I 
 blame much of Unix on that fact.

There are definitely two camps.

Whether you blame the limited original hardware or bless the simplicity
of the design, many people value the binary model. Witness what we do
with VM: You get alphabet soup, meaning you're a trusted VM admin, all
CP privilege classes. Same thing was common practice in the DEC VMS world.

On balance, many people want granular controls, division of labor.
Witness the advent of SELinux (and SEVMS before it, as if VMS didn't
already have excess granularity).

 Now, MULTICS -- *that* had granular privileges; record level access control 
 in some cases.   ...

The inspiration for things which followed. Unix forked one direction and
VMS forked the other. Maybe.

-- R; 




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/