Re: SFS
Alan forgot to mention one restriction: with a DIRC, only one user can get R/W access at a given time. And, the benefit: a DIRC can be placed in a dataspace. As for the trick to update a few files in one atomic operation: you had it almost right, except that COPYFILE has no NOUPDIRT option, but that isn't needed. The use of temp files and the RENAMEs with NOUPDIRT that care of that. With SFS however, RENAME does not honor the NOUPDIRT option. I never tried but you can use the CSL routine DMSFILEC, it has a NOCOMMIT option. At the end of the DMSFILEC calls, you then call DMSCOMM to commit all copy operations (or DMSROLLB if you change your mind). There is also a DMSRENAM CSL routine, (with a NOCOMMIT option) but that is no longer required thanks to DMSFILEC NOCOMMIT. 2011/3/22 Les Koehler > So with FILE CONTROL you can't replace co-dependent files in one atomic > operation, as one would do with the 'copyfile two-step' (love that phrase!)? > > Les > > > Alan Altmark wrote: > >> On Monday, 03/21/2011 at 10:54 EDT, Les Koehler >> wrote: >> >>> Does FILE CONTROL thus have the same exposure to a file being changed >>> >> 'under the >> >>> covers' as a minidisk has, possibly causing an error for the other >>> >> users? >> >>> Is there something similar to the minidisk trick of: >>> >>> copyfile new1 version a pseudo1 name k (noupdir >>> copyfile new2 version a pseudo2 name k (noupdir >>> rename old1 version k save1 version k (noupdir >>> rename old2 version k save2 version k (noupdir >>> rename pseudo1 name k old1 version k (noupdir >>> rename pseudo2 name k old2 version k >>> >>> (hope I got that right!) to avoid impacting other users? >>> >> >> You never get ERROR 3 READING FILE with SFS and you don't use the >> "copyfile twostep" with SFS. You just change the files. If someone >> accesses the directory while you're updating, then they will see changed >> files on for files that are closed when they access it. In that respect, >> DIRCONTROL directories are better than minidisks. >> >> FILECONTROL directories reveal file changes immediately. I.e. you can >> open a file and see one set of content, then close and re-open and see >> something new. But you never see a mix and you never see the file while it >> is open and being written to - you see the old version. And if you erase a >> file in a FILECONTROL directory, all authorizations are lost. >> >> Alan Altmark >> >> z/VM and Linux on System z Consultant >> IBM System Lab Services and Training >> ibm.com/systems/services/labservicesoffice: 607.429.3323 >> mobile; 607.321.7556 >> alan_altm...@us.ibm.com >> IBM Endicott >> >> -- Kris Buelens, IBM Belgium, VM customer support
Re: SFS
So with FILE CONTROL you can't replace co-dependent files in one atomic operation, as one would do with the 'copyfile two-step' (love that phrase!)? Les Alan Altmark wrote: On Monday, 03/21/2011 at 10:54 EDT, Les Koehler wrote: Does FILE CONTROL thus have the same exposure to a file being changed 'under the covers' as a minidisk has, possibly causing an error for the other users? Is there something similar to the minidisk trick of: copyfile new1 version a pseudo1 name k (noupdir copyfile new2 version a pseudo2 name k (noupdir rename old1 version k save1 version k (noupdir rename old2 version k save2 version k (noupdir rename pseudo1 name k old1 version k (noupdir rename pseudo2 name k old2 version k (hope I got that right!) to avoid impacting other users? You never get ERROR 3 READING FILE with SFS and you don't use the "copyfile twostep" with SFS. You just change the files. If someone accesses the directory while you're updating, then they will see changed files on for files that are closed when they access it. In that respect, DIRCONTROL directories are better than minidisks. FILECONTROL directories reveal file changes immediately. I.e. you can open a file and see one set of content, then close and re-open and see something new. But you never see a mix and you never see the file while it is open and being written to - you see the old version. And if you erase a file in a FILECONTROL directory, all authorizations are lost. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: SFS
On Monday, 03/21/2011 at 10:54 EDT, Les Koehler wrote: > Does FILE CONTROL thus have the same exposure to a file being changed 'under the > covers' as a minidisk has, possibly causing an error for the other users? > > Is there something similar to the minidisk trick of: > > copyfile new1 version a pseudo1 name k (noupdir > copyfile new2 version a pseudo2 name k (noupdir > rename old1 version k save1 version k (noupdir > rename old2 version k save2 version k (noupdir > rename pseudo1 name k old1 version k (noupdir > rename pseudo2 name k old2 version k > > (hope I got that right!) to avoid impacting other users? You never get ERROR 3 READING FILE with SFS and you don't use the "copyfile twostep" with SFS. You just change the files. If someone accesses the directory while you're updating, then they will see changed files on for files that are closed when they access it. In that respect, DIRCONTROL directories are better than minidisks. FILECONTROL directories reveal file changes immediately. I.e. you can open a file and see one set of content, then close and re-open and see something new. But you never see a mix and you never see the file while it is open and being written to - you see the old version. And if you erase a file in a FILECONTROL directory, all authorizations are lost. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: SFS
Does FILE CONTROL thus have the same exposure to a file being changed 'under the covers' as a minidisk has, possibly causing an error for the other users? Is there something similar to the minidisk trick of: copyfile new1 version a pseudo1 name k (noupdir copyfile new2 version a pseudo2 name k (noupdir rename old1 version k save1 version k (noupdir rename old2 version k save2 version k (noupdir rename pseudo1 name k old1 version k (noupdir rename pseudo2 name k old2 version k (hope I got that right!) to avoid impacting other users? Les Alan Altmark wrote: On Monday, 03/21/2011 at 05:50 EDT, clifford jackson wrote: What are the major differences between filecontrol and directorycontrol in a SFS structure DIRECTORY CONTROL directories have two important attributes: 1. You don't seen any changes to any files until you re-ACCESS the directory. 2. Authority for the files resides at the directory level (DIRREAD, DIRWRITE). That is, all files have the same access rights, matching the access rights of the directory. You just grant access to the directory and the person has those rights to all the files. If there are new files, they automatically get access, but only after they re-access the directory. The above is called "Access-to-Release Consistency" and mimics the way a minidisk works. FILE CONTROL directories have separate file and directory access rights, and any changes to a file are visible to others as soon as the file is closed. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: SFS
On Monday, 03/21/2011 at 05:50 EDT, clifford jackson wrote: > What are the major differences between filecontrol and directorycontrol in a > SFS structure DIRECTORY CONTROL directories have two important attributes: 1. You don't seen any changes to any files until you re-ACCESS the directory. 2. Authority for the files resides at the directory level (DIRREAD, DIRWRITE). That is, all files have the same access rights, matching the access rights of the directory. You just grant access to the directory and the person has those rights to all the files. If there are new files, they automatically get access, but only after they re-access the directory. The above is called "Access-to-Release Consistency" and mimics the way a minidisk works. FILE CONTROL directories have separate file and directory access rights, and any changes to a file are visible to others as soon as the file is closed. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: SMTP authentication?
> This appliance can connect to a VSWITCH? Yes. It will tolerate both layer 2 and layer 3 VSWITCHes. > And how will my > SMTP talk to it? Over CTC? HS? What we suggest for front-ending these older VM TCP services is that you get another IP address from your networking folks (just one is fine), attach that to our firewall appliance (I'll also put that up), and define two private VSWITCHes or GLANs as internal bus networks. You attach a interface from the VM TCPIP stack to the 2nd VSWITCH. You attach the SMTP appliance to the "outside" VSWITCH put an additional interface on the same VSWITCH as the VM TCPIP stack. Use 192.xxx or 172.xxx addresses for the internal VSWITCHes. You log into the appliance and edit /etc/exim/config and insert your SMTP auth credentials in the appropriate places (comments in the file tell you where), and then /etc/init.d/exim restart. You can test it by punching a BSMTP file to the RDR of the Linux appliance; if it's delivered, you win. Once you're happy with it, you configure the IPMAILERADDRESS in the VM SMTP configuration to point to the IP of the Linux appliance on the internal VSWITCH (so no unprotected traffic ever leaves your machine), and you're off to the races. It sounds complicated, but once this is all in place, you can start front-ending FTP, NFS, etc, etc with modern versions that are directly what the networking guys are used to (and they can help you configure them to work Just Like Everyone Else). Takes away any complaining about the VM system being "weird" or "not compatible", and gets the job done while we all wait for IBM to have spare cycles to update the basic TCP services.
Re: VSWITCH Layer2 & Layer3
It seems that z/VSE does have this restriction (and it's the REAL not VIRTUAL addresses that must be an even-odd pair). Just a FYI, Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Monday, March 21, 2011 1:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VSWITCH Layer2 & Layer3 On Monday, 03/21/2011 at 02:14 EDT, Bob McCarthy wrote: >I run layer 2 and layer 3 on the same OSA. I believe that the addresses must > begin on an even boundary, therefore you would need to begin with 0D14-0D16. OSAs haven't required even boundaries for a long time, though you will find that restriction still in some host software. DEFINE VSWITCH does not have such a restriction. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: VSWITCH Layer2 & Layer3
On Monday, 03/21/2011 at 02:14 EDT, Bob McCarthy wrote: >I run layer 2 and layer 3 on the same OSA. I believe that the addresses must > begin on an even boundary, therefore you would need to begin with 0D14-0D16. OSAs haven't required even boundaries for a long time, though you will find that restriction still in some host software. DEFINE VSWITCH does not have such a restriction. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: VSWITCH Layer2 & Layer3
Karl, I run layer 2 and layer 3 on the same OSA. I believe that the addresses must begin on an even boundary, therefore you would need to begin with 0D14-0D16. Bob From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Karl Kingston Sent: Monday, March 21, 2011 1:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VSWITCH Layer2 & Layer3 Hi Folks I currently have a layer3 VSWITCH defined. This vswitch has been used for production guest machines so I don't want to break this. I have a need for a layer2 VSWITCH. My Layer2 VSWITCH is on CHPID 01, using devices 0D10-0D12. Current subnet is 10.207.1.x I want to add a Layer2 VSWITCH. Can I use devices 0D13-0D15 on CHPID 01. Will be using the same subnet (10.207.1.x). Can it be done? If so, any issues with this?We're running z/VM 5.4 RSU 1001. Thanks
Re: VSWITCH Layer2 & Layer3
Tom, > Can I use devices 0D13-0D15 on CHPID 01 Be sure "Q D13-D15" replies with "OSA FREE". Or conversely, use "Q OSA FREE" to be sure these devices are available. "Mike MacIsaac"(845) 433-7061
Re: Anyone using Dirmaint with a z10?
On Monday, 03/21/2011 at 09:11 EDT, gclo...@br.ibm.com wrote: > Robert, > I normally test it manually: > Logon MAINT (at Z10) > DIRM USER WITHPASS > DIRECTXA USER WITHPASS > > If something goes wrong, change it: > Note: $DIRCTL$ is a pseudo user for Directory statements. > > DIRM FOR $DIRCTL$ GET > CP Q CPUID > XEdit $DIRCTL$ DIRECT (and update) > DIRM FOR $DIRCTL$ REPlace Just use the DIRM DIRECTORY command. It's easier, quicker, and less prone to error. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: VSWITCH Layer2 & Layer3
Running multiple VSWITCHs on the same OSA is a perfectly standard thing to do. They don't have to be same layer 2 / 3. Only question is why you don't use a backup OSA or link aggregation to protect from a single OSA port/card/IO cage or network switch failure. That's not what you asked though. Regards, Mike Barclays Bank _ From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Karl Kingston Sent: 21 March 2011 17:00 To: IBMVM@LISTSERV.UARK.EDU Subject: VSWITCH Layer2 & Layer3 Hi Folks I currently have a layer3 VSWITCH defined. This vswitch has been used for production guest machines so I don't want to break this. I have a need for a layer2 VSWITCH. My Layer2 VSWITCH is on CHPID 01, using devices 0D10-0D12. Current subnet is 10.207.1.x I want to add a Layer2 VSWITCH. Can I use devices 0D13-0D15 on CHPID 01. Will be using the same subnet (10.207.1.x). Can it be done? If so, any issues with this?We're running z/VM 5.4 RSU 1001. Thanks This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC.Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised and regulated by the Financial Services Authority.
VSWITCH Layer2 & Layer3
Hi Folks I currently have a layer3 VSWITCH defined. This vswitch has been used for production guest machines so I don't want to break this. I have a need for a layer2 VSWITCH. My Layer2 VSWITCH is on CHPID 01, using devices 0D10-0D12. Current subnet is 10.207.1.x I want to add a Layer2 VSWITCH. Can I use devices 0D13-0D15 on CHPID 01. Will be using the same subnet (10.207.1.x). Can it be done? If so, any issues with this?We're running z/VM 5.4 RSU 1001. Thanks
AUTO: Rakesh Krishnakumar is out of the office (returning 24/03/2011)
I am out of the office until 24/03/2011. I am on vacation with no access to e-mails and limited access to phone. Note: This is an automated response to your message "Re: Anyone using Dirmaint with a z10?" sent on 3/21/11 19:24:39. This is the only notification you will receive while this person is away.
Presentations from Hillgang
Presentations from the last Hillgang meeting are available at http://www.sinenomine.net/node/722
Re: Anyone using Dirmaint with a z10?
Robert, I normally test it manually: Logon MAINT (at Z10) DIRM USER WITHPASS DIRECTXA USER WITHPASS If something goes wrong, change it: Note: $DIRCTL$ is a pseudo user for Directory statements. DIRM FOR $DIRCTL$ GET CP Q CPUID XEdit $DIRCTL$ DIRECT (and update) DIRM FOR $DIRCTL$ REPlace __ Clovis From: RPN01 To: IBMVM@listserv.uark.edu Date: 20/03/2011 06:47 Subject: Anyone using Dirmaint with a z10? Sent by: The IBM z/VM Operating System We just installed a z10 processor this morning, and the Dirmaint satellite on it won’t install a directory. The message I get says that there is no DIRECTORY statement which matches the serial and model number, and then has the serial and model in parens. OK, so I cut and paste the serial and model and copied it into a directory statement in Dirmaint (which actually matched what I had there, but hey, I wanted to be sure it was right). I tried direct again, and it still says the same thing. The old statement for our z9 was: DIRECTORY 0123 3390 54GRES 0123 025A7E-2094 GRIZZLY And I replaced it with the following for the z10: DIRECTORY 0123 3390 54GRES 0123 02B3E6-2097 GRIZZLY What small gem of wisdom am I missing here? -- Robert P. Nix Mayo Foundation.~. RO-OC-1-18 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different."
Re: Anyone using Dirmaint with a z10?
Since I came in this morning and it has "magically" repaired itself, I think that this may indeed be the problem. I'll go in and turn off caching on the shared disks today so as to avoid this issue next weekend when we install our second z10. Thanks. -- Robert P. Nix Mayo Foundation.~. RO-OC-1-18 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 3/20/11 9:19 AM, "Alan Altmark" wrote: > On Sunday, 03/20/2011 at 05:53 EDT, RPN01 wrote: >> We just installed a z10 processor this morning, and the Dirmaint > satellite on >> it won?t install a directory. The message I get says that there is no > DIRECTORY >> statement which matches the serial and model number, and then has the > serial >> and model in parens. OK, so I cut and paste the serial and model and > copied it >> into a directory statement in Dirmaint (which actually matched what I > had >> there, but hey, I wanted to be sure it was right). I tried direct again, > and it >> still says the same thing. >> >> The old statement for our z9 was: >> >> DIRECTORY 0123 3390 54GRES 0123 025A7E-2094 GRIZZLY >> >> >> And I replaced it with the following for the z10: >> >> DIRECTORY 0123 3390 54GRES 0123 02B3E6-2097 GRIZZLY >> >> What small gem of wisdom am I missing here? > > My guess is that you forgot to turn off minidisk cache for the shared > disks on the satellite system and you're not seeing the directory update. > I had that problem a couple of weeks ago. I couldn't figure it out until > I linked to the DIRMAINT 1DF on the satellite system and noticed that the > file content didn't match the primary system. (slap forehead) > > I suggested to one of the developers that satellites should turn off MDC > for all config and db disks if their partner DIRMAINT server is on a > different system. > > Alan Altmark > > z/VM and Linux on System z Consultant > IBM System Lab Services and Training > ibm.com/systems/services/labservices > office: 607.429.3323 > mobile; 607.321.7556 > alan_altm...@us.ibm.com > IBM Endicott
