Re: Retricting jobs that use a certain DDNAME, certain DSNAME to a groups of classes
Gadi, To my knowledge, in OPS you can trap the file's allocation message (if the file is sms managed) or if the job name is known trap message $HASP373 or IEF403I and cancel the job as it is beginning Doron On Tue, Dec 28, 2010 at 13:46, גדי בן אבי gad...@malam.com wrote: Hi, The reason for this request is that the specified DSNAME is a VSAM KSDS. Many jobs read the file, and some update it. Sometimes, about once a year, a job running on the 'wrong' LPAR updates the file, and corrupts it. The corruption is not immediately apparent, and may be discovered days or weeks after it happens. The jobs accessing the file are both production (scheduled) jobs and one time, ad hoc jobs. We have access to OPS, if that may help. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John McKown Sent: Tuesday, December 28, 2010 1:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Retricting jobs that use a certain DDNAME, certain DSNAME to a groups of classes Have fun writing an exit. By LPAR, I assume you mean a specific z/OS image (SYSNAME. or SMFID), an not a specific hardware LPAR name. But I guess either is possible. Now, which exit? Well, IEFUJV or IEFUSI comes to mind. But what about if somebody gets clever and used DYNALLOC? Is this for a specific program? How about using RACF to restrict who can run the program itself? Or is this more of a scheduling thing, as in: When a job is submitted and contains the specific DD name and DSNAME combination, make sure that the system routes its execution to a specific MAS node? In JES2, this would be setting the SYSAFF. In this case, you might be able to use JES2 exit 6 (converted exit), look at the internal text, and set the SYSAFF in the JES2 control block for the job. I don't know which control block. On Tue, 2010-12-28 at 13:05 +0200, גדי בן אבי wrote: Hi, I have the following request: Check if a job uses a certain DD, and that DD references a certain DSNAME, make sure that the job runs on a specified LPAR. Thanks Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- בברכה *דורון גבע* - 054-4974548 doron.geva...@gmail.com Regards Doron Geva - +972-54-4974548 doron.geva...@gmail.com
Re: Potential z/OS MPF behavior change -- comments please
Kevin , The SYSLOG / OPERLOG in many place treated as an aeroplane black boxes. It records *everything *that is happening in the system. It server as tool for technical and legal problems investigation and it is archived for years. There are installations that forbid suppressing any message, including messages that create and serve only automation processes (by automation products). Another issue is that, the MPF does not have a security mechanism. Therefore, anyone that can write a MPF process can cause eliminating messages from SYSLOG unintentionally or intentionally. Automation products, that already suppress messages from everywhere, have the security mechanism that can and should be use. Bottom line: Leave it as today. Those that need more sophisticated options should use more sophisticated tools. Have a nice day Doron On Wed, Oct 20, 2010 at 08:02, Barbara Nitz nitz-...@gmx.net wrote: Kevin, maybe som of the others have the same problem *I* have in understanding the term 'monitor message'. I just reread Planning:OPS and the message manual where the IEF's are in, and I am still unclear what 'monitor message' is/means. Take IEF403I and IEF404I (two of those that I need in hardcopy to *prove* that something happened at a certain time, in addition to the HASP messages and our home-grown uji001 and trt002 at step start/stop): Is all of IEF403I the monitor message that would not be issued if we hadn't set the consolxx definition to MONITOR(JOBNAMES-T)? Or is just the time part of ief403I (which would appear in joblog that doesn't have the hardcopy-log- timestamp) the 'monitor' thing? The 1.12 message book for ief403i is certainly VERY silent about this. Is a list of 'the monitor messages' published anywhere? We still have the MN dsname command in commndxx, which at IPL gets the expected error of 'monitor command not supported' or some such (I was not allowed to remove it for heaven knows what reasons). Despite that, D opdata still shows that DSNAME monitoring is on (because of the INIT statement in consolxx?) Why can I not specify the log option on the INIT statement? We don't issue any setcon command for it, and it defaults to LOG (which isn't explicitly stated in the books, either!) Presumably for monitor dsname on init, it will also default to log. In addition, the message books are fairly obtuse about what a monitor message is. Unless you already know, it is not clear what is a monitor message and what isn't. Looking at the hardcopy log, IEF403I shows that it is issued without any routing codes, but it does have the 'MESSAGE NOT SERVICED BY ANY WTO USER EXIT' and 'AUTOMATION REQUESTED' bits on in HCLREQFL (x'0090'). I have always been unclear if such a message would show up on the console or not and had to rely on actually *looking* at he console to determine that. This despite us having a default routcode of 11 specified in consolxx. Which does not show up in the hardcopied message. And some of the responses here seem to reflect the same lack of understanding I have, probably because of fairly insufficient docs. Maybe IBM will consider to educate us at the next SHARE? Richard, But if I understand this correctly, these messages normally didn't go to syslog. They only went to syslog if MPF deleted them from the console. No. We don't have anything in MPF for ief403/404 (other than a no_entry statement explicitly saying SUP(NO)), and these messages certainly appear in hardcopy log *and* on the console. Brian, Personally I have used seemingly trivial Syslog entries to debug and correct issues that would have been difficult or next to impossible to do in a timely manner without them. I don't think making a no-log default is ever a good idea. I concur. Thanks. Best regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFHSM, Control-O, and Top Secret issue
Bill It seems that the security in the rule is SEC=TRIGGER, you may have to change it to SEC=OWNER *Best Regards Doron Geva *Consulting Developing on z/OS system Mobile: +972-54-4974548 Mail: doron.geva...@gmail.com On Fri, Jul 16, 2010 at 02:48, Bill Johnson mellonb...@yahoo.com wrote: Control-O already has auth to perform all of the commands that we've been running for years. This is a new rule owned by contrlo but initiated by programmers when they need to recall a migrated dataset. It looks like the programmers ID owns the recall and Control-O can't cancel it. Until that is the security guy gave storage admin auth to the programmers. The reason for this need is a long story and goes away this Sunday. Thanks From: Rob Schramm rob.schr...@siriuscom.com To: IBM-MAIN@bama.ua.edu Sent: Thu, July 15, 2010 3:18:17 PM Subject: Re: DFHSM, Control-O, and Top Secret issue Bill, I am unsure why this would be surprising. If the security is setup, properly.. you can deny pretty much anything. TSS PER(control-o's acid) OPERCMDS(MVS.REPLY) ACC(READ) TSSUTIL security report should show the reason for the denial. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Which OMEGAMON is correct?
Hi ITsckak We are DB2 only. We stop using IMS about 10 months ago All numbers related to ECSA Have fun Doron On Mon, Aug 25, 2008 at 10:16 PM, Itschak Mugzach [EMAIL PROTECTED]wrote: Doron, There is doubt that your CSA size in not 10M, there are only 16M down there... Did you use IRLM for IMS as well? I mean, may be from DB2 point of view IRLM uses only 10M in ECSA, and the rest 3MB are used by IMS settings left behind after IMS drop? Start OM for DBCTL and see what it has to tell about CSA consumption... ITschak On 8/24/08, Doron Geva [EMAIL PROTECTED] wrote: Hi All I need help in understanding the numbers OMEGAMONMVS nd DB2 show. In the site I work, we have DB2 and OMEGAMON MVS and DB2. The OMEGAMON for OMEGAMON DB2 shows that IRLM CSA numbers are: Max 10M *Current 8M* High watermark is 8M At the same time, OMEGAMON MVS shows that IRLM allocated: *1356K in ECSA * 15K in ESQA 256 bytes in SQA Can anyone explain the difference? Thanks Doron -- 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 -- Best Regards Doron Geva Email: [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
Which OMEGAMON is correct?
Hi All I need help in understanding the numbers OMEGAMONMVS nd DB2 show. In the site I work, we have DB2 and OMEGAMON MVS and DB2. The OMEGAMON for OMEGAMON DB2 shows that IRLM CSA numbers are: Max 10M *Current 8M* High watermark is 8M At the same time, OMEGAMON MVS shows that IRLM allocated: *1356K in ECSA * 15K in ESQA 256 bytes in SQA Can anyone explain the difference? Thanks Doron -- 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: APF authorization question
Hi since your boss came with - 00E40002 check if DSNUTILB is in the PPT (member SCHEDxx in the sys1.parmlib). It has to be define with *KEY(7)* On Wed, Aug 13, 2008 at 10:29 PM, Chase, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Walt Farrell On Wed, 13 Aug 2008 14:32:42 -0400, Fletcher, Kevin [EMAIL PROTECTED] wrote: We have a job running a db2 utility DSNUTILB and we are getting the generic db2 abend of S04E. Further probing determines this module is not APF'd. The SDSNLOAD lib is APF'd and is in the linklst. The job has a JOBLIB with non APF'd libraries and the db2 lib SDSNLOAD is not in the JOBLIB concatenation. I have scanned the libs in the JOBLIB and the DSNUTILB does not exist. When we use it in a stand alone STEPLIB the job works fine. My question is, is this working how it should? Does a JOBLIB invalidate APF authorization of a module pulled from the link list (remember no STEPLIB) when first tried? It appears there are no calls to sub modules. Any feedback would be appreciated. No, a JOBLIB does not generally invalidate APF authorization when you pull a module from the linklist. But authorization is a complex topic. Showing us your JCL and the invocation of DSNUTILB may shed some light on the issue. Check for message IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED Explanation: The initiator found that a program to be run did not satisfy all the requirements needed to obtain all the special properties designated by the program name. System Programmer Response: If no special properties are required, no action is necessary. If special properties are required and a JOBLIB or STEPLIB is in use, ensure that the JOBLIB or STEPLIB data sets are APF authorized. Also ensure the special attributes 'started only' or '1-step only' are satisfied for the required special properties. DSNUTILB has AC=1, which implies that (in some cases, at least) it needs special properties. This seems similar to CICS startup, which needs to run authorized for a portion of its initialization; thus requires that any libraries in a STEPLIB concatenation be APF-authorized. -jc- -- 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 -- Best Regards Doron Geva Email: [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
