Re: SWAPGEN EXEC
Thanks Fernando and DavidDave Jones sent me a VMARC version of SWAPGE N and it is working fine. To David Boyes :I tried what you suggested but when I Downloaded it to my PC then VM the file got mangled. I tried every possible way...maybe there i s something wrong on my PC, anyway am now working so thanks again.
Re: SWAPGEN EXEC
When you downloaded the MAILABLE file to your PC and then to VM, did you transfer the file as a TEXT file? A MAILABLE file is intended to survive going between different systems and arrive in a format that will unpack cleanly. George Shedlock Jr AEGON Information Technology AEGON USA 502-560-3541 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dave de Noronha Sent: Thursday, June 19, 2008 2:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SWAPGEN EXEC Thanks Fernando and DavidDave Jones sent me a VMARC version of SWAPGE= N and it is working fine. To David Boyes :I tried what you suggested but when I Downloaded it to my= PC then VM the file got mangled. I tried every possible way...maybe there i= s something wrong on my PC, anyway am now working so thanks again.
Re: Who Has the Longest Running VM System?
We had been at July 30, 2003 until last month when management decided we needed to IPL the system just to see if we still remembered. We are VM 4.4 Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Wednesday, June 18, 2008 3:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Who Has the Longest Running VM System? We have a VM 2.3 system that was last IPL'ed on August 17, 2003. Anybody have one that was last IPL'ed before then? q cplevel VM/ESA Version 2 Release 3.0, service level 0101 Generated at 03/11/02 17:44:14 EDT IPL at 08/17/03 04:40:50 EDT Ready; T=0.01/0.01 14:59:18 Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing, a WIPRO Company 11707 Miracle Hills Dr. Omaha, NE 68154 Office 402.963.8905
Re: SFS REVOKE AUTH question
Respectfully, I'll have to disagree with that. In my case, the user is not enrolled, I checked with a QUERY ENROLL. The directory is in VMSYS: the user is only enrolled in VMSYSU: When I log on to the user, I am able to issue an ACCESS command and get to the files in VMSYS: . I'm running VM 5.2. dirid= VMSYS:MAINT.PUBLIC userid=wstape When I do a query enroll, it is a very short list and I know all of my users, approx. 200, can access the dirid. Did I misunderstand what you said? Is there perhaps a PTF I need to apply? Steve -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams Sent: Thursday, June 19, 2008 7:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question On Wed, 18 Jun 2008 08:52:50 -0700 Schuh, Richard said: Unfortunately for you, granting authority to PUBLIC grants it to everyone who has an id on the system. If the filepool is listed as a One minor correction, PUBLIC grants access to everyone who has been enrolled in the filepool. If the id in question is not enrolled, it gains no access. They'll receive a DMSACCR1240E if they try to ACCESS the directory, FPLSFS733E reason code 30100 if they try to read a file with PIPEs, etc. Not helpful if it is the filepool where all users connect, but useful in some situations. Global Resource, the authority carries over to other systems connected to your system via APPC. Yes, PUBLIC is the problem. And via ISFC Your ESM may provide an out. I do not know the abilities of VM:Secure and RACF in this area. SafeSFS may be another way to control access the way you are hoping for. Whenever I enroll a new user in our SFS, I tell them to not grant authority to PUBLIC for any files or subdirectories that they would not want posted on the web or printed in the Enquirer. Regards, Richard Schuh /ahw -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gentry, Stephen Sent: Wednesday, June 18, 2008 8:23 AM To: IBMVM@LISTSERV.UARK.EDU Subject: SFS REVOKE AUTH question I am trying to REVOKE AUTH for an SFS user. The directory, let's call it VMSYS:MAINT.PUBLIC has had a GRANT AUTH PUBLIC done to it earlier. I have a specific user I do not want to access this directory. When I issue the REVOKE AUTH, (specifically: revoke auth vmsys:maint.public from steveg) I get DMSJAU1138E File sharing conflict with a return code of 70. The user is not logged on when I issue the command. Is the PUBLIC authority causing this problem? Thanks, Steve
Re: SFS REVOKE AUTH question
Incorrect: PUBLIC grants access to everyone who has NOT been enrolled in the filepool. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams Sent: Thursday, June 19, 2008 7:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question On Wed, 18 Jun 2008 08:52:50 -0700 Schuh, Richard said: Unfortunately for you, granting authority to PUBLIC grants it to everyone who has an id on the system. If the filepool is listed as a One minor correction, PUBLIC grants access to everyone who has been enrolled in the filepool. If the id in question is not enrolled, it gains no access. They'll receive a DMSACCR1240E if they try to ACCESS the directory, FPLSFS733E reason code 30100 if they try to read a file with PIPEs, etc. Not helpful if it is the filepool where all users connect, but useful in some situations. Global Resource, the authority carries over to other systems connected to your system via APPC. Yes, PUBLIC is the problem. And via ISFC Your ESM may provide an out. I do not know the abilities of VM:Secure and RACF in this area. SafeSFS may be another way to control access the way you are hoping for. Whenever I enroll a new user in our SFS, I tell them to not grant authority to PUBLIC for any files or subdirectories that they would not want posted on the web or printed in the Enquirer. Regards, Richard Schuh /ahw -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gentry, Stephen Sent: Wednesday, June 18, 2008 8:23 AM To: IBMVM@LISTSERV.UARK.EDU Subject: SFS REVOKE AUTH question I am trying to REVOKE AUTH for an SFS user. The directory, let's call it VMSYS:MAINT.PUBLIC has had a GRANT AUTH PUBLIC done to it earlier. I have a specific user I do not want to access this directory. When I issue the REVOKE AUTH, (specifically: revoke auth vmsys:maint.public from steveg) I get DMSJAU1138E File sharing conflict with a return code of 70. The user is not logged on when I issue the command. Is the PUBLIC authority causing this problem? Thanks, Steve This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: SWAPGEN EXEC
Dave_de_Noronha wrote: I am trying to download the SWAPGEN EXEC from the Sine Nomine website and cannot get it in a format we can use. I do not understand why it is in Mailable format. Can anyone please tell me how to do it or, if possible send me the code What problem are you having? The point of MAILABLE is to package multiple files, preserve timestamps, and be easy to extract without requiring extra tools (such as VMARC). I'm always interested in understanding what pitfalls await... ...phsiii
Re: SWAPGEN EXEC
What problem are you having? It would be nice to have some cookbook-style steps of how to use SWAPGEN on the Web site. On http://www.sinenomine.net/products/vm/swapgen the only instructions I see are: The VMARC file contains the updates to the module and control files, the EXEC, the RXDASD MODULE (for FBA mode), and the CMS HELP file. without requiring extra tools (such as VMARC). Oh wait a minute, is it a VMARC file or a MAILABLE file? And how does one work with MAILABLE files? Thanks. Mike MacIsaac [EMAIL PROTECTED] (845) 433-7061
Re: SWAPGEN EXEC
On Thu, Jun 19, 2008 at 4:26 PM, Michael MacIsaac [EMAIL PROTECTED] wrote: What problem are you having? I am concerned about the approach of teaching adults to download and just run it to see what happens That's one of the aspects that distinguishes us from the folks who close their eyes and do Next, next, finish and end up re-install their operating system on a regular basis after a number of those actions. My preference is to use a familiar tool (like VMARC) to review what's in the archive before I unpack it. And when I forget, I can at least use it to get a list of the files it installed and use that to manage the package. Transfer of a file in binary is not harder than transfer in text mode - you just have to remember doing it right in both cases. Accidental damage during transfer of a self-expanding program is most likely to make it fail in a visible manner. Deliberate modification of the code would be a concern. Somehow it does not make sense to me to ship the packaging tools with each package. Rob (from a comfortable place at the gallery, frowning at what grew out of the 10 lines posted a few years ago)
Re: SWAPGEN EXEC
On Jun 19, 2008, at 9:00 AM, Phil Smith III wrote: Dave_de_Noronha wrote: I am trying to download the SWAPGEN EXEC from the Sine Nomine website and cannot get it in a format we can use. I do not understand why it is in Mailable format. Can anyone please tell me how to do it or, if possible send me the code What problem are you having? The point of MAILABLE is to package multiple files, preserve timestamps, and be easy to extract without requiring extra tools (such as VMARC). I'm always interested in understanding what pitfalls await... Well, last time it was a difference between PC and Unix line endings. I'm very tempted to go back to VMARC and say download as binary, reblock to FIX 80, unpack with VMARC. Go get VMARC if you don't have it, because we didn't have these problems reported before we went to MAILABLE for the download. But there's a lot of confusion with MAILABLE. Adam
Re: SFS REVOKE AUTH question
One minor correction, PUBLIC grants access to everyone who has been enrolled in the filepool. If the id in question is not enrolled, it gains no access. They'll receive a DMSACCR1240E if they try to ACCESS the directory, FPLSFS733E reason code 30100 if they try to read a file with PIPEs, etc. Not helpful if it is the filepool where all users connect, but useful in some situations. Not so if PUBLIC has been enrolled. Purpose Use the ENROLL PUBLIC command to give connect authority for a file pool to all users. File pool administration authority is required to use this command. I have never been in a situation where I did not want users to not see Public data. It may be possible that there are circumstances where it is necessary to keep only one or a few users away from data that is accessible to everyone else. I just have not encountered any. If that is the case, do not enroll public and only enroll those users who do need access. In many cases, that means thousands of enrollments. That could be cumbersome and even become unworkable if someone who is legitimately enrolled and has data in the pool suddenly gets put on the blacklist. I find it much easier to enroll Public and not put sensitive data in any directory that has authorized everyone. And via ISFC In this case, ISFC is a transport mechanism for APPC traffic. APPC is still required, it simply flows over the ISFC connection instead of via SNA. Regards, Richard Schuh
Re: SFS REVOKE AUTH question
Only if PUBLIC is enrolled. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTS) Sent: Thursday, June 19, 2008 6:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question Incorrect: PUBLIC grants access to everyone who has NOT been enrolled in the filepool.
Re: SFS REVOKE AUTH question
On Thu, 19 Jun 2008 08:32:59 -0700 Schuh, Richard said: One minor correction, PUBLIC grants access to everyone who has been enrolled in the filepool. If the id in question is not enrolled, it gains no access. They'll receive a DMSACCR1240E if they try to ACCESS the directory, FPLSFS733E reason code 30100 if they try to read a file with PIPEs, etc. Not helpful if it is the filepool where all users connect, but useful in some situations. Not so if PUBLIC has been enrolled. Purpose Use the ENROLL PUBLIC command to give connect authority for a file pool to all users. File pool administration authority is required to use this command. I have never been in a situation where I did not want users to not see Public data. It may be possible that there are circumstances where it is necessary to keep only one or a few users away from data that is accessible to everyone else. I just have not encountered any. If that is the case, do not enroll public and only enroll those users who do need access. In many cases, that means thousands of enrollments. That could be cumbersome and even become unworkable if someone who is legitimately enrolled and has data in the pool suddenly gets put on the blacklist. I find it much easier to enroll Public and not put sensitive data in any directory that has authorized everyone. The use case that comes to mind is that you have a filespace that you want to restrict access to a large group of people, but not everyone and you don't want to have a large number of authorization records in the catalog. Without an ESM, every grant is an entry in the catalog, which increases its size, and slows down the process to check authorizations. I'm not saying it's a good case, but it is s case. I had forgotted about enrolling PUBLIC. It isn't something we do, and at one time was on the not reccomended list. We've moved a couple things to separate filepools to ease access control. Richard Schuh /ahw
Re: Redhat Install on z/VM
Mary Zervos wrote: Hello all, Our first install of Redhat on our z/VM 5.3 system. We are having trouble using Xwindows from a UBUNTU system into the Redhat install shell for a GUI interface install window. We can Xwindow from our UBUNTU system to other systems, just the z/VM5.3 side of it won't allow it. Any ideas? Thanks, Mary Zervos Binghamton University VM Systems Programmer While I don't use RedHat (yet), I do use SLES 9 10. I specify using SSH in the install parms for the install and connect to the Linux system with 'ssh -X linux.add.re.ss' and this allows the X forwarding to show the installation window. You can contact me directly if you have any questions. Kim
Re: Redhat Install on z/VM
On Jun 19, 2008, at 11:04 AM, Kim Goldenberg wrote: Mary Zervos wrote: Hello all, Our first install of Redhat on our z/VM 5.3 system. We are having trouble using Xwindows from a UBUNTU system into the Redhat install shell for a GUI interface install window. We can Xwindow from our UBUNTU system to other systems, just the z/VM5.3 side of it won't allow it. Any ideas? Thanks, Mary Zervos Binghamton University VM Systems Programmer While I don't use RedHat (yet), I do use SLES 9 10. I specify using SSH in the install parms for the install and connect to the Linux system with 'ssh -X linux.add.re.ss' and this allows the X forwarding to show the installation window. You can contact me directly if you have any questions. Yeah, the -X should turn on X forwarding. That said...why not just do the RH textmode install? I find it much faster and less annoying (but my z is very slow and I have a lousy network between me and it). Adam
Re: Redhat Install on z/VM
We do use the -X command and the Xwindow still does not come up. We'll probably begin the textmode install tomorrow like you suggested. Thanks, Mary Adam Thornton wrote: On Jun 19, 2008, at 11:04 AM, Kim Goldenberg wrote: Mary Zervos wrote: Hello all, Our first install of Redhat on our z/VM 5.3 system. We are having trouble using Xwindows from a UBUNTU system into the Redhat install shell for a GUI interface install window. We can Xwindow from our UBUNTU system to other systems, just the z/VM5.3 side of it won't allow it. Any ideas? Thanks, Mary Zervos Binghamton University VM Systems Programmer While I don't use RedHat (yet), I do use SLES 9 10. I specify using SSH in the install parms for the install and connect to the Linux system with 'ssh -X linux.add.re.ss' and this allows the X forwarding to show the installation window. You can contact me directly if you have any questions. Yeah, the -X should turn on X forwarding. That said...why not just do the RH textmode install? I find it much faster and less annoying (but my z is very slow and I have a lousy network between me and it). Adam
Re: Redhat Install on z/VM
We also do the ssh -X ... like you suggested but Xwindow still does not come up? Mary Kim Goldenberg wrote: Mary Zervos wrote: Hello all, Our first install of Redhat on our z/VM 5.3 system. We are having trouble using Xwindows from a UBUNTU system into the Redhat install shell for a GUI interface install window. We can Xwindow from our UBUNTU system to other systems, just the z/VM5.3 side of it won't allow it. Any ideas? Thanks, Mary Zervos Binghamton University VM Systems Programmer While I don't use RedHat (yet), I do use SLES 9 10. I specify using SSH in the install parms for the install and connect to the Linux system with 'ssh -X linux.add.re.ss' and this allows the X forwarding to show the installation window. You can contact me directly if you have any questions. Kim
Re: SFS REVOKE AUTH question
Like I said, I have never witnessed such a situation. Your case is hypothetical, and I admit there may be other hypothetical cases where it is necessary to enroll all but a few users in a filepool and then using the grant public mechanism without public being enrolled. What happens if one of those who is denied access need to see other files in the filepool? It is better to not authorize public if you want to deny access to anyone. Without having a Deny Access capability in SFS, there probably is no really good answer to the various cases that can be conjured. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams Sent: Thursday, June 19, 2008 8:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question On Thu, 19 Jun 2008 08:32:59 -0700 Schuh, Richard said: One minor correction, PUBLIC grants access to everyone who has been enrolled in the filepool. If the id in question is not enrolled, it gains no access. They'll receive a DMSACCR1240E if they try to ACCESS the directory, FPLSFS733E reason code 30100 if they try to read a file with PIPEs, etc. Not helpful if it is the filepool where all users connect, but useful in some situations. Not so if PUBLIC has been enrolled. Purpose Use the ENROLL PUBLIC command to give connect authority for a file pool to all users. File pool administration authority is required to use this command. I have never been in a situation where I did not want users to not see Public data. It may be possible that there are circumstances where it is necessary to keep only one or a few users away from data that is accessible to everyone else. I just have not encountered any. If that is the case, do not enroll public and only enroll those users who do need access. In many cases, that means thousands of enrollments. That could be cumbersome and even become unworkable if someone who is legitimately enrolled and has data in the pool suddenly gets put on the blacklist. I find it much easier to enroll Public and not put sensitive data in any directory that has authorized everyone. The use case that comes to mind is that you have a filespace that you want to restrict access to a large group of people, but not everyone and you don't want to have a large number of authorization records in the catalog. Without an ESM, every grant is an entry in the catalog, which increases its size, and slows down the process to check authorizations. I'm not saying it's a good case, but it is s case. I had forgotted about enrolling PUBLIC. It isn't something we do, and at one time was on the not reccomended list. We've moved a couple things to separate filepools to ease access control. Richard Schuh /ahw
Re: SFS REVOKE AUTH question
If you want to try to 'roll your own' SFS authorisation package, look at 'WORF' on the VM download page. Peter -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: June 19, 2008 12:52 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question Like I said, I have never witnessed such a situation. Your case is hypothetical, and I admit there may be other hypothetical cases where it is necessary to enroll all but a few users in a filepool and then using the grant public mechanism without public being enrolled. What happens if one of those who is denied access need to see other files in the filepool? It is better to not authorize public if you want to deny access to anyone. Without having a Deny Access capability in SFS, there probably is no really good answer to the various cases that can be conjured. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams Sent: Thursday, June 19, 2008 8:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question On Thu, 19 Jun 2008 08:32:59 -0700 Schuh, Richard said: One minor correction, PUBLIC grants access to everyone who has been enrolled in the filepool. If the id in question is not enrolled, it gains no access. They'll receive a DMSACCR1240E if they try to ACCESS the directory, FPLSFS733E reason code 30100 if they try to read a file with PIPEs, etc. Not helpful if it is the filepool where all users connect, but useful in some situations. Not so if PUBLIC has been enrolled. Purpose Use the ENROLL PUBLIC command to give connect authority for a file pool to all users. File pool administration authority is required to use this command. I have never been in a situation where I did not want users to not see Public data. It may be possible that there are circumstances where it is necessary to keep only one or a few users away from data that is accessible to everyone else. I just have not encountered any. If that is the case, do not enroll public and only enroll those users who do need access. In many cases, that means thousands of enrollments. That could be cumbersome and even become unworkable if someone who is legitimately enrolled and has data in the pool suddenly gets put on the blacklist. I find it much easier to enroll Public and not put sensitive data in any directory that has authorized everyone. The use case that comes to mind is that you have a filespace that you want to restrict access to a large group of people, but not everyone and you don't want to have a large number of authorization records in the catalog. Without an ESM, every grant is an entry in the catalog, which increases its size, and slows down the process to check authorizations. I'm not saying it's a good case, but it is s case. I had forgotted about enrolling PUBLIC. It isn't something we do, and at one time was on the not reccomended list. We've moved a couple things to separate filepools to ease access control. Richard Schuh /ahw 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.
Re: Redhat Install on z/VM
What has to happen is, and forgive me if you know all of this, Mary, when you are working from the Ubuntu, be sure it is in X mode (some of us do run desktop Linuxen in text mode) and have a shell presented in an ' xterm' window. (Other terminal windows should give the same effect: We need your X desktop available to other applications.) If there are any doubts, try an 'xterm' command manually and use the new window which pops up. When you do the 'ssh -X [EMAIL PROTECTED]' command, SSH client and server negotiate a tunnel so that X clients on the remote end get secured access to the desktop at your end. Here too, try a manual 'xterm' command before you run any other graphical apps on the target system. If you are successful at getting that final XTERM window from the remote system, then all other X apps should have the same level of access to your desktop. Launch the RH installer. (I am unfamiliar with it, but YaST2 is how we do it in SuSE land, following these same steps.) On Thu, Jun 19, 2008 at 12:34 PM, Mary Zervos [EMAIL PROTECTED] wrote: We do use the -X command and the Xwindow still does not come up. We'll probably begin the textmode install tomorrow like you suggested. Thanks, Mary Adam Thornton wrote: On Jun 19, 2008, at 11:04 AM, Kim Goldenberg wrote: Mary Zervos wrote: Hello all, Our first install of Redhat on our z/VM 5.3 system. We are having trouble using Xwindows from a UBUNTU system into the Redhat install shell for a GUI interface install window. We can Xwindow from our UBUNTU system to other systems, just the z/VM5.3 side of it won't allow it. Any ideas? Thanks, Mary Zervos Binghamton University VM Systems Programmer While I don't use RedHat (yet), I do use SLES 9 10. I specify using SSH in the install parms for the install and connect to the Linux system with 'ssh -X linux.add.re.ss' and this allows the X forwarding to show the installation window. You can contact me directly if you have any questions. Yeah, the -X should turn on X forwarding. That said...why not just do the RH textmode install? I find it much faster and less annoying (but my z is very slow and I have a lousy network between me and it). Adam -- -- R;
Re: SFS REVOKE AUTH question
The cases under discussion were hypothetical. I have never needed nor have I seen a real case that could not be handled with the current facilities. Considering my employment situation, a home-grown solution would not be viable if the capabilities of WORF WORFAUTH are needed. It would have to be included in CMS or be an integral part of an overall ESM from a short list of vendors. Should the situation arise, I would be more inclined to write a requirement requesting the capability if it is not already in one of the ESMs. I am not too worried about it because I do not think that it will be needed before I retire. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, June 19, 2008 9:56 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question If you want to try to 'roll your own' SFS authorisation package, look at 'WORF' on the VM download page. Peter -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: June 19, 2008 12:52 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question Like I said, I have never witnessed such a situation. Your case is hypothetical, and I admit there may be other hypothetical cases where it is necessary to enroll all but a few users in a filepool and then using the grant public mechanism without public being enrolled. What happens if one of those who is denied access need to see other files in the filepool? It is better to not authorize public if you want to deny access to anyone. Without having a Deny Access capability in SFS, there probably is no really good answer to the various cases that can be conjured. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams Sent: Thursday, June 19, 2008 8:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question On Thu, 19 Jun 2008 08:32:59 -0700 Schuh, Richard said: One minor correction, PUBLIC grants access to everyone who has been enrolled in the filepool. If the id in question is not enrolled, it gains no access. They'll receive a DMSACCR1240E if they try to ACCESS the directory, FPLSFS733E reason code 30100 if they try to read a file with PIPEs, etc. Not helpful if it is the filepool where all users connect, but useful in some situations. Not so if PUBLIC has been enrolled. Purpose Use the ENROLL PUBLIC command to give connect authority for a file pool to all users. File pool administration authority is required to use this command. I have never been in a situation where I did not want users to not see Public data. It may be possible that there are circumstances where it is necessary to keep only one or a few users away from data that is accessible to everyone else. I just have not encountered any. If that is the case, do not enroll public and only enroll those users who do need access. In many cases, that means thousands of enrollments. That could be cumbersome and even become unworkable if someone who is legitimately enrolled and has data in the pool suddenly gets put on the blacklist. I find it much easier to enroll Public and not put sensitive data in any directory that has authorized everyone. The use case that comes to mind is that you have a filespace that you want to restrict access to a large group of people, but not everyone and you don't want to have a large number of authorization records in the catalog. Without an ESM, every grant is an entry in the catalog, which increases its size, and slows down the process to check authorizations. I'm not saying it's a good case, but it is s case. I had forgotted about enrolling PUBLIC. It isn't something we do, and at one time was on the not reccomended list. We've moved a couple things to separate filepools to ease access control. Richard Schuh /ahw 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.
Re: Dirmaint Start Up Problem.
Thanks Mike. We were able to get Dirmaint at least to start working by reworking the config datadvh file. Would anyone on the list have an sample over ride file I can use as an example which I could use to make changes to the real config dvhdata file. I never created any such over ride file before. If you could give me a sample over ride file, would you be good enough to email it to me off list. Thanks. Mike Walter [EMAIL PROTECTED] 6/18/2008 5:20 PM Howard, I little more on your 2nd level DIRMAINT test... I found the uncompiled rexx source for the DVFPROF EXEC in the 5VMDIR30 disk 02B1. At line 626, it contains comments, followed by code to do it: /*!* /*! Release and detach non-required disks. * /*! (A disk is not required if it is linked R/O* /*! and has not been accessed yet.)* /*!* It appears that something is preventing DIRMAINT from getting its R/W link to the 192 and 21F disks, and then DVHPROF detaches them. That's an area of interests, but does not explain why DIRMAINT does not find the DVHUPDIR MODULE on its 191 disk. Answering that should get you closer. Are you sure that the source system from which you are DDRing these disks had a successful PUT2PROD DIRM? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Dirmaint Start Up Problem.
Here is Mine: CONFIG00 DATADVH A1 V 80 Trunc=80 Size=10 Line=0 Col=1 Alt=0 |...+1+2+3+4+5+6+7+ 0 * * * Top of File * * * 1DATAMOVE_MACHINE=DATAMOVE * * 2ONLINE= IMMED 3PW_INTERVAL_FOR_GEN= 83 90 4PW_INTERVAL_FOR_SET= 1 5PW_LOCK_MODE=AUTOMATIC 6PW_MIN_LENGTH= 6 7PW_WARN_MODE=AUTOMATIC 8RUNMODE= OPERATIONAL 9SORT_BY_DEVICE_ADDRESS= YES 00010SORT_DIRECTORY= YES 00011 * * * End of File * * * Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing, a WIPRO Company 11707 Miracle Hills Dr. Omaha, NE 68154 Office 402.963.8905 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Thursday, June 19, 2008 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Dirmaint Start Up Problem. Thanks Mike. We were able to get Dirmaint at least to start working by reworking the config datadvh file. Would anyone on the list have an sample over ride file I can use as an example which I could use to make changes to the real config dvhdata file. I never created any such over ride file before. If you could give me a sample over ride file, would you be good enough to email it to me off list. Thanks. Mike Walter [EMAIL PROTECTED] 6/18/2008 5:20 PM Howard, I little more on your 2nd level DIRMAINT test... I found the uncompiled rexx source for the DVFPROF EXEC in the 5VMDIR30 disk 02B1. At line 626, it contains comments, followed by code to do it: /*!* /*! Release and detach non-required disks. * /*! (A disk is not required if it is linked R/O * /*! and has not been accessed yet.) * /*!* It appears that something is preventing DIRMAINT from getting its R/W link to the 192 and 21F disks, and then DVHPROF detaches them. That's an area of interests, but does not explain why DIRMAINT does not find the DVHUPDIR MODULE on its 191 disk. Answering that should get you closer. Are you sure that the source system from which you are DDRing these disks had a successful PUT2PROD DIRM? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Dirmaint Start Up Problem.
Thanks Scott, BTW, do we have to change any SES service control files or do we just create these over ride files? My thinking and from what I got from the manual is that Dirmaint will look for any other files which are named CONIIG* DATADVH and apply them in reverse order... Thanks. Wandschneider, Scott [EMAIL PROTECTED] 6/19/2008 5:04 PM Here is Mine: CONFIG00 DATADVH A1 V 80 Trunc=80 Size=10 Line=0 Col=1 Alt=0 |...+1+2+3+4+5+6+7+ 0 * * * Top of File * * * 1DATAMOVE_MACHINE=DATAMOVE * * 2ONLINE= IMMED 3PW_INTERVAL_FOR_GEN= 83 90 4PW_INTERVAL_FOR_SET= 1 5PW_LOCK_MODE=AUTOMATIC 6PW_MIN_LENGTH= 6 7PW_WARN_MODE=AUTOMATIC 8RUNMODE= OPERATIONAL 9SORT_BY_DEVICE_ADDRESS= YES 00010SORT_DIRECTORY= YES 00011 * * * End of File * * * Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing, a WIPRO Company 11707 Miracle Hills Dr. Omaha, NE 68154 Office 402.963.8905 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Thursday, June 19, 2008 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Dirmaint Start Up Problem. Thanks Mike. We were able to get Dirmaint at least to start working by reworking the config datadvh file. Would anyone on the list have an sample over ride file I can use as an example which I could use to make changes to the real config dvhdata file. I never created any such over ride file before. If you could give me a sample over ride file, would you be good enough to email it to me off list. Thanks. Mike Walter [EMAIL PROTECTED] 6/18/2008 5:20 PM Howard, I little more on your 2nd level DIRMAINT test... I found the uncompiled rexx source for the DVFPROF EXEC in the 5VMDIR30 disk 02B1. At line 626, it contains comments, followed by code to do it: /*!* /*! Release and detach non-required disks. * /*! (A disk is not required if it is linked R/O* /*! and has not been accessed yet.)* /*!* It appears that something is preventing DIRMAINT from getting its R/W link to the 192 and 21F disks, and then DVHPROF detaches them. That's an area of interests, but does not explain why DIRMAINT does not find the DVHUPDIR MODULE on its 191 disk. Answering that should get you closer. Are you sure that the source system from which you are DDRing these disks had a successful PUT2PROD DIRM? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance
Re: Dirmaint Start Up Problem.
I believe it searches for CONFIG* DATADVH as you mentioned. Don't leave any files like these on you're A disk, DIRMAINT will use them first. Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing, a WIPRO Company 11707 Miracle Hills Dr. Omaha, NE 68154 Office 402.963.8905 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Thursday, June 19, 2008 4:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Dirmaint Start Up Problem. Thanks Scott, BTW, do we have to change any SES service control files or do we just create these over ride files? My thinking and from what I got from the manual is that Dirmaint will look for any other files which are named CONIIG* DATADVH and apply them in reverse order... Thanks. Wandschneider, Scott [EMAIL PROTECTED] 6/19/2008 5:04 PM Here is Mine: CONFIG00 DATADVH A1 V 80 Trunc=80 Size=10 Line=0 Col=1 Alt=0 |...+1+2+3+4+5+6+7+ 0 * * * Top of File * * * 1 DATAMOVE_MACHINE= DATAMOVE * * 2 ONLINE= IMMED 3 PW_INTERVAL_FOR_GEN= 83 90 4 PW_INTERVAL_FOR_SET= 1 5 PW_LOCK_MODE= AUTOMATIC 6 PW_MIN_LENGTH= 6 7 PW_WARN_MODE= AUTOMATIC 8 RUNMODE= OPERATIONAL 9 SORT_BY_DEVICE_ADDRESS= YES 00010 SORT_DIRECTORY= YES 00011 * * * End of File * * * Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing, a WIPRO Company 11707 Miracle Hills Dr. Omaha, NE 68154 Office 402.963.8905 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Thursday, June 19, 2008 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Dirmaint Start Up Problem. Thanks Mike. We were able to get Dirmaint at least to start working by reworking the config datadvh file. Would anyone on the list have an sample over ride file I can use as an example which I could use to make changes to the real config dvhdata file. I never created any such over ride file before. If you could give me a sample over ride file, would you be good enough to email it to me off list. Thanks. Mike Walter [EMAIL PROTECTED] 6/18/2008 5:20 PM Howard, I little more on your 2nd level DIRMAINT test... I found the uncompiled rexx source for the DVFPROF EXEC in the 5VMDIR30 disk 02B1. At line 626, it contains comments, followed by code to do it: /*!* /*! Release and detach non-required disks. * /*! (A disk is not required if it is linked R/O * /*! and has not been accessed yet.) * /*!* It appears that something is preventing DIRMAINT from getting its R/W link to the 192 and 21F disks, and then DVHPROF detaches them. That's an area of interests, but does not explain why DIRMAINT does not find the DVHUPDIR MODULE on its 191 disk. Answering that should get you closer. Are you sure that the source system from which you are DDRing these disks had a successful PUT2PROD DIRM? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be
Re: SFS REVOKE AUTH question
On Thursday, 06/19/2008 at 12:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Like I said, I have never witnessed such a situation. Your case is hypothetical, and I admit there may be other hypothetical cases where it is necessary to enroll all but a few users in a filepool and then using the grant public mechanism without public being enrolled. What happens if one of those who is denied access need to see other files in the filepool? It is better to not authorize public if you want to deny access to anyone. Without having a Deny Access capability in SFS, there probably is no really good answer to the various cases that can be conjured. GRANT AUTH PUBLIC gives access to anyone who is enrolled in the filepool. If you have ENROLL PUBLIC, then all VM users on the system are enrolled by policy. If it is a GLOBAL filepool, then all users in the ISFC collection are enrolled. We have IBMers on our primary VM system who do not have a Need To Know the information in our development filepool servers. Therefore we do not ENROLL PUBLIC. But we know that, by policy, all of the persons enrolled in the filepool have a Need To Know. We use GRANT AUTH PUBLIC to give the entire lab access to the information. Alan Altmark z/VM Development IBM Endicott
Gavin Appleton is out of the office.
I will be out of the office starting 20/06/2008 and will not return until 24/06/2008. I will respond to your message when I return.
