Re: controlling user who can mount tape.
Allocations of scratch tape mounts can be controlled if in an SMS tape environment such as a VTS or 3494 library. The SMS routines have access to info such as the RACF userid, group, and job name and can fail execution for those who aren't your loved ones. The SMS routines are not called for existing datasets in these environments, so they cannot prevent users from mounting existing tape datasets. Ben Alford Enterprise Systems Programming University of Tennessee[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
Ben Alford wrote: Allocations of scratch tape mounts can be controlled if in an SMS tape environment such as a VTS or 3494 library. The SMS routines have access to info such as the RACF userid, group, and job name and can fail execution for those who aren't your loved ones. The SMS routines are not called for existing datasets in these environments, so they cannot prevent users from mounting existing tape datasets. SMS ACS routines are not the best thing to control who's allowed to do anything. That's RACF domain. Fortunately RACF SMS can play together: SMS assigns MGMTCLAS and STORCLAS and these resources are controlled by RACF. This is the time solution for scratch mount only, however access to existing tape datasets can be protected by DATASET class and/or TAPEVOL class. This works for both SMS-managed library tapes and stand-alone (or Storagetek resident) tapes. SMS ACS routines are only for system-managed (read IBM) tape libraries. It can be circumvented by defining STK library as MTL (Manual Tape Library), but AFAIK it is not popular among STK users. My $0.02 -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
Ed, You could automatically start more initiators :) and if you implement TMM then there is no mount request for output (and often for the input as well). Caleb, You can use TMM to direct USER tape output to disk, and therefore there is no input tape for USER datasets. More user friendly than cancelling jobs. Ron With robotic tape mechanisms mounting tape is probably costs less so in some situations it maybe almost irrelevant. The issue I see is throughput for an iebgener step for instance even though it calls for an input (and possibly an output tape) the step could last for 10 seconds or 30 minutes (or more) it would tie up that specific init for that amount of elapsed time leaving the other jobs in that job class waiting. It is in a way allocating resources (tape drives). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
I haven't really been paying very much attention to this topic since it's not at all my forte - if anything is. However, I'm struck by the seeming fact that there is no current general solution to the tape set-up problem. If there were and some users were allowed to use the required procedure and some users weren't then there would be a solution also to the subject line. I remember many years ago when I submitted a job involving typically tape mounting - there was a time when disks could be mounted per job also - then I had to include a JES2 card - I vaguely remember. The card had to mention in text suitable for an operator rather than a program which tape volumes the job would require. I think the presence of the card caused the job to be held so that the operator could release it presumably when both the tape drives and the tapes from the library were available. That was the state of play about 20 years ago I guess and I'm surprised there's not a more solid solution about now - or maybe there is but, somehow, it can't be used to block use of it by a particular user. Chris Mason - Original Message - From: Robert A. Rosenberg [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, 27 December, 2005 2:50 AM Subject: Re: controlling user who can mount tape. At 13:30 -0600 on 12/23/2005, Ed Gould wrote about Re: controlling user who can mount tape.: On Dec 23, 2005, at 3:12 AM, caleb ong wrote: Hello, Is there a way to restrict users from being able to submit job that requires a tape mount in os/390 ? The objective is to enable only our operations group to submit jobs that requires tape mounting. Applications group will be prohibited in submitting jobs that will require tape mounting. We have RACF as our security sw. I have looked at the racf and tso uads. it seems that you can control tso mount thru the mount attribute in the uads or the racf tso segment (tsoauth, mount attribute). But for jobs submitted by the users , i coudn't find anyway to control this ? Can anyone provide any suggestion to do this. You can only do it (I am pretty sure) if you look for a MOUNT message in the wto exit. Then you get to decide if you want to cancel the user or not. This helps only if you have good job naming standards . There *MIGHT* be away if you can get the info from RACFUID This solution is not that viable since it kicks in AS the job step that requires the tape mount starts to execute. Thus you might have had a number of steps run before you run into trouble. You want a solution that will prevent the job from being initiated in the first place (such as my suggestion to have JES2 parse the converted JCL to spot any tape requests and trigger a JCL error at that point). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
On Dec 27, 2005, at 7:32 AM, Chris Mason wrote: I haven't really been paying very much attention to this topic since it's not at all my forte - if anything is. However, I'm struck by the seeming fact that there is no current general solution to the tape set-up problem. If there were and some users were allowed to use the required procedure and some users weren't then there would be a solution also to the subject line. I remember many years ago when I submitted a job involving typically tape mounting - there was a time when disks could be mounted per job also - then I had to include a JES2 card - I vaguely remember. The card had to mention in text suitable for an operator rather than a program which tape volumes the job would require. I think the presence of the card caused the job to be held so that the operator could release it presumably when both the tape drives and the tapes from the library were available. That was the state of play about 20 years ago I guess and I'm surprised there's not a more solid solution about now - or maybe there is but, somehow, it can't be used to block use of it by a particular user. Chris Mason Chrism, If you mean automatically system code., then I agree with you. The user code (that I wrote) is invoked at each mount request. The decision to cancel has to be done within user written code. Each installation has to make their own mind up whether to cancel the job or not. I could just see if IBM came up with a process there would still have to be rules if not then the user community would be lobbying IBM to have an exit so they could decide. Some installations may or may not care less about tape mounts. Each installation would then have to create rules unique to their installation. With robotic tape mechanisms mounting tape is probably costs less so in some situations it maybe almost irrelevant. The issue I see is throughput for an iebgener step for instance even though it calls for an input (and possibly an output tape) the step could last for 10 seconds or 30 minutes (or more) it would tie up that specific init for that amount of elapsed time leaving the other jobs in that job class waiting. It is in a way allocating resources (tape drives). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
On Dec 26, 2005, at 7:50 PM, Robert A. Rosenberg wrote: At 13:30 -0600 on 12/23/2005, Ed Gould wrote about Re: controlling user who can mount tape.: On Dec 23, 2005, at 3:12 AM, caleb ong wrote: Hello, Is there a way to restrict users from being able to submit job that requires a tape mount in os/390 ? The objective is to enable only our operations group to submit jobs that requires tape mounting. Applications group will be prohibited in submitting jobs that will require tape mounting. We have RACF as our security sw. I have looked at the racf and tso uads. it seems that you can control tso mount thru the mount attribute in the uads or the racf tso segment (tsoauth, mount attribute). But for jobs submitted by the users , i coudn't find anyway to control this ? Can anyone provide any suggestion to do this. You can only do it (I am pretty sure) if you look for a MOUNT message in the wto exit. Then you get to decide if you want to cancel the user or not. This helps only if you have good job naming standards . There *MIGHT* be away if you can get the info from RACFUID This solution is not that viable since it kicks in AS the job step that requires the tape mount starts to execute. Thus you might have had a number of steps run before you run into trouble. You want a solution that will prevent the job from being initiated in the first place (such as my suggestion to have JES2 parse the converted JCL to spot any tape requests and trigger a JCL error at that point). True, But in order to do it ahead of time (well most of the time) you have to muck around in the converter text. I have tried it a few time and it is not simple. Plus this not do anything for dynamically allocated files. You would still have the possibility of missing tape mounts. The exit I talked about originally is the (one minor exception) will catch 99.9 percent of tape requests. It is easy to code and (IIRC) no chasing of OCO control blocks. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
controlling user who can mount tape.
Hello, Is there a way to restrict users from being able to submit job that requires a tape mount in os/390 ? The objective is to enable only our operations group to submit jobs that requires tape mounting. Applications group will be prohibited in submitting jobs that will require tape mounting. We have RACF as our security sw. I have looked at the racf and tso uads. it seems that you can control tso mount thru the mount attribute in the uads or the racf tso segment (tsoauth, mount attribute). But for jobs submitted by the users , i coudn't find anyway to control this ? Can anyone provide any suggestion to do this. Thanks. Caleb _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
caleb ong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hello, Is there a way to restrict users from being able to submit job that requires a tape mount in os/390 ? The objective is to enable only our operations group to submit jobs that requires tape mounting. Applications group will be prohibited in submitting jobs that will require tape mounting. We have RACF as our security sw. I have looked at the racf and tso uads. it seems that you can control tso mount thru the mount attribute in the uads or the racf tso segment (tsoauth, mount attribute). But for jobs submitted by the users , i coudn't find anyway to control this ? Can anyone provide any suggestion to do this. Thanks. Caleb Caleb, in our system a user has to specify if a job uses tape or not. It is impossible for an exit or other central routine to tell in advance if a job is going to use tapes or not. Tapejobs are then routed to special jobclasses with a (restricted) number of initiators. If a user requests a tape in another jobclass the job is cancelled. This is done by intercepting mount messages: IEC101A IEC501A IEC501E IEF233A IEF233D. I think the last part is what you can use. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
We use ThruPut manager, among other things, to control the demand for tape drives. This has really faded as we have eliminated almost all of our demand mounts and many of the scratch mounts thru TMM, but the controls are still there. ThruPut Manager will see tape units called via JCL or cataloged datasets, it will not see any that might be allocated via DYNALLOC. I think the MOUNT attribute controls most of those. The only things I see fall thru are jobs like TMSINIT and FATS/FATAR. While I had never thought of limiting tape access by user, I think ThruPut Manager could force any tape mounts to a certain class. Access to job classes has been discussed in the past, again since I don't do it, I'm not sure of the details, but exit 6 and/or IEFUTL come to mind. The thought of TMSINIT woke up another brain cell, could you control tape access thru your tape magement system? We have CA-1, would limiting access to class [EMAIL PROTECTED] profile YSVCCOND do the trick? I notice it's UACC UPDATE here. There are other profiles for foreign tape access as well. You might be able to prevent users from accessing you tape library, but allow them to read a tape from an external source. (I'm a university, we do that sort of thing.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of caleb ong Sent: Friday, December 23, 2005 3:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: controlling user who can mount tape. Hello, Is there a way to restrict users from being able to submit job that requires a tape mount in os/390 ? The objective is to enable only our operations group to submit jobs that requires tape mounting. Applications group will be prohibited in submitting jobs that will require tape mounting. We have RACF as our security sw. I have looked at the racf and tso uads. it seems that you can control tso mount thru the mount attribute in the uads or the racf tso segment (tsoauth, mount attribute). But for jobs submitted by the users , i coudn't find anyway to control this ? Can anyone provide any suggestion to do this. Thanks. Caleb I don't know where I got it, but I have a subsystem which can control access to tape addresses via a RACF profile in the FACILITY class. This supports generics, so it would be possible to do something like: RDEF FACILITY TAPEDEV.** UACC(NONE) PE TAPEDEV.** CLASS(FACILITY) ID(...) ACCESS(READ) This does require installing authorized code in LPALIB and a subsystem called TAPE. It consists of two programs. The first is a subsystem initialization routine. The second is the code which get control when a tape device is to be allocated (via SSI call 78) and tests the device number using a RACROUTE against the above profile. I tried it in my sandbox and it appeared to work with no problems. I think I got it from someone on the RACF-L list. The comments are in Portugese (I think). Oh, this doesn't stop job submission. It causes a JCL failure during allocation for a tape drive if the user doesn't have RACF access to at least one tape address. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
We use a product called DSS by Chaney Systems that cancels jobs in certain classes if they ask for tape mounts. We have classes for quick in out jobs that we don't allow tape for. I wouldn't recommend DSS though, as it has not been upgraded to my knowledge for 64 bit real processing. We still have an MP3000, so that doesn't matter. Eric Bielefeld Sr. Systems Programmer PH Mining Equipment 414-671-7849 Milwaukee, Wisconsin - Original Message - From: Vernooy, C.P. - SPLXM [EMAIL PROTECTED] Caleb, in our system a user has to specify if a job uses tape or not. It is impossible for an exit or other central routine to tell in advance if a job is going to use tapes or not. Tapejobs are then routed to special jobclasses with a (restricted) number of initiators. If a user requests a tape in another jobclass the job is cancelled. This is done by intercepting mount messages: IEC101A IEC501A IEC501E IEF233A IEF233D. I think the last part is what you can use. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** --- --- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
On Dec 23, 2005, at 3:12 AM, caleb ong wrote: Hello, Is there a way to restrict users from being able to submit job that requires a tape mount in os/390 ? The objective is to enable only our operations group to submit jobs that requires tape mounting. Applications group will be prohibited in submitting jobs that will require tape mounting. We have RACF as our security sw. I have looked at the racf and tso uads. it seems that you can control tso mount thru the mount attribute in the uads or the racf tso segment (tsoauth, mount attribute). But for jobs submitted by the users , i coudn't find anyway to control this ? Can anyone provide any suggestion to do this. Thanks. Caleb You can only do it (I am pretty sure) if you look for a MOUNT message in the wto exit. Then you get to decide if you want to cancel the user or not. This helps only if you have good job naming standards . There *MIGHT* be away if you can get the info from RACFUID . Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: controlling user who can mount tape.
At 17:12 +0800 on 12/23/2005, caleb ong wrote about controlling user who can mount tape.: Hello, Is there a way to restrict users from being able to submit job that requires a tape mount in os/390 ? The objective is to enable only our operations group to submit jobs that requires tape mounting. Applications group will be prohibited in submitting jobs that will require tape mounting. We have RACF as our security sw. I have looked at the racf and tso uads. it seems that you can control tso mount thru the mount attribute in the uads or the racf tso segment (tsoauth, mount attribute). But for jobs submitted by the users , i coudn't find anyway to control this ? Can anyone provide any suggestion to do this. Thanks. Caleb If you are running JES2, you can have a JES2 Exit parse the converted JCL as it goes though the converter stage and spot if it is referencing Tape Volumes. If so, it can trigger an error which will cause the job to get rejected at the end of the conversion step. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
