Re: VARY too many devices offline
How would you handle a person that scrutinizes blood for a living and mistakes a diagnosis ? In some case an operator is just as guilty as the blood analyzer. If you say thats not the same, I would agree but not in all I wouldn't even begin to make the analogy. But, mistakes happen. That's a fact of life, and, putting an unbearable amount of strain on someone, as in - make a mistake and you're fired, will not, under any circumstances, help that person to not make mistakes. In fact, I'd go as far as to say it would only make things worse. If an operator put in a wrong date at IPL and (because of that) RACF refuses to come up and there is no backout or even worse datasets gets scratched because of the operator error which leads to a fine from say the SEC (or take you pick of agency). See all of those issues? All perfectly valid. But, if I were having to unravel the mess that came about from the wrong input at the console, the operator would not be the person who should be blamed. There should be contingency in place so that if RACF refuses to come up, we get alerted very early on as to why, and have steps in place to remedy the situation. Perhaps by re-IPL'ing. After all, that's what you're going to do in 99% of cases if a wrong parameter is passed at IPL time. If datasets get scratched, where's the back up? What's the contingency in place to restore the data. If there isn't one, that's not the guy who entered 'U' on the console instead of 'N''s fault. There are degrees of error of course some are who cares to a possible company going bankrupt there are in the last case MANY people being out of work (possibly 1000's or more) would you not fire the person? If the company went bankrupt, it wouldn't be because someone varied off the wrong device. I think you are comparing apples and oranges. An operator can by mistake put the company out of business, a programmer can cause loss revenue and yes possibly a fine. I'd love to see how the wrong prompt on the console was traced back to the one thing that put the company out of business. Seriously, if anyone has any stories along those lines, I'd love to hear it. As would any maker of automation software, because it would be the most amazing sales pitch ever. BUT that should have been found in QA before the program goes live. In other words their work is checked by others. QA can pick up a lot of things, but, for example, can QA pick up an application program that performs ten million inserts and no commit into a DB2 table, then, for whatever reason, abend, and have DB2 rollback all its work, thus rendering the objects unavailable for x hours? I've seen it done. - Didn't make the company go bankrupt though. An operator does not have this luxury. Yes programmers can make mistakes but (in most cases) its not a shut the front doors and turn off the power whoever is the last one to leave. An operator can do so with a small oops. That is why an operator, IMO must go through several years of training so they CAN'T make stupid mistakes. I agree that console commands are free from any sort of QA, however, there are ways and means to ensure that mistakes are minimised. Automation products can help here, or, if they're not available, an application program can write out WTO or WTOR messages with meaningful text, which can also help an operator make a decision. Training does not, and never will ensure that mistakes are never made. Training educates, and helps people understand better, but it never, ever eradicates mistakes from any process. Its possible that a programmer could write a program that misdiagnoses a test (health) result and yes that could lead to the persons death, but presumably there are other fingers in the stew to catch the errors. I agree with that, and, broadly, that's the point I was trying to make. There should be enough tech support/ops support/sys progs around to see what went wrong, and implement some sort of contingency to rectify the mistake with the minimum of outage/cost to the company, be that restoring data, re-IPLing a system, or whatever. In the case of an operator there is no way to catch all errors that could cause a major issue. There are ways to catch all operator entries from the console via various automation products which can interrogate what has been entered, and take appropriate measures. Catching a Vary is a small part of any possible error. Catching a bad date at lets say early on in the IPL process is impossible by any of the suggestions mentioned as the exits (programs) are not available then. I agree, but, if the wrong date, or IPL parm, or whatever is entered, then the chances are you're going to have to re-IPL to rectify the situation. As you said above, if RACF doesn't start, you can go back to see why, and take steps to fix the issue. There must always be contingency plans in place to catch human errors, but, to go back to the original point, sacking someone for entering
Re: VARY too many devices offline
On Tue, 23 Oct 2007 08:54:31 +0100, Kenny Fogarty wrote: I agree, but, if the wrong date, or IPL parm, or whatever is entered, then the chances are you're going to have to re-IPL to rectify the situation. As you said above, if RACF doesn't start, you can go back to see why, and take steps to fix the issue. I absolutely agree. It is just ridiculous to make operators responsible for design shortages in an operating system. How comes system programmers haven't seen the danger of losing system(s) and / or data through a single error (or a typo) in all these cases? -- Zaromil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF SWITCHING WITH IEFU29
Ed Long wrote: The one remaining, nagging, issue it has, is the DUMPXY exit aka IEFU29 doesn't seem to execute when I issue a i smf command. The previous system it worked fine. Load modules are same length;both are in USER.LPALIB. CSV550I 18.21.37 LPA DISPLAY 581 FLAGS MODULE ENTRY PT LOAD PT LENGTH DIAG P IEFU29 8507FA68 0507FA68 0020 08C1C860 Are you sure the same lenght? Check your display of LENGTH above. The length of x'20' usually means you're picking up a default IBM supplied IEFU29 in SYS1.LPALIB. You can use ISRDDN in ISPF and search for IEFU29. Probably not in USER.LPALIB. HTH! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
Zaromil Tisler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Tue, 23 Oct 2007 08:54:31 +0100, Kenny Fogarty wrote: I agree, but, if the wrong date, or IPL parm, or whatever is entered, then the chances are you're going to have to re-IPL to rectify the situation. As you said above, if RACF doesn't start, you can go back to see why, and take steps to fix the issue. I absolutely agree. It is just ridiculous to make operators responsible for design shortages in an operating system. How comes system programmers haven't seen the danger of losing system(s) and / or data through a single error (or a typo) in all these cases? -- Zaromil Right, like the beautiful $PQ command in the early 80's, when it still was accepted without parameters, guess what it purged? After we discovered it, the command was corrected to require parameters. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF SWITCHING WITH IEFU29
- Original Message From: Ed Long [EMAIL PROTECTED] CSV550I 18.21.37 LPA DISPLAY 581 FLAGS MODULE ENTRY PT LOAD PT LENGTH DIAG P IEFU29 8507FA68 0507FA68 0020 08C1C860 As Elardus already said a length of 20 could mean you're picking up the dummy LMOD in LPALIB delivered with the SystemPac/ServerPac. You should be able to dynamically delete the dummy IEFU29 and then add your own from USER.LPALIB using the SETPROG EXIT command. Look at the Command Reference or in the ibm-main archive to see how to do it. Walter Marguccio z/OS Systems Programmer Munich - Germany ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS DFHCOMMAREA changes
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jacky Bright One of my colleague informed me whenever apps team request to add the Program and Transaction definitions they should also inform the DFHCOMMAREA details to system support so that system personal can ensure that is defined in the system. It was bouncer for me .Does this make any sense to any of you .? No. DFHCOMMAREA is not defined by system staff. It's built-in to the CICS API. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Outsmarting WLM (was: Re: Are there tasks that don't play by WLM's rules)
First of all, my apologies to the original poster that I had appropriated his thread! I am finally changing the name snipping Peters good stuff about UNIX I did check into syslog. In general, we have quite a few BPXASs around, so when a burst of work comes in (messages uji001 written whenever a bpxas is selected out of iefuji), I see lots of these messages, a few of them using the same asid number. But then there are also the mentioned bpxas started: UJI001 CST2EIM9 - STARTED - DATE=22/10/07 - ASID=0295 UJI001 BPXAS- STARTED - DATE=22/10/07 - ASID=0298 IEF403I BPXAS - STARTED - TIME=10.37.10 BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB CST2EIM4 RUNNING IN ASID 0296 I have checked with our resident unix people - a little program to do fork() will be easy to write. The trick will be to pick the point when to kick it off - I had the idea of getting automation to listen to IEF404I BPXAS - ENDED - TIME=00.31.51 $HASP395 BPXASENDED (one of the two), and whenever it happens do the forks under the assumption that that will not hinder the *actual* work that needs it. - As for he messages from the SMF exits: UJI001 is written once per init selection (mostly to see which asid number we're running in), and the message out of iefactrt (trt002) is not written when the jobname is one of 'them' (I had changed that with 1.8...) As expected, setting these things into sysstc meets resistance of my colleague, more on general grounds. So, I am still waiting on what our SMF99 records are showing - IBM is not answering despite explicit question in my ETR... Best regards, Barbara -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bob Shannon Sent: Monday, October 22, 2007 4:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VARY too many devices offline Operators (especially console operators) are extremely competent and if they screw up, IMO, they need to be fired. As a systems programmer I'm glad I wasn't fired every time I screwed something up. Bob Shannon Yea! Like the time under OS/VS1 that I compressed SYS1.LINKLIB using IEBCOPY. So much for __that__ system! Luckily for me, this shop had two 370/145's running the same version of the OS, so that I could use the 2nd system to recover SYS1.LINKLIB of the 1st one. This was when I was first in the business around 1979. Or, more recently, so of the problems that we've been having going from 1.6 to 1.8 (messed up the APF list and CAS9 failed - not a good thing since our IPL is automated). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Outsmarting WLM (was: Re: Are there tasks that don't play by WLM's rules)
Or are we really now talking about outSTUPIDing WLM? :-) :-) Cheers, Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
I had not responded yet because I have not yet been able to get the complete answer. But it seems that something needs to be said in the meantime. When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. If that proves to be incorrect, then we will change the check not to flag that case as an exception. If that is correct, however, and your scenario was that the data set was migrated and then subsequently added to the APF list, then an exception is reasonable. Was Barbara saying that other mechanisms than HSM were used to migrate data sets? If so, then we can consider some sort of rules parameter. . Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Check CHECK(XCF_CDS_SEPARATION)
Do I really need to pursue this with defect support to get it fixed before whatever release comes after z/OS 1.9 so I don't have to delete the check on my Sysplexes that only use the two volume method? As Bill Neiman's append clearly stated, yes. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
JES2 / JES3 in same plex
does anyone have any experience with running JES2 and JES3 images within the same plex ? It can be done in the lab, I'm curious if anyone has tried it in production. I may need to merge two JES3 images into an exsiting JES2 plex. TIA and you can reply directly so as to not clutter up the list. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
About dispatching process
Hi, list I'm trying to get some overview understanding about this process. I know it's very complicated and you can hardly find any good documents or books on this topic so simplification is used in my endeavour. My starting point is when the TCB is selected by dispatcher to execute. Dispatcher will set the status using PSW and register areas in TCB/STCB. After that CPU will be executing instructions of my program. It's obvious that my TCB can hardly have the chance to occupy CPU exclusively until it terminates because there're many other dispatch units who need to be served too. The question is how that happens. From what I know, interrupt is the only way. When interrupt occurs, my TCB will lose control and after interrupt handling (FLIH, SLIH..etc) control will be given to dispatcher and it'll select the next dispatched unit using its algorithm. I know execution of my program will usually generate interrupts, for example, I/O interrupt or page-fault. But will the system solely depend on that? In an extreme case, my program will not lead to any interrupt and will it eat all CPU cycles? Searching the old posts I learned that there are at least two cases when interrupts will be generated regardless of my programs' behaviour: 1. SRM will be invoked routinely via clock comparator interrupt. 2. Each dispatch unit will have a time slice and when it expires a CPU timer interrupt occurs. Using the above two methods, dispatcher will be invoked even if my program doesn't do it 'voluntarily'. Thus other dispatch units will have the chance to be served. However, if my program is also running disabled for external interrupts and it uses CPU cycles heavily , how will the system 'pre-empt' my TCB? Or it cannot and just let my TCB starve other users? I cannot figure out. -- Best Regards, Johnny Luo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Peter, On one of our z/OS 1.8 systems I definitely have APF-list datasets that are migrated. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: 23 October 2007 14:00 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck (IBMCSV,CSV_APF_EXISTS) I had not responded yet because I have not yet been able to get the complete answer. But it seems that something needs to be said in the meantime. When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. If that proves to be incorrect, then we will change the check not to flag that case as an exception. If that is correct, however, and your scenario was that the data set was migrated and then subsequently added to the APF list, then an exception is reasonable. Was Barbara saying that other mechanisms than HSM were used to migrate data sets? If so, then we can consider some sort of rules parameter. . Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Using IARVSERV across Address Spaces
A bit late, but I have just found this when looking for something else!! It does have samples www.redbooks.ibm.com/redbooks/pdfs/sg244584.pdf Chapter 7 and Appendix D1 It may be of use Mike Kerford-Byrnes -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF SWITCHING WITH IEFU29
On Mon, 22 Oct 2007 16:03:59 -0700, Ed Long [EMAIL PROTECTED] wrote: Hi everyone. I have finished upgrading one of my 7060's to the latest, and last version of z/OS 1.5. The one remaining, nagging, issue it has, is the DUMPXY exit aka IEFU29 doesn't seem to execute when I issue a i smf command. The previous system it worked fine. Load modules are same length;both are in USER.LPALIB. I am certain its something I've done, but darned if I know what it is. Any and all suggestions most appreciated. As you can see from the following, the exit is being seen, and loaded properly, its not being heard however. CSV550I 18.21.37 LPA DISPLAY 581 FLAGS MODULE ENTRY PT LOAD PT LENGTH DIAG P IEFU29 8507FA68 0507FA68 0020 08C1C860 CSV461I 18.21.37 PROG,EXIT DISPLAY 584 EXIT MODULE STATE MODULE STATE MODULE STATE SYS.IEFU29 IEFU29 A CSV461I 18.21.37 PROG,EXIT DISPLAY 585 EXIT MODULE STATE MODULE STATE MODULE STATE SYSSTC.IEFU29 IEFU29 A Please post the output of D SMF,O from this system. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Shannon Operators (especially console operators) are extremely competent and if they screw up, IMO, they need to be fired. As a systems programmer I'm glad I wasn't fired every time I screwed something up. Indeed. In that kind of environment I'd have become a machinist a long time ago (probably be a former machinist by now; I've certainly made my share of scrap in the shop working part-time). -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
On Tue, 23 Oct 2007 09:15:08 -0400, Rob Scott [EMAIL PROTECTED] wrote: On one of our z/OS 1.8 systems I definitely have APF-list datasets that are migrated. Might this be a case such Sam Knutson mentioned, Rob, where HSM on some other system that doesn't have that data set in the APF list migrated it? Or perhaps a case where you did not have the data set in the APF list at the time HSM decided to migrate it, and added it to the APF list after the migration occurred? -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Check CHECK(XCF_CDS_SEPARATION)
On Tue, 23 Oct 2007 09:00:58 -0400, Peter Relson [EMAIL PROTECTED] wrote: Do I really need to pursue this with defect support to get it fixed before whatever release comes after z/OS 1.9 so I don't have to delete the check on my Sysplexes that only use the two volume method? As Bill Neiman's append clearly stated, yes. Peter Relson Peter, I will. It doesn't take much longer to open an ETR than a post on IBM-MAIN (unless of course I am asked to start collecting a bunch of doc). But I thought other checks discussed here were changed without opening defect PMRs. Guess I am wrong about that... Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF SWITCHING WITH IEFU29
On Tue, 23 Oct 2007 03:25:15 -0500, Elardus Engelbrecht [EMAIL PROTECTED] wrote: CSV550I 18.21.37 LPA DISPLAY 581 FLAGS MODULE ENTRY PT LOAD PT LENGTH DIAG P IEFU29 8507FA68 0507FA68 0020 08C1C860 Are you sure the same lenght? Check your display of LENGTH above. The length of x'20' usually means you're picking up a default IBM supplied IEFU29 in SYS1.LPALIB. Good catch. Didn't notice that before I replied.I agree, but Ed did say the modules were the same length as before (although maybe he was looking at the library and not the output of the D PROG command. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Hi, If I understand correctly APF data sets cannot be migrated on the system where they are APF authorized. If you have an asymmetrical configuration in a Sysplex with shared DASD you can have data sets that are infrequently used and APF authorized only a test system migrated on another LPAR where DFHSM migration runs. This could also occur in the same scenario with command migration on the other LPAR. We worked through this scenario with RACF Level-2 when we saw data sets flagged V instead of M in RACF_SENSITIVE_RESOURCES. APAR OA15290 corrected the display in the check. The CSV_APF_EXISTS and RACF_SENSITIVE_RESOURCES checks have been very useful to us! This has allowed us to close real integrity exposures identified by RACF_SENSITIVE_RESOURCES and to tightly police the APF list. We discover typos or miscommunication between groups making requests and the z/OS team right away. I would like to see the checking done by CSV_APF_EXISTS removed from RACF_SENSITIVE_RESOURCES. The biggest problem with RACF_SENSITIVE_RESOURCES is that it surfaces too many different problems in once check where some are much more urgent than others. I imagine some customers would like to see CA ship checks ACF_SENSITIVE_RESOURCES and TOP_SECRET_SENSITIVE_RESOURCES for their customers! I think the Health Checker for z/OS as delivered combined with the way IBM continues to enhance it, developing and shipping meaningful checks is one of the most useful and beneficial features implemented in base z/OS in years. We had for so long not had a framework for exceptions that could be known to be available. Now we have a good framework with great content provided by IBM and the ability to add our own in as well as integrate checks from third party vendors. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: Tuesday, October 23, 2007 9:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck (IBMCSV,CSV_APF_EXISTS) I had not responded yet because I have not yet been able to get the complete answer. But it seems that something needs to be said in the meantime. When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. If that proves to be incorrect, then we will change the check not to flag that case as an exception. If that is correct, however, and your scenario was that the data set was migrated and then subsequently added to the APF list, then an exception is reasonable. Was Barbara saying that other mechanisms than HSM were used to migrate data sets? If so, then we can consider some sort of rules parameter. . Peter Relson z/OS Core Technology Design This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Outsmarting WLM (was: Re: Are there tasks that don't play by WLM's rules)
Barbara, Here's one trick I've used in the past when working in this area is this: go into SDSF, do a DA ALL, and SORT it by ASID. You should then see some number of idle address spaces, named BPXAS. Then when a process forks and needs to do something, you'll see that BPXAS change it's name to the requstor's name while it's busy, then when it's idle it will change back to BPXAS. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
multiple z/OS sharing considerations.
I know that is vague. What has happened is that somebody with political clout is strongly pushing the idea that having two separate z/OS images on a single CEC (separate LPARs of course) would be better than having a single z/OS system. They have not defined better. We have not decided on how to implement this. I know of three possibilities, in my order of desirability: (1) Parallel Sysplex; (2) basic sysplex; (3) separate monoplexes. Is there anything that documents, in a single place, what CANNOT be done in the various environments? As an example, a JES2 MAS requires at least a basic sysplex. If we go to separate monoplexes, then the JES2s could only communicate via NJE. Is there ANYTHING that I can do in a single image that I cannot do in a parallel sysplex (other than share memory, VTAM LU names, and IP addresses)? Many thanks from a rather upset sysprog. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jacobs Sent: Tuesday, October 23, 2007 9:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. snip Not exactly an answer to your question but; If you are sharing DASD you will have to implement GRS or a GRS like product. In a parallel sysplex you can use the GRSSTAR functionally which is vastly improved over GRS ring processing. With a basic sysplex you can implement GRS ring with sysplex support while in two separate monoplexes you will have to use the original GRS (BCTC's) without the assistance of XCF communications. There are also tape sharing considerations between sysplex and monoplex environments. -- Mark Jacobs I should have mentioned that we already run MIMIT (MIM Integrity) to stop programmers from destroying datasets (such as by linking into a source PDS). This could also do many of the GRS type functions between the two systems. We have also used MIM Allocation to share tape drives in the past. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
I should have mentioned that we already run MIMIT (MIM Integrity) to stop programmers from destroying datasets (such as by linking into a source PDS). In 1.9 the Binder will not link into a PDS unless it is RECFM=U. This was done for PDSEs in an earlier release. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
You are probably aware of this, I would check out software costs of all options. You may be able to direct them better if can quote dollars for A, B, C -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Addendum, this was on the same system that the dataset was authorized on. SNIP snip When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. /snip This is incorrect. I APF added a test dataset and issued a HMIGRATE command. (Command migration). The migrate was successful. IIRC, the dataset will not auto-migrate. HTH, /SNIP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Check CHECK(XCF_CDS_SEPARATION)
Mark, I also opened a PMR but it was easy not a bunch of docs just cut and paste the email. Roland I will. It doesn't take much longer to open an ETR than a post on IBM-MAIN (unless of course I am asked to start collecting a bunch of doc). But I thought other checks discussed here were changed without opening defect PMRs. Guess I am wrong about that... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
A couple of questions, to try to avoid the risk of entering a teaching grandma to suck eggs scenario: How do you upgrade z/OS or ISV software currently if you are only running one image? Do you have a Coupling Facility in this CEC? FWIW, I can't see any advantages at all to going with monoplexes. If you don't have a CF then I don't think I'd parallel sysplex. Jon snip I know that is vague. What has happened is that somebody with political clout is strongly pushing the idea that having two separate z/OS images on a single CEC (separate LPARs of course) would be better than having a single z/OS system. They have not defined better. We have not decided on how to implement this. I know of three possibilities, in my order of desirability: (1) Parallel Sysplex; (2) basic sysplex; (3) separate monoplexes. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
I hate to even think about the pain that might have caused. Jon snip or the operator who put a future date at IPL time and really screwed up RACF. (story I heard from another company) /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
McKown, John wrote: I know that is vague. What has happened is that somebody with political clout is strongly pushing the idea that having two separate z/OS images on a single CEC (separate LPARs of course) would be better than having a single z/OS system. They have not defined better. We have not decided on how to implement this. I know of three possibilities, in my order of desirability: (1) Parallel Sysplex; (2) basic sysplex; (3) separate monoplexes. Is there anything that documents, in a single place, what CANNOT be done in the various environments? As an example, a JES2 MAS requires at least a basic sysplex. If we go to separate monoplexes, then the JES2s could only communicate via NJE. Is there ANYTHING that I can do in a single image that I cannot do in a parallel sysplex (other than share memory, VTAM LU names, and IP addresses)? Many thanks from a rather upset sysprog. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology Not exactly an answer to your question but; If you are sharing DASD you will have to implement GRS or a GRS like product. In a parallel sysplex you can use the GRSSTAR functionally which is vastly improved over GRS ring processing. With a basic sysplex you can implement GRS ring with sysplex support while in two separate monoplexes you will have to use the original GRS (BCTC's) without the assistance of XCF communications. There are also tape sharing considerations between sysplex and monoplex environments. -- Mark Jacobs Time Customer Service Tampa, FL -- A desire not to butt into other people's business is at least eighty percent of all human wisdom...and the other twenty percent isn't very important. Jubal Harshaw (Stranger in a Strange Land) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
snip When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. /snip This is incorrect. I APF added a test dataset and issued a HMIGRATE command. (Command migration). The migrate was successful. IIRC, the dataset will not auto-migrate. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: About dispatching process
Johnny, If you are running disabled, then you are the machine and you better know what you are doing. Getting 'disabled' is not something a normal program can do, you have to be authorized. Getting rights to be authorized means you can then do just about anything you want, and you had better be careful. So to answer the questions, once disabled the system has no way to interrupt you and you can starve everyone else out. Chris Blaicher BMC Software, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Johnny Luo Sent: Tuesday, October 23, 2007 8:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: About dispatching process However, if my program is also running disabled for external interrupts and it uses CPU cycles heavily , how will the system 'pre-empt' my TCB? Or it cannot and just let my TCB starve other users? I cannot figure out. -- Best Regards, Johnny Luo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bob Shannon Sent: Tuesday, October 23, 2007 9:43 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. I should have mentioned that we already run MIMIT (MIM Integrity) to stop programmers from destroying datasets (such as by linking into a source PDS). In 1.9 the Binder will not link into a PDS unless it is RECFM=U. This was done for PDSEs in an earlier release. Bob Shannon That's good. But I still have wippo's who have BLKSIZE=some_number in their JCL which sometimes attempts to reblock dataset smaller. Gotta protect from them as well. And if anything goes wrong, it is always my fault for not protecting them. (victim mentality). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
I can think of nothing that can be done in a single image that cannot be done in a basic (or parallel) sysplex. Some things are more complicated, some things are easier. IIRC, 3-5% utilization is the ROT for parallel sysplex overhead (maybe for basic, but I am not sure). Parallel sysplex = stand-alone CF = $ (is most likely not going to happen for you (based on previous posts) Basic sysplex #1 = CF engine = (is most likely not going to happen for you) Basic sysplex #2 = CTC communication With 2 LPARS, not too difficult, - exponential increase in complexity as lpars are added (2**N) Inter-lpar communications/control are the big issue here. GRS/MIM, VTAM/APPN/EE, share *EVERYTHING*, naming conventions. If you are WLM Goal mode, you are (at least) a monoplex. snip I know that is vague. What has happened is that somebody with political clout is strongly pushing the idea that having two separate z/OS images on a single CEC (separate LPARs of course) would be better than having a single z/OS system. They have not defined better. We have not decided on how to implement this. I know of three possibilities, in my order of desirability: (1) Parallel Sysplex; (2) basic sysplex; (3) separate monoplexes. Is there anything that documents, in a single place, what CANNOT be done in the various environments? As an example, a JES2 MAS requires at least a basic sysplex. If we go to separate monoplexes, then the JES2s could only communicate via NJE. Is there ANYTHING that I can do in a single image that I cannot do in a parallel sysplex (other than share memory, VTAM LU names, and IP addresses)? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 / JES3 in same plex
J Ellis wrote: does anyone have any experience with running JES2 and JES3 images within the same plex ? It can be done in the lab, I'm curious if anyone has tried it in production. I may need to merge two JES3 images into an exsiting JES2 plex. TIA and you can reply directly so as to not clutter up the list. The considerations for running multiple JESplexes within a single sysplex are pretty much the same no matter which JESes you use:: JES2 and JES2, JES3 and JES3, JES2 and JES3 -- it doesn't really matter. If you're currently using JES3 to provide tape sharing support across an existing sysplex, and you don't use third-party tape sharing software, it probably makes sense to switch that sysplex over to MVS tape sharing support. That way, all images will be using the same tape sharing mechanism after the merge. Also, remember that Operlog is always sysplex wide. So, if you're using that in both existing JESplex=sysplex configurations, you will be interleaving the logs for both JESplexes after you combine into a single sysplex. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Tuesday, October 23, 2007 9:49 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. A couple of questions, to try to avoid the risk of entering a teaching grandma to suck eggs scenario: How do you upgrade z/OS or ISV software currently if you are only running one image? Usually using STEPLIBs for testing. We only have a few things in the LNKLST. We do have a sandbox for testing things such a CA-OPS/MVS, Mainview, etc. This push is to separate Production Work from Other Work in a separate system To Increase And Enhance Manageability. Or some such thing. Do you have a Coupling Facility in this CEC? No, put I'm pushing for it if we do this (highly likely). An LPAR and a new CFL is not all that expensive. FWIW, I can't see any advantages at all to going with monoplexes. If you don't have a CF then I don't think I'd parallel sysplex. I don't see any advantage to doing this at all. Jon -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Tuesday, October 23, 2007 10:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. I can think of nothing that can be done in a single image that cannot be done in a basic (or parallel) sysplex. Some things are more complicated, some things are easier. IIRC, 3-5% utilization is the ROT for parallel sysplex overhead (maybe for basic, but I am not sure). Parallel sysplex = stand-alone CF = $ (is most likely not going to happen for you (based on previous posts) Why not a CF LPAR and a CFL in the current box? Not as expensive. I have the memory. Basic sysplex #1 = CF engine = (is most likely not going to happen for you) If I can get a CF, I see no reason to not go Parallel Sysplex. Basic sysplex #2 = CTC communication With 2 LPARS, not too difficult, - exponential increase in complexity as lpars are added (2**N) I already have the CTCs set up between the current production system and our sandbox. I once had 4 systems on this box interconnected with CTCs. Yes, I got headaches keeping them sorted. Inter-lpar communications/control are the big issue here. GRS/MIM, VTAM/APPN/EE, share *EVERYTHING*, naming conventions. Yeah! I want to put up every possible, valid, roadblock and have management sign off on it. Otherwise it will all be my fault when the thing tanks. If you are WLM Goal mode, you are (at least) a monoplex. Yes, single image monoplex. z/OS 1.8. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of J Ellis Sent: Tuesday, October 23, 2007 9:46 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. You are probably aware of this, I would check out software costs of all options. You may be able to direct them better if can quote dollars for A, B, C My manager has supposedly looked into this. All of our software is apparently licensed so that it doesn't matter whether the software is in one LPAR or multiple, so long as it is on the same physical machine (as in this case). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
On 22 Oct 2007 14:12:07 -0700, [EMAIL PROTECTED] (Zahir Hemini) wrote: This is exactly why there are products like CA OPS/MVS and Automan and probably a few others. People sometimes are new to a procedure, they do accidentally make mistakes, and read and write instructions incorrectly. Which is the response to the message that compared operator errors with blood tester errors. People do make mistakes. When the results of likely mistakes are too expensive, procedures and tools need to be created to minimize the impact of those mistakes. Lots of software design is like the design of sidewalks which have lines scored on them to encourage the breaks into a predictable direction. Don't deny that errors happen- handle them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
On 22 Oct 2007 18:43:18 -0700, [EMAIL PROTECTED] wrote: What should happen to a computer operator in the US Marine Corps whose typo causes an infantry platoon to be destroyed by friendly fire or a human error resulting in a $1 loss? One size does not fit all. Let the punishment fit the crime. If that happens, punishment is too late.Management has screwed up relying on a system that is that vulnerable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
John, You might have a look at this redbook: http://www.redbooks.ibm.com/abstracts/SG246818.html?Open It looks at the problem from the other side, i.e. combining disparate systems into a sysplex, but it's still a good read, and a good collection of info from many different products gathered into one place, and should give you some food for thought. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dana Mitchell Sent: Tuesday, October 23, 2007 10:31 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. John, You might have a look at this redbook: http://www.redbooks.ibm.com/abstracts/SG246818.html?Open It looks at the problem from the other side, i.e. combining disparate systems into a sysplex, but it's still a good read, and a good collection of info from many different products gathered into one place, and should give you some food for thought. Dana Thanks! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
John, I don't understand the fervor of your opposition to sysplex. Even on a single CEC, sysplex offers a degree of increased availability that cannot be achieved any other way. Even basic sysplex provides benefits, although I would strenuously hit up the 'multi-system advocate' for the cost of an ICF engine. Some clarification of terms. - Whether a sysplex is 'parallel' has nothing to do with whether CF LPARs are internal or external. If you have a CF, your sysplex is parallel. - A 'basic' sysplex uses only CTC to communicate among members, but there is most definitely sharing of resources: GRS, console, JES MAS. The only justification for *not* running parallel is lack of a CF. The main benefit of a well configured sysplex is that you can bring down one image for software maintenance while the other one stays up. With a single CEC, you may still have outages because of hardware changes or anything requiring POR, but those cases should be much rarer than scheduled PTF refreshes. What's missing from the discussion so far is what your user community thinks of all this. Or would think if the discussion went public. They're probably resigned to the ho-hum availability they have become accustomed to. People's expectations typically sink to the level of their experience. If they learn that life can be better, they begin to demand better. You have a chance to lead them out of the dinosaur wilderness here. It's not their old man's mainframe anymore, but the past is an unimaginative tutor. If I were you, I'd be tickled pink at the chance to leap into current technology. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] McKown, John [EMAIL PROTECTED] THMARKETS.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: multiple z/OS sharing considerations. 10/23/2007 08:17 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Tuesday, October 23, 2007 10:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. I can think of nothing that can be done in a single image that cannot be done in a basic (or parallel) sysplex. Some things are more complicated, some things are easier. IIRC, 3-5% utilization is the ROT for parallel sysplex overhead (maybe for basic, but I am not sure). Parallel sysplex = stand-alone CF = $ (is most likely not going to happen for you (based on previous posts) Why not a CF LPAR and a CFL in the current box? Not as expensive. I have the memory. Basic sysplex #1 = CF engine = (is most likely not going to happen for you) If I can get a CF, I see no reason to not go Parallel Sysplex. Basic sysplex #2 = CTC communication With 2 LPARS, not too difficult, - exponential increase in complexity as lpars are added (2**N) I already have the CTCs set up between the current production system and our sandbox. I once had 4 systems on this box interconnected with CTCs. Yes, I got headaches keeping them sorted. Inter-lpar communications/control are the big issue here. GRS/MIM, VTAM/APPN/EE, share *EVERYTHING*, naming conventions. Yeah! I want to put up every possible, valid, roadblock and have management sign off on it. Otherwise it will all be my fault when the thing tanks. If you are WLM Goal mode, you are (at least) a monoplex. Yes, single image
Re: multiple z/OS sharing considerations.
Another possible -- although perhaps a bit questionable -- benefit of multiple images is that it gives you another layer of control over system resources allocated to your production work. WLM is a fine thing, but it does have its gotchas; LPAR weighting can assure that the production systems *always* outweigh the others. Jon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 / JES3 in same plex
Jerry, I don't have an answer to your question, but I do have a request. If you get answers to your question direct to you, and not to the list, I would request a summary be posted to IBM-Main. I think this is an interesting topic, and I expect others will also. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: J Ellis [EMAIL PROTECTED] does anyone have any experience with running JES2 and JES3 images within the same plex ? It can be done in the lab, I'm curious if anyone has tried it in production. I may need to merge two JES3 images into an exsiting JES2 plex. TIA and you can reply directly so as to not clutter up the list. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
On Tue, 23 Oct 2007 09:15:08 -0400, Rob Scott [EMAIL PROTECTED] wrote: On one of our z/OS 1.8 systems I definitely have APF-list datasets that are migrated. Might this be a case such Sam Knutson mentioned, Rob, where HSM on some other system that doesn't have that data set in the APF list migrated it? This is what happened to us, that is, we had a library defined in APF on one system (SYSA) but not another another system (SYSB) in a plex. The library got migrated on SYSB. George Fogg Or perhaps a case where you did not have the data set in the APF list at the time HSM decided to migrate it, and added it to the APF list after the migration occurred? -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
Yes, I quite agree with you. At our organization we do brainstorm about what could potentially go wrong and we admit that humans are error prone for a whole variety of reasons. So we do try to have contingencies planned as well as procedures to catch gross errors. My management is very strict that we should present the benefits and drawbacks of all of our procedures, and consider what could go wrong. Sometimes this makes us slow to implement new systems, but they do tend to be quite reliable. But they have to be, because many people depend upon our services, including the dispatch of police and ambulances, as well as payrolls for public services. On 10/23/07, Howard Brazee [EMAIL PROTECTED] wrote: On 22 Oct 2007 14:12:07 -0700, [EMAIL PROTECTED] (Zahir Hemini) wrote: This is exactly why there are products like CA OPS/MVS and Automan and probably a few others. People sometimes are new to a procedure, they do accidentally make mistakes, and read and write instructions incorrectly. Which is the response to the message that compared operator errors with blood tester errors. People do make mistakes. When the results of likely mistakes are too expensive, procedures and tools need to be created to minimize the impact of those mistakes. Lots of software design is like the design of sidewalks which have lines scored on them to encourage the breaks into a predictable direction. Don't deny that errors happen- handle them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
IIRC, 3-5% utilization is the ROT for parallel sysplex overhead (maybe for basic, but I am not sure). BUT, you forget the biggest overhead when you have multiple images on the same box. Each MVS image is going to eat 15-25% of the processor for the OS and its friends. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
Having worked in a smaller environment for the last 21 years, I can understand John's reluctance to run a sysplex. If you have one machine, and it crashes or loses power, then your whole sysplex crashes, and your outage is probably longer because you have to start 2 Lpars and connect them before starting your work back up. Granted, if one Lpar crashes, the other will keep going. A lot depends on how easy it is for a shop to do IPLs. At PH Mining, as a manufacturer, it was very easy. We IPL'd every week. On Saturday at 6:00 P.M., all the CICSs were shut down. It didn't take much more to shut down batch and IPL, especially since we did backups right after the IPL, and didn't want anything running anyway. Now that contrasts sharply with my last job, where they IPL'd once a quarter or even longer. That brings up a question I had on the part of the post I quoted below. If you have 2 Lpars in a sysplex, and each Lpar runs say 10 CICSs, how do you prevent shutting down the 10 CICSs on the system you want to IPL? I know when I worked at my last job, they had 2 separate z/900s in a sysplex, and when either one was IPL'd, there was an outage. The bigger machine ran all the CICSs, and the other ran lots of DB2 batch. They had outages for each IPL when we were installing z/OS 1.7. Is there a way to migrate the work from one Lpar to another? Another comment. I know they could probably get one z/9 box a lot cheaper than the 2 z/900s, but they really wanted the redundancy of 2 separate systems. At least it would probably be cheaper considering software costs. I suspect the z9 is enough more reliable than 2 z/900s and that it would be worthwhile to make that switch. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Skip Robinson [EMAIL PROTECTED] John, I don't understand the fervor of your opposition to sysplex. Even on a single CEC, sysplex offers a degree of increased availability that cannot be achieved any other way. Even basic sysplex provides benefits, although I would strenuously hit up the 'multi-system advocate' for the cost of an ICF engine. SNIP The main benefit of a well configured sysplex is that you can bring down one image for software maintenance while the other one stays up. With a single CEC, you may still have outages because of hardware changes or anything requiring POR, but those cases should be much rarer than scheduled PTF refreshes. JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
My overhead numbers have historically been closer to 10% than 20% for the OS and its friends (excluding subsystems e.g. CICS, IMS) BTW, that's 10%-20% of the LPAR consumption. E.G. If the LPAR consumes 20% of the CEC, that would be 10-20% of the 20%. IOTW 2-4%. My 3-5% is in addition to that. snip IIRC, 3-5% utilization is the ROT for parallel sysplex overhead (maybe for basic, but I am not sure). BUT, you forget the biggest overhead when you have multiple images on the same box. Each MVS image is going to eat 15-25% of the processor for the OS and its friends. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
snip That brings up a question I had on the part of the post I quoted below. If you have 2 Lpars in a sysplex, and each Lpar runs say 10 CICSs, how do you prevent shutting down the 10 CICSs on the system you want to IPL? I know when I worked at my last job, they had 2 separate z/900s in a sysplex, and when either one was IPL'd, there was an outage. The bigger machine ran all the CICSs, and the other ran lots of DB2 batch. They had outages for each IPL when we were installing z/OS 1.7. Is there a way to migrate the work from one Lpar to another? /snip Check out VTAM APPN and MNPS (Multi-Node Persistent Sessions) also VIPA. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
It kinda depends on how your work is separated. We have a production LPAR and a development/test LPAR. We IPL production and off it goes whether test is up or not; there's no waiting for test. Jon snip If you have one machine, and it crashes or loses power, then your whole sysplex crashes, and your outage is probably longer because you have to start 2 Lpars and connect them before starting your work back up. Granted, if one Lpar crashes, the other will keep going. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
tso racf
is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or anyother method. Thank You Bill Carroll EMAIL DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
-Original Message- From: Eric Bielefeld [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 12:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. Snipped That brings up a question I had on the part of the post I quoted below. If you have 2 Lpars in a sysplex, and each Lpar runs say 10 CICSs, how do you prevent shutting down the 10 CICSs on the system you want to IPL? I know when I worked at my last job, they had 2 separate z/900s in a sysplex, and when either one was IPL'd, there was an outage. The bigger machine ran all the CICSs, and the other ran lots of DB2 batch. They had outages for each IPL when we were installing z/OS 1.7. Is there a way to migrate the work from one Lpar to another? Check out ARM (Automated Restart Management) in the manual: z/OS V1R8.0 MVS Sysplex Services Guide Chapter 3. Using the Automatic Restart Management Function of XCF URL to the contents page, but watch the line wrap: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2i660/CONTENTS ?SHELF=EZ2ZO10I.bksDT=20060620144434#CONTENTS HTH Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 Exit 53
Exit 53 operates in a different environment than Exit 3. Exit 3 is in the JES2 Environment. Exit 53 is in the USER environment. The different environments require different services, different LOAD parms, register contents, and especially information passed in the exit list. RTFM - JES2 Installation Exits. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 12:21 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or anyother method. Thank You Bill Carroll If you mean stop them from issuing a specific command, then yes. If you mean stop them from issuing any command at all, then I don't think so. Why? Well, if you could, then what would the user do? They'd get the READY prompt, but not be able to start up ISPF or anything else. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 / JES3 in same plex
Will do... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 13:20:59 -0400, Carroll, William wrote: is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or anyother method. This sounds more like a management problem than a technical problem. While you can sometimes address management problems by technical means, the overall satisfaction rate isn't as high as most folks might expect. Maybe it would help us help you if you could describe your problem a little better? -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
tso racf
is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll EMAIL DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 1:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll I would guess that you actually invoke some sort of start up CLIST or REXX program. If so, then after the line which invokes ISPF, put in the LOGOFF command. You would also need to capture any attention exits. In CLIST, you could put the lines: ATTN + DO LOGOFF END At the top of the startup CLIST. In REXX, I think that you'd SIGNAL ON HALT ... HALT: LOGOFF This doesn't do anything for disabling ISPF option 6, or keep the person from doing a TSO somecmd on almost any screen to invoke somecmd while in ISPF. So, the general answer is still NO. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
The parm that you are passing could be a CLIST, constructed along these lines: PROC 0 do some allocates and stuff start ISPF LOGOFF As soon as the user leaves ISPF it should log them off Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 2:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Hi William. On the last question you could easily do it this way. Just add the command 'LOGOFF' within thier TSO segment of RACF. Works every time. HTH Claude Richbourg -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 2:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll EMAIL DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 1:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. SNIP Do your programmers use any tools, such as TSO TEST that can't be run under ISPF? Do you programmers do any panel development? If so, then (re)starting ISPF with the TEST option (or the use of some other parm) will become problematic. Systems programmers are not the only ones that sometimes need TSO READY prompts. Loss of such functionality may become quite painful. It is something for consideration. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Richbourg, Claude Sent: Tuesday, October 23, 2007 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf Hi William. On the last question you could easily do it this way. Just add the command 'LOGOFF' within thier TSO segment of RACF. Works every time. HTH Claude Richbourg Couldn't the user just blank that out on the TSO logon screen? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
yes they can, that is why i need to go after it another way. such as updating the startup clist. Bill Carroll -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, October 23, 2007 2:46 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Richbourg, Claude Sent: Tuesday, October 23, 2007 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf Hi William. On the last question you could easily do it this way. Just add the command 'LOGOFF' within thier TSO segment of RACF. Works every time. HTH Claude Richbourg Couldn't the user just blank that out on the TSO logon screen? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html EMAIL DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
On Oct 23, 2007, at 9:51 AM, Jon Brock wrote: I hate to even think about the pain that might have caused. Jon Jon, A person here on the list had to go through the exercise maybe he will speak up and give details. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
-Original Message- From: Farley, Peter x23353 Sent: Tuesday, October 23, 2007 1:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. Snipped Check out ARM (Automated Restart Management) in the manual: z/OS V1R8.0 MVS Sysplex Services Guide Chapter 3. Using the Automatic Restart Management Function of XCF URL to the contents page, but watch the line wrap: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/iea2i660/CONTENTS ?SHELF=EZ2ZO10I.bksDT=20060620144434#CONTENTS I forgot to also say that we have used it quite successfully to move multiple CICS's and other complex online applications from a failed lpar to a designated backup lpar. It was kind of fun to see them come back to life almost magically when the sysprogs deliberately stopped the original lpar on the test weekend. A recovery ballet, as it were. One gotcha that we found: The JES spool output which is outstanding at the failure point is NOT released from the spool. It is retained as part of the recovered job on the backup lpar (using the same MAS in our case). When the recovered job ends, THEN all the spool output will be released. FREE=CLOSE does not help here, because nothing is ever officially closed because of the recovery mechanism. Another potential gotcha: If there are dependencies between CICS's or between CICS's and other online work also being recovered, make sure that the order of recovery is carefully controlled. In our case, there were EXCI dependencies which required certain CICS's to be recovered first, and then the other work that needed those CICS's for EXCI. Obviously MQ managers also fit into the do me first category, as do DB2 functions. As I said, it's a lovely ballet to watch when it happens. HTH Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
yes they can, that is why i need to go after it another way. Since people can enter almost all TSO commands under ISPF, I am trying to figure out your need. What problem are you trying to solve? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Oct 23, 2007, at 1:28 PM, Carroll, William wrote: is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll Bill, I do not know if IBM still sells it but at one time there was a product called PCF. It was cheap IIRC and it worked quite well. I was responsible for it for over 20 years and I never had an issue with it. Just to give you an idea there is a table which has all TSO commands in it and a level that you must have before the command will be executed. The level is kept in UADS (or RACF IIRC). There is also a table that restricts where a user can allocate new datasets. a lot of the function of it has been doled out to other products (SMS RACF etc) but I believe this product is a lot easier to implement and you don't have to fool around with RACF to get a clean yes/no answer to the question am I allowed to do this command. BTW PCF = Program Control Facility Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Don, Could I create a CLIST/REXX called LOGOFF that would bypass this process so long as my CLIST/REXX called LOGOFF is at the top of the concatenation of the SYSPROC or EXEC DD Statement? Lizette The parm that you are passing could be a CLIST, constructed along these lines: PROC 0 do some allocates and stuff start ISPF LOGOFF As soon as the user leaves ISPF it should log them off Don Imbriale -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Being an applications programmer, I can say that doing such a thing would prevent me from doing certain aspects of my job. Which includes setting up or modifying personal command tables, non ISPF Clist's, REXX utilities, mainframe FTP, receiving notices issued by send commands, unpacking XMIT'd PDS libraries, etc... I'd want to have a serious talk to any manager that thought I shouldn't have access to TSO Ready Prompt. If they wouldn't change their minds about it, it would be time to find another Job. TSO Ready Prompt is too useful of a tool for any programmer (systems or application) to put up with that sort of foolish and uninformed decision. Darren -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 11:28 AM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
To invoke your LOGOFF, the command would need to be entered as %LOGOFF to force search of SYSPROC/SYSEXEC before the usual order which will find the standard command. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Tuesday, October 23, 2007 3:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf Don, Could I create a CLIST/REXX called LOGOFF that would bypass this process so long as my CLIST/REXX called LOGOFF is at the top of the concatenation of the SYSPROC or EXEC DD Statement? Lizette The parm that you are passing could be a CLIST, constructed along these lines: PROC 0 do some allocates and stuff start ISPF LOGOFF As soon as the user leaves ISPF it should log them off Don Imbriale *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 12:30:34 -0700, GAVIN Darren * OPS EAS [EMAIL PROTECTED] wrote: Being an applications programmer, I can say that doing such a thing would prevent me from doing certain aspects of my job. Which includes setting up or modifying personal command tables, non ISPF Clist's, REXX utilities, mainframe FTP, receiving notices issued by send commands, unpacking XMIT'd PDS libraries, etc... I'd want to have a serious talk to any manager that thought I shouldn't have access to TSO Ready Prompt. If they wouldn't change their minds about it, it would be time to find another Job. TSO Ready Prompt is too useful of a tool for any programmer (systems or application) to put up with that sort of foolish and uninformed decision. I agree with for any programmer. I have seen shops implement such things for other users. There are usually ways around it if you try hard enough... but without at least the attn exits (CLIST or REXX), it is very easy to get around. One way around it (even with trapping attn) is to make ISPF abend. Exactly how to do that is left as an exercise to the reader. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
TSO Ready Prompt is too useful of a tool for any programmer (systems or application) to put up with that sort of foolish and uninformed decision. I agree with you, especially since you can do almost everything under ISPF that you can do with the READY prompt. TSOEXEC makes that possible. Not that I use READY very much anymore. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
McKown, John wrote: snip This doesn't do anything for disabling ISPF option 6, or keep the person from doing a TSO somecmd on almost any screen to invoke somecmd while in ISPF. So, the general answer is still NO. snip I think ISPF Exit 5 (its TSO Command Exit) can restrict that, though. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
Thanks. I read part of the chapter. That brings up one question - how much extra overhead is there for the CICS during normal operation? Also, I gather that any transactions being processed within a CICS are lost if an Lpar fails, and that batch jobs, if restarted on another system start over from the beginning again. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Farley, Peter x23353 [EMAIL PROTECTED] Check out ARM (Automated Restart Management) in the manual: z/OS V1R8.0 MVS Sysplex Services Guide Chapter 3. Using the Automatic Restart Management Function of XCF URL to the contents page, but watch the line wrap: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2i660/CONTENTS ?SHELF=EZ2ZO10I.bksDT=20060620144434#CONTENTS Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Check CHECK(XCF_CDS_SEPARATION)
On Tue, 23 Oct 2007 09:00:58 -0400, Peter Relson [EMAIL PROTECTED] wrote: Do I really need to pursue this with defect support to get it fixed before whatever release comes after z/OS 1.9 so I don't have to delete the check on my Sysplexes that only use the two volume method? As Bill Neiman's append clearly stated, yes. Peter Relson z/OS Core Technology Design Here was IBM's initial response: I know that development is investigating if they should update the manual or that the check be modify to exclude the LOGGER CDS. Hopefully the healthchecker check and the documentation will be synchronized in the near future regarding this matter. So for now, if the check (like it is now) is not applicable to your site, you could just change the severity or disable the check I sited Bill's post to IBM-MAIN and re-queued. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: multiple z/OS sharing considerations.
-Original Message- From: Eric Bielefeld [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 3:59 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: multiple z/OS sharing considerations. Thanks. I read part of the chapter. That brings up one question - how much extra overhead is there for the CICS during normal operation? Also, I gather that any transactions being processed within a CICS are lost if an Lpar fails, and that batch jobs, if restarted on another system start over from the beginning again. - Original Message - From: Farley, Peter x23353 [EMAIL PROTECTED] Check out ARM (Automated Restart Management) in the manual: z/OS V1R8.0 MVS Sysplex Services Guide Chapter 3. Using the Automatic Restart Management Function of XCF URL to the contents page, but watch the line wrap: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/iea2i660/CONTENTS ?SHELF=EZ2ZO10I.bksDT=20060620144434#CONTENTS Peter No idea about the overhead. I don't think anyone here even measured it, or if they did they didn't tell us about it. I don't think there is much, but we have so much running I might not see it even if it was significant. I believe our SLA's to our clients were not affected, if that's any help. For your other questions, I believe the answers are Yes and Yes. Batch does need to be aware of the possibility of restarting (I assume we're talking long running production/QA batch here, not compiles or unit tests). We have several varieties of those, which fortunately already had some restart awareness built previously. Not much change was needed to handle ARM restarts for those. Obviously YMMV. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
We have a CLIST that is invoked by putting the following at the front of any CLIST/EXEC that needs protecting. It checks an ISPF table, by userid, for authorization. EdP * Top of Data ** PROC 0 /**/ /**/ /* CONTROL CONLIST SYMLIST LIST /** /* CHECK AUTHORIZATION /** %AUTH DBLOG ISPEXEC VGET (AUTH) IF AUTH = STR(N) THEN EXIT /** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:20:10 -0500, Ed Gould wrote: I do not know if IBM still sells it but at one time there was a product called PCF. It was cheap IIRC and it worked quite well. I was responsible for it for over 20 years and I never had an issue with it. Just to give you an idea there is a table which has all TSO commands in it and a level that you must have before the command will be executed. The level is kept in UADS (or RACF IIRC). There is also a table that restricts where a user can allocate new datasets. a lot of the function of it has been doled out to other products (SMS RACF etc) but I believe this product is a lot easier to implement and you don't have to fool around with RACF to get a clean yes/no answer to the question am I allowed to do this command. BTW PCF = Program Control Facility PCF was a joke as far as 'TSO security' was concerned. As long as you understood how TSO's command processors work and a quick understanding of PCF's working storage it can be a matter of minutes before you can build a working prototype to bypass PCF. (At least it was for me about 20 years ago.) I would not recommend it on that basis. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:40:40 -0400, Imbriale, Donald wrote: The parm that you are passing could be a CLIST, constructed along these lines: PROC 0 do some allocates and stuff start ISPF LOGOFF As soon as the user leaves ISPF it should log them off If you are an applications programmer bent on actually doing your job (in spite of spiteful managers elsewhere): To defeat Don's mechanism you need to clear the TSO command stack prior to leaving ISPF. Read the TSO publications to find out how to do that. It isn't particularly hard and is a worthwhile exercise in programming by itself. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Check CHECK(XCF_CDS_SEPARATION)
Don't know if this was just opened or just updated, but here is the APAR. Thanks IBM (assuming it isn't closed FIN for release 730). :-) APAR Identifier .. OA22931 Last Changed 07/10/23 XCF HEALTHCHECK XCF_CDS_SEPARATION CHECKS TO ENSURE THE LOGR CDS IS ON A DIFFERENT VOLUME THAN THE CFRM OR SYSPLEX Symptom .. IN INCORROUT Status ... INTRAN Severity ... 3 Date Closed . Component .. 5752SCXCF Duplicate of Reported Release . 730 Fixed Release Component Name XCF Special Notice Current Target Date .. Flags SCP ... Platform Status Detail: Not Available PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: CHECK(IBMXCF,XCF_CDS_SEPARATION) reports an exception if the LOGR CDS resides on the same volume as the CFRM or SYSPLEX CDS. IBM no longer recommends ensuring the LOGR CDS is a different volume CFRM CDS or SYSPLEX CDS. The LOGR piece of the check should be optional for the customer. LOCAL FIX: Lower the severity of the check. Disabling the check will result in the check not triggering if the CFRM and SYSPLEX are on the same volume. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Ted MacNEIL wrote: I was under the impression that data sets in the APF list were ineligible for migration. Nope! ARC1001I apf.authorized.data.set MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Explanation: DFSMShsm was considering if a data set was eligible for a space management operation and determined that the data set type is one that DFSMShsm does not process, by command or automatically, regardless of the selection criteria being applied. The name of the data set is given in the preceding ARC1001I message or the associated ARC0734I message. The return code field in the ARC1001I or ARC0734I message has a value of 99 (to correspond to the ARC1299I message). The reason code field in the ARC1001I or ARC0734I message lists the reason that DFSMShsm could not space manage the data set. Reascode Meaning 14The data set is an authorized program facility (APF) authorized library. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Ed, Was this from auto-migration or command migration? snip ARC1001I apf.authorized.data.set MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Reascode Meaning 14The data set is an authorized program facility (APF) authorized library. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
ARC1001I apf.authorized.data.set MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Others on the list have shown that it can happen, with HMIG. I have not tried. But, in an SMS-Managed world should it matter? As long as updates are protected and it doesn't stray too far from its point of origin, who cares? If it's not SMS managed, it's probably on a had-built pack -- why would you send HSM after it? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Staller, Allan wrote: Ed, Was this from auto-migration or command migration? READY hmig linklib ARC1007I MIGRATE REQUEST 0117 SENT TO DFSMSHSM READY ARC1001I userid.LINKLIB MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION READY -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
I worked with a shop some years ago that had a similar requirement. For a certain class of user, management wanted this: 1. LOGON 2. Be placed immediately into ISPF 3. Exit ISPF 4. LOGOFF In other words, these users were not allowed to sit at Ready. Don't remember why. Doesn't matter. There turned out to be a simple solution. The 'moment' the user gets logged on and enters ISPF, issue this MVS command: P userid . It's not documented well (or maybe at all), but a TSO user in the 'stopping state' (my term), can continue the 'current operation' but will be logged off at the conclusion of that operation. ISPF is treated as one long continuous operation. The moment you exit ISPF, you are logged off. You can try this for yourself. We tried to break the sequence with abend and Attention keys, but the result was always the same: once ISPF ends, you're gone. The mechanism for issuing the P command is left as an exercise for a sysprog more highly motivated than this one. ;-) . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Carroll, William [EMAIL PROTECTED] To NSURANCE.COM IBM-MAIN@BAMA.UA.EDU Sent by: IBM cc Mainframe Discussion List Subject [EMAIL PROTECTED] tso racf .EDU 10/23/2007 11:28 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Ted MacNEIL wrote: ARC1001I apf.authorized.data.set MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Others on the list have shown that it can happen, with HMIG. I have not tried. But, in an SMS-Managed world should it matter? As long as updates are protected and it doesn't stray too far from its point of origin, who cares? If it's not SMS managed, it's probably on a had-built pack -- why would you send HSM after it? HSM disallows all migration activity (auto or command) for an SMS managed data set on the APF list. If the data set is not SMS managed, HSM will allow migration if the data set being migrated is on a volume other than what's specified in the APF list. Otherwise, the migration is disallowed exactly as in the SMS managed case. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
I worked with a shop some years ago that had a similar requirement. For a certain class of user, management wanted this: 1. LOGON 2. Be placed immediately into ISPF 3. Exit ISPF 4. LOGOFF In other words, these users were not allowed to sit at Ready. Don't remember why. Doesn't matter. There turned out to be a simple solution. The 'moment' the user gets logged on and enters ISPF, issue this MVS command: P userid . It's not documented well (or maybe at all), but a TSO user in the 'stopping state' (my term), can continue the 'current operation' but will be logged off at the conclusion of that operation. ISPF is treated as one long continuous operation. The moment you exit ISPF, you are logged off. Skip: Seems to work OK. Now you need a bulletproof solution to force those users to be placed in ISPF at logon and find a way to issue the P userid command. I think it can be done in RACF's post-processing exit. George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Carroll, William wrote: ... my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. What's wrong with giving users access to the READY prompt? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:58:23 -0700, George Fogg wrote: I worked with a shop some years ago that had a similar requirement. For a certain class of user, management wanted this: 1. LOGON 2. Be placed immediately into ISPF 3. Exit ISPF 4. LOGOFF In other words, these users were not allowed to sit at Ready. Don't remember why. Doesn't matter. There turned out to be a simple solution. The 'moment' the user gets logged on and enters ISPF, issue this MVS command: P userid . It's not documented well (or maybe at all), but a TSO user in the 'stopping state' (my term), can continue the 'current operation' but will be logged off at the conclusion of that operation. ISPF is treated as one long continuous operation. The moment you exit ISPF, you are logged off. Skip: Seems to work OK. Now you need a bulletproof solution to force those users to be placed in ISPF at logon and find a way to issue the P userid command. I think it can be done in RACF's post-processing exit. George, That might be too early - under some odd timing conditions you might succeed (FSVO 'succeed') in logoff prior to ISPF (which would frustrate the end users and waste the company's resources... who's the bad guy then?) I would suggest pushing out an operator message in an ISPF initialization exit and letting automated operations issue the STOP command. That way you know the user was safely tucked into ISPF. I would also suggest that it should be mandatory that this 'feature' be verified documented as an intended interface by IBM before using it. (I've used it in the dim past for a few things but none were particularly long-term. It worked for me, for example, when running a CLIST in a started task doing TSO RECEIVE (as in XMIT/RECEIVE) processing many years ago. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
HSM disallows all migration activity (auto or command) for an SMS managed data set on the APF list. Okay. I shall take your word for it, since I cannot check it out. But, other posters have given examples, where it (supposedly) works. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
That way you know the user was safely tucked into ISPF. Why do we care? What problem are we solving by restricting access to the READY prompt? I've already asked this question; received no response. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:58:23 -0700, George Fogg wrote: I worked with a shop some years ago that had a similar requirement. For a certain class of user, management wanted this: 1. LOGON 2. Be placed immediately into ISPF 3. Exit ISPF 4. LOGOFF In other words, these users were not allowed to sit at Ready. Don't remember why. Doesn't matter. There turned out to be a simple solution. The 'moment' the user gets logged on and enters ISPF, issue this MVS command: P userid . It's not documented well (or maybe at all), but a TSO user in the 'stopping state' (my term), can continue the 'current operation' but will be logged off at the conclusion of that operation. ISPF is treated as one long continuous operation. The moment you exit ISPF, you are logged off. Skip: Seems to work OK. Now you need a bulletproof solution to force those users to be placed in ISPF at logon and find a way to issue the P userid command. I think it can be done in RACF's post-processing exit. George, That might be too early - under some odd timing conditions you might succeed (FSVO 'succeed') in logoff prior to ISPF (which would frustrate the end users and waste the company's resources... who's the bad guy then?) It is too early in the process as I just found out. I issued a P userid after the READY prompt and before the userid went into ISPF so when the user tried to get into ISPF then boom, the user was forced to logon or logoff. The RACF post-processing is not a choice. Messages I got at READY prompt when entering ISPF : IKJ56620I MVS STOP command encountered. TSO/E session is terminated. IKJ56470I USR000 LOGGED OFF TSO AT 15:26:27 ON OCTOBER 23, 2007 IKJ56400A ENTER LOGON OR LOGOFF- George Fogg I would suggest pushing out an operator message in an ISPF initialization exit and letting automated operations issue the STOP command. That way you know the user was safely tucked into ISPF. Does the I would also suggest that it should be mandatory that this 'feature' be verified documented as an intended interface by IBM before using it. (I've used it in the dim past for a few things but none were particularly long-term. It worked for me, for example, when running a CLIST in a started task doing TSO RECEIVE (as in XMIT/RECEIVE) processing many years ago. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Oct 23, 2007, at 3:17 PM, Tom Schmidt wrote: PCF was a joke as far as 'TSO security' was concerned. As long as you understood how TSO's command processors work and a quick understanding of PCF's working storage it can be a matter of minutes before you can build a working prototype to bypass PCF. (At least it was for me about 20 years ago.) I would not recommend it on that basis. The issue is command control NOT anything else. If you had access to the library then you could bypass all command checking by running the the command under test library(asm) cp but we nave gave out access to the library where commands where. But you are correct about dataset security it was easily bypassable. In fact if you get access to where the 2 byte security key was (read only protected storage) if I remember correctly you could do anything. Its the same story with RACF though if you are authorized you can bypass any security package. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
On Oct 23, 2007, at 3:17 AM, Zaromil Tisler wrote: On Tue, 23 Oct 2007 08:54:31 +0100, Kenny Fogarty wrote: I agree, but, if the wrong date, or IPL parm, or whatever is entered, then the chances are you're going to have to re-IPL to rectify the situation. As you said above, if RACF doesn't start, you can go back to see why, and take steps to fix the issue. I wish the person this had happened to would pipe up, but to set the record more precisely because of a bad date RACF (This is hear say) did something to the (RACF) database that essentially rendered the system not operatrional. Just by IPLing (again) with the correct date was too late as the RACF database unusable. I do not know if they had backups or any specifics. I heard they were down for a day or so. Luckily this was a weekend. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
On Oct 23, 2007, at 2:54 AM, Kenny Fogarty wrote: How would you handle a person that scrutinizes blood for a living and mistakes a diagnosis ? In some case an operator is just as guilty as the blood analyzer. If you say thats not the same, I would agree but not in all I wouldn't even begin to make the analogy. But, mistakes happen. That's a fact of life, and, putting an unbearable amount of strain on someone, as in - make a mistake and you're fired, will not, under any circumstances, help that person to not make mistakes. In fact, I'd go as far as to say it would only make things worse. Well, I am not sure I agree with you about worse. The operators usually had a great time (especially off day shift) The day shift only had one occurrence after that bad IPL. We (sysprogs) were consulted before any first time commands were entered so we were by the operators side as it was keyed in. Issues? not really the operators enjoyed their jobs and everyone was a little more productive. We did have an issue with delays of tape mounts we ended up buying hardware to monitor those events . The finger pointing was put squarely on the operators. But other than that the operators really liked their job (of course there were one or two exceptions) and everyone went about their own jobs happily. I think that department had the lowest turnover of any. If an operator put in a wrong date at IPL and (because of that) RACF refuses to come up and there is no backout or even worse datasets gets scratched because of the operator error which leads to a fine from say the SEC (or take you pick of agency). See all of those issues? All perfectly valid. But, if I were having to unravel the mess that came about from the wrong input at the console, the operator would not be the person who should be blamed. There should be contingency in place so that if RACF refuses to come up, we get alerted very early on as to why, and have steps in place to remedy the situation. Perhaps by re-IPL'ing. After all, that's what you're going to do in 99% of cases if a wrong parameter is passed at IPL time. See above reply If datasets get scratched, where's the back up? What's the contingency in place to restore the data. If there isn't one, that's not the guy who entered 'U' on the console instead of 'N''s fault. Backup in our case was 24 hours ago, I can't speak for the actual company that it happened to. There are degrees of error of course some are who cares to a possible company going bankrupt there are in the last case MANY people being out of work (possibly 1000's or more) would you not fire the person? If the company went bankrupt, it wouldn't be because someone varied off the wrong device. Hmmm well how about this scenario. System A is writing the master file to tape drive d system b varies online the same tape drive and it starts to write to that tape drive you would have a clobbered tape and not know it for some time . If it was discovered during the database load that the tape was no good. The database would not be loaded and the firm could not open the next day. Not far fetched at all. I think you are comparing apples and oranges. An operator can by mistake put the company out of business, a programmer can cause loss revenue and yes possibly a fine. I'd love to see how the wrong prompt on the console was traced back to the one thing that put the company out of business. Seriously, if anyone has any stories along those lines, I'd love to hear it. As would any maker of automation software, because it would be the most amazing sales pitch ever. See above and wait to see if the sysprog it happened to will pipe up. BUT that should have been found in QA before the program goes live. In other words their work is checked by others. QA can pick up a lot of things, but, for example, can QA pick up an application program that performs ten million inserts and no commit into a DB2 table, then, for whatever reason, abend, and have DB2 rollback all its work, thus rendering the objects unavailable for x hours? I've seen it done. - Didn't make the company go bankrupt though. It depends on the company. If its a matter of opening (or not) for daily trading chances are good they will be out of business. If its for a small business I might agree but small business's probably don't have mainframes either. An operator does not have this luxury. Yes programmers can make mistakes but (in most cases) its not a shut the front doors and turn off the power whoever is the last one to leave. An operator can do so with a small oops. That is why an operator, IMO must go through several years of training so they CAN'T make stupid mistakes. I agree that console commands are free from any sort of QA, however, there are ways and means to ensure that mistakes are minimised. Automation products can help here, or, if they're not available, an application program can write out WTO or WTOR
Re: tso racf
Ted Macneil said: Why do we care? Edward Jaffe said: What's wrong with giving users access to the READY prompt? Ted and Ed. In my case, I'm just curious if it can be done--not that I would suggest that we do this in our shop. BTW, does the ISPF exits run authorized? I read the manual but not quite sure if they do. George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Hi, I think this might explain different perceptions of what is possible. Case 1 HMIGRATE attempt for SMS managed dataset defined to APF by using the SMS keyword MIGRATE REQUEST 00019980 SENT TO DFSMSHSM ARC1001I U06T03.LOAD.TEST.APFMIG MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Case 2 HMIGRATE attempt for SMS managed APF dataset defined to APF incorrectly using an explicit DASD volser. MIGRATE REQUEST 00019995 SENT TO DFSMSHSM ARC1000I U06T03.LOAD.TEST.APFMIG MIGRATE PROCESSING ENDED *** Now the second case of not using SMS but a volser works as far as APF is concerned but DFSMShsm does not recognize it and WILL migrate it. This wrinkle had not occurred to me until today reading seemingly contradictory statements of fact. The CSV_APF_EXISTS will flag the second case but it is ignored by RACF_SENSITIVE_RESOURCES. CHECK(IBMCSV,CSV_APF_EXISTS) START TIME: 10/23/2007 20:03:57.740282 CHECK DATE: 20050720 CHECK SEVERITY: LOW A problem was found with each APF list entry displayed. VOLUME DSNAME ERROR G10078 U06T03.LOAD.TEST.APFMIG DS is SMS-managed DS is SMS-managed The data set is SMS-managed, but the APF list entry specified a volume. If the APF list entry represents a SMS-managed data set but has specified the volume parameter, the data set would not be authorized if it were moved to a different volume. In order for DFSMShsm to verify APF-authorization properly, the APF list entry must indicate that the data set is SMS-managed. I think you could make a good case for DFSMShsm not functioning correctly. It should refuse to migrate both since using SMS is recommended by not required by APF. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, October 23, 2007 5:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS) Staller, Allan wrote: Ed, Was this from auto-migration or command migration? READY hmig linklib ARC1007I MIGRATE REQUEST 0117 SENT TO DFSMSHSM READY ARC1001I userid.LINKLIB MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION READY -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
