Re: LE options
I prefer the PARMLIB method, but use the assembled module as a backup. With the PARMLIB method, displaying options is easier and making dynamic changes is easier. Also, as you pointed out, it allows you to have different options on different systems that share the LE libraries. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Friday, July 17, 2009 5:25 PM To: IBM-MAIN@bama.ua.edu Subject: LE options There appears to be (at least) two ways to change LE runtime options system wide. There's the assember macro table way (CEEDOPT for batch and CEECOPT for CICS) and there's the PARMLIB(CEEPRM00) way. Is one preferred over the other? Does one offer something the other does not? I am thinking that the PARMLIB way allows for multiple systems to share the same LE libraries and still have different LE options, if desired. Is this the reason for is its existence? If we use the PARMLIB way is there anything that has to be done with the macros and can't be done with the PARMLIB? Honestly, there are so many ways to change LE options that it's hard to keep them all straight! Thanks, This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- 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: LE options
On Fri, 17 Jul 2009 19:25:28 -0400, Lizette Koehler stars...@mindspring.com wrote: Don't forget that there is also a JCL over ride now at z/OS V1.9 (IIRC) that allows your programmers to put in the LE Parms there was well. Actually 2 releases earlier, z/OS 1.7 - via CEEOPTS DD. Not all options can be overridden at run time. For example RTEREUS=(ON), which has to do with how the run time environment is built, so specifying it at run time is too late. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: LE options
Thanks for all of the thoughts. We are already using the PARMLIB member, and it looks like we'll continue to do so. Just wanted to make sure that was the right choice. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: LE options
Thanks for all of the thoughts. We are already using the PARMLIB member, and it looks like we'll continue to do so. Just wanted to make sure that was the right choice. When I started in this business, almost everything was assembled tables and required huge unnatural acts to get things changed. But, we IPL'd every morning, so it wasn't an issue (much -- if it failed[?]). But, now (almost 30 years later), IPLs are not something we do, even with SYSPLEX. So, I'm a big proponent of as much 'clear text' dynamic parms as possible. But, change control is STILL required! IMO, even more so! - Too busy driving to stop for gas! -- 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: LE options
Frank Swarbrick pisze: I have read the manuals and understand there are many ways to set them. I'm interested in more fully understand, however, the pros and cons of CEEDOPT versus CEEPRMxx. Manuals too often tell you *how* to do things but not *why*. I think, its quite obvious. There is general trend to code parameters in text files instead of load modules. It's easier to code understand, less error-prone, usually dynamic (can be changed online). IMHO mainframe OSes are last systems which need assmbler for configuration and parametrization. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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
LE options
There appears to be (at least) two ways to change LE runtime options system wide. There's the assember macro table way (CEEDOPT for batch and CEECOPT for CICS) and there's the PARMLIB(CEEPRM00) way. Is one preferred over the other? Does one offer something the other does not? I am thinking that the PARMLIB way allows for multiple systems to share the same LE libraries and still have different LE options, if desired. Is this the reason for is its existence? If we use the PARMLIB way is there anything that has to be done with the macros and can't be done with the PARMLIB? Honestly, there are so many ways to change LE options that it's hard to keep them all straight! Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: LE options
On Fri, 17 Jul 2009 15:25:26 -0600, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: There are more ways (CEEROPT, CEEUOPT and more). Check the manuals for more details about the order of settings. Also understand the term LE enclave and how the LE options takes effect for some application especially under CICS. BTW: SHOWzOS shows the CEEDOPT and CEEPRMxx settings Roland There appears to be (at least) two ways to change LE runtime options system wide. There's the assember macro table way (CEEDOPT for batch and CEECOPT for CICS) and there's the PARMLIB(CEEPRM00) way. Is one preferred over the other? Does one offer something the other does not? I am thinking that the PARMLIB way allows for multiple systems to share the same LE libraries and still have different LE options, if desired. Is this the reason for is its existence? If we use the PARMLIB way is there anything that has to be done with the macros and can't be done with the PARMLIB? Honestly, there are so many ways to change LE options that it's hard to keep them all straight! -- 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: LE options
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Friday, July 17, 2009 4:25 PM To: IBM-MAIN@bama.ua.edu Subject: LE options There appears to be (at least) two ways to change LE runtime options system wide. There's the assember macro table way (CEEDOPT for batch and CEECOPT for CICS) and there's the PARMLIB(CEEPRM00) way. Is one preferred over the other? Does one offer something the other does not? I am thinking that the PARMLIB way allows for multiple systems to share the same LE libraries and still have different LE options, if desired. Is this the reason for is its existence? If we use the PARMLIB way is there anything that has to be done with the macros and can't be done with the PARMLIB? SNIP Be aware of the differences in the defaults from release to release. You may find that behaviors change for not so obvious reasons, all because of depending on a default setting that changes. Regards, Steve Thompson -- 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
LE options
Frank, As others have pointed out, there are still other ways to do set LE options. One difference between the old ways (e.g. CEEDCOPT) and the new ways (PARMLIB) is that the old ways allowed for fixed options, i.e. system defaults that could NOT be overridden by the programmer or later methods of setting options. For some people, this is/was a good thing and for others it was not. Certainly the IBM direction (as seen with more recent options) is AWAY from fixed options. OBVIOUSLY, get used to how the RPTOPTS shows options in effect and where they were/are sent. See, for example http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea1190/1.1.2.1 Frank Swarbrick frank.swarbr...@efirstbank.com wrote in message news:4a6097e6.6f0f.008...@efirstbank.com... There appears to be (at least) two ways to change LE runtime options system wide. There's the assember macro table way (CEEDOPT for batch and CEECOPT for CICS) and there's the PARMLIB(CEEPRM00) way. Is one preferred over the other? Does one offer something the other does not? I am thinking that the PARMLIB way allows for multiple systems to share the same LE libraries and still have different LE options, if desired. Is this the reason for is its existence? If we use the PARMLIB way is there anything that has to be done with the macros and can't be done with the PARMLIB? Honestly, there are so many ways to change LE options that it's hard to keep them all straight! Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: LE options
Don't forget that there is also a JCL over ride now at z/OS V1.9 (IIRC) that allows your programmers to put in the LE Parms there was well. So many choices, so little time. Lizette There appears to be (at least) two ways to change LE runtime options system wide. There's the assember macro table way (CEEDOPT for batch and CEECOPT for CICS) and there's the PARMLIB(CEEPRM00) way. Is one preferred over the other? Does one offer something the other does not? I am thinking that the PARMLIB way allows for multiple systems to share the same LE libraries and still have different LE options, if desired. Is this the reason for is its existence? If we use the PARMLIB way is there anything that has to be done with the macros and can't be done with the PARMLIB? Honestly, there are so many ways to change LE options that it's hard to keep them all straight! -- 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: LE options
I have read the manuals and understand there are many ways to set them. I'm interested in more fully understand, however, the pros and cons of CEEDOPT versus CEEPRMxx. Manuals too often tell you *how* to do things but not *why*. -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 On 7/17/2009 at 3:34 PM, in message listserv%200907171634126241.0...@bama.ua.edu, Roland Schiradin rol...@schiradin.de wrote: On Fri, 17 Jul 2009 15:25:26 -0600, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: There are more ways (CEEROPT, CEEUOPT and more). Check the manuals for more details about the order of settings. Also understand the term LE enclave and how the LE options takes effect for some application especially under CICS. BTW: SHOWzOS shows the CEEDOPT and CEEPRMxx settings Roland There appears to be (at least) two ways to change LE runtime options system wide. There's the assember macro table way (CEEDOPT for batch and CEECOPT for CICS) and there's the PARMLIB(CEEPRM00) way. Is one preferred over the other? Does one offer something the other does not? I am thinking that the PARMLIB way allows for multiple systems to share the same LE libraries and still have different LE options, if desired. Is this the reason for is its existence? If we use the PARMLIB way is there anything that has to be done with the macros and can't be done with the PARMLIB? Honestly, there are so many ways to change LE options that it's hard to keep them all straight! -- 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 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: LE options
Don't forget that there is also a JCL over ride now at z/OS V1.9 (IIRC) that allows your programmers to put in the LE Parms there was well. That's been around a lot longer than 1.9! IIRC, it was around during OS/390. The option(s) are specified by: //STEP EXEC PGM=appl,PARM='appl/LE' Or vice versa: //STEP EXEC PGM=appl,PARM='LE/appl' I don't remember which way it's specified, but I also think that's an installation option. And, it was way back! - Too busy driving to stop for gas! -- 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: LE options
anuals too often tell you *how* to do things but not *why*. I guess, in my case, it's because it's dynamic and more flexible. So, I prefer PARMLIB. - Too busy driving to stop for gas! -- 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: LE options
Actually I was talking about the //CEEOPT DD statement that can be added to JCL rather than the PARM. Lizette Don't forget that there is also a JCL over ride now at z/OS V1.9 (IIRC) that allows your programmers to put in the LE Parms there was well. That's been around a lot longer than 1.9! IIRC, it was around during OS/390. The option(s) are specified by: //STEP EXEC PGM=appl,PARM='appl/LE' Or vice versa: //STEP EXEC PGM=appl,PARM='LE/appl' I don't remember which way it's specified, but I also think that's an installation option. And, it was way back! -- 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: Utility for LE Options?
SHOWzOS and COBANAL display the CEExOPT settings but not for CEEROPT. However the code should also work for CEEROPT unless you modify it and load the CEEROPT entry. Starting with z/OS R9 (?) IBM deliver a macro (CEEOCB?) to map the CEExOPT. Regards Roland Is there some utility out there where you supply as input the CEEROPT load module, and the utility reports on what options it specifies? I'd hate to write one only to find out that I re-invented the wheel... Thanks. Adam Johanson IMS Systems Programming USAA -- 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
Utility for LE Options?
Is there some utility out there where you supply as input the CEEROPT load module, and the utility reports on what options it specifies? I'd hate to write one only to find out that I re-invented the wheel... Thanks. Adam Johanson IMS Systems Programming USAA -- 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: Utility for LE Options?
Is this for IMS, CICS, Batch or other environment? What level of z/OS would you be running this on? Cics has CLER for seeing the options, and I think IMS may also have one for the online side. If you are at z/OS V1.9 then the parms might be maintained in CEEPRMxx in SYS1.PARMLIB or a CEEOPT DD statement in the JCL. What are you looking for specifically? Lizette Is there some utility out there where you supply as input the CEEROPT load module, and the utility reports on what options it specifies? I'd hate to write one only to find out that I re-invented the wheel... Thanks. -- 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: Utility for LE Options?
It's for an IMS MPR. We're at z/OS 1.9. What I'd really like is for the utility to take the load module, and output the CEEXOPT macro, complete with options contained in the CEEROPT module. -- 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
Utility for LE Options?
OOPS, my idea won't work. It is the CEEROPT module itself that you are trying to find what options are set. I do not know of a dis-assembler for a CEEROPT load module. -Original Message- From: Bill Klein [mailto:wmkl...@ix.netcom.com] Sent: Monday, January 19, 2009 6:44 PM To: IBM-MAIN (IBM-MAIN@BAMA.UA.EDU) Subject: Fw: Utility for LE Options? I don't know if this is what you are looking for, but at LE 1.9, you can A) create a CEEROPT stand-alone module with RPTOPTS(ON) (You may or may not want to modify MSGFILE as well) See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cee a2180/1.9.2 B) place the resuliting load module in in you IMS JCL and run the MPR C) check your output. It will show you what options are set in that region and where they are set. See for example, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cee a1180/1.1.2.1 This will NOT tell you what the options are in sources that were overriden nor will it provide output that is already in macro format - but I think it should (might?) give you want you want. Adam Johanson adam.johan...@usaa.com wrote in message news:listserv%200901191506445185.0...@bama.ua.edu... It's for an IMS MPR. We're at z/OS 1.9. What I'd really like is for the utility to take the load module, and output the CEEXOPT macro, complete with options contained in the CEEROPT module. -- 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
Utility for LE Options?
Final thought (replying to myself, replying to myself G) Code a small program that CALLs CEE3DMP, that program's output will show you the run-time options in effect. -Original Message- From: Bill Klein [mailto:wmkl...@ix.netcom.com] Sent: Monday, January 19, 2009 6:53 PM To: IBM-MAIN (IBM-MAIN@BAMA.UA.EDU) Subject: Utility for LE Options? OOPS, my idea won't work. It is the CEEROPT module itself that you are trying to find what options are set. I do not know of a dis-assembler for a CEEROPT load module. -Original Message- From: Bill Klein [mailto:wmkl...@ix.netcom.com] Sent: Monday, January 19, 2009 6:44 PM To: IBM-MAIN (IBM-MAIN@BAMA.UA.EDU) Subject: Fw: Utility for LE Options? I don't know if this is what you are looking for, but at LE 1.9, you can A) create a CEEROPT stand-alone module with RPTOPTS(ON) (You may or may not want to modify MSGFILE as well) See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cee a2180/1.9.2 B) place the resuliting load module in in you IMS JCL and run the MPR C) check your output. It will show you what options are set in that region and where they are set. See for example, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cee a1180/1.1.2.1 This will NOT tell you what the options are in sources that were overriden nor will it provide output that is already in macro format - but I think it should (might?) give you want you want. Adam Johanson adam.johan...@usaa.com wrote in message news:listserv%200901191506445185.0...@bama.ua.edu... It's for an IMS MPR. We're at z/OS 1.9. What I'd really like is for the utility to take the load module, and output the CEEXOPT macro, complete with options contained in the CEEROPT module. -- 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
Fw: Utility for LE Options?
I don't know if this is what you are looking for, but at LE 1.9, you can A) create a CEEROPT stand-alone module with RPTOPTS(ON) (You may or may not want to modify MSGFILE as well) See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea2180/1.9.2 B) place the resuliting load module in in you IMS JCL and run the MPR C) check your output. It will show you what options are set in that region and where they are set. See for example, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea1180/1.1.2.1 This will NOT tell you what the options are in sources that were overriden nor will it provide output that is already in macro format - but I think it should (might?) give you want you want. Adam Johanson adam.johan...@usaa.com wrote in message news:listserv%200901191506445185.0...@bama.ua.edu... It's for an IMS MPR. We're at z/OS 1.9. What I'd really like is for the utility to take the load module, and output the CEEXOPT macro, complete with options contained in the CEEROPT module. -- 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: PARMLIB(s) (Was: how to list LE options)
On Mon, 7 Jan 2008 20:30:53 -0600, Ed Gould wrote: //STEP1 EXEC PGM=BPXBATCH,PARM='PGM /bin/sleep ' //STEP2 EXEC PGM=IEFBR14,COND=(0,LE) //SYSUT99 DD DISP=OLD,DSN=SYS1.PARMLIB ... but RACF won't help you there. But the initiator might stop you as RMF has (assuming you are running RMF) the disp=shr in its JCL. But the damage is done; the job is tying up an initiator and requesting an exclusive ENQ which prevents any further allocations of PARMLIB. -- gil -- 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: PARMLIB(s) (Was: how to list LE options)
On Mon, 7 Jan 2008 20:30:53 -0600, Ed Gould wrote: On Jan 7, 2008, at 12:32 PM, Paul Gilmartin wrote: Take my remark as largely rhetorical. IIRC, I was rebutting a prior post expressing a phobic delusion that if PARMLIB had UACC=READ, an incompetently or maliciously crafted job might ABEND leaving an unreleased restrictive ENQ on PARMLIB. I never considered it a realistic concern. (more likely means some larger multiple of 0.) Of course, there's always: //STEP1 EXEC PGM=BPXBATCH,PARM='PGM /bin/sleep ' //STEP2 EXEC PGM=IEFBR14,COND=(0,LE) //SYSUT99 DD DISP=OLD,DSN=SYS1.PARMLIB ... but RACF won't help you there. Gil: But the initiator might stop you as RMF has (assuming you are running RMF) the disp=shr in its JCL. And you will be waiting for your exclusive enq on parmlib. Meanwhile, if I'm not mistaken, anyone else who tries to enq it will queue behind your exclusive request. -- Tom Marchant -- 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: PARMLIB(s) (Was: how to list LE options)
On Jan 8, 2008, at 7:21 AM, Paul Gilmartin wrote: On Mon, 7 Jan 2008 20:30:53 -0600, Ed Gould wrote: //STEP1 EXEC PGM=BPXBATCH,PARM='PGM /bin/sleep ' //STEP2 EXEC PGM=IEFBR14,COND=(0,LE) //SYSUT99 DD DISP=OLD,DSN=SYS1.PARMLIB ... but RACF won't help you there. But the initiator might stop you as RMF has (assuming you are running RMF) the disp=shr in its JCL. But the damage is done; the job is tying up an initiator and requesting an exclusive ENQ which prevents any further allocations of PARMLIB. Well yes but the address space will gets swapped out and either the operator gets awoken by the aiutomation product or the automation product cancels the job. It depends. 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: PARMLIB(s) (Was: how to list LE options)
In [EMAIL PROTECTED], on 06/27/2007 at 02:19 PM, Paul Gilmartin [EMAIL PROTECTED] said: But, as discussed here recently, prohibiting read access doesn't prevent the allocation, and it might be more likely that a program that ABENDs on OPEN will exit abnormally without doing the FREE. Depending on how he is looking at the data set, the free might be automatic. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: PARMLIB(s) (Was: how to list LE options)
On Mon, 7 Jan 2008 12:46:34 -0500, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 06/27/2007 Time warp? at 02:19 PM, Paul Gilmartin said: But, as discussed here recently, prohibiting read access doesn't prevent the allocation, and it might be more likely that a program that ABENDs on OPEN will exit abnormally without doing the FREE. Depending on how he is looking at the data set, the free might be automatic. Take my remark as largely rhetorical. IIRC, I was rebutting a prior post expressing a phobic delusion that if PARMLIB had UACC=READ, an incompetently or maliciously crafted job might ABEND leaving an unreleased restrictive ENQ on PARMLIB. I never considered it a realistic concern. (more likely means some larger multiple of 0.) Of course, there's always: //STEP1 EXEC PGM=BPXBATCH,PARM='PGM /bin/sleep ' //STEP2 EXEC PGM=IEFBR14,COND=(0,LE) //SYSUT99 DD DISP=OLD,DSN=SYS1.PARMLIB ... but RACF won't help you there. -- gil -- 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: PARMLIB(s) (Was: how to list LE options)
On Jan 7, 2008, at 12:32 PM, Paul Gilmartin wrote: On Mon, 7 Jan 2008 12:46:34 -0500, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 06/27/2007 Time warp? at 02:19 PM, Paul Gilmartin said: But, as discussed here recently, prohibiting read access doesn't prevent the allocation, and it might be more likely that a program that ABENDs on OPEN will exit abnormally without doing the FREE. Depending on how he is looking at the data set, the free might be automatic. Take my remark as largely rhetorical. IIRC, I was rebutting a prior post expressing a phobic delusion that if PARMLIB had UACC=READ, an incompetently or maliciously crafted job might ABEND leaving an unreleased restrictive ENQ on PARMLIB. I never considered it a realistic concern. (more likely means some larger multiple of 0.) Of course, there's always: //STEP1 EXEC PGM=BPXBATCH,PARM='PGM /bin/sleep ' //STEP2 EXEC PGM=IEFBR14,COND=(0,LE) //SYSUT99 DD DISP=OLD,DSN=SYS1.PARMLIB ... but RACF won't help you there. Gil: But the initiator might stop you as RMF has (assuming you are running RMF) the disp=shr in its JCL. -- 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: PARMLIB(s) (Was: how to list LE options)
In [EMAIL PROTECTED], on 06/21/2007 at 02:58 PM, Tom Savor [EMAIL PROTECTED] said: Funny how it's ok for SYSPROGs to cruise Applications and tell us what needs to be changed or how to tune our application (when we didn't ask for their opinion), but it's not ok for us to cruise your PARMLIB settings Never heard of a PARMLIB setting getting screwed-up by looking at it. Unbelieveable !!! But never forget that the original Dilbert strips were nature studies. IMHO there should be transparency in both directions, subject to security issues. However, don't keep long ENQ's on the datasets that you want to view. Similarly, don't waste people's time suggesting improvements that aren't; learn what it actually does, and why, before suggesting changes. Another pet-peave, why do companies buy tools, then SYSPROG decides that only they get to use it. Sometimes it's an ego trip, sometimes it's due to management decree. I've been at shops where I was allowed to build my own tools and to install tools from, e.g., the CBT tape, but I was *not* allowed to make them available to the users, on the grounds that anything we made available had to be supported and that we weren't authorized to commit to the support. I asked them why can't we both use it ??, answer...because none of the applications asked for it. ROTF,LMAO! The correct answer was Whoops! It was an oversight. It was their job to determine who needed access and to convince people to use it when it was to the company's benefit. Of course, given that they were your customer you needed to be diplomatic. More and more SYSPROGs like to hide their stuff, even from viewing. My guess is that either they are not sysprogs or the decision was imposed from above. If your system security is setup properly, I can see no harm in browsing anything on the system. One problem, which has been discussed here before, is users who allocate systems data sets and don't free them when they're done browsing. In a shop where you're not allowed to cancel their sessions, the easiest fix is to remove the read access. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: PARMLIB(s) (Was: how to list LE options)
On Wed, 27 Jun 2007 09:13:09 -0300, Shmuel Metz (Seymour J.) wrote: If your system security is setup properly, I can see no harm in browsing anything on the system. One problem, which has been discussed here before, is users who allocate systems data sets and don't free them when they're done browsing. In a shop where you're not allowed to cancel their sessions, the easiest fix is to remove the read access. But, as discussed here recently, prohibiting read access doesn't prevent the allocation, and it might be more likely that a program that ABENDs on OPEN will exit abnormally without doing the FREE. -- gil -- 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: SV: how to list LE options
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Gould On Jun 22, 2007, at 7:05 AM, Thomas Berg wrote: == Ed Gould == wrote2007-06-21 21:58: On Jun 21, 2007, at 4:44 AM, Thomas Berg wrote: --SNIP-- The consultants howled as they could no longer assemble programs (no access to sys1.maclib) ??? Our official language was COBOL nothing else was permitted into production. The consultants had a habit of doing the other work on our system, those contained assembler. Ed Still don't understand why they wasn't allowed to assemble their programs. Were they doing private programming or what ? Thomas Berg ---SNIP The standard company wide language was COBOL. None of the programmers knew assembler. As I explained in a previous post none of the programmers could debug assembler code. The consultants were using our resources to compile programs for the consultants essentially stealing resources from our company. The two steps we made to stop the process was taking away access to sys1.maclib and also not allowing assembler to be invoked. Oh Sort of like, None of the folks knew how to use a lawn mower, so they banned lawns. Must have been a gummint shop. -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
Re: SV: how to list LE options
The consultants were using our resources to compile programs for the consultants essentially stealing resources from our company. The two steps we made to stop the process was taking away access to sys1.maclib and also not allowing assembler to be invoked. You let them off easy! I would have dismissed them, right away. - Too busy driving to stop for gas! -- 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: SV: how to list LE options
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL The consultants were using our resources to compile programs for the consultants essentially stealing resources from our company. ... You let them off easy! I would have dismissed them, right away. Along with giving them some free room and board at the local Crossbar Hotel. -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
Re: SV: how to list LE options
On Jun 25, 2007, at 7:50 AM, Chase, John wrote: --SNIP- The consultants were using our resources to compile programs for the consultants essentially stealing resources from our company. The two steps we made to stop the process was taking away access to sys1.maclib and also not allowing assembler to be invoked. Oh Sort of like, None of the folks knew how to use a lawn mower, so they banned lawns. Must have been a gummint shop. John, The programmers were the one to initiate this process. They were the ones who only knew COBOL and could not figure out assembler. They were far from dumb just not trained in assembler. I guess I couldn't blame them. It would be like getting called in on APL2 and not having a clue what it was. I certainly wasn't conversant in it. I was able to call IBM and report the problem and get a resolution to it. But did not know anything but how to spell it. In the case of assembler they had no one to call. One could argue they could learn it but not at 2AM. There was no sense in trying to hire programmers who already knew it as 100 percent (or 99.9) of the programs was written in COBOL. Would you hire (at more $$) a person that might never use his (or her) expertise? Do you think a programmer would even consider such a position? My feeling and talking with hiring managers then the answer is no. This was back in the early 80's and finding experience programmers was just difficult. Ed -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 -- 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: SV: how to list LE options
== Ed Gould == wrote2007-06-23 13:09: On Jun 23, 2007, at 4:15 AM, Thomas Berg wrote: -SNIP That explains it. But what were they expected to do, btw ? Thomas Berg -- I am not sure I understand the question. They were expected to work on any work that was assigned to them by our company. Not use their time there for some other use. snip Of course. Was just curious. Seems to me that they were ineffectively used. (As they have time to do private work.) Thomas Berg -- __ Mundus Vult Decipi __ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Military justice is to justice what military music is to music. - Groucho Marx -- 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: SV: how to list LE options
== Ed Gould == wrote2007-06-23 01:49: On Jun 22, 2007, at 7:05 AM, Thomas Berg wrote: Still don't understand why they wasn't allowed to assemble their programs. Were they doing private programming or what ? Thomas Berg ---SNIP The standard company wide language was COBOL. None of the programmers knew assembler. As I explained in a previous post none of the programmers could debug assembler code. The consultants were using our resources to compile programs for the consultants essentially stealing resources from our company. The two steps we made to stop the process was taking away access to sys1.maclib and also not allowing assembler to be invoked. Ed That explains it. But what were they expected to do, btw ? Thomas Berg -- __ Mundus Vult Decipi __ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Military justice is to justice what military music is to music. - Groucho Marx -- 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: SV: how to list LE options
On Jun 23, 2007, at 4:15 AM, Thomas Berg wrote: -SNIP That explains it. But what were they expected to do, btw ? Thomas Berg -- I am not sure I understand the question. They were expected to work on any work that was assigned to them by our company. Not use their time there for some other use. We had one consultant that was an ISV and was using our system to do development work on his product. THEN he tried to sell the work to us at the retail price. What a rip off. Yes it was a management issue but our management (and I use the term loosely) did not require time sheets and the like. Nor did management stay much after 5PM to see what was going on. When most of the goofing off was occurring. *IF* we would have had had a single programmer trying to do a homework assignment I probably would never had done this. I would have probably run through SMF and sent the report over to the application people for them to decide. 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: SV: how to list LE options
Ed Gould wrote: I am not sure I understand the question. They were expected to work on any work that was assigned to them by our company. Not use their time there for some other use. We had one consultant that was an ISV and was using our system to do development work on his product. THEN he tried to sell the work to us at the retail price. What a rip off. I've been on both sides of this issue. When doing consulting work, it's a lot quicker (selling point) to use software you're comfortable with, instead of trying to learn non-standard software or options the client has. I had a standard agreement that they retained the right to use the software, in exchange for my installing it, and if necessary, modifying it to adapt to their environment. In twenty years, only two installations declined the offer; one was a government site with security concerns, the other insisted on 100% ownership of anything developed at their facility - so they got 100% of nothing, instead. Yes it was a management issue but our management (and I use the term loosely) did not require time sheets and the like. Nor did management stay much after 5PM to see what was going on. When most of the goofing off was occurring. That's poor practice. I have never worked on a consulting contract that didn't require time sheets. *IF* we would have had had a single programmer trying to do a homework assignment I probably would never had done this. I would have probably run through SMF and sent the report over to the application people for them to decide. To me that seems backwards. As systems manager, I had the chance to get other employees interested in programming; learning makes jobs easier to understand and carry out. One of our operators wrote a very nice football game, with suggestions and feedback from other operators and programmers, and it spoiled him G. Last time I ran into him at Share he was an IBM manager, complete with three piece suit and pocket watch with fob. Gerhard Postpischil Bradford, VT new e-mail address: gerhardp (at) charter (dot) net -- 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: SV: how to list LE options
On Jun 23, 2007, at 12:57 PM, Gerhard Postpischil wrote: Ed Gould wrote: I am not sure I understand the question. They were expected to work on any work that was assigned to them by our company. Not use their time there for some other use. We had one consultant that was an ISV and was using our system to do development work on his product. THEN he tried to sell the work to us at the retail price. What a rip off. I've been on both sides of this issue. When doing consulting work, it's a lot quicker (selling point) to use software you're comfortable with, instead of trying to learn non-standard software or options the client has. I had a standard agreement that they retained the right to use the software, in exchange for my installing it, and if necessary, modifying it to adapt to their environment. In twenty years, only two installations declined the offer; one was a government site with security concerns, the other insisted on 100% ownership of anything developed at their facility - so they got 100% of nothing, instead. When I got feelers to install the product so everyone could use it. I wanted to make sure there was a signed contract and also some assurance it didn't need any APF or SVC's type requirements or any operating system dependencies. I also had a few other simple requests like who was going to maintain it and who was going to call in problems and to where. The individual thought those questions were way to much and wouldn't answer them. I suggested to management that if they needed a product to right up their requirements and we could do a joint search and go through the proper channels. I wanted to make sure that everyone had input. They didn't want to go through the process so I just sent back the request with a note to defer any payment to the vendor until the applications manager put things in writing. Yes it was a management issue but our management (and I use the term loosely) did not require time sheets and the like. Nor did management stay much after 5PM to see what was going on. When most of the goofing off was occurring. That's poor practice. I have never worked on a consulting contract that didn't require time sheets. What can I say our managers seemed to be the trusting kind. I did not agree but it wasn't my place to say so. zzsnip--- To me that seems backwards. As systems manager, I had the chance to get other employees interested in programming; learning makes jobs easier to understand and carry out. One of our operators wrote a very nice football game, with suggestions and feedback from other operators and programmers, and it spoiled him G. Last time I ran into him at Share he was an IBM manager, complete with three piece suit and pocket watch with fob. I have worked with such a person (in fact he is now a billionaire) from the money he made from the company he started and then sold to CA. Good for him I hope he enjoys the $$. He swore he would never sell the company but the big bucks was just too much temptation. On the other hand I can also tell you about another consulting company that was fairly dishonest. Yes they paid their people the BIG $$, but they were nothing but crooks when they came down to it. I had utter contempt for all its employees and the work they did. 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: HR policy (was: how to list LE options)
Chase, John wrote: [...] ITYM dumb rather than stupid (dumb is curable via education; stupid is as stupid does). That was actually a stated policy in a university (!!) where I worked previously. In that boss's own words, If we allow you more training, your marketability will be enhanced and you'll leave us for more money somewhere else. It is quite common HR policy. It is usually kept 'in secret' (in silence at least), becasue it nothing to be proud of, but it is in quite common use. From the other hand I know companies in Poland where people work for two reasons: a) to get some experience, take some classes and go away with better CV. b) because they don't want to learn, they don't want to work to hard, usually they rather stupid than dumb. Since I part of my job is teaching on mainframe courses, I often meet them (only mainframe staff in fact) and observe their careers. Sometimes one can distinguish a and b -types during first lab. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: Security vs knowledge [was: RE: how to list LE options]
This thread was originally entitled How to list LE Options. One of the responses was to browse the LE options member of PARMLIB. I see this as a valid requirement for an application programmer. Hence they need READ access to PARMLIB. However I, from a system programmers perspective, know that there is information, members, in PARMLIB that people other than the system programmers should know. Hence the UACC(NONE) argument. All valid many years ago but today with the ability to concatenate PARMLIB we, the system programmers, just need to put a little effort into segregating members into READ/NOREAD areas. This will still not satisfy every one especially people like Peter Farley who reading between the lines of many of this posts his probably involved in applications tuning and probably has a real argument for a higher degree of read access to many members Ken Brick -- 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: Security vs knowledge [was: RE: how to list LE options]
On 6/22/07, J R [EMAIL PROTECTED] wrote: In the JES2 Init deck, you can specify clear text passwords for RJE lines. That is a great reason for specifying UACC(NONE). That sounds like a great reason for not keeping the JES2 Init deck in PARMLIB. Yes, indeed. Otherwise someone with an approved need to see the LE options (or something else) would automatically be able to see your passwords. A popular response to my why do you need that is people dreaming up some possible emergency situation that never happened but might occur some day (when everyone else is sick and there is a sev 1, so I need write access on production libraries all the time). Where technically feasible, I like an approach where exceptional access can be granted but is audited properly and requires justification afterwards. If needed a separate RACF userid can be used (because it is not something you need for your normal work). We found logonby useful to implement this. If needed you could even have a duty-manager involved in the process to grant accesss to the call-out person (rather than share this week's operator password on the phone). Rob -- 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: how to list LE options
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Thomas Berg -Ursprungligt meddelande- Från: IBM Mainframe Discussion List För Ed Gould The consultants howled as they could no longer assemble programs (no access to sys1.maclib) ??? If you hire consultants to (among other things) assemble programs, then configure security to prevent them from doing so, why are you not in breach of contract? -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
Re: SV: how to list LE options
== Ed Gould == wrote2007-06-21 21:58: On Jun 21, 2007, at 4:44 AM, Thomas Berg wrote: --SNIP-- The consultants howled as they could no longer assemble programs (no access to sys1.maclib) ??? Our official language was COBOL nothing else was permitted into production. The consultants had a habit of doing the other work on our system, those contained assembler. Ed Still don't understand why they wasn't allowed to assemble their programs. Were they doing private programming or what ? Thomas Berg -- __ Mundus Vult Decipi __ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Military justice is to justice what military music is to music. - Groucho Marx -- 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: how to list LE options
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Barkow, Eileen that in most medium to large organizations, lines do need to be drawn in order to keep people focused on the jobs they are hired to do I take this to mean keep them stupid so that they cannot get a job anywhere else. ITYM dumb rather than stupid (dumb is curable via education; stupid is as stupid does). That was actually a stated policy in a university (!!) where I worked previously. In that boss's own words, If we allow you more training, your marketability will be enhanced and you'll leave us for more money somewhere else. Well, No $h1t, Sherlock! -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
Re: Security vs knowledge [was: RE: how to list LE options]
On Fri, 22 Jun 2007 16:27:40 +1000, Ken Brick [EMAIL PROTECTED] wrote: All valid many years ago but today with the ability to concatenate PARMLIB we, the system programmers, just need to put a little effort into segregating members into READ/NOREAD areas. This will still not satisfy every one especially people like Peter Farley who reading between the lines of many of this posts his probably involved in applications tuning and probably has a real argument for a higher degree of read access to many members That will work, but if he has a valid need the security product rules can also be changed to allow him access. UACC is just a default. It doesn't mean it's right for all or everyone in a particular group with similar job functions. There can be exceptions. I myself have the AUDITOR attribute in RACF to help diagnose problems that may be security related that aren't obvious. But not all the MVS sysprogs have it.All AUDITOR does is give me READ access to profiles and doesn't let me circumvent security in any way, but every year during audit my manager and the security manager have to sign off on the access and explain it. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Security vs knowledge [was: RE: how to list LE options]
All AUDITOR does is give me READ access to profiles and doesn't let me circumvent security in any way, but every year during audit my manager and the security manager have to sign off on the access and explain it. Doesn't it also allow you to make changes using SETROPTS? - Too busy driving to stop for gas! -- 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: how to list LE options
O SNIP ITYM dumb rather than stupid (dumb is curable via education; stupid is as stupid does). That was actually a stated policy in a university (!!) where I worked previously. In that boss's own words, If we allow you more training, your marketability will be enhanced and you'll leave us for more money somewhere else. Well, No $h1t, Sherlock! John, Thanks for reminding me of this. I had put this out of my memory. (wish it had never happened ). The senior VP of a company that I worked for had this belief. He would never send anyone for training no matter what. At the time the way they scheduled jobs was to read all the jobs into the input Q with typrun=hold, and then depended on the operator to release them in the right sequence. The number of jobs that were read in grew to be over 1000 and the poor operator had a hell of a time keeping track of them. AFter a few mistakes and the time lost from the mistakes the market didn't open on time (we were fined big time). They finally decided to get a job scheduler. The went out and found one and purchased it. They thought they had worked out how to use it. The first night was almost catastrophic. They just didn't understand how to schedule for it. Instead of training their people the decided to hire consultants the next attempt was a little better (at least the market opened on time). This went one for several weeks finally a news system was to be turned over to production and the proverbial hell arose . The market did not open on time either. The VP was called on the carpet for a dressing down like he had never gotten before. The next day we had a 5 people appear out of nowhere from the vendor to give classes for the scheduler and the production control people were given an intensive 2 day class. Even the night shift people were brought in. The results were self evident they rewrote the nights schedule with some help from the trainers and the next night the production ran rather well. Yes there were some rough edges but the jobs did get done in the right sequence. From then on the VP always made it part of the job for training. It took him getting raked over the coals to get it to happen. 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: Security vs knowledge [was: RE: how to list LE options]
On Fri, 22 Jun 2007 16:27:40 +1000, Ken Brick wrote: This thread was originally entitled How to list LE Options. One of the responses was to browse the LE options member of PARMLIB. I see this as a valid requirement for an application programmer. Hence they need READ access to PARMLIB. Since this thread has been taken over by another religious war, it's impossible to tell if the original poster actually got something useful out of the reponses. Remember the stories written about ServiceLink outages quoting mostly from this list Give it a rest or the Windows folks will start to appear reasonable every time they ask a user to reboot. -- 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: PARMLIB(s) (Was: how to list LE options)
---snip-- Funny how it's ok for SYSPROGs to cruise Applications and tell us what needs to be changed or how to tune our application --unsnip- In our shop, it was called Quality Assurance Review and we caught some real howlers. Like OPEN and CLOSE within the loop that actually wrote the records. Or IDMS PREPARE, fetch and update and IDMS FINISH within a database update loop. -- 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: how to list LE options
Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Barkow, Eileen that in most medium to large organizations, lines do need to be drawn in order to keep people focused on the jobs they are hired to do I take this to mean keep them stupid so that they cannot get a job anywhere else. ITYM dumb rather than stupid (dumb is curable via education; stupid is as stupid does). That was actually a stated policy in a university (!!) where I worked previously. In that boss's own words, If we allow you more training, your marketability will be enhanced and you'll leave us for more money somewhere else. Not just univeristies. There was a period of time when many businesses also adopted that policy. sarcasmThank goodness those days are past./sarcasm Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- 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: how to list LE options
On Jun 22, 2007, at 6:48 AM, Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Thomas Berg -Ursprungligt meddelande- Från: IBM Mainframe Discussion List För Ed Gould The consultants howled as they could no longer assemble programs (no access to sys1.maclib) ??? If you hire consultants to (among other things) assemble programs, then configure security to prevent them from doing so, why are you not in breach of contract? I thought I made it clear, perhaps not. The only language company wide that was to be used was COBOL. None of the applications types knew any assembler. If they were called in in the middle of the night and they found out the program was assembler. They bumped the problem to the one lone programmer that vaguely understood assembler. Most of the time he would say its a systems issue and then we were called. Only to point the finger back at the applications people and the fun began. Ed -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 -- 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: SV: how to list LE options
On Jun 22, 2007, at 7:05 AM, Thomas Berg wrote: == Ed Gould == wrote2007-06-21 21:58: On Jun 21, 2007, at 4:44 AM, Thomas Berg wrote: --SNIP-- The consultants howled as they could no longer assemble programs (no access to sys1.maclib) ??? Our official language was COBOL nothing else was permitted into production. The consultants had a habit of doing the other work on our system, those contained assembler. Ed Still don't understand why they wasn't allowed to assemble their programs. Were they doing private programming or what ? Thomas Berg ---SNIP The standard company wide language was COBOL. None of the programmers knew assembler. As I explained in a previous post none of the programmers could debug assembler code. The consultants were using our resources to compile programs for the consultants essentially stealing resources from our company. The two steps we made to stop the process was taking away access to sys1.maclib and also not allowing assembler to be invoked. 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: PARMLIB(s) (Was: how to list LE options)
- Original Message - From: Rick Fochtman [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, June 22, 2007 12:44 PM Subject: Re: PARMLIB(s) (Was: how to list LE options) ---snip-- Funny how it's ok for SYSPROGs to cruise Applications and tell us what needs to be changed or how to tune our application --unsnip- In our shop, it was called Quality Assurance Review and we caught some real howlers. Like OPEN and CLOSE within the loop that actually wrote the records. Or IDMS PREPARE, fetch and update and IDMS FINISH within a database update loop. LOL! Or like installing ISPF-based products without renaming the default library names! Oh wait, that was a sysprog screwupnever mind... :-) -- 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
SV: how to list LE options
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] För Ed Gould Skickat: den 21 juni 2007 04:49 Till: IBM-MAIN@BAMA.UA.EDU Ämne: Re: how to list LE options The consultants howled as they could no longer assemble programs (no access to sys1.maclib) ??? Thomas Berg IT Utveckling Swedbank AB (Publ) -- 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: how to list LE options
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Phil Knight Sent: Wednesday, June 20, 2007 9:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to list LE options Dittoever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). Oh really? And did you then publish elsewhere the contents of LNKLST, the APF list, and other important system info stored in PARMLIB that is NOT performance related? Ever consider that your better application people (the ones who still know how to use assembler effectively and with sophistication, for the benefit of the business's bottom line) might need that information you just closed off? Agreed, outsiders telling you how to bake your bread when it's your oven and your dinner is annoying at the least -- but to cut off access to everyone but the privileged sysprog is closet-think of the worst sort. If the consultants are bothering you, fire them, or limit *their* access (I can see that as a reasonable security precaution, actually) but not the entire shop. The attitude I don't understand seems to be If I hide it they won't find out how I do my job, or bother me about it, or try to show me a better way to get this business done than I know about. Good relations between sysprogs and application programmers are crucial to business success. Locking yourself and your data in a closet does not help. Peter (Assembler Applications Programmer and Proud Of It) This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: how to list LE options
On Thu, 21 Jun 2007 10:10:31 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: Dittoever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). Oh really? And did you then publish elsewhere the contents of LNKLST, the APF list, and other important system info stored in PARMLIB that is NOT performance related? Ever consider that your better application people (the ones who still know how to use assembler effectively and with sophistication, for the benefit of the business's bottom line) might need that information you just closed off? There are pros and cons like everything else. If you want or need tight security controls, then on a need to know basis is a good approach. You picked a bad example. I don't want to handcuff anyone to keep them from doing their jobs, but PARMLIB should definitely be UACC(NONE) except to the sysprogs who need to update it. The exception is other sysprogs who request updates when only a select number of sysprogs do the updates. In our shop, only the MVS guys are allowed to update PARMLIB(s), the CICS,DB2,MQ, WAS, etc. teams have read access and need to request updates through the MVS group. If you don't think that is proper... just ask any auditor. ;-) Do you really think the APF list should be published?!Seriously... have you ever been involved with a SAS70 audit? The attitude I don't understand seems to be If I hide it they won't find out how I do my job, or bother me about it, or try to show me a better way to get this business done than I know about. Unfortunately, that is probably the attitude many application programmers have. Hiding things is more likely due to security / audit concerns. Don't take it personally, it isn't a conspiracy to keep you from doing your job (at least at the shops I've worked at). Good relations between sysprogs and application programmers are crucial to business success. Locking yourself and your data in a closet does not help. Agree. But having tight security doesn't preclude that. I am a phone call, email or instant message away.Bad relations are more likely due to the stereotypical grouchy sysprog who just shoves someone away without helping or answers questions with a response of RTFM all the time. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: how to list LE options
Peter, Calm down. Nobody is picking on anyone, crush working relationships, or trying to over step authority. Yes, good relations are crucial and I doubt that very many sysprogs are out there undermining that. The simple fact is that in most medium to large organizations, lines do need to be drawn in order to keep people focused on the jobs they are hired to do. Yes, it can instill some frustration, especially if you came from a smaller environment and are used to diving in where ever you wish. Believe it or not, even sysprogs have limitations placed on their activities. In some cases, so strict that they can't get trivial tasks completed without major approvals. Today, I would think that Parmlib security is pretty much a standard in most large shops. Any information that you think you may be lacking due to your inability to browse at-will, should be adequately documented. My quip actually dates back to experiences back in the 80's. I wouldn't really expect much of that happening today. Please note that I do make a distinction on organizational size. This makes a very big difference as to how you run things. And, as to the job titles, many of us have worn many different hats over the years and have been on different sides of the fence. I don't think this is an argument as much as a criticism on certain individuals bent on being somewhat disruptive or worse. sage - From: Farley, Peter x23353 [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, June 21, 2007 10:10 AM Subject: Re: how to list LE options -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Phil Knight Sent: Wednesday, June 20, 2007 9:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to list LE options Dittoever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). Oh really? And did you then publish elsewhere the contents of LNKLST, the APF list, and other important system info stored in PARMLIB that is NOT performance related? -- 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: how to list LE options
--snip--- Dittoever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). -unsnip- I always figured it was b ecause that user had too much spare time. Solution: notify his manager. Politics disallowed UACC(NONE). -- 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: PARMLIB(s) (Was: how to list LE options)
ever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). I have yet to see a single member of PARMLIB that is any business of anybody outside SYSPROGs. - Too busy driving to stop for gas! -- 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: how to list LE options
In this case politics led to security. Management decision (as it should be). - Original Message - From: Rick Fochtman [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, June 21, 2007 11:46 AM Subject: Re: how to list LE options --snip--- Dittoever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). -unsnip- I always figured it was b ecause that user had too much spare time. Solution: notify his manager. Politics disallowed UACC(NONE). -- 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: how to list LE options
Good relations between sysprogs and application programmers are crucial to business success. Locking yourself and your data in a closet does not help. I'm with Peter on this one. His comment above, says it all. Mike Hill Saffron Services tel: +44(0)1-322-337338 e-mail: [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: how to list LE options
that in most medium to large organizations, lines do need to be drawn in order to keep people focused on the jobs they are hired to do I take this to mean keep them stupid so that they cannot get a job anywhere else. And just why is it a security breach to allow someone to look at a dataset they cannot update? Certain applications programmers can also utilize things like linklists and apf datasets as well as LE options so they should have the right to at least look at how they are defined to the system. a long time ago the MVS group here would not even allow the CICS and other groups to browse their SMP datasets. Well we saw how long that lasted! A good portion of the systems problems I encounter in CICS are due to bugs in other components like LE, DFSMS, VTAM, etc. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Phil Knight Sent: Thursday, June 21, 2007 11:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to list LE options Peter, Calm down. Nobody is picking on anyone, crush working relationships, or trying to over step authority. Yes, good relations are crucial and I doubt that very many sysprogs are out there undermining that. The simple fact is that in most medium to large organizations, lines do need to be drawn in order to keep people focused on the jobs they are hired to do. Yes, it can instill some frustration, especially if you came from a smaller environment and are used to diving in where ever you wish. Believe it or not, even sysprogs have limitations placed on their activities. In some cases, so strict that they can't get trivial tasks completed without major approvals. Today, I would think that Parmlib security is pretty much a standard in most large shops. Any information that you think you may be lacking due to your inability to browse at-will, should be adequately documented. My quip actually dates back to experiences back in the 80's. I wouldn't really expect much of that happening today. Please note that I do make a distinction on organizational size. This makes a very big difference as to how you run things. And, as to the job titles, many of us have worn many different hats over the years and have been on different sides of the fence. I don't think this is an argument as much as a criticism on certain individuals bent on being somewhat disruptive or worse. sage - From: Farley, Peter x23353 [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, June 21, 2007 10:10 AM Subject: Re: how to list LE options -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Phil Knight Sent: Wednesday, June 20, 2007 9:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to list LE options Dittoever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). Oh really? And did you then publish elsewhere the contents of LNKLST, the APF list, and other important system info stored in PARMLIB that is NOT performance related? -- 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: how to list LE options
Ditto here. I've worked in three banks in my career and in each one update access to any system library was allowed only to the MVS sysprogs, and their update access was logged and reported. Other sysprogs and the performance analyst/capacity planner(me) had read access and sent requests to the MVS sysprogs for updates. Any of the bank auditing groups (internal, independent, and/or governmental) would have had a hissy-fit if it had been set up any other way. Tom Kelman Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Thursday, June 21, 2007 9:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to list LE options There are pros and cons like everything else. If you want or need tight security controls, then on a need to know basis is a good approach. You picked a bad example. I don't want to handcuff anyone to keep them from doing their jobs, but PARMLIB should definitely be UACC(NONE) except to the sysprogs who need to update it. The exception is other sysprogs who request updates when only a select number of sysprogs do the updates. In our shop, only the MVS guys are allowed to update PARMLIB(s), the CICS,DB2,MQ, WAS, etc. teams have read access and need to request updates through the MVS group. If you don't think that is proper... just ask any auditor. ;-) Do you really think the APF list should be published?!Seriously... have you ever been involved with a SAS70 audit? * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: how to list LE options
I disagree. The boss may not always be right, but he's still the boss. :-( Our COBOL-only staff has/had no reason to be diving into PARMLIB. In the old days of IPS/ICS tuning, I got far too many complaints: My database shouldn't be pageable, My TSO session should have a storage fence., etc. Tuning is for the business needs, NOT the individuals' (perceived) needs The overall business needs MUST be the first consideration. Rick Phil Knight wrote: In this case politics led to security. Management decision (as it should be). - Original Message - From: Rick Fochtman [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, June 21, 2007 11:46 AM Subject: Re: how to list LE options --snip--- Dittoever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). -unsnip- I always figured it was b ecause that user had too much spare time. Solution: notify his manager. Politics disallowed UACC(NONE). -- 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 -- 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
Security vs knowledge [was: RE: how to list LE options]
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Thursday, June 21, 2007 10:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to list LE options Snipped There are pros and cons like everything else. If you want or need tight security controls, then on a need to know basis is a good approach. See, that's the attitude I am talking about. Hide the data and make people ask for it and justify asking for it. Why? Because some fool of an auditor doesn't understand mainframes? That's just BS IMHO. Fire the auditor for incompetence. You picked a bad example. I don't want to handcuff anyone to keep them from doing their jobs, but PARMLIB should definitely be UACC(NONE) except to the sysprogs who need to update it. Again, why? What possible security exposure could result from application programmers browsing PARMLIB? AFAIK there aren't any passwords or any secrets stored there that would give any programmer the ability to bypass RACF or any other active security protocol. If that's true, why UACC(NONE)? Even if (to take an old and probably obsolete example) there are user SVC numbers listed in PARMLIB which when used would provide supervisor state and key zero, RACF and/or other active security in the SVC code itself should already prevent said programmer from actually using that SVC unless authorized to do so, so where is the harm is letting the SVC number be known? And if there is NOT security software protecting that privileged resource, why not? THAT would be the security exposure, not the availability of the information that it exists. If you don't think that is proper... just ask any auditor. ;-) Do you really think the APF list should be published?! Yes I do. Where is the harm? What is the exposure? If I am not authorized to write into any of the libraries in that list, what harm can I do knowing their names? Seriously... have you ever been involved with a SAS70 audit? No, nor ever hope to be. But if I was, I would strenuously argue against hiding any non-security-exposure information. Knowing there IS a secured facility and being able to USE it are NOT the same thing. Knowing is not a security exposure, only the ability to use it is. The attitude I don't understand seems to be If I hide it they won't find out how I do my job, or bother me about it, or try to show me a better way to get this business done than I know about. Unfortunately, that is probably the attitude many application programmers have. Hiding things is more likely due to security / audit concerns. Don't take it personally, it isn't a conspiracy to keep you from doing your job (at least at the shops I've worked at). Well it certainly looks that way most of the time, because no one gives a good reason for hiding anything -- just security and need to know. Good relations between sysprogs and application programmers are crucial to business success. Locking yourself and your data in a closet does not help. Agree. But having tight security doesn't preclude that. I am a phone call, email or instant message away.Bad relations are more likely due to the stereotypical grouchy sysprog who just shoves someone away without helping or answers questions with a response of RTFM all the time. Possibly, or also possibly management that tells sysprogs to keep everyone else ignorant because they like it that way. I can only go by what I see. I do have and have had excellent relations with sysprogs, but still there are stupidities foisted on them and us as security requirements. That's my real beef. Thanks for listening. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: how to list LE options
-snip--- that in most medium to large organizations, lines do need to be drawn in order to keep people focused on the jobs they are hired to do I take this to mean keep them stupid so that they cannot get a job anywhere else. ---unsnip Not necessarily. But how often do these same people look at the whole picture, instead of just their piece of it? snip-- And just why is it a security breach to allow someone to look at a dataset they cannot update? ---unsnip- Just ask your auditors. Would you want your users browsing the RACF database? Or payroll information in the accounting department's files? NOT ME!!! ---snip- Certain applications programmers can also utilize things like linklists and apf datasets as well as LE options so they should have the right to at least look at how they are defined to the system. unsnip- Each shop has its own needs and viewpoint. In our shop, all applications were run from a NON-APF, NON-LINKLIST library set. Language-related libraries were sometimes in LINKLIST, but we made this known and allowed browsing. LE options were copied to an application parmlib, as were COBOL Compiler defaults, SORT options, etc. We found alternative mechanisms to give applications programmers the information they had legitimate need for, then we locked the PARMLIB, with (finally) management approval. snip-- a long time ago the MVS group here would not even allow the CICS and other groups to browse their SMP datasets. Well we saw how long that lasted! A good portion of the systems problems I encounter in CICS are due to bugs in other components like LE, DFSMS, VTAM, etc. --unsnip- There's no reason that Database, CICS and other groups can't maintain their own SMP/E datasets, though I found that some guidance always made for happier relations between systems and other groups in this area. Not edicts, but suggestions and the benefit of experience for new users of SMP/e. Cooperation is a key aspect of dealing with SMP/E in all the different environments. -- 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: PARMLIB(s) (Was: how to list LE options)
On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL [EMAIL PROTECTED] wrote: :ever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). :I have yet to see a single member of PARMLIB that is any business of anybody outside SYSPROGs. How much of PARMLIB cannot be detected by examining storage in a live system - not using APF or anything special? Security by obscurity is useless. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: how to list LE options
we are just referring to parmlib and other systems settings here -not RACF databases or sensitive application data. for whatever reason an applications programmer has to look at this stuff, be it a real buisness need or just their own curiousity and desire to expand their knowledge, there is no real reason not to let them do so, including the say-so of some clueless auditor. as for SMPE datasets, I was only referring to being able to look at other compoenents SMPE datasets for which there is a real need for in debugging a product using a different SMPE environment. Which SMPE datasets a product uses is a function of the vendors installation requirements, not some management security policy. Fortuneatly, this issue was resolved here a long time ago. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Thursday, June 21, 2007 1:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to list LE options -snip--- that in most medium to large organizations, lines do need to be drawn in order to keep people focused on the jobs they are hired to do I take this to mean keep them stupid so that they cannot get a job anywhere else. ---unsnip Not necessarily. But how often do these same people look at the whole picture, instead of just their piece of it? snip-- And just why is it a security breach to allow someone to look at a dataset they cannot update? ---unsnip- Just ask your auditors. Would you want your users browsing the RACF database? Or payroll information in the accounting department's files? NOT ME!!! ---snip- Certain applications programmers can also utilize things like linklists and apf datasets as well as LE options so they should have the right to at least look at how they are defined to the system. unsnip- Each shop has its own needs and viewpoint. In our shop, all applications were run from a NON-APF, NON-LINKLIST library set. Language-related libraries were sometimes in LINKLIST, but we made this known and allowed browsing. LE options were copied to an application parmlib, as were COBOL Compiler defaults, SORT options, etc. We found alternative mechanisms to give applications programmers the information they had legitimate need for, then we locked the PARMLIB, with (finally) management approval. snip-- a long time ago the MVS group here would not even allow the CICS and other groups to browse their SMP datasets. Well we saw how long that lasted! A good portion of the systems problems I encounter in CICS are due to bugs in other components like LE, DFSMS, VTAM, etc. --unsnip- There's no reason that Database, CICS and other groups can't maintain their own SMP/E datasets, though I found that some guidance always made for happier relations between systems and other groups in this area. Not edicts, but suggestions and the benefit of experience for new users of SMP/e. Cooperation is a key aspect of dealing with SMP/E in all the different environments. -- 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: Security vs knowledge [was: RE: how to list LE options]
Because some fool of an auditor doesn't understand mainframes? That's just BS IMHO. Fire the auditor for incompetence An auditor doesn't set the rules. They just report on compliance. I still see no reason for a non-SYSPROG to have access to PARMLIB! - Too busy driving to stop for gas! -- 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: PARMLIB(s) (Was: how to list LE options)
How much of PARMLIB cannot be detected by examining storage in a live system - not using APF or anything special? Security by obscurity is useless. I (honestly) do not understand your point. - Too busy driving to stop for gas! -- 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: how to list LE options
On Thu, 21 Jun 2007 09:44:21 -0500, Mark Zelden wrote: ... Do you really think the APF list should be published?! Yes. Why not? It is readily available. Using the APF list as the excuse for preventing read access to PARMLIB is a red herring. The APF command in ISRDDN is one of the easiest ways to get it. Please don't tell me that you would advocate disabling that. But if you do, anyone can obtain SHOWMVS and run it to get the APF list and LNKLST, as well as a lot of other information that is specified in PARMLIB. It is my belief that knowledge is always a good thing. -- Tom Marchant -- 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: PARMLIB(s) (Was: how to list LE options)
Binyamin Dissen wrote: On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL [EMAIL PROTECTED] wrote: :ever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). :I have yet to see a single member of PARMLIB that is any business of anybody outside SYSPROGs. How much of PARMLIB cannot be detected by examining storage in a live system - not using APF or anything special? Security by obscurity is useless. 100% agreed. However in this case UACC(N) not for security, it is for shutting up folks commenting PARMLIB settings. Just to stop discussions and complaints. IMHO, if I have nothing to be ashamed, I don't have to hide it. From the other hand it is not bad to hide PARMLIB, *but not for the purpose above*. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: PARMLIB(s) (Was: how to list LE options)
On Thu, 21 Jun 2007 18:29:05 + Ted MacNEIL [EMAIL PROTECTED] wrote: :How much of PARMLIB cannot be detected by examining storage in a live system - not using APF or anything special? :Security by obscurity is useless. :I (honestly) do not understand your point. That by securing parmlib you are securing nothing. You are pulling down the shade on one side, while there is a clear view on the other side. That anyone who attempts to use obscurity as security has holes in their security. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Security vs knowledge [was: RE: how to list LE options]
Ted MacNEIL wrote: Because some fool of an auditor doesn't understand mainframes? That's just BS IMHO. Fire the auditor for incompetence An auditor doesn't set the rules. They just report on compliance. I still see no reason for a non-SYSPROG to have access to PARMLIB! Assuiming there is a reason, including curiosity and willingness to learn. What would you do if non-SYSPROG would ask you about some member in the PARMLIB ? Deny the knowledge, just beacuse you are the God ? IMHO the poorer tuned parmlib the higher will to hide the parmlib. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone. -- 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: how to list LE options
On Thu, 21 Jun 2007 12:55:58 -0400, Barkow, Eileen [EMAIL PROTECTED] wrote: And just why is it a security breach to allow someone to look at a dataset they cannot update? Please give me read access to the data set that has your SS# and credit card information. I promise not to update it. On Thu, 21 Jun 2007 13:32:36 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: Again, why? What possible security exposure could result from application programmers browsing PARMLIB? AFAIK there aren't any passwords or any secrets stored there that would give any programmer the ability to bypass RACF or any other active security protocol. If that's true, why UACC(NONE)? Even if (to take an old and probably obsolete example) there are user SVC numbers listed in PARMLIB which when used would provide supervisor state and key zero, RACF and/or other active security in the SVC code itself should already prevent said programmer from actually using that SVC unless authorized to do so, so where is the harm is letting the SVC number be known? Because it is an additional layer of security. Some of the information in there could help lead someone to a security circumvention. Yes, it is security by ignorance - but there is nothing wrong with that in addition to other controls. Why revoke a userid after n number of wrong password attempts.Why are there firewalls? Why require VPN to access your systems over the internet when there are other authentications once you get there? If it was your company and your ay ess ess on the line, you might think differently. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: PARMLIB(s) (Was: how to list LE options)
Binyamin Dissen wrote: On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL [EMAIL PROTECTED] wrote: :ever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). :I have yet to see a single member of PARMLIB that is any business of anybody outside SYSPROGs. How much of PARMLIB cannot be detected by examining storage in a live system - not using APF or anything special? Security by obscurity is useless. 100% agreed. However in this case UACC(N) not for security, it is for shutting up folks commenting PARMLIB settings. Just to stop discussions and complaints. IMHO, if I have nothing to be ashamed, I don't have to hide it. From the other hand it is not bad to hide PARMLIB, *but not for the purpose above*. Funny how it's ok for SYSPROGs to cruise Applications and tell us what needs to be changed or how to tune our application (when we didn't ask for their opinion), but it's not ok for us to cruise your PARMLIB settings Never heard of a PARMLIB setting getting screwed-up by looking at it. Unbelieveable !!! Another pet-peave, why do companies buy tools, then SYSPROG decides that only they get to use it. Example: My customer has purchased CICS/Abend-Aid, but has only configured it for CICS dumps. None of the applicatioin dumps can access it. I asked them why can't we both use it ??, answer...because none of the applications asked for it. More and more SYSPROGs like to hide their stuff, even from viewing. Now the ability to insure that CICS definitions are setup properly is being hidden from view. This makes some problems VERY difficult to solve or eliminate possible causes when all you want to do is view the definition. If your system security is setup properly, I can see no harm in browsing anything on the system. After all, isn't that how you learn ?? Tom Savor Fidelity National Information Services 11720 Amber Park Drive Suite 500 Alpharetta, GA 30004 Phone: 678-867-8431 cell: 404-660-6898 E-Mail: [EMAIL PROTECTED] -- This message contains information from Certegy, Inc which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e:mail [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: PARMLIB(s) (Was: how to list LE options)
Funny how it's ok for SYSPROGs to cruise Applications and tell us what needs to be changed or how to tune our application Funny how I haven't worked at a shop (for over 20 years) that allowed me to cruise applications. Record layouts also need to be protected. - Too busy driving to stop for gas! -- 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: Security vs knowledge [was: RE: how to list LE options]
In the JES2 Init deck, you can specify clear text passwords for RJE lines. That is a great reason for specifying UACC(NONE). Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Farley, Peter x23353 Sent: Thursday, June 21, 2007 12:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Security vs knowledge [was: RE: how to list LE options] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Thursday, June 21, 2007 10:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to list LE options Snipped There are pros and cons like everything else. If you want or need tight security controls, then on a need to know basis is a good approach. See, that's the attitude I am talking about. Hide the data and make people ask for it and justify asking for it. Why? Because some fool of an auditor doesn't understand mainframes? That's just BS IMHO. Fire the auditor for incompetence. You picked a bad example. I don't want to handcuff anyone to keep them from doing their jobs, but PARMLIB should definitely be UACC(NONE) except to the sysprogs who need to update it. Again, why? What possible security exposure could result from application programmers browsing PARMLIB? AFAIK there aren't any passwords or any secrets stored there that would give any programmer the ability to bypass RACF or any other active security protocol. If that's true, why UACC(NONE)? Even if (to take an old and probably obsolete example) there are user SVC numbers listed in PARMLIB which when used would provide supervisor state and key zero, RACF and/or other active security in the SVC code itself should already prevent said programmer from actually using that SVC unless authorized to do so, so where is the harm is letting the SVC number be known? And if there is NOT security software protecting that privileged resource, why not? THAT would be the security exposure, not the availability of the information that it exists. If you don't think that is proper... just ask any auditor. ;-) Do you really think the APF list should be published?! Yes I do. Where is the harm? What is the exposure? If I am not authorized to write into any of the libraries in that list, what harm can I do knowing their names? Seriously... have you ever been involved with a SAS70 audit? No, nor ever hope to be. But if I was, I would strenuously argue against hiding any non-security-exposure information. Knowing there IS a secured facility and being able to USE it are NOT the same thing. Knowing is not a security exposure, only the ability to use it is. The attitude I don't understand seems to be If I hide it they won't find out how I do my job, or bother me about it, or try to show me a better way to get this business done than I know about. Unfortunately, that is probably the attitude many application programmers have. Hiding things is more likely due to security / audit concerns. Don't take it personally, it isn't a conspiracy to keep you from doing your job (at least at the shops I've worked at). Well it certainly looks that way most of the time, because no one gives a good reason for hiding anything -- just security and need to know. Good relations between sysprogs and application programmers are crucial to business success. Locking yourself and your data in a closet does not help. Agree. But having tight security doesn't preclude that. I am a phone call, email or instant message away.Bad relations are more likely due to the stereotypical grouchy sysprog who just shoves someone away without helping or answers questions with a response of RTFM all the time. Possibly, or also possibly management that tells sysprogs to keep everyone else ignorant because they like it that way. I can only go by what I see. I do have and have had excellent relations with sysprogs, but still there are stupidities foisted on them and us as security requirements. That's my real beef. Thanks for listening. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: PARMLIB(s) (Was: how to list LE options)
On Thu, 21 Jun 2007 14:58:28 -0400, Tom Savor wrote: Another pet-peave, why do companies buy tools, then SYSPROG decides that only they get to use it. Example: My customer has purchased CICS/Abend-Aid, but has only configured it for CICS dumps. None of the applicatioin dumps can access it. I asked them why can't we both use it ??, answer...because none of the applications asked for it. So ask already! Don't wait to be asked to the prom - if you want to dance, make 'em dance! More and more SYSPROGs like to hide their stuff, even from viewing. Now the ability to insure that CICS definitions are setup properly is being hidden from view. This makes some problems VERY difficult to solve or eliminate possible causes when all you want to do is view the definition. I disagree with your more and more assertion -- there are fewer and fewer sysprogs around these days, after all. (Check the archives here.) If your system security is setup properly, I can see no harm in browsing anything on the system. After all, isn't that how you learn ?? That is certainly one way to learn. Reading books and taking classes is another. But if your company doesn't believe in you enough to pay to send you to, say, a z/OS Installation and Tuning class (even though you are in Apps), why should the Tech Support manager (or a sysprog) believe in you enough to spend time (i.e., money) out of their limited budget to answer your questions whenever you feel like asking (and learning)?? Besides, there are a surprisingly small number of sites with proper security... and the requirements for security/audit compliance/support have increased substantially (what with SOX, HIPPA, etc.). Cover-ups don't stop at the boardroom, you know. -- Tom Schmidt Madison, WI -- 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: SV: how to list LE options
On Jun 21, 2007, at 4:44 AM, Thomas Berg wrote: --SNIP-- The consultants howled as they could no longer assemble programs (no access to sys1.maclib) ??? Our official language was COBOL nothing else was permitted into production. The consultants had a habit of doing the other work on our system, those contained assembler. 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: PARMLIB(s) (Was: how to list LE options)
Funny how it's ok for SYSPROGs to cruise Applications and tell us what needs to be changed or how to tune our application (when we didn't ask for their opinion), but it's not ok for us to cruise your PARMLIB settings Never heard of a PARMLIB setting getting screwed-up by looking at it. Unbelieveable !!!. Hmmm, funny how it's okay for application programmers to avoid coding their application to work correctly with daylight savings time, or god forbid actually SYSPLEX ENABLING their applications. UNBELIEVABLE. -- 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: Security vs knowledge [was: RE: how to list LE options]
Wayne Driscoll wrote: In the JES2 Init deck, you can specify clear text passwords for RJE lines. That is a great reason for specifying UACC(NONE). It is also good reason to get rid of such solution. However, if - for any reason - it cannot be done, this is really good reason for UACC(N). Similar reasons can exist in other members. BTW: Do we discuss about access to parmlib on PRODUCTION or DEVELOPMENT? Developers could (or couldn't) have access to parmlib on dev. system. When we talk about production, the anwser is simple: no access to the system at all - including parmlib. *Very well* justified excpetions could apply. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: PARMLIB(s) (Was: how to list LE options)
On Thu, 21 Jun 2007 15:14:00 -0500, Robert Justice [EMAIL PROTECTED] wrote: Funny how it's ok for SYSPROGs to cruise Applications and tell us what needs to be changed or how to tune our application (when we didn't ask for their opinion), but it's not ok for us to cruise your PARMLIB settings Never heard of a PARMLIB setting getting screwed-up by looking at it. Unbelieveable !!!. Hmmm, funny how it's okay for application programmers to avoid coding their application to work correctly with daylight savings time, or god forbid actually SYSPLEX ENABLING their applications. UNBELIEVABLE. Why can't we all just get along? :-) To respond to the first statement in many shops that is not true at all. Here (and also in other large environments I have worked at) the performance team is actively involved in helping applications tune, but it is at their request because the techies have more experience with tuning and some of the tools. That is their primary job. The application programmers' primary job is to write code (under a deadline usually) and performance / efficient code is not always given the attention it needs for production. And that other pet peeve about not letting applications use the tools... well, in my experience the application people are the main users of products like Strobe, Expedite, etc. Those are their tools (even though we install them). Many of them I don't really have a clue how to use beyond the very basics if at all. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: PARMLIB(s) (Was: how to list LE options)
[EMAIL PROTECTED] wrote: Binyamin Dissen wrote: On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL [EMAIL PROTECTED] wrote: :ever have users cruise your parmlib and then tell you how to tune the system? Solution: UACC(NONE). :I have yet to see a single member of PARMLIB that is any business of anybody outside SYSPROGs. How much of PARMLIB cannot be detected by examining storage in a live system - not using APF or anything special? Security by obscurity is useless. 100% agreed. However in this case UACC(N) not for security, it is for shutting up folks commenting PARMLIB settings. Just to stop discussions and complaints. IMHO, if I have nothing to be ashamed, I don't have to hide it. From the other hand it is not bad to hide PARMLIB, *but not for the purpose above*. Funny how it's ok for SYSPROGs to cruise Applications and tell us what needs to be changed or how to tune our application (when we didn't ask for their opinion), but it's not ok for us to cruise your PARMLIB settings Never heard of a PARMLIB setting getting screwed-up by looking at it. Unbelieveable !! ... Tom Savor ... Perhaps it's somehow related to the fact that most SYSPROGs have System Performance as part of their job responsibility and training while application folks only have responsibility that their apps generate correct results in a manner their end users find acceptable. If their apps cause system-wide problems to other end-users, that's frequently viewed as someone else's problem. As a SYSPROG I have never had time to randomly inspect application code, but if the system is under stress, one starts looking for what changed and if there are any obvious big resource hogs contributing to the problem. If this points to application code, then we do whatever it takes to resolve the problem, and if this involves looking at application code or JCL for obvious deficiencies, we go to that level. The more experienced application programmers usually do a decent job, but we also find that most colleges tend to do a poor job of instilling performance thinking into new programmers - the idea that techniques OK for 100 transactions may be inappropriate when scaled to millions, or that dataset access can be tuned for performance, too often tends to be untaught or unlearned. Fortunately, everyone here accepts that eliminating performance problems is part of our job and theirs. We publish daily charts and tables of where the system resources are being used. We have on numerous occasions had application areas and managers question relative allocation of resources when their users are hurting and request changes to policies and/or priorities. The esoteric details of how such changes are implemented, via PARMLIB or elsewhere, is generally of minimal interest - their interest is in the results. -- Joel C. Ewing, Fort Smith, AR[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: Security vs knowledge [was: RE: how to list LE options]
On 6/21/2007 3:40 PM, Wayne Driscoll wrote: In the JES2 Init deck, you can specify clear text passwords for RJE lines. That is a great reason for specifying UACC(NONE). But why would you want to have clear-text RJE passwords in the JES2 init deck when JES2 supports using RACF to perform the RJE authentication (and has done so for the last 17 years or so)? Walt Farrell, CISSP STSM, z/OS Security Design, IBM -- 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: Security vs knowledge [was: RE: how to list LE options]
In the JES2 Init deck, you can specify clear text passwords for RJE lines. That is a great reason for specifying UACC(NONE). That sounds like a great reason for not keeping the JES2 Init deck in PARMLIB. From: Wayne Driscoll [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Security vs knowledge [was: RE: how to list LE options] Date: Thu, 21 Jun 2007 15:40:02 -0400 In the JES2 Init deck, you can specify clear text passwords for RJE lines. That is a great reason for specifying UACC(NONE). Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Farley, Peter x23353 Sent: Thursday, June 21, 2007 12:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Security vs knowledge [was: RE: how to list LE options] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Thursday, June 21, 2007 10:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to list LE options Snipped There are pros and cons like everything else. If you want or need tight security controls, then on a need to know basis is a good approach. See, that's the attitude I am talking about. Hide the data and make people ask for it and justify asking for it. Why? Because some fool of an auditor doesn't understand mainframes? That's just BS IMHO. Fire the auditor for incompetence. You picked a bad example. I don't want to handcuff anyone to keep them from doing their jobs, but PARMLIB should definitely be UACC(NONE) except to the sysprogs who need to update it. Again, why? What possible security exposure could result from application programmers browsing PARMLIB? AFAIK there aren't any passwords or any secrets stored there that would give any programmer the ability to bypass RACF or any other active security protocol. If that's true, why UACC(NONE)? Even if (to take an old and probably obsolete example) there are user SVC numbers listed in PARMLIB which when used would provide supervisor state and key zero, RACF and/or other active security in the SVC code itself should already prevent said programmer from actually using that SVC unless authorized to do so, so where is the harm is letting the SVC number be known? And if there is NOT security software protecting that privileged resource, why not? THAT would be the security exposure, not the availability of the information that it exists. If you don't think that is proper... just ask any auditor. ;-) Do you really think the APF list should be published?! Yes I do. Where is the harm? What is the exposure? If I am not authorized to write into any of the libraries in that list, what harm can I do knowing their names? Seriously... have you ever been involved with a SAS70 audit? No, nor ever hope to be. But if I was, I would strenuously argue against hiding any non-security-exposure information. Knowing there IS a secured facility and being able to USE it are NOT the same thing. Knowing is not a security exposure, only the ability to use it is. The attitude I don't understand seems to be If I hide it they won't find out how I do my job, or bother me about it, or try to show me a better way to get this business done than I know about. Unfortunately, that is probably the attitude many application programmers have. Hiding things is more likely due to security / audit concerns. Don't take it personally, it isn't a conspiracy to keep you from doing your job (at least at the shops I've worked at). Well it certainly looks that way most of the time, because no one gives a good reason for hiding anything -- just security and need to know. Good relations between sysprogs and application programmers are crucial to business success. Locking yourself and your data in a closet does not help. Agree. But having tight security doesn't preclude that. I am a phone call, email or instant message away.Bad relations are more likely due to the stereotypical grouchy sysprog who just shoves someone away without helping or answers questions with a response of RTFM all the time. Possibly, or also possibly management that tells sysprogs to keep everyone else ignorant because they like it that way. I can only go by what I see. I do have and have had excellent relations with sysprogs, but still there are stupidities foisted on them and us as security requirements. That's my real beef. Thanks for listening. Peter _ Who's that on the Red Carpet? Play win glamorous prizes. http://club.live.com/red_carpet_reveal.aspx?icid=REDCARPET_hotmailtextlink3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN
Re: PARMLIB(s) (Was: how to list LE options)
I (honestly) do not understand your point. And that's part of the problem. As someone who's spent a couple of decades on each side of this discussion, I can see both points of view. However, the system is there for the benefit of the applications; the reverse is not the case. If the systems guy cannot understand the application guy's point, that is a problem. From: Ted MacNEIL [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARMLIB(s) (Was: how to list LE options) Date: Thu, 21 Jun 2007 18:29:05 + How much of PARMLIB cannot be detected by examining storage in a live system - not using APF or anything special? Security by obscurity is useless. I (honestly) do not understand your point. - Too busy driving to stop for gas! _ Hotmail to go? Get your Hotmail, news, sports and much more! http://mobile.msn.com -- 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: how to list LE options
On Jun 21, 2007, at 1:08 PM, Barkow, Eileen wrote: as for SMPE datasets, I was only referring to being able to look at other compoenents SMPE datasets for which there is a real need for in debugging a product using a different SMPE environment. Which SMPE datasets a product uses is a function of the vendors installation requirements, not some management security policy. Fortuneatly, this issue was resolved here a long time ago. I don't know if I quite agree with you on this one. Especially when it comes to consultants. I have had personally hours of discussions with with quite a few consultants about which PTF was on or which was not. Some of them think they understand SMPe concepts, some of them know enough to be dangerous. I once got a call at 2AM saying that they needed PTF x on *NOW*. It was an IBM ptf . I listened to their remarks and finally woke up enough to say I would check on it in a few minutes. I logged on and went into SMPe dialogs and did a list for the PTF and came back not found so I switched over to IBMLINK and found the PTF but it was *NOT* for our ptf level I did a little more research and found the ptf and did a little back tracking and came up with the correct PTF for our system so I went back to SMPe and found out that we had it on (for at least 6 months). I called back and informed them that the PTF number was not correct for our system and PTF Y which was was on. They insisted I was wrong and I reiterated the correct information. They hung up and called the VP and insisted they needed this fix on NOW. So I got another call this time from the VP and he said put it on. I told him it was already on. I then told him the exact sequence of pre and coreqs for the ptf in question. I told him I could put the PTF on even if I wanted to. He told me to get in there and figure out what was going on. I got dressed and went into work and took one look at the sysout and it was a parm error not a ptf error. I pointed this out to the consultant and he said the message was in error. So we got the book out and indeed the parm was incorrect. He turn a couple shades of pale so I got the VP out of bed and explained to him what had happened. The next day the consultant was gone. I really didn't like to have to explain to a VP at 3AM what I did day in and day out and was really PE'oed that the VP wouldn't believe me. I know it was a political thing but I did not appreciate the whole thing. Information is OK if its in the right hands other than that they don't need to know. 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: Security vs knowledge [was: RE: how to list LE options]
On Jun 21, 2007, at 2:40 PM, Wayne Driscoll wrote: In the JES2 Init deck, you can specify clear text passwords for RJE lines. That is a great reason for specifying UACC(NONE). Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. Wayne, Not to disagree with you too much. But a long time ago (10+ years) I moved jes2 init deck out of parmlib. 2 reasons at that time (IIRC) parmlib had to be 80-80 (f) and I kept having to compress it and the other reason was was that the network people needed (at times) to browse the member and I could not give out read access to only one member. 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: how to list LE options
I don't know about your shop, but at ours it gets to be a pain when users call to complain because: my job is 20th on the queue Hit Enter. Tell them: Stop hitting enter because all the computer has time to do is service your request to see if it moved up in the queue. Put a NOTIFY=SYSUID on your job card and the system will tell you when your job came to an end. While you are waiting, write that documentation you have been meaning to get to. Get 100 programmers tapping that enter key just as quick as they can to see if their job ran and you know why that procesor upgrade is imminent. Monitors in the wrong hands need the same control you hear on tv about the machine where someone in the hospital can press a button to get more pain reliever into their drip line. Only it does not honor every request. SDSF and RMFMON should have an IGNORE x number of enter requests in a certain period of time. -- 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: Security vs knowledge [was: RE: how to list LE options]
I never said that putting clear text passwords was a good idea, just that it could be a reason that parmlib has UACC(NONE). As for not putting JES2 Init deck in parmlib, you are correct that it doesn't have to be there, but for you time reference, it has been at least 20 years (probably longer) since parmlib could not be blocked. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, June 21, 2007 9:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Security vs knowledge [was: RE: how to list LE options] On Jun 21, 2007, at 2:40 PM, Wayne Driscoll wrote: In the JES2 Init deck, you can specify clear text passwords for RJE lines. That is a great reason for specifying UACC(NONE). Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. Wayne, Not to disagree with you too much. But a long time ago (10+ years) I moved jes2 init deck out of parmlib. 2 reasons at that time (IIRC) parmlib had to be 80-80 (f) and I kept having to compress it and the other reason was was that the network people needed (at times) to browse the member and I could not give out read access to only one member. 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 -- 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
how to list LE options
I keep looking thru the manuals, but all I see is the use of RPTOPTS(ON) on some current LE using program. I am sure (ok.. hoping) that there is a way list out all LE run-time options? -Rob Schramm This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: how to list LE options
On Wed, 20 Jun 2007 12:38:44 -0400, Schramm, Rob [EMAIL PROTECTED] wrote: I keep looking thru the manuals, but all I see is the use of RPTOPTS(ON) on some current LE using program. I am sure (ok.. hoping) that there is a way list out all LE run-time options? -Rob Schramm If you don't know of a cobol program to run, compile/link the IVP: see hlq.SIGYSAMP(IGYWFIV1) Then run it with... // PARM='/RPTOPTS(ON)' LE OPTS or // PARM='/RPTOPTS(ON),RPTSTG(ON)' This gives you the storage report also. In z/OS 1.7 and above you can also use a CEEOPTS DD instead: //CEEOPTS DD * RPTOPTS(ON),RPTSTG(ON) /* -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: how to list LE options
On Wed, 20 Jun 2007 12:38:44 -0400, Schramm, Rob wrote: I keep looking thru the manuals, but all I see is the use of RPTOPTS(ON) on some current LE using program. I am sure (ok.. hoping) that there is a way list out all LE run-time options? Run a stub with the LE report options on in the JCL: Sorry about the length of this one. I clipped most of the comments and unnecessary junk from the program, but it's still pretty long. Just compile the program and run the JCL and you'll get an LE report. This is the only way I know of to list currently active LE options. // //DUMMY1 EXEC PGM=DUMMYPGM, // PARM='/RPTOPTS(ON),RPTSTG(ON)' // //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SUBDAT DD DSN=MFD.PARMADLY.MFDE0S0G(POPDATE), // DISP=SHR //DUMMYFIL DD DUMMY, // DCB=BLKSIZE=80 //* IDENTIFICATION DIVISION. PROGRAM-ID.DUMMYPGM. AUTHOR.DAVE KOPISCHKE. DATE-WRITTEN. JULY 23, 2003. DATE-COMPILED. ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. IBM-370. OBJECT-COMPUTER. IBM-370. INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT DUMMY-FILE ASSIGN TO DUMMYFIL. DATA DIVISION. FILE SECTION. FD DUMMY-FILE LABEL RECORDS ARE STANDARD RECORDING MODE IS F BLOCK CONTAINS 0 RECORDS. 01 DUMMY-RECORD. 05 DUMMY-REC PIC X(80). WORKING-STORAGE SECTION. 01 FILLER PIC X(40) VALUE 'WORKING STORAGE STARTS HERE'. PROCEDURE DIVISION. ** * * * -MAIN-PROCESSING. * * * ** -MAIN-PROCESSING. PERFORM 1000-INITIALIZATION THRU 1000-INITIALIZATION-EXIT. PERFORM 9000-TERMINATION THRU 9000-TERMINATION-EXIT. GOBACK. ** * * * 1000-INITIALIZATION.* * * * THIS ROUTINE OPENS INPUT FILE AND INITIALIZES AREAS
Re: how to list LE options
Schramm, Rob wrote: I keep looking thru the manuals, but all I see is the use of RPTOPTS(ON) on some current LE using program. I am sure (ok.. hoping) that there is a way list out all LE run-time options? -Rob Schramm If you are at zOS 1.7 or above this command seems to work; D CEE,CEEDOPT CEE3745I 13.03.12 DISPLAY CEEDOPT CEE=(00) LAST WHERE SET OPTION --- PARMLIB(CEEPRM00)ABPERC(NONE) PARMLIB(CEEPRM00)ABTERMENC(ABEND) PARMLIB(CEEPRM00) NOAIXBLD PARMLIB(CEEPRM00)ALL31(OFF) PARMLIB(CEEPRM00)ANYHEAP(16384,8192,ANYWHERE,FREE) PARMLIB(CEEPRM00) NOAUTOTASK PARMLIB(CEEPRM00)BELOWHEAP(8192,4096,FREE) PARMLIB(CEEPRM00)CBLOPTS(ON) PARMLIB(CEEPRM00)CBLPSHPOP(OFF) PARMLIB(CEEPRM00)CBLQDA(ON) PARMLIB(CEEPRM00)CHECK(ON) PARMLIB(CEEPRM00)COUNTRY(US) PARMLIB(CEEPRM00)DEBUG PARMLIB(CEEPRM00)DEPTHCONDLMT(0) PARMLIB(CEEPRM00)ENVAR() PARMLIB(CEEPRM00)ERRCOUNT(0) This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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 -- Mark Jacobs Technical Services Time Customer Service - Tampa, FL -- Victory in defeat, there is none higher. She didn't give up, Ben; she's still trying to lift that stone after it has crushed her. She's a father going down to a dull office job while cancer is painfully eating away his insides, so as to bring home one more pay check for the kids. She's a twelve-year-old girl trying to mother her baby brothers and sisters because Mama had to go to Heaven. She's a switchboard operator sticking to her job while smoke is choking her and the fire is cutting off her escape. She's all the unsung heroes who couldn't quite cut it but never quit.* Robert A. Heinlein - Stranger in a Strange Land *Referring to the Auguste Rodin sculpture, Caryatid Who Has Fallen under Her Stone -- 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: how to list LE options
Under z/OS V1.7 and above you can use the CEEPRMxx member in Parmlib to set global parms. For onlines, you may need to look somewhere else for the answers. If you are below z/OS V1.7, then you need to look at CEEUOPT, CEECOPT, and CEEDOPT for what is set. First, WHICH LE options do you want. If you want something that may have been LKED into a program with CEEUOPT, then you would need to run that program with REPORTS(ON) If it is in the CICS or IMS environment, you need to do something different. The processes identified so far are for global LE options. But you still could have unique LE Options on a per application/program basis or Online environment. in CICS you have a CLER transaction that can show you the CICS options. Not sure about IMS. Lizette Run a stub with the LE report options on in the JCL: Sorry about the length of this one. I clipped most of the comments and unnecessary junk from the program, but it's still pretty long. Just compile the program and run the JCL and you'll get an LE report. This is the only way I know of to list currently active LE options. -- 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: how to list LE options
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Schramm, Rob wrote: I keep looking thru the manuals, but all I see is the use of RPTOPTS(ON) on some current LE using program. I am sure (ok.. hoping) that there is a way list out all LE run-time options? If you are at zOS 1.7 or above this command seems to work; D CEE,CEEDOPT CEE3745I 13.03.12 DISPLAY CEEDOPT CEE=(00) Doesn't work if you haven't migrated to using the PARMLIB member CEEPRMxx. -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
Re: how to list LE options
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Snipped -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Snipped If you are at zOS 1.7 or above this command seems to work; D CEE,CEEDOPT CEE3745I 13.03.12 DISPLAY CEEDOPT CEE=(00) Doesn't work if you haven't migrated to using the PARMLIB member CEEPRMxx. Also doesn't work if you don't have OPERATOR authority (like me and many others on the list). I never understood the auditor/sysprog paranoia about letting normal users have access to the operator Display commands, but I also understand that sufficiently fine-grained definitions of authority that permit Display and nothing else (and $D for JES2) haven't been available. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: how to list LE options
On Wed, 20 Jun 2007 12:19:42 -0500, Mark Zelden [EMAIL PROTECTED] wrote: If you don't know of a cobol program to run, compile/link the IVP: see hlq.SIGYSAMP(IGYWFIV1) I hadn't looked in a while. The sample name I quoted was from COBOL for MVS VM. The same sample for Enterprise COBOL is in hlq.SIGYSAMP(IGYWIVP1). //IGYWIVP1 JOB JOB PARAMETERS // JCLLIB ORDER=SYS1.IGY.SIGYPROC //RUNIVP EXEC IGYWCLG,PARM.COBOL=RENT,REGION=1400K, // PARM.LKED='LIST,XREF,LET,MAP', // LNGPRFX='SYS1.IGY',LIBPRFX='SYS1.CEE', // PARM.GO='/RPTOPTS(ON),RPTSTG(ON)' //COBOL.SYSIN DD DSN=SYS1.IGY.SIGYSAMP(IGYIVP),DISP=SHR //GO.SYSOUT DD SYSOUT=* Someone already mentioned using CLER for finding out the options under CICS. Another way is to look at a dump with IPCS and use VERBX LEDATA. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: how to list LE options
On 20 Jun 2007 09:39:22 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Schramm, Rob) wrote: I keep looking thru the manuals, but all I see is the use of RPTOPTS(ON) on some current LE using program. I am sure (ok.. hoping) that there is a way list out all LE run-time options? It's been a long time since I did this, but you might try assembling, linking, and running: CEEUOPT CSECT CEEUOPT AMODE ANY CEEUOPT RMODE ANY CEEXOPT RPTOPTS=(ON) END -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot com -- 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
