Re: Strange RACF Issue
Alan Altmark [EMAIL PROTECTED] :- z/OS 1.4 was pre-dynamic templates. z/OS 1.7 is post-dynamic templates. You need to talk to the (z/OS RACF) support center about the reports you ran and exactly what they reported. (And I presume you upgraded the templates as part of the RACF FL530 installation.) Yes, the z/OS people are following this up with the support center but I was trying to understand what sequence of events could have lead to this. Yes, the template upgrade as part of the RACFVM FL530 installation did take place successfully (before RACFVM FL530 was used on the database). Colin Allinson IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: VSWITCH bug ?
Marcy Cortes [EMAIL PROTECTED] wrote: I'll never forget it again like I've done before because I have this nifty z/VM 5.3 feature in my directory entries: COMMAND SET VSWITCH TD6VSW1 GRANT USERID I believe the devices get created BEFORE the command occurs. So the NICDEF happens, does NOT get COUPLEd because the GRANT has not occurred, then the GRANT happens. Try adding an explicit COUPLE *after* the GRANT. This is me guessing, but it would make sense... ...apologies if this is old news; I get the list DIGESTed (burp). ...phsiii
Re: VSWITCH bug ?
On Friday, 12/07/2007 at 03:55 EST, Rob van der Heij [EMAIL PROTECTED] wrote: On Dec 7, 2007 3:36 AM, Marcy Cortes [EMAIL PROTECTED] wrote: I'll never forget it again like I've done before because I have this nifty z/VM 5.3 feature in my directory entries: COMMAND SET VSWITCH TD6VSW1 GRANT USERID Haha. :-) Now you did it. I cannot get this picture out of my mind anymore: a crowd standing near Chuckie's cubicle calling get rid of silly double authentication schemes that don't do anything What double authentication? I see exactly one *authorization*: SET VSWITCH GRANT. A VSWITCH has the RESTRICTED attribute and that means there's an access list. I know I've said it before, but if you want a more flexibile authorization scheme on your system than that provided by CP, use an ESM. If you use an ESM you can give unrestricted access to the VSWITCH. Layer zoning on top of that, if you like. It is my philosophy that directory entries are *desired* configurations. If authorization has not been given to achieve that, so be it. If the person setting up the directory entry also has authority to confer authority upon others, that works, too (e.g. the COMMAND SET above). That CP has been inconsistent in that behavior over the years isn't a particularly good reason (IMO) to continue it. If someone wants to submit a requirement for an UNRESTRICTED VSWITCH, we'll consider it. Alan Altmark z/VM Development IBM Endicott
Re: Tues, Dec 4 - Linux on System z Security - Live Virtual Class
Pamela Christina in cold and snowY Endicott wrote: Now, my question for youwhat other topics for z/VM, z/VSE, and Linux on System z you like to hear in the LVC format? It's ok to suggest topics that you don't often hear at SHARE or at the z Tech conferences, and special interest areas. Feel free to append or to send to me offline. What happened to Alan Altmark's z/VM security talk that was to be rescheduled? Kim -- Kim Goldenberg Systems Programmer I State of NJ - OIT 609-777-3722 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: VSWITCH bug ?
On Dec 7, 2007 12:44 PM, Michael MacIsaac [EMAIL PROTECTED] wrote: silly double authentication schemes that don't do anything But Rob implies this *doesn't* work? Try adding an explicit COUPLE *after* the GRANT. And Phil implies it *can* work? Now I'm confused. It was the other way around, but we work for the same boss so that's ok... ;-) Phil pointed out why this does not work. Since the COUPLE is implied by defining the virtual NIC, it requires the GRANT to be done first. As Phil suggests, when you put another COUPLE after the GRANT in the directory, it should work... When I responded, I had overlooked that... Many of us feel that authorisation through the CP directory should be enough, and should not require an additional GRANT (because those permissions are handed out by the same people). Unfortunately Alan decided otherdumb since he used the wrong analogy. For a moment I thought putting the GRANT in the directory entry was a very interesting way to protest against this silly design, but having to put the COUPLE there too makes it not very elegant, to say the least. -Rob
Re: SAN and Linux on zSeries
We have migrated a number of guests from ECKD to SAN. The O/S is still on ECKD and will remain there for the foreseeable future. We've been giving each SAN participant its own pair of FCP adapters. (Two, because our SAN guys have architected for dual path access. But I know of one site which uses four paths instead.) This makes each guest look more like a stand-alone server. To isolate them from each other, we then use N-port ID Virtualization. Thanks to the folks who helped us get all this working! It is quite reliable and performs well. The direct connection presents a whole new administration game, so be prepared! It would be better to give the SAN volumes directly to VM (that is, EDEV) and let VM slice things up into minidisks (or even full-pack or near-full-pack). There was a performance issue with EDEV because it naturally introduces more overhead, so we did not go there at first. IBM has addressed that in DIAG 250. (We have not yet revisitted the Linux driver which would use it. Planning to ... RSN!) Another question about EDEV is whether or not you can share volumes across LPARs. Might require NPIV. With ECKD and traditional IBM I/O fabric sharing works as we all know and love it. I don't know how well a SAN fabric supports that. We would need it. Handing each guest its own HBA (host bus adapter, the open systems term for and FCP adapter) kind of blows one of the reasons to go virtual. By comparison, when VMware plays the SAN game, it does something akin to EDEV and does not (to my knowledge) even offer the ability for a guest to connect directly into SAN space. z/VM can go either way, direct or pooled. -- R;
Re: SAN and Linux on zSeries
On Friday, 12/07/2007 at 06:16 EST, Rick Troth [EMAIL PROTECTED] wrote: Handing each guest its own HBA (host bus adapter, the open systems term for and FCP adapter) kind of blows one of the reasons to go virtual. Eh? 480 servers can use a single FCP adapter (chpid) concurrently. That's the whole point of N_port ID virtualization: 480 separate fabric endpoints. Alan Altmark z/VM Development IBM Endicott
Re: Tues, Dec 4 - Linux on System z Security - Live Virtual Class
On Friday, 12/07/2007 at 11:00 EST, Kim Goldenberg [EMAIL PROTECTED] wrote: What happened to Alan Altmark's z/VM security talk that was to be rescheduled? I would like to do it in January. Unfortunately I am being held hostage by Chuckie right now in a secure, undisclosed location. I long to see the sun again. Alan Altmark z/VM Development IBM Endicott
Re: VSWITCH bug ?
On Dec 7, 2007 3:36 AM, Marcy Cortes [EMAIL PROTECTED] wrote: I'll never forget it again like I've done before because I have this nifty z/VM 5.3 feature in my directory entries: COMMAND SET VSWITCH TD6VSW1 GRANT USERID Haha. :-) Now you did it. I cannot get this picture out of my mind anymore: a crowd standing near Chuckie's cubicle calling get rid of silly double authentication schemes that don't do anything -Rob
Re: VSWITCH bug ?
On Friday, 12/07/2007 at 12:19 EST, Rob van der Heij [EMAIL PROTECTED] wrote: Consistency in treating every animal as if it were a pony may be simple, but still not a good idea. When the resource is owned by another user, then it is appropriate that the other user can control access (so the ESM is involved even when the LINK comes out of the directory entry). With DIRMAINT the LINK statement could even be done by the requester himself. Or the owner may want to change his mind and revoke access at some point in time. MDISK statements are done by system staff and don't need that treatment (and I don't know why RACF even provides that control other than maybe for completeness of auditing). You can create a userid that holds minidisks to be linked by other users. While revoking the user is probably a better approach, you can simply deny the user access to the minidisks it holds. That's something that requires an ESM. But VSWITCH is a system owned thing. It is sysprog involved in getting the NIC entries in the directory already. You should not require the sysprog to put on his other hat and issue the GRANT to make this work (and whoever came up with the SET GRANT for that should be put in the corner for an hour). I would agree with a requirement for NICDEF to operate like LINK w.r.t. implicit authorization when an ESM is not present. (But I'm just one of the people you have to convince!) Get those requirements in! Alan Altmark z/VM Development IBM Endicott
Re: REquest for IOCP for DS6800 FICON Z890
Hello Raymond, Physically, yes it would but (I keep asking to ensure that I get the question right), Would the below generate one Control Block in VM that would become a bottle neck, Where if you have 4 control units defined, would the system know that one is being used And then use the other to pass the I/O (commands and the like)? I am sure that this may not be problem until we hit something like 3000 i/o (per the manuals) But it would seem that having a control block busy (enqueued for any reason) would case other code to Be activated. Some DASD manufactures will tell you that placement of files do not matter, it does still matter if you want the best response time you can get. We are pushing the 6 ESCON channels at 5-10% most of the time, but I have seen them jump to 30%. I intend to keep the FICON channels at under 5%. Ed Martin 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Noal Sent: Thursday, December 06, 2007 7:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: REquest for IOCP for DS6800 FICON Z890 Kevin, Edward, Would not - CU0130 CNTLUNIT CUNUMBR=0130,PATH=(30,31,40,41),CUADD=01, X UNITADD=((00,256)),UNIT=2105 DV800IODEVICE ADDRESS=(0800,256),CUNUMBR=(0130), X UNIT=3390 give you the same results?? HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Thursday, December 06, 2007 2:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: REquest for IOCP for DS6800 FICON Z890 Hello Kevin, Thanks that is what I was looking for. I have this right now. * CU0130 CNTLUNIT CUNUMBR=0130,PATH=(30),CUADD=01, X UNITADD=((00,256)),UNIT=2105 CU0140 CNTLUNIT CUNUMBR=0140,PATH=(40),CUADD=01, X UNITADD=((00,256)),UNIT=2105 CU0131 CNTLUNIT CUNUMBR=0131,PATH=(31),CUADD=01, X UNITADD=((00,256)),UNIT=2105 CU0141 CNTLUNIT CUNUMBR=0141,PATH=(41),CUADD=01, X UNITADD=((00,256)),UNIT=2105 CU0230 CNTLUNIT CUNUMBR=0230,PATH=(30),CUADD=02, X UNITADD=((00,256)),UNIT=2105 CU0240 CNTLUNIT CUNUMBR=0240,PATH=(40),CUADD=02, X UNITADD=((00,256)),UNIT=2105 CU0231 CNTLUNIT CUNUMBR=0231,PATH=(31),CUADD=02, X UNITADD=((00,256)),UNIT=2105 CU0241 CNTLUNIT CUNUMBR=0241,PATH=(41),CUADD=02, X UNITADD=((00,256)),UNIT=2105 DV800IODEVICE ADDRESS=(0800,256),CUNUMBR=(0130,0140,0141,0131),X UNIT=3390 DV900IODEVICE ADDRESS=(0900,256),CUNUMBR=(0241,0231,0230,0240),X UNIT=3390 * Ed Martin 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Neubert, Kevin (DIS) Sent: Thursday, December 06, 2007 4:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: REquest for IOCP for DS6800 FICON Z890 You definitely want and should take advantage of all four channels. Your CHPIDs look okay to me, but consider something like the following for your CNTLUNITs and IODEVICEs CU130CNTLUNIT CUNUMBR=130,PATH=(30), X UNITADD=((00,256)),CUADD=0,UNIT=2105 CU140CNTLUNIT CUNUMBR=140,PATH=(40), X UNITADD=((00,256)),CUADD=0,UNIT=2105 CU131CNTLUNIT CUNUMBR=131,PATH=(31), X UNITADD=((00,256)),CUADD=0,UNIT=2105 CU141CNTLUNIT CUNUMBR=141,PATH=(41), X UNITADD=((00,256)),CUADD=0,UNIT=2105 CUA30CNTLUNIT CUNUMBR=130,PATH=(30), X UNITADD=((00,256)),CUADD=1,UNIT=2105 CUA40CNTLUNIT CUNUMBR=140,PATH=(40), X UNITADD=((00,256)),CUADD=1,UNIT=2105 CUA31CNTLUNIT CUNUMBR=131,PATH=(31), X UNITADD=((00,256)),CUADD=1,UNIT=2105 CUA41CNTLUNIT CUNUMBR=141,PATH=(41), X UNITADD=((00,256)),CUADD=1,UNIT=2105 DV800IODEVICE ADDRESS=(0800,256),CUNUMBR=(130,140,131,141),X UNIT=3390,UNITADD=00 DV900IODEVICE ADDRESS=(0900,256),CUNUMBR=(A30,A40,A31,A41),X UNIT=3390,UNITADD=00 Regards, Kevin From: The IBM z/VM Operating System [mailto:[EMAIL
Re: VCTC vs VSWITCH
On Friday, 12/07/2007 at 12:56 EST, Huegel, Thomas [EMAIL PROTECTED] wrote: VCTCA SNA protocol requires VTAM for POWER PNETTING. Is VTAM more efficient than TCP/IP? Why use SNA at all? Use non-SNA CTCs and define the node to POWER, then specify the vaddr of the VCTC on the PSTART. Alan Altmark z/VM Development IBM Endicott
Re: VCTC vs VSWITCH
If you can work with VCTCA, then that is the way to go. Biggest reason, lower overhead. You are communicating over hardware. With the IP method, you have multiple IP stacks that you have to drive with your 390 processor(s). Tom Duerbusch THD Consulting Law of Cat Sleeping All cats must sleep with people whenever possible, in a position as uncomfortable for the people involved, and as comfortable as possible for the cat Huegel, Thomas [EMAIL PROTECTED] 12/7/2007 11:24 AM I have several VSE under z/VM and PNET files around the VSE's. I was just wondering what others think is the best way to do this. Virtual CTC's or TCP/IP using a VSWITCH. Any opinions? Would my TCP/IP PNETTING ever hit a 'real' wire?
Re: Service of a corrective service doc
yes they do have the same filetype but it is the filename that you put alter the ( filename I believe Edward M. Martin [EMAIL PROTECTED] To com IBMVM@LISTSERV.UARK.EDU Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Service of a corrective service doc 12/07/2007 01:25 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Hello everyone, After I get a Corrective Service PTF up to the 500 disk, I deterse them. The Service envelope has to be a filetype of SERVLINK. Does the correct Service Document Ie S7527127 SHIPDOCS C1 have to be some special filetype? The reason I am asking is that in the Guide to Automated Installation and Service page 175 has d. Run SERVICE against the COR documentation envelope file. This step is only for COR service as the RSU documentation envelope file is a text readable file. service all docenvfndocenvfn is the file name of the documentation envelope vmfupdat sysmemoDisplays the memos that were in the documentation envelope e. Run SERVICE against PTF or RSU envelope. But how does it know to go against the DocEnvfn and not the SERVLINK file? It has to something simple. Ed Martin 330-588-4723 ext 40441 __ This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. To reply to our email administrator directly, send an email to [EMAIL PROTECTED]
Re: VSWITCH bug ?
On Friday, 12/07/2007 at 03:10 EST, Huegel, Thomas [EMAIL PROTECTED] wrote: I haven't really thought this thru, but how about something like this in the VSWITCH start-up or config file an unrestrict parm that could be generic, ie UNRESTRICT VSE* ZOS* then just machines with those prefixes would be unrestricted ??? Restricted and Unrestricted are attributes of the VSWITCH, not the user. If the VSWITCH is unrestricted, then there is no access list and all users can couple to it. If the VSWITCH is restricted, then there is an access list and only those users in the access list can couple to it. Based on what I've read here and input I've received in other venues, I've concluded that, for non-ESM environments, the access list is the set of all users who have a NICDEF (not SPECIAL!) statement in their directory entry that references a particular VSWITCH or Guest LAN, *plus* the users identified on SET VSWITCH GRANT. No additional authorization is required, but they will not show up in QUERY VSWITCH AUTH (since no GRANT issued), nor can the authorization be revoked by command. Uncoupling from the VSWITCH doesn't hurt. If you COUPLE again, it will work (a la LINK). All of the above applies equally to a restricted Guest LAN. Alan Altmark z/VM Development IBM Endicott
Service of a corrective service doc
Hello everyone, After I get a Corrective Service PTF up to the 500 disk, I deterse them. The Service envelope has to be a filetype of SERVLINK. Does the correct Service Document Ie S7527127 SHIPDOCS C1 have to be some special filetype? The reason I am asking is that in the Guide to Automated Installation and Service page 175 has d. Run SERVICE against the COR documentation envelope file. This step is only for COR service as the RSU documentation envelope file is a text readable file. service all docenvfndocenvfn is the file name of the documentation envelope vmfupdat sysmemoDisplays the memos that were in the documentation envelope e. Run SERVICE against PTF or RSU envelope. But how does it know to go against the DocEnvfn and not the SERVLINK file? It has to something simple. Ed Martin 330-588-4723 ext 40441
Re: VSWITCH bug ?
I haven't really thought this thru, but how about something like this in the VSWITCH start-up or config file an unrestrict parm that could be generic, ie UNRESTRICT VSE* ZOS* then just machines with those prefixes would be unrestricted ??? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Alan Altmark Sent: Friday, December 07, 2007 1:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VSWITCH bug ? On Friday, 12/07/2007 at 02:31 EST, Marcy Cortes [EMAIL PROTECTED] wrote: Ding ding! We have a winner! Thanks Phil (yet again). The explicit couple in another COMMAND solved that. (but yeah, in my copious spare time, maybe I'll open a unrestricted vswitch requirement). BTW, an unrestricted VSWITCH would mean anyone could couple to it at any time. If you still want a restricted VSWITCH, but with implicit authorization when specified on NICDEF in the directory (sans ESM), that's a different requirement. Alan Altmark z/VM Development IBM Endicott
Re: SAN and Linux on zSeries
To avoid timeout errors, IBM recommends having no more then 32 servers per an NPIV-mode FCP channel. The 480 servers is ok on non-NPIV FCP. (see Introducing N_Port Identifier Virtualization for IBM System z9 page 4 http://www.redbooks.ibm.com/redpapers/pdfs/redp4125.pdf ) Configuration considerations Some general recommendations for using NPIV include: Do not use more than 32 subchannels per physical channel in NPIV mode. Also, do not perform more than 128 total target logins (for example, in a configuration with 32 subchannels, limit the number of target logins to no more than an average of 4). Using more subchannels, target logins, or both can create timeouts. This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, December 07, 2007 11:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SAN and Linux on zSeries On Friday, 12/07/2007 at 06:16 EST, Rick Troth [EMAIL PROTECTED] wrote: Handing each guest its own HBA (host bus adapter, the open systems term for and FCP adapter) kind of blows one of the reasons to go virtual. Eh? 480 servers can use a single FCP adapter (chpid) concurrently. That's the whole point of N_port ID virtualization: 480 separate fabric endpoints. Alan Altmark z/VM Development IBM Endicott
Re: VSWITCH bug ?
On Dec 7, 2007 5:08 PM, Alan Altmark [EMAIL PROTECTED] wrote: It is my philosophy that directory entries are *desired* configurations. If authorization has not been given to achieve that, so be it. If the person setting up the directory entry also has authority to confer authority upon others, that works, too (e.g. the COMMAND SET above). That CP has been inconsistent in that behavior over the years isn't a particularly good reason (IMO) to continue it. Consistency in treating every animal as if it were a pony may be simple, but still not a good idea. When the resource is owned by another user, then it is appropriate that the other user can control access (so the ESM is involved even when the LINK comes out of the directory entry). With DIRMAINT the LINK statement could even be done by the requester himself. Or the owner may want to change his mind and revoke access at some point in time. MDISK statements are done by system staff and don't need that treatment (and I don't know why RACF even provides that control other than maybe for completeness of auditing). But VSWITCH is a system owned thing. It is sysprog involved in getting the NIC entries in the directory already. You should not require the sysprog to put on his other hat and issue the GRANT to make this work (and whoever came up with the SET GRANT for that should be put in the corner for an hour). -Rob - waiting for the European Union to force Endicott to unbundle this ;-)
Re: FTP
Never mind. I was giving it too much information. By leaving of the high level qualifier of the dsn when I did the cd, it worked as you said. Leaving the hlq on and enclosing the name in single quotes also works. Original note below -- It almost helps. I can send files to MVS, but the result is flat files. For example, the sequence Cd hlq Put fn.ft.fm fn Results in a flat file named hlq.fn. The result is even more interesting if I leave the member name off - the file gets written in USS, not in the pds, not as a flat file on a normal disk. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Lionel B. Dyck Sent: Tuesday, December 04, 2007 3:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP To FTP a file to a member of a PDS do the following: ftp mvs-host enter userid/pw mode b type e cd pds-dsname put cms-file member-name quit
Re: Good Citizenship Opportunity
On Friday, 12/07/2007 at 03:55 EST, Kris Buelens [EMAIL PROTECTED] wrote: When I used Lotus/Notes, I could tell not to use HTML, now with Gmail, I don't know what it looks like. Click on the plain text on the tool bar above the text input window. Alan Altmark z/VM Development IBM Endicott
Re: VCTC vs VSWITCH
On Friday, 12/07/2007 at 12:25 EST, Huegel, Thomas [EMAIL PROTECTED] wrote: I have several VSE under z/VM and PNET files around the VSE's. I was just wondering what others think is the best way to do this. Virtual CTC's or TCP/IP using a VSWITCH. Any opinions? Would my TCP/IP PNETTING ever hit a 'real' wire? I'd just use a Guest LAN (DEFINE LAN) instead of a VSWITCH. Then it is impossible to accidentally connect it to a real wire. But if your VSE environment is already set up and working, leave it alone. Guest LANs and VSWITCHes are great when you have a requirement for external connectivity or you expect to add more guests that need any-to-any connectivity. Alan Altmark z/VM Development IBM Endicott
VCTC vs VSWITCH
I have several VSE under z/VM and PNET files around the VSE's. I was just wondering what others think is the best way to do this. Virtual CTC's or TCP/IP using a VSWITCH. Any opinions? Would my TCP/IP PNETTING ever hit a 'real' wire?
Re: Good Citizenship Opportunity
When I used Lotus/Notes, I could tell not to use HTML, now with Gmail, I don't know what it looks like. 2007/12/7, Jeff Gribbin, EDS [EMAIL PROTECTED] : It's been a while but, if I may, I think it's time to repeat my perennial plea on behalf of those who, like me, have good reasons to access this list in, Plain Daily Digest Mode. When possible, could you PLEASE use Plain Text for your messages and ESPECIALLY PLEASE, when possible, avoid HTML. Daily Digest Mode displays all the HTML source and, currently, the, junk substantially overwhelms the, content when one is reading a digest (I would estimate about 80% junk in every digest received). Secondary to this plea for Plain Text, but also significant; it would als o be appreciated if you could consciously consider whether or not it is strictly necessary to re-send the original message when replying. Sometimes it's obviously of benefit but at other times it's, just more clutter and communication is actually enhanced by the deletion of the original from the reply. As I usually do when it's time for me to make this request, I'd like to emphasise that I'm not trying to discourage anybody from posting - if all you have is HTML, and all your replies are required to contain the original messages, then, please, fire away! However, if you DO have any control over this and are willing to exercise that control, your consideration for others will be appreciated. Regards Jeff -- Kris Buelens, IBM Belgium, VM customer support
Re: VCTC vs VSWITCH
VCTCA SNA protocol requires VTAM for POWER PNETTING. Is VTAM more efficient than TCP/IP? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Tom Duerbusch Sent: Friday, December 07, 2007 11:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VCTC vs VSWITCH If you can work with VCTCA, then that is the way to go. Biggest reason, lower overhead. You are communicating over hardware. With the IP method, you have multiple IP stacks that you have to drive with your 390 processor(s). Tom Duerbusch THD Consulting Law of Cat Sleeping All cats must sleep with people whenever possible, in a position as uncomfortable for the people involved, and as comfortable as possible for the cat Huegel, Thomas [EMAIL PROTECTED] 12/7/2007 11:24 AM I have several VSE under z/VM and PNET files around the VSE's. I was just wondering what others think is the best way to do this. Virtual CTC's or TCP/IP using a VSWITCH. Any opinions? Would my TCP/IP PNETTING ever hit a 'real' wire?
Re: VSWITCH bug ?
Ding ding! We have a winner! Thanks Phil (yet again). The explicit couple in another COMMAND solved that. (but yeah, in my copious spare time, maybe I'll open a unrestricted vswitch requirement). Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Phil Smith III Sent: Friday, December 07, 2007 2:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VSWITCH bug ? Marcy Cortes [EMAIL PROTECTED] wrote: I'll never forget it again like I've done before because I have this nifty z/VM 5.3 feature in my directory entries: COMMAND SET VSWITCH TD6VSW1 GRANT USERID I believe the devices get created BEFORE the command occurs. So the NICDEF happens, does NOT get COUPLEd because the GRANT has not occurred, then the GRANT happens. Try adding an explicit COUPLE *after* the GRANT. This is me guessing, but it would make sense... ...apologies if this is old news; I get the list DIGESTed (burp). ...phsiii
Re: VCTC vs VSWITCH
VTAM can send more data per buffer. And has pacing and vpacing for buffer controls. TCP/IP was made to connect and communicate but not always at a very large rate. Ed Martin 330-588-4723 ext 40441
Re: VSWITCH bug ?
Well, *anyone* is a pretty small crowd. No one gets an VM id except the vm sysprogs and a few who need to look at ESAMON. If I were super-paranoid, we could remove the define nic and/or couple from class g and put them in a privclass that only a linux got. It would be interesting to see those folks *try* to do something with the vswitch nic they defined :) Unless the *anyone* is perhaps someone who has gotten root on a linux... But then, they've already got an interface into the vswitch... So, unrestricted VSWITCH and implicit authorization - I don't care one way or the other. Which requirement would be easier to get through? Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, December 07, 2007 11:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VSWITCH bug ? On Friday, 12/07/2007 at 02:31 EST, Marcy Cortes [EMAIL PROTECTED] wrote: Ding ding! We have a winner! Thanks Phil (yet again). The explicit couple in another COMMAND solved that. (but yeah, in my copious spare time, maybe I'll open a unrestricted vswitch requirement). BTW, an unrestricted VSWITCH would mean anyone could couple to it at any time. If you still want a restricted VSWITCH, but with implicit authorization when specified on NICDEF in the directory (sans ESM), that's a different requirement. Alan Altmark z/VM Development IBM Endicott
