Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
>Data set protection alone isn't granular enough. >It's all or nothing for update access and this change allows more granular >control. Yes, you're right it is simple, but (personal attacks aside) why is this needed? Are we going to be changing the roles of SYSPROGs so that one does a RECEIVE, one does an APPLY, etc? That kind of granularity is required? - 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On 2 Apr 2010 21:41:10 -0700, in bit.listserv.ibm-main (Message-ID:) d10j...@us.ibm.com (Jim Mulder) wrote: And this whole idea of trying to hide "Integrity" APARs has outlived its usefulness. If it ever had any. I have no gripe with fixing the hole then letting the cat out of the bag, but never doing it ?. Don't vendors ever learn ?. We have no way of knowing when all customers have applied a System Integrity fix to all systems, so that there are no longer any exposed systems anywhere in the world. Discussions right here on IBM-MAIN suggest that some customers run releases which are no longer supported, and a fix will never be available for those unsupported releases. As a courtesy to customers with exposed systems, we do not discuss the nature of System Integrity APARs, since understanding an exposure is one of the steps towards formulating a method of attack on an exposed system. Naturally, you may be curious about the nature of an exposure, and of course, we would love to show off how clever we were in discovering an exposure by telling you all about it. However, we feel that your curiosity and our desire to show off are overridden by the need to avoid unnecessarily assisting potential attackers. This particular fix, though, requires each company's security department to define who can use SMP/E and in what way. Without knowing what the security hole is, how can they know how to assign access? -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur "at" pobox "dot" com -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
> And this whole idea of trying to hide "Integrity" APARs has outlived its > usefulness. If it ever had any. > I have no gripe with fixing the hole then letting the cat out of the > bag, but never doing it ?. Don't vendors ever learn ?. > I also wonder about Brians assertion of: > The (fortunately) rare "integrity" flag > How the hell are we supposed to be able to tell how rare it is. And if > IBM doesn't have the confidence that they can talk about fixing these > exposures, what are we to think of the rest of the codebase ?. Is it > (supposedly) secure only until exposed/compromised ?. Excuse my lack of > confidence. We have no way of knowing when all customers have applied a System Integrity fix to all systems, so that there are no longer any exposed systems anywhere in the world. Discussions right here on IBM-MAIN suggest that some customers run releases which are no longer supported, and a fix will never be available for those unsupported releases. As a courtesy to customers with exposed systems, we do not discuss the nature of System Integrity APARs, since understanding an exposure is one of the steps towards formulating a method of attack on an exposed system. Naturally, you may be curious about the nature of an exposure, and of course, we would love to show off how clever we were in discovering an exposure by telling you all about it. However, we feel that your curiosity and our desire to show off are overridden by the need to avoid unnecessarily assisting potential attackers. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, 2 Apr 2010 18:03:58 -0700, Ted MacNEIL wrote: >>Keep an open mind and use your imagination a little, your point of view >isn't the only correct one. > >Please don't attribute motivations that aren't there. >I was asking a question and pointing out what may have been a flaw in reasoning. >This has nothing to do with a point of view. > >I still don't understand the need to protect commands, when the resources are protected. >Same question as others have. >Still no answer. I'll try one last time. No one seems to know why for sure, but possible explanations have been discussed. Data set protection alone isn't granular enough. It's all or nothing for update access and this change allows more granular control. Pretty simple concept. We can't force you to understand if you don't. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Bob, You are correct, I had the PPT option incorrect, thanks for jogging my memory. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Bob Rutledge To: IBM-MAIN@bama.ua.edu Date: 04/02/2010 06:04 PM Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use Sent by: IBM Mainframe Discussion List Wayne Driscoll wrote: > Thankfully, APF authorization and system resource access security are 2 > separate things. When the OPEN SVC gets invoked, it will perform a > RACROUTE REQUEST=AUTH call for the dataset being opened, regardless of the > value in JSCBAUTH. The only way that security checks are bypassed is via > the NODSI option in the PPT. I think you mean NOPASS. NODSI bypasses the SYSDSN enqueues. Bob -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
>Keep an open mind and use your imagination a little, your point of view isn't the only correct one. Please don't attribute motivations that aren't there. I was asking a question and pointing out what may have been a flaw in reasoning. This has nothing to do with a point of view. I still don't understand the need to protect commands, when the resources are protected. Same question as others have. Still no answer. __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- 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: "Hidden" APARs (Was: Heads Up: APAR IO11698...)
On Sat, Apr 3rd, 2010 at 5:18 AM, Tom Marchant wrote: > >... we missed the "action" item for the PTF because the > >HOLDDATA was marked REASON(EXIT) not REASON(ACTION) and > >we had to remove our SMF dump exit routine > > Don't you think you should check _all_ of the HOLDDATA? What if you don't have the authority to check the RACF profile to see who's role it falls under ... ? Sorry - couldn't resist. Have a good weekend all. Shane ... -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Mark, There has been quite a bit if speculation about "why" IBM made this change. What was the integrity issue. Like you, I was mildly curious. A lot of good people have made a lot of good points and now I have become very curious. As you and others have said, RACF DATASET protection can be used to prevent users from making updates. Assuming that all SMP/E, target, distribution and APF-authorized datasets are properly protected, there shouldn't be an issue. As many have said, RACF PADS can be used to limit those who may invoke SMP/E. I believe that there is a general consensus that it probably isn't solely related to the fact that GIMSMP runs AC(1). As we all know, if you cannot trust staff that has UPDATE access to an APF-authorized library, then all bets are off. I am unaware of any special access that GIMSMP would have when executed by a user who cannot normally update the datasets / HFS files affected by APPLY. At first I thought that a clever user could copy the SMP/E datasets and thereby get around the UPDATE protection (i.e. execute APPLY or ACCEPT using their copy of the SMP/E environment). But, so what? Who cares if they modify their own copies of the SMP/E environment? The target and distribution libraries will not be updated by any of the utilities that SMP/E invokes because SAF will prevent it. All of this lead me to believe that the issue may not be as critical as getting unauthorized access to a dataset or, worse, AC(1) capabilities. It is more likely a consideration that is specific to SMP/E commands. I therefore very much like your "stretch" hypothesis and would like to offer my own: Many of us are more cautious with ACCEPT than we are with APPLY. ACCEPT can delete things (e.g. SMPPTS members and TLIBs). More importantly, ACCEPT can modify an object in a distribution dataset that could conceivably be INCLUDEd into some other product that is installed into a different zone. Perhaps, in some large shop, an untested MOD was ACCEPTed into a DLIB and subsequently pulled into another product's LMOD (via an APPLY in some other zone), which then fell over. Just a thought, but I can "stretch" to envision some customers wanting to control those who may ACCEPT (i.e. limit it to a subset of those who may APPLY). Happy Easter all! Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Friday, April 02, 2010 06:46 To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Fri, 2 Apr 2010 10:41:36 +, Bob Shannon wrote: >We applied the APAR. We protect the SMP data. I'm sort of baffled why >IBM felt SAF support was necessary for SMPE. > >Since we are a development shop in which dozens of people use SMPE, we simply set the access to UACC(READ) which gives everyone access to all of the SMP/E commands. > It's not necessary, but I can "stretch" and see the case where a shop might want to let an ID or group have RECEIVE authority for example, but not let them to do an APPLY or not let them perform admin functions. Perhaps a production userid that does RECEIVE ORDER via a job scheduler on a nightly or weekly basis. For query only, the CSI can simply be protected from update via RACF data set profiles. I'd be mildly curious to know where the requirement came from. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
That was my example. And it is valid. Production job schedulers are the biggest security whole in a shop. The admins can usually make a job run under any ID they want. Regardless, that was just an example. The same could apply to real people whose job it could be to receive maintenance, but not apply it. As R.S. wrote, if you don't like it, there is a simple answer, define a single generic resource with UACC(READ). Keep an open mind and use your imagination a little, your point of view isn't the only correct one. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Fri, 2 Apr 2010 19:29:10 +, Ted MacNEIL wrote: >>Suppose you want a job run via your automated scheduler. This job is only to do a RECEIVE of maintenance. >>You want to run this job with an ID which has only enough authority to do the RECEIVE. > >It's a production job, so it's controlled. >How many controls do we need for the same function? > >>So the job runs under that id. >>That id is only allowed to do the RECEIVE command in SMP/E, and nothing else. The id must have UPDATE access to the SMP/E datasets, but only WHEN using SMP/E. > >I'm too OCD to be AR! > >- >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 -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Wayne Driscoll wrote: Thankfully, APF authorization and system resource access security are 2 separate things. When the OPEN SVC gets invoked, it will perform a RACROUTE REQUEST=AUTH call for the dataset being opened, regardless of the value in JSCBAUTH. The only way that security checks are bypassed is via the NODSI option in the PPT. I think you mean NOPASS. NODSI bypasses the SYSDSN enqueues. Bob -- 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: CBR0095E
Lucy, I am sorry but we have now exceeded my expertise. If you are able to allocate a dataset unto a new 3390-9 in the storage group, I tend to agree with your assessment that all is well with DF/SMS. Unfortunately, I know zilch about DMS. I hope that others will be able to help you. Good luck! Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lucy Arnold Sent: Friday, April 02, 2010 15:28 To: IBM-MAIN@bama.ua.edu Subject: Re: CBR0095E Alan, Here is a screen print of the LDS I am trying to move - it is a VTAPE cache LDS: ,, Menu, Options, View, Utilities, Compilers, Help, ,-- ,DSLIST - Data Sets Matching SYSP.VTTSOC.VVE.D099B.SAND Row 1 of 2, ,Command ===>,,Scroll ===>,CSR , , ,Command - Enter "/" to select action, Message , Volume ,--- , SYSP.VTTSOC.VVE.D099B.SAND ,, *VSAM* , SYSP.VTTSOC.VVE.D099B.SAND.DATA ,, VVE001+ I was able to REPRO this LDS to a new one, and the new one went to the correct pool: ALLOC. FOR SYSLLART REPRO JES2 ALLOCATED TO SYSPRINT JES2 ALLOCATED TO SYSUDUMP SMS ALLOCATED TO DDNAME INFILE SMS ALLOCATED TO DDNAME (OUTFILE ) DSN (SYSP.VTTSOC.VVE.D040210.TEST) STORCLAS (SCVTAPE) MGMTCLAS (SVTSMAN) DATACLAS (DCVTAPE) VOL SER NOS FOR DATA COMPONENT= SBVTP1 I'm beginning to think there is something wrong with my DMS job - not the ACS routines. Thanks! Lucy Arnold Storage Manager U.C. Davis Medical Center 916-734-5498 -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Wayne, I hadn't known that about the DSI keyword on PPT entries. My understanding until now had been: 1) OPEN always invokes SAF, which then invokes RACHECK processing. 2) RACHECK processing bypasses all checks if the trusted or privileged bit is set (logging done for the former but not the latter). These bits are typically set in STDATA segments for STCs. I had always thought that NODSI was applied at ALLOCation time to determine whether or not a SYSDSN ENQ is to be issued. Ya learn something new every day. Thanks for that clarification. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Wayne Driscoll Sent: Friday, April 02, 2010 15:12 To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use Paul, Thankfully, APF authorization and system resource access security are 2 separate things. When the OPEN SVC gets invoked, it will perform a RACROUTE REQUEST=AUTH call for the dataset being opened, regardless of the value in JSCBAUTH. The only way that security checks are bypassed is via the NODSI option in the PPT. Now an APF authorized program could switch to key 0 and update various fields so the security system thinks they have more authority than they really should, but that isn't an issue when using a utility, particularly one that is covered under the z/OS statement of integrity. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Paul Gilmartin To: IBM-MAIN@bama.ua.edu Date: 04/02/2010 05:04 PM Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use Sent by: IBM Mainframe Discussion List On Fri, 2 Apr 2010 16:47:54 -0500, Wayne Driscoll wrote: >Ed's concern is much more valid and realistic than Gil's. In Gil's case, >having SYSPUNCH refer to SYS1.PARMLIB, or some other protected dataset >really won't cause a problem, because APF authorization doesn't >automatically bypass the security system. However, a maliciously coded > OK. Educate me. I had thought that once a program was APF authorized, it became the responsibility of that program to issue the SAF calls and respect the replies; if not, the program could do anything it wanted. For example, suppose someone link edited IEBGENER into an APF authorized library and marked it AC=1. Now, I do: //STEP EXEC PGM=IEBGENER //STEPLIB DD DISP=SHR,DSN=... //SYSUT2DD DISP=SHR,DSN=SYS1.PARMLIB(...) //SYSUT1DD * ... Where does it fail? >HLASM user exit could, since it contains customer supplied code. Of >course, if the Assembler is invoked via SMP/E authorized, those HLASM >exits will have to be located in an APF authorized library, or else a 306 >abend will occur, so the writer of the malicious exit will still need a >way to update an APF library. > And that wouldn't happen, except at Bob Shannon's site. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CBR0095E
Alan, Here is a screen print of the LDS I am trying to move - it is a VTAPE cache LDS: ,, Menu, Options, View, Utilities, Compilers, Help, ,-- ,DSLIST - Data Sets Matching SYSP.VTTSOC.VVE.D099B.SAND Row 1 of 2, ,Command ===>,,Scroll ===>,CSR , , ,Command - Enter "/" to select action, Message , Volume ,--- , SYSP.VTTSOC.VVE.D099B.SAND ,, *VSAM* , SYSP.VTTSOC.VVE.D099B.SAND.DATA ,, VVE001+ I was able to REPRO this LDS to a new one, and the new one went to the correct pool: ALLOC. FOR SYSLLART REPRO JES2 ALLOCATED TO SYSPRINT JES2 ALLOCATED TO SYSUDUMP SMS ALLOCATED TO DDNAME INFILE SMS ALLOCATED TO DDNAME (OUTFILE ) DSN (SYSP.VTTSOC.VVE.D040210.TEST) STORCLAS (SCVTAPE) MGMTCLAS (SVTSMAN) DATACLAS (DCVTAPE) VOL SER NOS FOR DATA COMPONENT= SBVTP1 I'm beginning to think there is something wrong with my DMS job - not the ACS routines. Thanks! Lucy Arnold Storage Manager U.C. Davis Medical Center 916-734-5498 -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Paul, Thankfully, APF authorization and system resource access security are 2 separate things. When the OPEN SVC gets invoked, it will perform a RACROUTE REQUEST=AUTH call for the dataset being opened, regardless of the value in JSCBAUTH. The only way that security checks are bypassed is via the NODSI option in the PPT. Now an APF authorized program could switch to key 0 and update various fields so the security system thinks they have more authority than they really should, but that isn't an issue when using a utility, particularly one that is covered under the z/OS statement of integrity. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Paul Gilmartin To: IBM-MAIN@bama.ua.edu Date: 04/02/2010 05:04 PM Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use Sent by: IBM Mainframe Discussion List On Fri, 2 Apr 2010 16:47:54 -0500, Wayne Driscoll wrote: >Ed's concern is much more valid and realistic than Gil's. In Gil's case, >having SYSPUNCH refer to SYS1.PARMLIB, or some other protected dataset >really won't cause a problem, because APF authorization doesn't >automatically bypass the security system. However, a maliciously coded > OK. Educate me. I had thought that once a program was APF authorized, it became the responsibility of that program to issue the SAF calls and respect the replies; if not, the program could do anything it wanted. For example, suppose someone link edited IEBGENER into an APF authorized library and marked it AC=1. Now, I do: //STEP EXEC PGM=IEBGENER //STEPLIB DD DISP=SHR,DSN=... //SYSUT2DD DISP=SHR,DSN=SYS1.PARMLIB(...) //SYSUT1DD * ... Where does it fail? >HLASM user exit could, since it contains customer supplied code. Of >course, if the Assembler is invoked via SMP/E authorized, those HLASM >exits will have to be located in an APF authorized library, or else a 306 >abend will occur, so the writer of the malicious exit will still need a >way to update an APF library. > And that wouldn't happen, except at Bob Shannon's site. Thanks, gil -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, 2 Apr 2010 16:47:54 -0500, Wayne Driscoll wrote: >Ed's concern is much more valid and realistic than Gil's. In Gil's case, >having SYSPUNCH refer to SYS1.PARMLIB, or some other protected dataset >really won't cause a problem, because APF authorization doesn't >automatically bypass the security system. However, a maliciously coded > OK. Educate me. I had thought that once a program was APF authorized, it became the responsibility of that program to issue the SAF calls and respect the replies; if not, the program could do anything it wanted. For example, suppose someone link edited IEBGENER into an APF authorized library and marked it AC=1. Now, I do: //STEP EXEC PGM=IEBGENER //STEPLIB DD DISP=SHR,DSN=... //SYSUT2DD DISP=SHR,DSN=SYS1.PARMLIB(...) //SYSUT1DD * ... Where does it fail? >HLASM user exit could, since it contains customer supplied code. Of >course, if the Assembler is invoked via SMP/E authorized, those HLASM >exits will have to be located in an APF authorized library, or else a 306 >abend will occur, so the writer of the malicious exit will still need a >way to update an APF library. > And that wouldn't happen, except at Bob Shannon's site. Thanks, gil -- 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: CBR0095E
Lucy, I don't see why you would need OAM unless you use it to track removable media datasets and/or volumes (e.g. an ATL). Physical status "CONVERT" says to me that ICKDSF got the STGR keyword. But perhaps a colleague who knows more than I can confirm this? Could you send a screen print of the dataset that is being MOVED? What happens when you try to allocate a dataset in this storage group yourself (e.g. with JCL)? Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lucy Arnold Sent: Friday, April 02, 2010 14:54 To: IBM-MAIN@bama.ua.edu Subject: Re: CBR0095E Alan, Yes if you display the Storage Group you see all volumes in the correct status: LINE ,,VOLUME,PHYSICAL STORAGE CF VOLUME SAND SAND OPERATOR ,,SERIAL,STATUSGRP NAME STATUSSMS MVS ---(1),,-(2)--,--(22)-- --(23)-- --(24)--- --(25)--- --(26)--- ,,SBVTP1,CONVERT VTPGRPSB - ENABLE <== mod9 ,,VVE001,CONVERT VTPGRPSB - DISNEW ,,VVE002,CONVERT VTPGRPSB - DISNEW ,,VVE003,CONVERT VTPGRPSB - DISNEW ,,VVE004,CONVERT VTPGRPSB - DISNEW ,,VVE005,CONVERT VTPGRPSB - DISNEW --,,--,--- BOTTOM OF DATA --- -- We haven't been running OAM, but we SHOULD have been running it, shouldn't we? Thanks! Lucy Arnold Storage Manager U.C. Davis Medical Center 916-734-5498 -- 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: CBR0095E
Alan, Yes if you display the Storage Group you see all volumes in the correct status: LINE ,,VOLUME,PHYSICAL STORAGE CF VOLUME SAND SAND OPERATOR ,,SERIAL,STATUSGRP NAME STATUSSMS MVS ---(1),,-(2)--,--(22)-- --(23)-- --(24)--- --(25)--- --(26)--- ,,SBVTP1,CONVERT VTPGRPSB - ENABLE <== mod9 ,,VVE001,CONVERT VTPGRPSB - DISNEW ,,VVE002,CONVERT VTPGRPSB - DISNEW ,,VVE003,CONVERT VTPGRPSB - DISNEW ,,VVE004,CONVERT VTPGRPSB - DISNEW ,,VVE005,CONVERT VTPGRPSB - DISNEW --,,--,--- BOTTOM OF DATA --- -- We haven't been running OAM, but we SHOULD have been running it, shouldn't we? Thanks! Lucy Arnold Storage Manager U.C. Davis Medical Center 916-734-5498 -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Ed's concern is much more valid and realistic than Gil's. In Gil's case, having SYSPUNCH refer to SYS1.PARMLIB, or some other protected dataset really won't cause a problem, because APF authorization doesn't automatically bypass the security system. However, a maliciously coded HLASM user exit could, since it contains customer supplied code. Of course, if the Assembler is invoked via SMP/E authorized, those HLASM exits will have to be located in an APF authorized library, or else a 306 abend will occur, so the writer of the malicious exit will still need a way to update an APF library. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Edward Jaffe To: IBM-MAIN@bama.ua.edu Date: 04/02/2010 04:31 PM Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use Sent by: IBM Mainframe Discussion List Paul Gilmartin wrote: > And I see that GIMSMP is linked with AC=1; ASMA90 with AC=0; > both in authorized libraries. > > So, now sheer conjecture. ASMA90 may or may not do exhaustive > SAF checking. Why should it feel obliged to? It was designed > to run unauthorized. So a maliciously crafty programmer could > code an SMP/E APPLY step which invokes ASMA90; preallocate > SYSPUNCH; and supply PUNCH statements which overwrite a member > in what? SYS1.PARMLIB? > Or have your HLASM source/library/print user exits now suddenly getting control in an authorized environment. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: CBR0095E
Lucy, As far as I know, OAM is doing what I would expect it to de doing. It is complaining that you have nothing defined to it, which sounds right to me (since you say that you don't usually use OAM in the sandbox). If I am understanding you correctly, you: > Initialized new 3390-9s > Added these new model 9s to an existing storage group > Set the existing model 3s to DISNEW > Activated the modified SCDS I assume that a dsiplay of the storage group now shows all volumes (i.e. old 3390-3 and new 3390-9)? When you initialized the model 9s, did you specify "STGR" to ICKDSF? I don't know enough about how DMS handles a MOVE, but he must delete the old dataset before attempting to allocate the new one or there will be a cataloguing issue. Regards, Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lucy Arnold Sent: Friday, April 02, 2010 14:19 To: IBM-MAIN@bama.ua.edu Subject: Re: CBR0095E We issued : T SMS=SB IEE252I MEMBER IGDSMSSB FOUND IN CPAC.SB.PARMLIB IGD031I SMS PARAMETERS 283 ACDS = SYS1.SB.ACDS COMMDS = SYS1.SB.COMMDS INTERVAL = 15 DINTERVAL = 150 CACHETIME = 3600SMF_TIME = YES CF-TIME = 3600 PDSE_RESTARTABLE_AS = NO PDSE_BMFTIME = 3600 PDSE1_BMFTIME = 3600 PDSE_LRUTIME = 60 PDSE1_LRUTIME = 60 PDSE_LRUCYCLES = 15PDSE1_LRUCYCLES = 15 LOCAL_DEADLOCK = 15 GLOBAL_DEADLOCK = 4 REVERIFY = NO ACSDEFAULTS = NO USE_RESOWNER = YES DSNTYPE = PDS GDS_RECLAIM = YES PDSESHARING = NORMAL OVRD_EXPDT = NO RLS_MAX_POOL_SIZE = 100MB SYSTEMS = 8 COMPRESS = GENERIC PDSE_HSP_SIZE = 0MB PDSE1_HSP_SIZE = 0MB RLSINIT = NORLSTMOUT = 0 CICSVR_INIT = NOCICSVR_DSNAME_PREFIX = DWW. CICSVR_RCDS_PREFIX = DWW CICSVR_GRPNAME_SUFFIX = PROD CICSVR_ZZVALUE_PARM = CICSVR_UNDOLOG_CONTROL = CICSVR_UNDOLOG_PREFIX = DWW CICSVR_BACKOUT_CONTROL = CICSVR_GENERAL_CONTROL = Rls_MaxCfFeatureLevel = Z RlsAboveTheBarMaxPoolSize = 0 RlsFixedPoolSize = 0 DSSTIMEOUT = 0 FAST_VOLSEL = OFF PDSE_MONITOR = (YES,0,0) PDSE1_MONITOR = (YES,0,0) PDSE_DIRECTORY_STORAGE = 2000M PDSE1_DIRECTORY_STORAGE = 2000M PDSE_BUFFER_BEYOND_CLOSE = NO PDSE1_BUFFER_BEYOND_CLOSE = NO BLOCKTOKENSIZE = NOREQUIRE IGD031I SMS TRACE PARAMETERS 284 IGD031I SMS TRACE PARAMETERS 284 TRACE= ON SIZE = 128K TYPE = ALL JOBNAME = *ASID = * TRACING EVENTS: MODULE = ON SMSSJF = ON SMSSSI = ON ACSINT = ON OPCMD = ON CONFC = ON CDSC = ON CONFS = ON MSG= ON ERR= ON CONFR = ON CONFA = ON ACSPRO = ON IDAX = ON DISP = ON CATG = ON VOLREF = ON SCHEDP = ON SCHEDS = ON VTOCL = ON VTOCD = ON VTOCR = ON VTOCC = ON VTOCA = ON RCD= ON DCF= ON DPN= ON TVR= ON DSTACK = ON UAFF = ON DEBUG = ON VOLSELMSG = (OFF,0)TYPE = ALLJOBNAME = * ASID = * STEPNAME = * DSNAME = * IGW040I Buffer Beyond Close not active for SMSPDSE IGW467I DFSMS RLSINIT PARMLIB VALUE ON SYSTEM: SAND 286 CURRENT VALUE: NO IGW451I REQUEST TO UPDATE VSAM/RLS PARMLIB 287 KEYWORD: RlsAboveTheBarMaxPoolSize KEYWORD: RlsAboveTheBarMaxPoolSize HAS BEEN SAVED IN THE SMS CONTROL STRUCTURES. THE PARMLIB KEYWORD WILL BE PROCESSED BY VSAM/RLS WHEN THE VSAM/RLS ADDRESS SPACE IS STARTED IGW451I REQUEST TO UPDATE VSAM/RLS PARMLIB 288 KEYWORD: RlsFixedPoolSize HAS BEEN SAVED IN THE SMS CONTROL STRUCTURES. THE PARMLIB KEYWORD WILL BE PROCESSED BY VSAM/RLS WHEN THE VSAM/RLS ADDRESS SPACE IS STARTED IGW451I REQUEST TO UPDATE VSAM/RLS PARMLIB 289 KEYWORD: DssTimeOut HAS BEEN SAVED IN THE SMS CONTROL STRUCTURES. THE PARMLIB KEYWORD WILL BE PROCESSED BY VSAM/RLS WHEN THE VSAM/RLS ADDRESS SPACE IS STARTED IEE536I SMS VALUE SB NOW IN EFFECT IGD009I ACDS SWITCHED TO SYS1.SB.ACDS We then started OAM: S OAM $HASP100 OAM ON STCINRDR IEF695I START OAM WITH JOBNAME OAM IS ASSIGNED TO USER OAM , GROUP SYS1 $HASP373 OAM STARTED IEF403I OAM - STARTED - TIME=14.09.47 CBR0001I OAM initialization starting. CBR0095E OAM waiting for SMS Control Data Set activation. Lucy Arnold Storage Manager U.C. Davis Medical Center 916-734-5498 -- 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: CBR0095E
Do you have a valid IGDSMSnn member in PARMLIB, which contains your SMS configuration? If so then issue the operator command: T SMS=nn If not, then create one. Ours looks like: SMS ACDS(SYS3.SMS.ACDS1) COMMDS(SYS3.SMS.COMMDS1) INTERVAL(15) OAMPROC(OAM) DB2SSID(NONE) DINTERVAL(150) REVERIFY(NO) ACSDEFAULTS(YES) TRACE(ON) SIZE(128K) PDSE_RESTARTABLE_AS(YES) OVRD_EXPDT(YES) VOLSELMSG(OFF) TYPE(ALL) JOBNAME(*) ASID(*) SELECT(ALL) Or you could do an operator command something like: SETSMS ACDS=my.acds.dsn,SCDS=my.scds.dsn,COMMDS=my.commds.dsn -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lucy Arnold > Sent: Friday, April 02, 2010 3:54 PM > To: IBM-MAIN@bama.ua.edu > Subject: CBR0095E > > Hello all! > > I am trying to change a DFSMS managed pool from 6 Shark MOD3s > to 1 Hitachi > MOD9. Our PROD and SANDBOX LPARs share the ACS routines, but have > different SCDS, ACDS & COMMDS. I made the MOD3s DISNEW, and added the > MOD9. I did the translate, validate and activate and the new > configuration > was activated. Yet, when I tried to move the data with DMS I got: > 2860 PROCESSING STARTED FOR VOLUME = VVE001 > 3446 SMS ERROR DETECTED, RC= > 3415 DEFINE FAILED FOR DATASET SYSP.VTTSOC.VVE.D0994.SAND > 3412 MOVE FAILED FOR DATA SET SYSP.VTTSOC.VVE.D0994.SAND . > RETURN CODE IS > 8 > 3446 SMS ERROR DETECTED, RC= > > These indicate a sub-system error. I went to my boss and he > said it was > because OAM was not running. We started OAM, but when we try > to activate > again we get: > > IEF403I OAM - STARTED - TIME=11.07.05 > CBR0001I OAM initialization starting. > CBR0095E OAM waiting for SMS Control Data Set activation. > > Explanation: OAM has initialized with a null configuration. > No optical > libraries, tape libraries or object storage groups are defined in the > active SMS configuration. > > We do have pools and a tape library defined, though the > SANDBOX has no > access to the library - but then it never has and there has been no > problem. I could find nothing on the Internet so was hoping > ya'll had > some ideas! > > Thanks in advance!!! > > > Lucy Arnold > Storage Manager > U.C. Davis Medical Center > 916-734-5498 > > > -- > 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: CBR0095E
Thanks! We'll look and give it a try! Lucy Arnold Storage Manager U.C. Davis Medical Center 916-734-5498 -- 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: WTO Alternative using HLASM
- From: Shmuel Metz (Seymour J.) To: IBM-MAIN@bama.ua.edu Sent: Thu, April 1, 2010 11:51:26 AM Subject: Re: WTO Alternative using HLASM In <432460.39432...@web54606.mail.re2.yahoo.com>, on 03/29/2010 at 09:42 PM, Ed Gould said: I cannot for the life of me remember the IBM module name that provides this maybe someone can pipe up here and remind me of the name. IEFYS? SNIP- I am pretty sure that is correct. Now for the 10 dollar question where is it documented? Ed --- It's DOC'd in MVS Installation Exits, but the example given is poorly written. Rick -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL > Sent: Friday, April 02, 2010 2:09 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class > definition required for any SMP/E use > > >I already wrote the idea is perfectly OK and (maybe) it's > NOT violated by the profiles. I repeat the possible > explanation: separation of rules. > > Juist because you've repeated your statement, it doesn't make > it valid. > Separate files, not commands! > > >Several rules could need same access to SMPE datasets, so if > you want to > make them separate, you need another check, access to > resources is not enough here. > > I disagree. > Give me an example; a valid one. > > Anything else is just rectal smoke! > > And, repeating what you've said without some evidence is just > more smoke. > > Why is command protection better than resource/file protection. > > Separate the SYSPROG roles by files/data rather than command. > > For example, everbody can invoke ISPF browse, but not all can > read all files. > > This may sound simplistic, or apples & oranges, but it > illustrates my point. > > - > Too busy driving to stop for gas! As somebody in this thread said. Suppose you want a job run via your automated scheduler. This job is only to do a RECEIVE of maintenance. You want to run this job with an ID which has only enough authority to do the RECEIVE. So the job runs under that id. That id is only allowed to do the RECEIVE command in SMP/E, and nothing else. The id must have UPDATE access to the SMP/E datasets, but only WHEN using SMP/E. Grant the id permission to the datasets via PADS (Program Access to Data Sets) via the WHEN clause of the PERMIT command. Grant the id only SMP/E permission to the RECEIVE command so that nothing else could be done using the command. This is similar logic to "I want user ... to be able to READ a dataset using program ..., but not be able to download the data via ftp or look at it in ISPF." In this case, the user would need PADS access to the dataset with the WHEN clause so that they can READ the data only using that exact program. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
>Suppose you want a job run via your automated scheduler. This job is only to >do a RECEIVE of maintenance. >You want to run this job with an ID which has only enough authority to do the >RECEIVE. It's a production job, so it's controlled. How many controls do we need for the same function? >So the job runs under that id. >That id is only allowed to do the RECEIVE command in SMP/E, and nothing else. >The id must have UPDATE access to the SMP/E datasets, but only WHEN using >SMP/E. I'm too OCD to be AR! - 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Paul Gilmartin wrote: And I see that GIMSMP is linked with AC=1; ASMA90 with AC=0; both in authorized libraries. So, now sheer conjecture. ASMA90 may or may not do exhaustive SAF checking. Why should it feel obliged to? It was designed to run unauthorized. So a maliciously crafty programmer could code an SMP/E APPLY step which invokes ASMA90; preallocate SYSPUNCH; and supply PUNCH statements which overwrite a member in what? SYS1.PARMLIB? Or have your HLASM source/library/print user exits now suddenly getting control in an authorized environment. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, 2 Apr 2010 07:47:23 -0700, Edward Jaffe wrote: > >Exactly! The problem is that GIMSMP is APF authorized. > >AFAIK, that's true only because IEBCOPY requires APF authorization. > What about S99WTDSN? -- gil -- 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: IMS log record sequence number first byte 'F1'x - why?
I don't know the answer to your question, but if you need to find the IMS List look at im...@imslistserv.bmc.com The instructions I have are: On August 1, 2008, the sponsorship of the IMS List Serv site will be changing. We would like to thank University of Missouri, especially Len Rugen for their many years of sponsorship. As Len has stated in the past the reason for the change is that they are no longer supporting IMS at their site. The new sponsor will be BMC Software, yet all data and processes will be managed by LSoft (the owner of ListServ software) on the LSoft servers. You should find that everything will work the same. The archives have been transferred to the LSoft server. The only change you might have would be email rules associated with the old name. Please feel free to logon to the new server at IMSListServ.bmc.com to update your profile if needed. All help, commands and user information will be available at that site. The new name to direct messages to all users will be ims-l-requ...@imslistserv.bmc.com. If you have any questions, feel free to contact us via the ListServ or nick_grif...@bmc.com Mark Hammond -Original Message- From: Barry Merrill [mailto:ba...@mxg.com] Sent: Friday, April 02, 2010 3:18 PM To: IBM-MAIN@bama.ua.edu Subject: IMS log record sequence number first byte 'F1'x - why? Hoping to find my answer within this esteemed group, rather than finding/subscribing/posting to an IMS equivalent, does anyone know the significance of the first byte of the 8-byte IMS Log Sequence Number (the last eight bytes of each record)? I'm seeing log records with 'F1'x (e.g., '1' EBCDIC) in the first byte in IMS 11, with one-to-several bytes with hex-zeros, and then the sequence number in the low bytes. Spent almost an hour searching with no clue before asking. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- 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
IMS log record sequence number first byte 'F1'x - why?
Hoping to find my answer within this esteemed group, rather than finding/subscribing/posting to an IMS equivalent, does anyone know the significance of the first byte of the 8-byte IMS Log Sequence Number (the last eight bytes of each record)? I'm seeing log records with 'F1'x (e.g., '1' EBCDIC) in the first byte in IMS 11, with one-to-several bytes with hex-zeros, and then the sequence number in the low bytes. Spent almost an hour searching with no clue before asking. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- 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
CBR0095E
Hello all! I am trying to change a DFSMS managed pool from 6 Shark MOD3s to 1 Hitachi MOD9. Our PROD and SANDBOX LPARs share the ACS routines, but have different SCDS, ACDS & COMMDS. I made the MOD3s DISNEW, and added the MOD9. I did the translate, validate and activate and the new configuration was activated. Yet, when I tried to move the data with DMS I got: 2860 PROCESSING STARTED FOR VOLUME = VVE001 3446 SMS ERROR DETECTED, RC= 3415 DEFINE FAILED FOR DATASET SYSP.VTTSOC.VVE.D0994.SAND 3412 MOVE FAILED FOR DATA SET SYSP.VTTSOC.VVE.D0994.SAND . RETURN CODE IS 8 3446 SMS ERROR DETECTED, RC= These indicate a sub-system error. I went to my boss and he said it was because OAM was not running. We started OAM, but when we try to activate again we get: IEF403I OAM - STARTED - TIME=11.07.05 CBR0001I OAM initialization starting. CBR0095E OAM waiting for SMS Control Data Set activation. Explanation: OAM has initialized with a null configuration. No optical libraries, tape libraries or object storage groups are defined in the active SMS configuration. We do have pools and a tape library defined, though the SANDBOX has no access to the library - but then it never has and there has been no problem. I could find nothing on the Internet so was hoping ya'll had some ideas! Thanks in advance!!! Lucy Arnold Storage Manager U.C. Davis Medical Center 916-734-5498 -- 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: CBR0095E
We issued : T SMS=SB IEE252I MEMBER IGDSMSSB FOUND IN CPAC.SB.PARMLIB IGD031I SMS PARAMETERS 283 ACDS = SYS1.SB.ACDS COMMDS = SYS1.SB.COMMDS INTERVAL = 15 DINTERVAL = 150 CACHETIME = 3600SMF_TIME = YES CF-TIME = 3600 PDSE_RESTARTABLE_AS = NO PDSE_BMFTIME = 3600 PDSE1_BMFTIME = 3600 PDSE_LRUTIME = 60 PDSE1_LRUTIME = 60 PDSE_LRUCYCLES = 15PDSE1_LRUCYCLES = 15 LOCAL_DEADLOCK = 15 GLOBAL_DEADLOCK = 4 REVERIFY = NO ACSDEFAULTS = NO USE_RESOWNER = YES DSNTYPE = PDS GDS_RECLAIM = YES PDSESHARING = NORMAL OVRD_EXPDT = NO RLS_MAX_POOL_SIZE = 100MB SYSTEMS = 8 COMPRESS = GENERIC PDSE_HSP_SIZE = 0MB PDSE1_HSP_SIZE = 0MB RLSINIT = NORLSTMOUT = 0 CICSVR_INIT = NOCICSVR_DSNAME_PREFIX = DWW. CICSVR_RCDS_PREFIX = DWW CICSVR_GRPNAME_SUFFIX = PROD CICSVR_ZZVALUE_PARM = CICSVR_UNDOLOG_CONTROL = CICSVR_UNDOLOG_PREFIX = DWW CICSVR_BACKOUT_CONTROL = CICSVR_GENERAL_CONTROL = Rls_MaxCfFeatureLevel = Z RlsAboveTheBarMaxPoolSize = 0 RlsFixedPoolSize = 0 DSSTIMEOUT = 0 FAST_VOLSEL = OFF PDSE_MONITOR = (YES,0,0) PDSE1_MONITOR = (YES,0,0) PDSE_DIRECTORY_STORAGE = 2000M PDSE1_DIRECTORY_STORAGE = 2000M PDSE_BUFFER_BEYOND_CLOSE = NO PDSE1_BUFFER_BEYOND_CLOSE = NO BLOCKTOKENSIZE = NOREQUIRE IGD031I SMS TRACE PARAMETERS 284 IGD031I SMS TRACE PARAMETERS 284 TRACE= ON SIZE = 128K TYPE = ALL JOBNAME = *ASID = * TRACING EVENTS: MODULE = ON SMSSJF = ON SMSSSI = ON ACSINT = ON OPCMD = ON CONFC = ON CDSC = ON CONFS = ON MSG= ON ERR= ON CONFR = ON CONFA = ON ACSPRO = ON IDAX = ON DISP = ON CATG = ON VOLREF = ON SCHEDP = ON SCHEDS = ON VTOCL = ON VTOCD = ON VTOCR = ON VTOCC = ON VTOCA = ON RCD= ON DCF= ON DPN= ON TVR= ON DSTACK = ON UAFF = ON DEBUG = ON VOLSELMSG = (OFF,0)TYPE = ALLJOBNAME = * ASID = * STEPNAME = * DSNAME = * IGW040I Buffer Beyond Close not active for SMSPDSE IGW467I DFSMS RLSINIT PARMLIB VALUE ON SYSTEM: SAND 286 CURRENT VALUE: NO IGW451I REQUEST TO UPDATE VSAM/RLS PARMLIB 287 KEYWORD: RlsAboveTheBarMaxPoolSize KEYWORD: RlsAboveTheBarMaxPoolSize HAS BEEN SAVED IN THE SMS CONTROL STRUCTURES. THE PARMLIB KEYWORD WILL BE PROCESSED BY VSAM/RLS WHEN THE VSAM/RLS ADDRESS SPACE IS STARTED IGW451I REQUEST TO UPDATE VSAM/RLS PARMLIB 288 KEYWORD: RlsFixedPoolSize HAS BEEN SAVED IN THE SMS CONTROL STRUCTURES. THE PARMLIB KEYWORD WILL BE PROCESSED BY VSAM/RLS WHEN THE VSAM/RLS ADDRESS SPACE IS STARTED IGW451I REQUEST TO UPDATE VSAM/RLS PARMLIB 289 KEYWORD: DssTimeOut HAS BEEN SAVED IN THE SMS CONTROL STRUCTURES. THE PARMLIB KEYWORD WILL BE PROCESSED BY VSAM/RLS WHEN THE VSAM/RLS ADDRESS SPACE IS STARTED IEE536I SMS VALUE SB NOW IN EFFECT IGD009I ACDS SWITCHED TO SYS1.SB.ACDS We then started OAM: S OAM $HASP100 OAM ON STCINRDR IEF695I START OAM WITH JOBNAME OAM IS ASSIGNED TO USER OAM , GROUP SYS1 $HASP373 OAM STARTED IEF403I OAM - STARTED - TIME=14.09.47 CBR0001I OAM initialization starting. CBR0095E OAM waiting for SMS Control Data Set activation. Lucy Arnold Storage Manager U.C. Davis Medical Center 916-734-5498 -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, 2 Apr 2010 09:56:28 -0700, Edward Jaffe wrote: > >An authorized program abends with 306-C if it tries to load a module >from an unauthorized library. That's all. There is no requirement that >the modules it attaches be linked with AC(1). > Thanks. I keep forgetting the rule. And I see that GIMSMP is linked with AC=1; ASMA90 with AC=0; both in authorized libraries. So, now sheer conjecture. ASMA90 may or may not do exhaustive SAF checking. Why should it feel obliged to? It was designed to run unauthorized. So a maliciously crafty programmer could code an SMP/E APPLY step which invokes ASMA90; preallocate SYSPUNCH; and supply PUNCH statements which overwrite a member in what? SYS1.PARMLIB? Multiply that by the increasing number of utilities called by SMP/E which may not do SAF checking and SMP/E is strongly impelled to shift the security burden to customers' system administrators. >>> IMHO, the "right" fix would have been to "enhance" IEBCOPY to use >>> alternate I/O techniques when not running APF authorized. (BTW, that >>> Amen. I can live without S99WTDSN. If I specify NOWAIT on my DDDEFS, SMP/E operations not involving a copy run fine. -- gil -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
>I wish life were that simple. In our shop each of the 6 disciplines you mention has a different maintenance team. Yes! So? That is not necessarily wrong. Protect the files, and let them use the commands. > We haven't yet developed roles that specialize, i.e. receive, apply, accept, but it's certainly thought provoking. Why? Who has that many sysprogs? >Has anyone ever applied something they should not have, due to inexperience? So, you're saying that these new rules will protect your shop? Somebody still has to apply, experienced or not. A protection of function doesn't stop that. You still need people who know what they ared doing. - 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
>I already wrote the idea is perfectly OK and (maybe) it's NOT violated by the >profiles. I repeat the possible explanation: separation of rules. Juist because you've repeated your statement, it doesn't make it valid. Separate files, not commands! >Several rules could need same access to SMPE datasets, so if you want to make them separate, you need another check, access to resources is not enough here. I disagree. Give me an example; a valid one. Anything else is just rectal smoke! And, repeating what you've said without some evidence is just more smoke. Why is command protection better than resource/file protection. Separate the SYSPROG roles by files/data rather than command. For example, everbody can invoke ISPF browse, but not all can read all files. This may sound simplistic, or apples & oranges, but it illustrates my point. - 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
I wish life were that simple. In our shop each of the 6 disciplines you mention has a different maintenance team. We haven't yet developed roles that specialize, i.e. receive, apply, accept, but it's certainly thought provoking. Has anyone ever applied something they should not have, due to inexperience? I've experienced both extremes of the size of shop. The mind sets are vastly different. The crew of the destroyer escort works differently than the crew of an aircraft carrier. Rules differ accordingly. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Friday, April 02, 2010 1:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use >large organizations should think this through in case a role based methodology would be helpful in the SMPE staff. Role Based? You install software & maintain it, or you don't. CICS, IMS, MQ, DB2, z/OS, and others. You don't want SYSPROG1 stumbling over SYSPROG2 means you protect their SMPTS, and other files. NOT the functions! - 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 -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
W dniu 2010-04-02 20:17, Ted MacNEIL pisze:
Last but not least: What's a problem gyus???
Do you want it to work in
the old manner?
You need to issue 2-3 RACF commands: RDEF FACI GIM.** DATA('I dont like
security for SMPE') UACC(A) SETR RACLIST(FACI) REF
And voila.
Yes! But!
Protect the resource, not the programme.
I already wrote the idea is perfectly OK and (maybe) it's NOT violated
by the profiles. I repeat the possible explanation: separation of rules.
Several rules could need same access to SMPE datasets, so if you want to
make them separate, you need another check, access to resources is not
enough here.
I don't care if it's only one step.
So what if it's sinple.
There is no reason to grumble, even if you don't need it, don't like it,
don't understand it.
The point is why?
Explained above.
Can/will IBM explain the so-called need?
I wish it too. However my guess looks quite
reasonable
--
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.2009 r. kapitał zakładowy BRE Banku SA (w całości
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym
BRE Banku SA będą w całości opłacone.
--
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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
>large organizations should think this through in case a role based methodology would be helpful in the SMPE staff. Role Based? You install software & maintain it, or you don't. CICS, IMS, MQ, DB2, z/OS, and others. You don't want SYSPROG1 stumbling over SYSPROG2 means you protect their SMPTS, and other files. NOT the functions! - 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, 2 Apr 2010 18:17:34 +, Ted MacNEIL wrote: >The point is why? > >Can/will IBM explain the so-called need? Not likely, but Ed did give a very plausible explanation. -- Tom Marchant -- 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: "Hidden" APARs (Was: Heads Up: APAR IO11698...)
On Fri, 2 Apr 2010 12:28:04 -0500, Larre Shiller wrote: >... we missed the "action" item for the PTF because the >HOLDDATA was marked REASON(EXIT) not REASON(ACTION) and >we had to remove our SMF dump exit routine Don't you think you should check _all_ of the HOLDDATA? -- Tom Marchant -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
>Last but not least: What's a problem gyus???
>Do you want it to work in
the old manner?
>You need to issue 2-3 RACF commands: RDEF FACI GIM.** DATA('I dont like
>security for SMPE') UACC(A) SETR RACLIST(FACI) REF
>And voila.
Yes! But!
Protect the resource, not the programme.
I don't care if it's only one step.
So what if it's sinple.
The point is why?
Can/will IBM explain the so-called need?
-
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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Well put, Mr. RS. I can certainly envision this
scenario in a large company with segregated roles.
Conceptually this looks like various sub-function
controls that CEMT has in the CICS world and the
STGADMIN profiles in storage management world.
As to why IBM developed this, maybe someone asked for
it... It's easy enough to implement, easy enough
to effectively bypass, though large organizations
should think this through in case a role based
methodology would be helpful in the SMPE staff.
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S.
Sent: Friday, April 02, 2010 12:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY
class definition required for any SMP/E use
W dniu 2010-04-02 16:19, Paul Gilmartin pisze:
> On Fri, 2 Apr 2010 10:41:36 +, Bob Shannon wrote:
>
>> We applied the APAR. We protect the SMP data. I'm
sort of baffled why IBM felt SAF support was necessary
for SMPE.
>>
>
> Me either. And since it's called "integrity", we'll
never know.
It's a pity. I'd like to know.
[...]
> What is becoming of the philosophy, "Protect
resources; don't restrict
> access to tools."
>
I agree with the rule. However I would imagine the
following scenario:
multiple rules within SMP/E team. I.e. John can receive
the service, but he cannot APPLY, because it's Fred's
responsibility. Both need access to datasets. Think
about granularity. Of course it's my guess only, but
not so wild - see latest SAF changes in ICSF - very
reasonable and a (very) little bit similar to those in
SMP/E.
Last but not least: What's a problem gyus??? Do you
want it to work in the old manner? You need to issue
2-3 RACF commands:
RDEF FACI GIM.** DATA('I dont like security for SMPE')
UACC(A) SETR RACLIST(FACI) REF And voila.
Happy Easter
--
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.2009 r. kapitał zakładowy
BRE Banku SA (w całości wpłacony) wynosi 118.763.528
złotych. W związku z realizacją warunkowego
podwyższenia kapitału zakładowego, na podstawie uchwały
XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z
dnia 27 października 2008r., może ulec podwyższeniu do
kwoty 123.763.528 zł. Akcje w podwyższonym kapitale
zakładowym BRE Banku SA będą w całości opłacone.
---
---
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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, Apr 2, 2010 at 12:27 PM, R.S. wrote:
> W dniu 2010-04-02 16:19, Paul Gilmartin pisze:
>
> On Fri, 2 Apr 2010 10:41:36 +, Bob Shannon wrote:
>>
>> We applied the APAR. We protect the SMP data. I'm sort of baffled why IBM
>>> felt SAF support was necessary for SMPE.
>>>
>>>
>> Me either. And since it's called "integrity", we'll never know.
>>
> It's a pity. I'd like to know.
> [...]
>
>
> What is becoming of the philosophy, "Protect resources; don't
>> restrict access to tools."
>>
>>
> I agree with the rule. However I would imagine the following scenario:
> multiple rules within SMP/E team. I.e. John can receive the service, but he
> cannot APPLY, because it's Fred's responsibility. Both need access to
> datasets. Think about granularity. Of course it's my guess only, but not so
> wild - see latest SAF changes in ICSF - very reasonable and a (very) little
> bit similar to those in SMP/E.
>
> Last but not least: What's a problem gyus??? Do you want it to work in the
> old manner? You need to issue 2-3 RACF commands:
> RDEF FACI GIM.** DATA('I dont like security for SMPE') UACC(A)
> SETR RACLIST(FACI) REF
> And voila.
>
> Yes, but since it is an integrity apar and you are now making everything
like it was what 'integrity hole' are you re-opening?
>
> Happy Easter
> --
> 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.2009 r. kapitał zakładowy BRE Banku SA (w
> całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją
> warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z
> dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r.,
> może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym
> kapitale zakładowym BRE Banku SA będą w całości opłacone.
>
>
> --
> 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe > > Paul Gilmartin wrote: > > On Fri, 2 Apr 2010 07:47:23 -0700, Edward Jaffe wrote: > > > >> Exactly! The problem is that GIMSMP is APF authorized. > >> [ snip ] > >> AFAIK, that's true only because IEBCOPY requires APF authorization. > >> That's required because IEBCOPY uses I/O appendages. But, trust me, it's > >> not doing *anything* that can't also be done without I/O appendages. > >> > > Performance? > > Maybe in the old days. The channel programs it uses are extremely > antiquated. New channel programs, without appendages, would run circles > around what they're doing now. Well, DFSORT gave us ICEGENER to "sub" for IEBGENER. Perhaps they could be persuaded to provide an ICECOPY (that doesn't require authorization) as a "substitute" for IEBCOPY? -jc- -- 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: "Hidden" APARs (Was: Heads Up: APAR IO11698...)
I don't recall ever reporting any integrity-related issues or getting a hidden APAR, but I did recently stumble over another hidden APAR: OA29894. Apparently we missed the "action" item for the PTF because the HOLDDATA was marked REASON(EXIT) not REASON(ACTION) and we had to remove our SMF dump exit routine until we could open an ETR and figure out what changed/happened. It makes problem determination fun when you cannot even cross-reference the symptoms of a problem with a hidden APAR in the IBMLink data base. Since then, IBM documented the messages, but you still cannot see the APAR. Larre Shiller US Social Security Administration 410.965.2209 www.ssa.gov "The contents of this message are mine personally and do not necessarily reflect any official position of the US Government or the US Social Security Administration." -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
W dniu 2010-04-02 16:19, Paul Gilmartin pisze:
On Fri, 2 Apr 2010 10:41:36 +, Bob Shannon wrote:
We applied the APAR. We protect the SMP data. I'm sort of baffled why IBM felt
SAF support was necessary for SMPE.
Me either. And since it's called "integrity", we'll never know.
It's a pity. I'd like to know.
[...]
What is becoming of the philosophy, "Protect resources; don't
restrict access to tools."
I agree with the rule. However I would imagine the following scenario:
multiple rules within SMP/E team. I.e. John can receive the service, but
he cannot APPLY, because it's Fred's responsibility. Both need access to
datasets. Think about granularity. Of course it's my guess only, but not
so wild - see latest SAF changes in ICSF - very reasonable and a (very)
little bit similar to those in SMP/E.
Last but not least: What's a problem gyus??? Do you want it to work in
the old manner? You need to issue 2-3 RACF commands:
RDEF FACI GIM.** DATA('I dont like security for SMPE') UACC(A)
SETR RACLIST(FACI) REF
And voila.
Happy Easter
--
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.2009 r. kapitał zakładowy BRE Banku SA (w całości
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym
BRE Banku SA będą w całości opłacone.
--
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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Paul Gilmartin wrote: On Fri, 2 Apr 2010 07:47:23 -0700, Edward Jaffe wrote: Exactly! The problem is that GIMSMP is APF authorized. I've long wondered about this. Does this mean, in turn, that all utilities GIMSMP invokes (IEBCOPY, Binder, Assembler, et al.) must likewise be authorized? It is my understanding that an authorized program ABENDs if it attempts to ATTACH an unauthorized subtask. An authorized program abends with 306-C if it tries to load a module from an unauthorized library. That's all. There is no requirement that the modules it attaches be linked with AC(1). AFAIK, that's true only because IEBCOPY requires APF authorization. That's required because IEBCOPY uses I/O appendages. But, trust me, it's not doing *anything* that can't also be done without I/O appendages. Performance? Maybe in the old days. The channel programs it uses are extremely antiquated. New channel programs, without appendages, would run circles around what they're doing now. IMHO, the "right" fix would have been to "enhance" IEBCOPY to use alternate I/O techniques when not running APF authorized. (BTW, that They're 1/3 of the way there. Ever do LOOKAT IEB1099I? I asked IBM in an RCF to elaborate this; IBM declined expressing an unwillingness to document, and thereby commit to maintaining the current behavior. This has been a "thorn" for years. They should do something about it. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
>>not doing *anything* that can't also be done without I/O appendages. >Performance? These days, I doubt that's a major issue. I'll stand by that equivocall response until somebody in the know tells me why it's still required. SPFCOPY works unauthorised. - 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
>>Since we are a development shop in which dozens of people use SMPE, we simply >>set the access to >>UACC(READ) which gives everyone access to all of the >>SMP/E commands. >Us too. I've put in the request. I should add that any user can APF-authorize a library. And the rest of you think you have integrity problems :-( Bob Shannon Rocket Software -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, 2 Apr 2010 07:47:23 -0700, Edward Jaffe wrote: >Lou Losee wrote: >> The thing is integrity APARs do not come from requirements, they come from >> exposures that violate IBMs integrity statement. So I would think that the >> reason behind the APAR has to be deeper than just segregating the use of >> SMPE. >> > >Exactly! The problem is that GIMSMP is APF authorized. > I've long wondered about this. Does this mean, in turn, that all utilities GIMSMP invokes (IEBCOPY, Binder, Assembler, et al.) must likewise be authorized? It is my understanding that an authorized program ABENDs if it attempts to ATTACH an unauthorized subtask. >AFAIK, that's true only because IEBCOPY requires APF authorization. >That's required because IEBCOPY uses I/O appendages. But, trust me, it's >not doing *anything* that can't also be done without I/O appendages. > Performance? >IMHO, the "right" fix would have been to "enhance" IEBCOPY to use >alternate I/O techniques when not running APF authorized. (BTW, that They're 1/3 of the way there. Ever do LOOKAT IEB1099I? I asked IBM in an RCF to elaborate this; IBM declined expressing an unwillingness to document, and thereby commit to maintaining the current behavior. >would solve numerous other non-SMP/E-related issues at the same time. >Ever tried to invoke IEBCOPY from a REXX?) > Even from "address TSO CALL *(GIMSMP)" (very schematically) from a Rexx running under z/OS Unix. I do it regularly. It works, sort of. But when SMP/E recovers from a Sx37 and reports "THE HIGHEST RETURN CODE WAS 00", TSO reports RC=12 for the CALL. >Removing APF authorization from GIMSMP would remove the potential for >integrity exposure. In that case, these ridiculous new SAF resources for >SMP/E--which really do nothing to protect the system--would never have >been created in the first place. > Yup. Marna's presentation mentions, but counsels against UACC(READ) I haven't easy access to the ++HOLD in the APAR. Does it expand on the depth of the exposure (unlikely in an integrity APAR), or provide the administrator any guidance for granting access? Might it be as serious as, "any user given access to APPLY can use that privilege to update any authorized library"? We'll never know. -- gil -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Brian Peterson > > My use of the phrase "(fortunately) rare" was a qualitative judgment on my > part, based upon observation of the z/OS service stream for many years. > > At SHARE in Washington DC (Summer 2003), I talked about secret APARs and > provided a technique that any customer can use to make their own > quantitative assessment of the state of their system. > > http://www.share.org/Portals/0/BitBuckets/BitBucket26.pdf (starting on page 22) Based on p. 29 of the cited .pdf document, it would seem that all "Integrity" APARs are HIPER "by definition"; thus failure to additionally flag them HIPER borders on fraud. -jc- -- 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: z/OS V1R11 Library unzip problem
Looks like the culprit was IE6. Thanks everyone. Luke -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Brian Peterson Sent: Wednesday, March 31, 2010 9:30 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS V1R11 Library unzip problem According to the following article, IE6 can only download 2 GB files, and IE7 only 4 GB. http://support.microsoft.com/kb/298618 -=-=-=-=- Symptom: When you attempt to download a file from the Internet by using Hypertext Transfer Protocol (HTTP) in Microsoft Internet Explorer, you may find that the download does not complete. As a result, you cannot download the file. Cause: This behavior can occur if you try to download a file that is larger than 2 gigabytes (GB) in Internet Explorer 6 or is larger than 4 GB in Internet Explorer 7. Note This download limit has been removed in Internet Explorer 8. Therefore, you should not experience this behavior in Internet Explorer 8. -=-=-=-=- Or, of course, Firefox or other browsers Brian On Wed, 31 Mar 2010 08:04:58 -0500, Tim Deller wrote: >The file was incomplete (corrupt) when I downloaded it with http (several >times). Then I used their 'download director' and that gave me the complete >file which could then be opened by Winzip. -- 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: ESS 2105-800 DS6800 comparison
Nigel, Converted from a Hitachi unit emulating a ESS 2105 to a DS6800 using FDRPAS and FLASHCOPY in 1 day, (10 TB), It was awhile back but there were no problems or issues. Except it didn't support Flashcopy 2 at the time (Dataset level) Since the DS6800 was rack mounted, I should have opted for the in rack LAPTOP, Instead of table to support my monitor and keyboard only. Oh yea. We went from ESCOM to FICON...so great for performance. Kevin ---Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Nigel Salway Sent: Thursday, April 01, 2010 12:07 PM To: IBM-MAIN@bama.ua.edu Subject: ESS 2105-800 DS6800 comparison I am looking at migrating from an ESS 2105-800 shark to a used DS6800 1750-522. I am curious to learn if anyone has done a similar conversion and can comment on the relative performance of the two storage subsystems. The IBM redbook SG24-6781-02 says the DS6800 will out-perform the 2105-800 shark in most zOS implementations. I am also interested in hearing from someone who has installed a used DS6800 and if they had any issues installing and setting up the DS Storage Manager software. TIA -- 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 This e-mail message and any attachments transmitted with it are confidential and are intended solely for the use of its authorized recipient(s). If you are not an intended or authorized recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the information contained in this e-mail is prohibited. If you have received this message in error or are not authorized to receive it, please immediately notify the sender and delete the original message and all copies of it from your computer. -- 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
"Hidden" APARs (Was: Heads Up: APAR IO11698...)
Shane Ginnane wrote: I also wonder about Brians assertion of: The (fortunately) rare "integrity" flag How the hell are we supposed to be able to tell how rare it is. And if IBM doesn't have the confidence that they can talk about fixing these exposures, what are we to think of the rest of the codebase ?. Is it (supposedly) secure only until exposed/compromised ?. Excuse my lack of confidence. I have no idea how rare they are. I have personally reported two "hidden" APARs in the last 10 years. If that's typical for an IBM-MAIN contributor, then there are a lot of them. I suspect it's not typical though. I would interested to hear from others about their experiences... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
My use of the phrase "(fortunately) rare" was a qualitative judgment on my part, based upon observation of the z/OS service stream for many years. At SHARE in Washington DC (Summer 2003), I talked about secret APARs and provided a technique that any customer can use to make their own quantitative assessment of the state of their system. http://www.share.org/Portals/0/BitBuckets/BitBucket26.pdf (starting on page 22) Check your system, and judge for yourself how "rare" these are. And while you are at it, check out nearly two decades of Bit Bucket presentations: http://www.share.org/Volunteers/ProgramsandProjects/MVSProgram/MVSArchives/tabid/309/Default.aspx Brian On Sat, 3 Apr 2010 01:01:26 +1100, Shane Ginnane wrote: >I also wonder about Brians assertion of: >The (fortunately) rare "integrity" flag >How the hell are we supposed to be able to tell how rare it is. -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe > > Lou Losee wrote: > > The thing is integrity APARs do not come from requirements, they come from > > exposures that violate IBMs integrity statement. So I would think that the > > reason behind the APAR has to be deeper than just segregating the use of > > SMPE. > > > > Exactly! The problem is that GIMSMP is APF authorized. > > AFAIK, that's true only because IEBCOPY requires APF authorization. > That's required because IEBCOPY uses I/O appendages. But, trust me, it's > not doing *anything* that can't also be done without I/O appendages. > > IMHO, the "right" fix would have been to "enhance" IEBCOPY to use > alternate I/O techniques when not running APF authorized. (BTW, that > would solve numerous other non-SMP/E-related issues at the same time. > Ever tried to invoke IEBCOPY from a REXX?) > > Removing APF authorization from GIMSMP would remove the potential for > integrity exposure. In that case, these ridiculous new SAF resources for > SMP/E--which really do nothing to protect the system--would never have > been created in the first place. But aspirin is cheaper than angioplasty.. -jc- -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Lou Losee wrote: The thing is integrity APARs do not come from requirements, they come from exposures that violate IBMs integrity statement. So I would think that the reason behind the APAR has to be deeper than just segregating the use of SMPE. Exactly! The problem is that GIMSMP is APF authorized. AFAIK, that's true only because IEBCOPY requires APF authorization. That's required because IEBCOPY uses I/O appendages. But, trust me, it's not doing *anything* that can't also be done without I/O appendages. IMHO, the "right" fix would have been to "enhance" IEBCOPY to use alternate I/O techniques when not running APF authorized. (BTW, that would solve numerous other non-SMP/E-related issues at the same time. Ever tried to invoke IEBCOPY from a REXX?) Removing APF authorization from GIMSMP would remove the potential for integrity exposure. In that case, these ridiculous new SAF resources for SMP/E--which really do nothing to protect the system--would never have been created in the first place. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, 2 Apr 2010 10:41:36 +, Bob Shannon wrote: >We applied the APAR. We protect the SMP data. I'm sort of baffled why IBM felt >SAF support was necessary for SMPE. > Me either. And since it's called "integrity", we'll never know. Apparently SMP/E took the easy way out: rather than take the admittedly tedious step of putting suitable SAF checks at all points where SMP/E accesses resources, SMP/E shifted the burden to systems adminstrators who can use only the relatively coarse granularity of permitting access to a certain command to a certain user regardless of which resources it may access. GIMZIP? Gimme a break! All GIMZIP does is invoke IEBCOPY and pax(1). Doesn't IEBCOPY have its own SAF checks? (I surely hope so.) And isn't pax constrained by the normal Unix file permissions and ACLs? Or did the perceptibly capable SMP/E designers simply succumb to ignorant pressure from administrators who chant, "SMP/E is an administrative tool (like ADRDSSU). Use of administrative tools must be restricted to administrators!" What is becoming of the philosophy, "Protect resources; don't restrict access to tools." >Since we are a development shop in which dozens of people use SMPE, we simply >set the access to UACC(READ) which gives everyone access to all of the SMP/E >commands. > Us too. I've put in the request. -- gil -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, Apr 2nd, 2010 at 9:41 PM, Bob Shannon wrote: > We protect the SMP data. I'm sort of baffled why > IBM felt SAF support was necessary for SMPE. Me too. And this whole idea of trying to hide "Integrity" APARs has outlived its usefulness. If it ever had any. I have no gripe with fixing the hole then letting the cat out of the bag, but never doing it ?. Don't vendors ever learn ?. I also wonder about Brians assertion of: The (fortunately) rare "integrity" flag How the hell are we supposed to be able to tell how rare it is. And if IBM doesn't have the confidence that they can talk about fixing these exposures, what are we to think of the rest of the codebase ?. Is it (supposedly) secure only until exposed/compromised ?. Excuse my lack of confidence. Bah humbug ... Shane -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, 2 Apr 2010 13:50:41 +, Bob Shannon wrote: >> I'd be mildly curious to know where the requirement came from. > >I'll bet you a beer at the Boston SHARE that it came from the zBLC. > I was thinking government. I only wish I could go to summer SHARE as I have the last 6 years, but sadly, my new employer doesn't normally let people go to SHARE - especially when travel is involved. When's the next time it will be in Chicago? :-)Oh, and now that my former employer is my client, zBLC is out also. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
I think you might owe him that beer. Jon L. Veilleux veilleu...@aetna.com (860) 636-9179 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob Shannon Sent: Friday, April 02, 2010 9:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use > I'd be mildly curious to know where the requirement came from. I'll bet you a beer at the Boston SHARE that it came from the zBLC. Bob -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, Apr 2, 2010 at 8:45 AM, Mark Zelden wrote: > On Fri, 2 Apr 2010 10:41:36 +, Bob Shannon < > bshan...@rocketsoftware.com> > wrote: > > >We applied the APAR. We protect the SMP data. I'm sort of baffled why IBM > felt SAF support was necessary for SMPE. > > > >Since we are a development shop in which dozens of people use SMPE, we > simply set the access to UACC(READ) which gives everyone access to all of > the SMP/E commands. > > > > It's not necessary, but I can "stretch" and see the case where a shop might > want to let an ID or group have RECEIVE authority for example, but > not let them to do an APPLY or not let them perform admin functions. > Perhaps > a production userid that does RECEIVE ORDER via a job scheduler on a > nightly or weekly basis. > > For query only, the CSI can simply be protected from update via > RACF data set profiles. > > I'd be mildly curious to know where the requirement came from. > The thing is integrity APARs do not come from requirements, they come from exposures that violate IBMs integrity statement. So I would think that the reason behind the APAR has to be deeper than just segregating the use of SMPE. Lou > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS > mailto:mzel...@flash.net > Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html > Systems Programming expert at http://expertanswercenter.techtarget.com/ > > -- > 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
> I'd be mildly curious to know where the requirement came from. I'll bet you a beer at the Boston SHARE that it came from the zBLC. Bob -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, 2 Apr 2010 10:41:36 +, Bob Shannon wrote: >We applied the APAR. We protect the SMP data. I'm sort of baffled why IBM felt SAF support was necessary for SMPE. > >Since we are a development shop in which dozens of people use SMPE, we simply set the access to UACC(READ) which gives everyone access to all of the SMP/E commands. > It's not necessary, but I can "stretch" and see the case where a shop might want to let an ID or group have RECEIVE authority for example, but not let them to do an APPLY or not let them perform admin functions. Perhaps a production userid that does RECEIVE ORDER via a job scheduler on a nightly or weekly basis. For query only, the CSI can simply be protected from update via RACF data set profiles. I'd be mildly curious to know where the requirement came from. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: The hardest JCL ERROR I have met
On Thu, 1 Apr 2010 18:37:05 -0500, Larry Stout wrote: >A quick way to determine the error is to submit the JCL as a batch >job. If the job fails during syntax checking, it will not matter >whether the data sets are cataloged or whether JES2 is already >running. > >//JES2PROC M=JES2PARM >//IEFPROC EXEC PGM=HASJES20,TIME=1440,DPRTY=(15,15) >//HASPLIST DD DDNAME=IEFRDER >//HASPPARM DD DSN=SYS1.CPAC.PARMLIB(&M),DISP=SHR >//PROC00DD DISP=SHR,DSN=SYS1.CPAC.PROCLIB >// DD DISP=SHR,DSN=SYS1.PROCLIB >//HASPLIST DD DDNAME=IEFRDER >//STEPLIB DD DISP=SHR,DSN=SYS1.SHASLNKE >//PEND >//DOITEXEC PROC=JES2 > >The resulting messages are: > >STMT NO. MESSAGE > > 3 IEFC001I PROCEDURE JES2 WAS EXPANDED USING INSTREAM PROCEDURE > DEFINITION > 10 IEF631I NUMBER OF DDNAMES EXCEEDS MAXIMUM IN THE DDNAME FIELD > 11 IEF686I DDNAME REFERRED TO ON DDNAME KEYWORD IN PRIOR STEP > WAS NOT RESOLVED > >The second message, IEF631I, is the error. This message is not fully >described in the System Messages manual: > And I was wondering why those messages were not seen on the console, but there is a good chance that IEF196I is suppressed via MPF. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Information can also be found in INFO APAR II14489. Essentially this contains the information supplied by the ACTION and DOC HOLDs within the PTF. Kurt Quackenbush -- IBM, SMP/E Development -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
We applied the APAR. We protect the SMP data. I'm sort of baffled why IBM felt SAF support was necessary for SMPE. Since we are a development shop in which dozens of people use SMPE, we simply set the access to UACC(READ) which gives everyone access to all of the SMP/E commands. Bob Shannon Rocket Software -- 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: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use (nomenclature)
Just to order nomenclature: The *class* is not new. The class is named FACILITY. The new thing is called resource name or less correctly profile. Example Class: FACILITY resource name: GIM.PGM.GIMZIP profile: GIM.PGM.** So, nobody should "define this FACILITY class". One should define profile in the FACILITY class. Or: One should create FACILITY class profile covering resource GIM.PGM.GIMZIP. Just €0.02 -- 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
