Terry,
To solve the problem of having to grant two accesses for each guest, I have
defined RACF groups that have the double access and connect the Linux guests
to the RACF groups. As a bonus, a RAC LU userid also shows the vlans the
guests is authorised to... and a RAC LG VLN# shows the
Alan,
Can you tell me where you have the Best Practices document?
Thank You,
Terry Martin
Lockheed Martin
CMS - CITIC
3300 Lord Baltimore Drive, Suite 200, 21244
Engineering Computing
Mainframe Support
Cell - 443 632-4191
-Original Message-
From: The IBM z/VM Operating System
(I'm guessing he uses it to line the bottom of Chuckie's cage g)
Has anyone used the 'rekey' function under z/VM on a TS1120? We have an IBM
3494/VTS/Library with 3592-E05s and z/VM 5.4. The rekey support was added in
z/VM 5.3 but we are unable to get it to work. I am in the process of having our
IBM CE check the microcode level on the drives. Is there a
Hello Steve,
We are using the same under 5.3 . We were told not to change the key
but use the default. Let me know when you get it working.
Ed Martin
Aultman Health Foundation
330-363-5050
Ext 35050
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of
On Tuesday, 04/05/2011 at 10:56 EDT, Steve Mondy
steve.mo...@opensolutions.com wrote:
set tape 704 rekey EKMCERT030911A
HCPSTA9968E Key alias not found: EKMCERT030911A
Ready(09968); T=0.01/0.01 10:38:35
q ta details 704
On Tuesday, 04/05/2011 at 10:46 EDT, Jeff Gribbin jeff.grib...@gmail.com
wrote:
(I'm guessing he uses it to line the bottom of Chuckie's cage g)
I am taking names. Irrelevantly, one notes that it is common in some
parts of the world to discover scorpions in your shoes. Hey, let's be
careful
Alan,
Try again. Did not work, same results.
Steve
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of Alan Altmark
Sent: Tuesday, April 05, 2011 10:15 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Encryption Rekey on TS1120 (3592-E05)
On
Hi Ed,
Did you get it to work with the default? If so, what did you have to do?
Thanks,
Steve
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of Edward M Martin
Sent: Tuesday, April 05, 2011 10:13 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Encryption Rekey on
Steve,
There is a difference between a key LABEL and a key ALIAS. Your console
suggests that the latter is not defined to VM:
set tape 704 rekey EKMCERT030911A
HCPSTA9968E Key alias not found: EKMCERT030911A
The LABEL is what is defined to the key store, and is what shows up in the
output
On Tuesday, 04/05/2011 at 10:37 EDT, Martin, Terry R. (CMS/CTR) (CTR)
terry.mar...@cms.hhs.gov wrote:
Can you tell me where you have the Best Practices document?
Document? What document? That's like asking for the complete list of
Alan's Rules for Networking. This listserver is part of
Erik,
Thanks that did it! It was the forest and the trees issue for me. Key alias is
a label pointing to the key store key label.
Ed,
Here is what I did and I can change the keys back and forth to any combination.
SET KEYALIAS key2011a KEYLABEL ekmcert030911a
SET KEYALIAS key2011b KEYLABEL
On Monday, 04/04/2011 at 10:02 EDT, Richard Troth vmcow...@gmail.com
wrote:
It's good that native Linux is an option, but it's rare
that I would recommend it.
That's just a reflection of the application workload you have encountered.
Lucky, you. :-) There are workloads that consume
On Monday, 04/04/2011 at 08:53 EDT, Martin, Terry R. (CMS/CTR) (CTR)
terry.mar...@cms.hhs.gov wrote:
We are planning for a z196 Enterprise Processor. I was wondering
specifically
about z/Manager. I know this is being touted as the Hub of this new
Enterprise
Processor. I also know that a
On Tuesday, 04/05/2011 at 12:38 EDT, Steve Mondy
steve.mo...@opensolutions.com wrote:
Thanks that did it! It was the forest and the trees issue for me. Key
alias is
a label pointing to the key store key label.
Some days I feel really old. I actually attended Eric's design meetings
where
Alan,
I know how you feel. Maybe we should take the rest of the day off! LOL
Steve
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of Alan Altmark
Sent: Tuesday, April 05, 2011 11:45 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Encryption
Should PIPEDDR work with attached DASD or does it only support MDISKs?
The documentation doesn't seem to say. I get an error with attached DASD
but it works fine with a full pack MDISK of the same DASD volume when
doing a dump/restore over TCPIP.
Using attached DASD will avoid label
PIPEDDR should work fine with attached DASD. I just tried it on the
latest version and some older levels and they all worked fine with a
3390-3 with both the source disk and target disk attached. I have the
latest Pipelines runtime module, if that makes a difference. PIPEDDR
doesn't really do
On 4/5/2011 at 12:04 PM, Alan Altmark alan_altm...@us.ibm.com wrote:
And if I wrote all my ideas down, no one would ever hire me. ;-)
Even though scorpions are not known in Michigan, I'll refrain from comment
anyway.
Mark Post
The next meeting of the Metropolitan VM and LINUX Users Association is
next Tuesday at the CA Offices - 520 Madison
http://www2.marist.edu/~mvmua/2011apr.html
Please let me know if you plan to attend
thanx
Bill Munson
201-418-7588
President - MVMUA
http://www2.marist.edu/~mvmua/
LVM
Just for clarification, it's opinion, not luck.
In my *opinion*, these cyberdraculae aren't necessarily suitable for Linux.
I said rare.
Linux ... without VM ... rare. Not never, just rare. Sheesh!
These absolutists!
-- R;
On Tue, Apr 5, 2011 at 12:42, Alan Altmark
On Tue, 5 Apr 2011 13:55:57 -0400, Bruce Hayden bjhay...@gmail.com wrot
e:
PIPEDDR should work fine with attached DASD. I just tried it on the
latest version and some older levels and they all worked fine with a
3390-3 with both the source disk and target disk attached. I have the
latest
On Tue, Apr 5, 2011 at 10:07 PM, Brian Nielsen bniel...@sco.idaho.gov wrote:
PIPTCQ1015E ERRNO 54: ECONNRESET.
PIPMSG004I ... Issued from stage 3 of pipeline 3 name iprestore.
PIPMSG001I ... Running tcpdata.
PIPUPK072E Last record not complete.
PIPMSG003I ... Issued from stage 2 of pipeline
Thanks Alan. I have been doing a lot of reading on this already I was looking
for some real world experiences to back up what I am reading.
Thank You,
Terry Martin
Lockheed Martin
CMS - CITIC
3300 Lord Baltimore Drive, Suite 200, 21244
Engineering Computing
Mainframe Support
Cell - 443
Additional note: After this failed transfer the receiving DASD has a
label of SCRTCH. I would expect it to be SYSDRL after cyl 0 is transfere
d.
det 6607
DASD 6607 DETACHED
Ready; T=0.01/0.01 14:15:13
q 6607
DASD 6607 SCRTCH
Ready; T=0.01/0.01 14:15:15
Brian Nielsen
On Tue, 5 Apr 2011
On Tue, 5 Apr 2011 22:15:31 +0200, Rob van der Heij rvdh...@gmail.com
wrote:
On Tue, Apr 5, 2011 at 10:07 PM, Brian Nielsen bniel...@sco.idaho.gov
wrote:
PIPTCQ1015E ERRNO 54: ECONNRESET.
PIPMSG004I ... Issued from stage 3 of pipeline 3 name iprestore.
PIPMSG001I ... Running tcpdata.
I don't know why the mdisk works and the attached disk doesn't. If
the label is still SCRTCH, then nothing was written on the disk.
That seems like the TCP/IP connection wasn't established correctly.
We should take this offline to work on it further.
On Tue, Apr 5, 2011 at 4:27 PM, Brian Nielsen
I could have sworn I had seen something about this in a presentation
regarding best practices for configuring z/OS z/VM LPAR's that share
the same DASD subsystems but now that I need it, no joy.
We have 2 (z10) CEC's, each with z/VM and z/OS LPAR's attached via FICON
Directors to a pair of
Registration is open for this Wed. April 20 System z user group:
Bay Area System z programmers for z/OS, z/VM and Linux on System z
PDF: http://www.vm.ibm.com/events/zsf0411.pdf
To: Bay Area Systems Programmers for z/OS, z/VM and Linux on System z
Are you interested in getting together
You're hitting the nail on the head.. 'best practice' is to dedicate the
DASD to each LPAR in the IODEF.. but this is best practice when security or
data integrity demands 'physical' separation. It keeps you from shooting
yourself in the foot and makes it impossible for an LPAR to effect
Having been in the same situation, my advice is that it is better to be safe
than sorry. We had one individual who, on more than one occasion, formatted MVS
volumes for use by TPF test systems. Needles to say, the MVS folks were not
happy. I took the power away from him on two fronts when I was
I think you can say best practice is on a need to know basis. This is
especially important for some industries :) You really can't say you have a
security system in place if something else can get there without it going
through that security system.
Does z/OS *need* to access your disk?
On 4/5/2011 18:43, Karl Huf wrote:
I could have sworn I had seen something about this in a presentation
regarding best practices for configuring z/OS z/VM LPAR's that share
the same DASD subsystems but now that I need it, no joy.
We have 2 (z10) CEC's, each with z/VM and z/OS LPAR's attached
33 matches
Mail list logo
