Re: BMC CMF vs. IBM RMF
Yes, that is my experience too. I can add that if you also purchase Mainview, you have a beautiful monitor for keeping a good eye on the behavings of your system, with very detailled drill down views and highly customizable presentation. I don't think RMF has this, at least not in that detail. And don't get me started on Omegamon/Tivoli, there most of the money was spent, in my opinion, on a nice GUI, not on producing useful information (defined capacities and group capacity limits: never heard of). Kees. McKown, John john.mck...@healthmarkets.com wrote in message news:a6b9336cdb62bb46b9f8708e686a7ea00b038bb...@nrhmms8p02.uicnrh.dom. .. I'll be a bit contrary. I don't know about expense. We can't afford much of anything any more. I guess we're too small to succeed. But I've never had a problem with CMF in 20 years. But we are never bleeding edge. I have had some problems with Data Accelerator due to maintenance. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Monday, October 17, 2011 3:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: BMC CMF vs. IBM RMF I would have said Bankrupting Mountain of Crap. :-) Rick -- Vernooij, CP - SPLXM wrote: From your choice of language, I assume you ended up in this group/forum unintentionally, by opening our door i.s.o. your manhole cover. Be more careful where you go next time. Jeeez. Kees. Nomen Nescio nob...@dizum.com wrote in message news:b6bb8fd9ebc3690f1ea46493a7d4c...@dizum.com... kees.verno...@klm.com (Vernooij, CP - SPLXM) wrote: Rick Fochtman rfocht...@ync.net wrote in message news:4e8f8f91.1040...@ync.net... --snip- --- --- I have been looking at CMF vs. RMF as a question. Is there any pros or cons between the two? Any other products besides CMF that competes with RMF on the mainframe? unsnip- --- --- CMF is a wonderful product but it's very maintenance-sensitive, not only for itself but for the rest of the system as well. It uses a number of hooks that it places in z/OS code when it starts and removes during shutdown. If there's a maintenance mis-match, you could be looking at a system outage. BTDT GTSS. I NEVER expirienced this in all my life (which is about the time we run CMF). So what? Just because you didn't have a problem doesn't mean problems don't exist. I'll bet what Rick says against anything you have to say. My choice is to stick with RMF. The numbers aren't as detailed but the risks are FAR lower. FUD! That's BMC all the way! Fire longtime employees and hire 10 dollar an hour Mexicans, Indians and Russians. If you want support or a fix, you're shit out of luck with BMC. BMC: Bastards Motherfuckers Cheats 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
Re: BMC CMF vs. IBM RMF
Well, that was a bad day. But this does not justify the general statement that this never has happnened, nor ever will, with RMF. I bet there will at least be one site that has had a similar experience with RMF? We had the same feeling with one product from a third party vendor, that we used in stead of the IBM product. The third party product had several nasty problems, but when I suggestes to convert to the IBM product, my colleague who does most of the SMP work, pointed out that he regularly saw PTFs on the IBM product for similarly nasty problems. No product is bugfree, even IEFBR14 has been enhanced in the past, so stating that one is better than the other should be based on decent investigations. Kees. Rick Fochtman rfocht...@ync.net wrote in message news:4e9c8f8e.8040...@ync.net... BTDTGTSS, Kees. Lost my PRODUCTION system at the worst possible time of day, with fines and penalties that run $1000's per MINUTE! Rick 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH
On Tue, 18 Oct 2011 00:26:08 -0400 Micheal Butz michealb...@optonline.net wrote: :I am trying to issue a branch entry form of a macro in a other address :space since the specifications say PASN=HASN=SASN Which macro? :SRB was the only way to go, the branch entry form of the macro was the only :code in the SRB I figured I would set up a FRR :So that if anything goes wrong RTM would give control to the FRR I could :examine the SDWA for any problems Have you done FRR's before? ESTAEs? If not, you might be biting off more than you can chew with testing a FRR and SRB's at the same time. Under which conditions will you recover? You might want to set it up so that the SRB will abend your issuing task. Also, I don't get the connection between what you are doing and a non-reentrent TSO command. Try to give details on WHAT you are trying to accomplish - not how you are trying to do it. :-Original Message- :From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf :Of Chris Craddock :Sent: Tuesday, October 18, 2011 12:05 AM :To: IBM-MAIN@bama.ua.edu :Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH : :No, you werent where you thought you were in the code. The system doesn't :lie about what happened. You can't issue any SVC instructions while you :have an FRR on the stack, regardless of what kind of FRR you have. And don't :forget you may be calling other system services whether you're aware of it :or not. : :Leaving aside the general undesirability of testing SRB code by trial and :error, If you did manage to get the SRB scheduled then two interesting :things are happening to you. First you have another independent unit of work :running (the SRB) which will muddy the waters because any error that befalls :the SRB will be reflected back on the TCB you're running under so your :debugging information is going to be quite confusing. : :Frankly you're kind of stumbling around in a coal mine with a flashlight :even trying this. I would usually give a little sermon about all the things :that can go horribly wrong. I will spare you that but here's the rub -- :there's not a lot of chance you're going to suddenly converge on a solution :that works. Tell us what problem you're trying to solve and maybe we can :help you without trashing your system. : :Sent from my iPad : :On Oct 17, 2011, at 10:07 PM, Micheal Butz michealb...@optonline.net :wrote: : : I didn't issue any SVC : : The code blew up under TESTAUTH at the fifth instruction after the : expansion of the SETFRR macro : : I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't abended : on a SVC I abended whitin STM of the SETFRR inst : : -Original Message- : From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On :Behalf : Of Lizette Koehler : Sent: Monday, October 17, 2011 10:54 PM : To: IBM-MAIN@bama.ua.edu : Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH : : Hi, : : : : I am trying to establish a FRR in a TSO command processor program that is : not re- : entrant this is because : : : Later I schedule a SRB and I want to use the routine I established as a : FRR, as input : to the SRBFRRA parameter : : : Did you review the abend and code? : S0F8 - 14 - THE SVC ISSUER HAD AN ENABLED UNLOCKED TASK MODE FRR. :IE. EUT=YES WAS SPECIFIED ON THE SETFRR MACRO. : : Did it help? : : Are you a member of the assembler language newsgroup? You might have :better : response there or better assistance. assembler-l...@listserv.uga.edu : :-- :For IBM-MAIN subscribe / signoff / archive access instructions, :send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO :Search the archives at http://bama.ua.edu/archives/ibm-main.html : :-- :For IBM-MAIN subscribe / signoff / archive access instructions, :send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO :Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: maxsystem in a sysplex - belated heads-up
Kees, Thanks, we will be adding systems to our sysplexes soon, which fit within our maxsystems, but now I have to recheck if they really fit next to the current systens and ancient rubbish. maybe you can test for me if one can find out via simple display commands what rubbish is kept in the sysplex CDS (I obviously cannot, since I've cleaned up all sysplex CDSs with residual information): D XCF,S,ALL supposedly lists all systems in the sysplex. It would be interesting to see if those are really all of them or only those that are active. The book isn't really clear on that distinction. D XCF,GRP will give a list of all defined groups. That means also groups that are no longer valid in the plex (and will never become active again) will still be listed (XCF group member state changes when permanent status recording is on are complicated enough in theory and in the books, but that design change might have also changed this further, without documentation update). From here on out you have to specify each group name individually to see all member(s). So that is not exactly easy to determine how much rubbish might have accumulated. For comparison, take a dump of XCFAS and all its dataspace and then issue the ipcs couple sysplex detail and couple group detail commands to see what *that* might tell you (and where it differs from the displayed information). The way I determined that there were residual systems in the sysplex CDS (which was inactive at the time, so no display commands possible) was to simply *review* browse (from the cbttape) the sysplex CDS. The system names in there fairly leap at you. Looking at group information is harder, as that requires switching left and right. Thanks in advance, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: maxsystem in a sysplex - belated heads-up
Barbara Nitz nitz-...@gmx.net wrote in message news:8637203851702442.wa.nitzibmgmx@bama.ua.edu... Kees, Thanks, we will be adding systems to our sysplexes soon, which fit within our maxsystems, but now I have to recheck if they really fit next to the current systens and ancient rubbish. maybe you can test for me if one can find out via simple display commands what rubbish is kept in the sysplex CDS (I obviously cannot, since I've cleaned up all sysplex CDSs with residual information): D XCF,S,ALL supposedly lists all systems in the sysplex. It would be interesting to see if those are really all of them or only those that are active. The book isn't really clear on that distinction. D XCF,GRP will give a list of all defined groups. That means also groups that are no longer valid in the plex (and will never become active again) will still be listed (XCF group member state changes when permanent status recording is on are complicated enough in theory and in the books, but that design change might have also changed this further, without documentation update). From here on out you have to specify each group name individually to see all member(s). So that is not exactly easy to determine how much rubbish might have accumulated. For comparison, take a dump of XCFAS and all its dataspace and then issue the ipcs couple sysplex detail and couple group detail commands to see what *that* might tell you (and where it differs from the displayed information). The way I determined that there were residual systems in the sysplex CDS (which was inactive at the time, so no display commands possible) was to simply *review* browse (from the cbttape) the sysplex CDS. The system names in there fairly leap at you. Looking at group information is harder, as that requires switching left and right. Thanks in advance, Barbara Barbara, I already did some research . I used IDCAMS PRINT to check the contents of the CDSs and found only valid systemids. Checking back what we did when, I concluded that we could not have polution in the CDSs. We converted our 'testsysplex' to a fully isolated sysplex, but this meant only full dasd isolation. The new testsysplex is polution free, so is the prodsysplex and the old testsysplex has been removed. Furthermore all this happened under z/OS 1.8, so I can't help you. The only thing I can do for you is check D XCF,S,ALL when one of the systems has been brought down, but I suppose you have a testplex yourself? 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: maxsystem in a sysplex - belated heads-up
The only thing I can do for you is check D XCF,S,ALL when one of the systems has been brought down, but I suppose you have a testplex yourself? Yes, we do. I don't remember ever to have issued this command with the ALL parm when one of the systems was down, but it will be easy to do that once the next IPL comes around. I had also forgotten about the idcams print job. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MQ alternatives
To oversimplify only slightly, MQ is a transport and Web services is (are) a protocol. It's quite OK, even common, to run Web services over a JMS/MQ transport. If you say you want to use Web services instead of MQ, it's a bit like saying you want to use voicemail instead of a cellular telephone network. Instead isn't exactly the right word to connect those two concepts. You could say something like We want to use Web services with a transport other than JMS or MQ or We want to use Web services with an HTTPS transport. That might be fine or might not. If the vendor application supports that, if it works, if it meets the non-functional requirements (reliability, performance, maintainability, recoverability, etc.), and if the business case is the strongest, then that's the approach I'd pick. If not, then not. Does the vendor support Web services for integrating their application? With what transport(s)? So far we only know about three available choices: MQ, JMS, and Microsoft Message Queuing. Are CICS-based application(s) the other party(ies) to the interaction(s) with this vendor application? Or some other type of application on the mainframe? Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
Lizette, Thanks for the advice, most probably I will have to do something. I was looking at doing a logical backup of the volume, using DFDSS and inserting the DELETE option. Next, I plan to re-initialize the volume with a larger VVDS and restore the dsns using a logical restore. My only concern is if this volume contains multi-volume dsns would I have a problem when trying to restore these dsns? What I mean by multi-volume dsn is that one segment of the dsn resides on PROD05 and another segment resides on PROD06. How will this play out? I was also told that another option is to ZAP the VVDS. I don't have a utility to do that but I would like to entertain that option as well. Does anybody know about it? Is it safe to use? From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@bama.ua.edu Sent: Monday, October 17, 2011 7:48:31 PM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) I am trying to trouble shoot the following problem : IEC331I 050-030(VVDSFULL, PROD06) According to the message error explanation it says that the VVDS is full. When I check via ISPF 3.4 is shows that it is a 1 ext. The VVDS was built at TRACKS(30 1). To fix the problem the doc says to move dsns off that volume. I tried that but the problem persists when the system is trying to allocate a dsn on the volume. Since the volume is SMS managed (phew), I put it at DISNEW. The doc says to backup the volume, and reinitialize it with a larger VVDS. Is there something else I can try before I try the doc's recommendation? Thanks in advance. The easiest way is to create a new PROD volume to add to the pool. Make sure the VTOC, VTOCIX and VVDS are larger than this one. Do a LISTC ENT(SYS1.VVDS.PROD06) ALL and see what the sizing looks like and either double or triple the new one.. then add it to you pool enabled. DISNEW the PROD06 and let it drain as best it can. Isolate the datasets that need an application (CICS, IMS, MQ, etc..) broght down or the file closed. Then pick a point you and your customers agree and move them. During the rest of the time, see what datasets are not enqueued that can be moved within the pool easily. So, rather than doing all that to PROD06, do it to a new volume and migrate/move the datasets off as you can. Much easier. If you have the spare dasd volume. Then return PROD06 to the group that gave you the new PROD0x volumes You might also want to review all VTOC/VTOCIX/VVDS datasets for the other PRODxx volumes and see if they might have future issues. Hope that helps. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
Linda, I did what you asked. I ran the report and moved 90 dsns from the volume, however the problem still persists. I was told to check OEM option to ZAP the VVDS. I would like to try that out but I am not sure where I should look for it. From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Monday, October 17, 2011 4:06:12 PM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Hi Esmie, If you want to get a look at the contents of the VVDS, you can run this - //STEP1 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * PRINT - INDATASET(SYS1.VVDS.Vvolser) - COUNT(1) It should shed some light on what has filled it up. HTH, Linda - Original Message - From: esmie moo esmie_...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Monday, October 17, 2011 11:59:24 AM Subject: IEC331I 050-030(VVDSFULL, PROD06) Good Afternoon Gentle Readers I am trying to trouble shoot the following problem : IEC331I 050-030(VVDSFULL, PROD06) According to the message error explanation it says that the VVDS is full. When I check via ISPF 3.4 is shows that it is a 1 ext. The VVDS was built at TRACKS(30 1). To fix the problem the doc says to move dsns off that volume. I tried that but the problem persists when the system is trying to allocate a dsn on the volume. Since the volume is SMS managed (phew), I put it at DISNEW. The doc says to backup the volume, and reinitialize it with a larger VVDS. Is there something else I can try before I try the doc's recommendation? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
Thanks for the advice, most probably I will have to do something. I was looking at doing a logical backup of the volume, using DFDSS and inserting the DELETE option. Next, I plan to re-initialize the volume with a larger VVDS and restore the dsns using a logical restore. My only concern is if this volume contains multi-volume dsns would I have a problem when trying to restore these dsns? What I mean by multi- volume dsn is that one segment of the dsn resides on PROD05 and another segment resides on PROD06. How will this play out? I was also told that another option is to ZAP the VVDS. I don't have a utility to do that but I would like to entertain that option as well. Does anybody know about it? Is it safe to use? First I would not zap a VVDS without an open PMR with IBM. That way they can guide me on what the current tools are they have available. Next, I would not rush this process. I would add a new volume to the SMS Pool and slowly drain the PROD06. If it is SMS managed pool, then the volsers are not important. That the pool has dasd it. Is there a need in your shop to always have a sequential volume number in your SMS Pools? That you could not have a PROD01 PROD03 PROD0A, etc? Multi-segments are trickier to move. The application must be down to ensure no data is being written to it at the time. I would backup and recover the entire dataset rather than just one part. It is safer. I would also look to print off the VVDS and compare it to the catalogs and datasets I currently have on the volume. You may find old names that no longer exist. Then you could have IBM help you remove those. On the www.ibm.com website there are tools documented to zapvvds and other functions. I would look at those and see if their functions would help. But remember, these are unsupported tools. Use at your own risk. For example, VVDSFIX - An unsupported VSAM utility used to correct problems with catalogs and VVDS. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS Tag Sort
Hi David, You wrote: .. That exit is limiting the sort to just 24MB of virtual storage when the optimum amount would be closer to 200MB. The data size was 360 GB (336m records). Can you please share the formula you've used to determine the optimum amount is around 200MB? The DFSORT Tuning Guide (1.12) seems to think 2GB is the upper limit when it comes to recommending minimum virtual storage settings :) Thanks, Yifat Oren -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
One other thought I had, run a DCOLLECT against the volume PROD06 and see if there are any errors. Also run a DIAGNOSE and EXAMINE against the VVDS, CATALOG both and individually. There might be some old stuff you could do an IDCAMS DEL on and get space back. Review the REDBOOK http://www.redbooks.ibm.com/redpapers/pdfs/redp4212.pdf ICF Catalog Backup and Recovery: Catalog RecoveryPlus Update ICF catalogs are essential system data sets. Even with the high availability storage subsystems and processors that are available today, there are still situations where you need to recover your catalogs. You should keep your catalogs healthy and be prepared for a recovery situation. Also, you must be sure that your recovery procedures do not have a big impact on your production environment. To minimize the recovery process, you should have a clear backup and recovery strategy and the proper utilities. IBMR Integrated Catalog Forward Recovery Utility (ICFRU) and Mainstar Catalog RecoveryPlus (CR+) are two of the available tools you can use to recover your catalogs. ICFRU is a basic tool to help you in a forward recovery situation. It does not offer a wide range of features, but it is useful for catalog recovery. Mainstar Catalog RecoveryPlus offers a set of features to help you with your ICF catalog environment maintenance. This IBM Redpaper explains how to use each of these products in a catalog recovery situation. It also offers storage administrators useful recommendations for implementing a catalog backup and recovery plan. It does not compare the two products but instead shows how each of them work. This paper also provides practical tests and examples that can help you with the different error scenarios that you might find in your daily production activities. It documents tools for taking care of catalogs and VVDS datasets. If you do not have the Mainstar product Catalog Recovery Plus (CR+) then ignore chapter 2. The CASE STUDIES will help in working with BCS and VVDS tools. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Monday, October 17, 2011 9:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH snip Are you a member of the assembler language newsgroup? You might have better response there or better assistance. assembler-l...@listserv.uga.edu Lizette But, at times, the people over on ASSEMBLER-LIST will refer people back here for system-specific problems. Something about ASSEMBLER-LIST being for problems and questions about the assembler itself, not about assembler coding to a system API function for a specific environment (z/VM vs. z/VSE vs. z/OS vs. z/TPF vs. z/Linux). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
Lizette, I did contact IBM and they suggested to apply and OEM zap. Since the client insists on keeping the same volsers I have no choice but to backup/delete restore the dsns on the same volume. My question is there a utility available to tell me which dsns on this particular volume could have a segment on another volume? This way I could move the whole dsn on to another volume. From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 18, 2011 7:29:46 AM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Thanks for the advice, most probably I will have to do something. I was looking at doing a logical backup of the volume, using DFDSS and inserting the DELETE option. Next, I plan to re-initialize the volume with a larger VVDS and restore the dsns using a logical restore. My only concern is if this volume contains multi-volume dsns would I have a problem when trying to restore these dsns? What I mean by multi- volume dsn is that one segment of the dsn resides on PROD05 and another segment resides on PROD06. How will this play out? I was also told that another option is to ZAP the VVDS. I don't have a utility to do that but I would like to entertain that option as well. Does anybody know about it? Is it safe to use? First I would not zap a VVDS without an open PMR with IBM. That way they can guide me on what the current tools are they have available. Next, I would not rush this process. I would add a new volume to the SMS Pool and slowly drain the PROD06. If it is SMS managed pool, then the volsers are not important. That the pool has dasd it. Is there a need in your shop to always have a sequential volume number in your SMS Pools? That you could not have a PROD01 PROD03 PROD0A, etc? Multi-segments are trickier to move. The application must be down to ensure no data is being written to it at the time. I would backup and recover the entire dataset rather than just one part. It is safer. I would also look to print off the VVDS and compare it to the catalogs and datasets I currently have on the volume. You may find old names that no longer exist. Then you could have IBM help you remove those. On the www.ibm.com website there are tools documented to zapvvds and other functions. I would look at those and see if their functions would help. But remember, these are unsupported tools. Use at your own risk. For example, VVDSFIX - An unsupported VSAM utility used to correct problems with catalogs and VVDS. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Time Zone Database Has New Home After Lawsuit
OK, people we can relax! http://abcnews.go.com/Technology/wireStory/time-zone-database-home-lawsuit-14748312 quote The organization in charge of the Internet's address system is taking over a database widely used by computers and websites to keep track of time zones around the world. The transition to the Internet Corporation for Assigned Names and Numbers, or ICANN, comes a week after the database was abruptly removed from a U.S. government server because of a federal lawsuit claiming copyright infringement. /quote John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
IEHLIST LIST VTOC should be able to identify any datasets that are multi-volume. Mark Jacobs On 10/18/11 07:56, esmie moo wrote: Lizette, I did contact IBM and they suggested to apply and OEM zap. Since the client insists on keeping the same volsers I have no choice but to backup/delete restore the dsns on the same volume. My question is there a utility available to tell me which dsns on this particular volume could have a segment on another volume? This way I could move the whole dsn on to another volume. From: Lizette Koehlerstars...@mindspring.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 18, 2011 7:29:46 AM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Thanks for the advice, most probably I will have to do something. I was looking at doing a logical backup of the volume, using DFDSS and inserting the DELETE option. Next, I plan to re-initialize the volume with a larger VVDS and restore the dsns using a logical restore. My only concern is if this volume contains multi-volume dsns would I have a problem when trying to restore these dsns? What I mean by multi- volume dsn is that one segment of the dsn resides on PROD05 and another segment resides on PROD06. How will this play out? I was also told that another option is to ZAP the VVDS. I don't have a utility to do that but I would like to entertain that option as well. Does anybody know about it? Is it safe to use? First I would not zap a VVDS without an open PMR with IBM. That way they can guide me on what the current tools are they have available. Next, I would not rush this process. I would add a new volume to the SMS Pool and slowly drain the PROD06. If it is SMS managed pool, then the volsers are not important. That the pool has dasd it. Is there a need in your shop to always have a sequential volume number in your SMS Pools? That you could not have a PROD01 PROD03 PROD0A, etc? Multi-segments are trickier to move. The application must be down to ensure no data is being written to it at the time. I would backup and recover the entire dataset rather than just one part. It is safer. I would also look to print off the VVDS and compare it to the catalogs and datasets I currently have on the volume. You may find old names that no longer exist. Then you could have IBM help you remove those. On the www.ibm.com website there are tools documented to zapvvds and other functions. I would look at those and see if their functions would help. But remember, these are unsupported tools. Use at your own risk. For example, VVDSFIX - An unsupported VSAM utility used to correct problems with catalogs and VVDS. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Jacobs Time Customer Service Tampa, FL One of life's greatest mysteries is how the boy who wasn't good enough to marry your daughter can be the father of the smartest grandchild in the world. Yiddish Proverb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assember Newsgroup ( Was SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH)
Lizette But, at times, the people over on ASSEMBLER-LIST will refer people back here for system-specific problems. Something about ASSEMBLER-LIST being for problems and questions about the assembler itself, not about assembler coding to a system API function for a specific environment (z/VM vs. z/VSE vs. z/OS vs. z/TPF vs. z/Linux). -- John McKown Systems Engineer IV IT John, thanks for letting me know that. I had thought that they would also be interested in discussing deep level coding techniques like FRR and SRB as well. This is good to know. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
Use DF/DSS logical dump. This will find all of the pieces and restore them E.G. DUMP DS include( dsn's ) - Other parameters RESTORE DS include(**) - Replace recatalog delete - Other parameters HTH, snip My question is there a utility available to tell me which dsns on this particular volume could have a segment on another volume? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH
Michael, It sounds like you are issuing the SETFRR under your TCB which is going to SCHEDULE your SRB. This is not necessary and will almost certainly cause you problems, such as the 0F8 abend, and this FRR will not protect your SRB. FRR's can be used to establish a recovery environment for a TCB, but I don't think you really need one here. If you do need such an environment, I would use an ESTAEX. You can choose to use an FRR with your SRB, or, you can just let it percolate back to your TCB, as Chris mentioned. If you do want an FRR for your SRB, you can just set its address in the SRBFRRA field or you can issue your own SETFRR rearly in the SRB code. I would also suggest issuing an SRBTIMER macro to catch any loops you might have. Like the Binjamin and Chris, I wonder what you're trying to accomplish here. It sounds like this is your first foray into this sort of coding, but it also appears that you haven't read all of the background material in the z/OS Authorized Programming Guide, which I suggest you should do. In there are the answers to all of the questions you've been asking here. If you are determined to push ahead, I'm hoping you are testing on a sandbox system. Please be more communicative with your objectives here. Tom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Tuesday, October 18, 2011 3:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH On Tue, 18 Oct 2011 00:26:08 -0400 Micheal Butz michealb...@optonline.net wrote: :I am trying to issue a branch entry form of a macro in a other address :space since the specifications say PASN=HASN=SASN Which macro? :SRB was the only way to go, the branch entry form of the macro was the only :code in the SRB I figured I would set up a FRR :So that if anything goes wrong RTM would give control to the FRR I could :examine the SDWA for any problems Have you done FRR's before? ESTAEs? If not, you might be biting off more than you can chew with testing a FRR and SRB's at the same time. Under which conditions will you recover? You might want to set it up so that the SRB will abend your issuing task. Also, I don't get the connection between what you are doing and a non-reentrent TSO command. Try to give details on WHAT you are trying to accomplish - not how you are trying to do it. :-Original Message- :From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf :Of Chris Craddock :Sent: Tuesday, October 18, 2011 12:05 AM :To: IBM-MAIN@bama.ua.edu :Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH : :No, you werent where you thought you were in the code. The system doesn't :lie about what happened. You can't issue any SVC instructions while you :have an FRR on the stack, regardless of what kind of FRR you have. And don't :forget you may be calling other system services whether you're aware of it :or not. : :Leaving aside the general undesirability of testing SRB code by trial and :error, If you did manage to get the SRB scheduled then two interesting :things are happening to you. First you have another independent unit of work :running (the SRB) which will muddy the waters because any error that befalls :the SRB will be reflected back on the TCB you're running under so your :debugging information is going to be quite confusing. : :Frankly you're kind of stumbling around in a coal mine with a flashlight :even trying this. I would usually give a little sermon about all the things :that can go horribly wrong. I will spare you that but here's the rub -- :there's not a lot of chance you're going to suddenly converge on a solution :that works. Tell us what problem you're trying to solve and maybe we can :help you without trashing your system. : :Sent from my iPad : :On Oct 17, 2011, at 10:07 PM, Micheal Butz michealb...@optonline.net :wrote: : : I didn't issue any SVC : : The code blew up under TESTAUTH at the fifth instruction after the : expansion of the SETFRR macro : : I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't abended : on a SVC I abended whitin STM of the SETFRR inst : : -Original Message- : From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On :Behalf : Of Lizette Koehler : Sent: Monday, October 17, 2011 10:54 PM : To: IBM-MAIN@bama.ua.edu : Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH : : Hi, : : : : I am trying to establish a FRR in a TSO command processor program that is : not re- : entrant this is because : : : Later I schedule a SRB and I want to use the routine I established as a : FRR, as input : to the SRBFRRA parameter : : : Did you review the abend and code? : S0F8 - 14 - THE SVC ISSUER HAD AN ENABLED UNLOCKED TASK MODE FRR. :IE. EUT=YES WAS SPECIFIED ON THE SETFRR MACRO. : : Did it help? : : Are you a member
Re: Thanks for all the PMR's
John, I'm confused, you sent the following -- what? Thanks, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List On Behalf Of John Mattson Sent: Monday, October 17, 2011 6:15 PM I sent the following to my IBM PMR handler (DFSMSrmm) and thought the rest of you might find it amusing. Sometimes I think there is something magical about posting a PMR. Well, Maybe its magic, or maybe the act of having to write out and have a clear description of the problem, or maybe the desire to beat IBM to the solution or maybe avoid the embarassment of not being able to resolve it myself. In any case... thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Looking for clues on a bug in assembler
To anyone who thinks I am off-base on this, I'll meet you half way. If anyone really believes that this problem could and should be reported to IBM productively, send me a note off-line (charlesm at mcn dot org) and I will take my existing code (1000+ lines, five entry points, a whole lot of surrounding C++ logic) and reduce it to a single short assembler program that runs and demonstrates the problem. I'll send it to you, and you can use it to report the problem to IBM. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Monday, October 17, 2011 12:53 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Looking for clues on a bug in assembler @Shmuel, I hear you. I certainly feel some duty to contribute to z/OS and the community by helping to make z/OS better. If the customers cared about this they would report it. Therein lies one of the problems. I'm not a customer. And I utterly anticipate spending hours arguing with them because what I am doing that *exposes* the bug is totally stupid programming. (The SYNAD error on file A is because -- due to an error in the initial coding of the calling code -- it opens for input and attempts to read a SYSOUT dataset.) I think IBM is wrong here in how they are running their business. I do not presume to tell them how to run their business, but I am entitled to my opinion, and I am of course running my business based on my opinions. If I had a product -- when I had a product, in fact -- if I became aware -- as IBM surely is -- that it was common knowledge on IBMMAIN that there was a glaring bug (or at least a glaring behavior versus documentation inconsistency) then I would fix it; I would not demand that a customer go through some particular ritual before I fixed it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH
Is all that's required for setting a recovery routine for the SRB is setting a address in SRBFRRA ? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tom Harper Sent: Tuesday, October 18, 2011 8:48 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH Michael, It sounds like you are issuing the SETFRR under your TCB which is going to SCHEDULE your SRB. This is not necessary and will almost certainly cause you problems, such as the 0F8 abend, and this FRR will not protect your SRB. FRR's can be used to establish a recovery environment for a TCB, but I don't think you really need one here. If you do need such an environment, I would use an ESTAEX. You can choose to use an FRR with your SRB, or, you can just let it percolate back to your TCB, as Chris mentioned. If you do want an FRR for your SRB, you can just set its address in the SRBFRRA field or you can issue your own SETFRR rearly in the SRB code. I would also suggest issuing an SRBTIMER macro to catch any loops you might have. Like the Binjamin and Chris, I wonder what you're trying to accomplish here. It sounds like this is your first foray into this sort of coding, but it also appears that you haven't read all of the background material in the z/OS Authorized Programming Guide, which I suggest you should do. In there are the answers to all of the questions you've been asking here. If you are determined to push ahead, I'm hoping you are testing on a sandbox system. Please be more communicative with your objectives here. Tom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Tuesday, October 18, 2011 3:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH On Tue, 18 Oct 2011 00:26:08 -0400 Micheal Butz michealb...@optonline.net wrote: :I am trying to issue a branch entry form of a macro in a other address :space since the specifications say PASN=HASN=SASN Which macro? :SRB was the only way to go, the branch entry form of the macro was the only :code in the SRB I figured I would set up a FRR :So that if anything goes wrong RTM would give control to the FRR I could :examine the SDWA for any problems Have you done FRR's before? ESTAEs? If not, you might be biting off more than you can chew with testing a FRR and SRB's at the same time. Under which conditions will you recover? You might want to set it up so that the SRB will abend your issuing task. Also, I don't get the connection between what you are doing and a non-reentrent TSO command. Try to give details on WHAT you are trying to accomplish - not how you are trying to do it. :-Original Message- :From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf :Of Chris Craddock :Sent: Tuesday, October 18, 2011 12:05 AM :To: IBM-MAIN@bama.ua.edu :Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH : :No, you werent where you thought you were in the code. The system doesn't :lie about what happened. You can't issue any SVC instructions while you :have an FRR on the stack, regardless of what kind of FRR you have. And don't :forget you may be calling other system services whether you're aware of it :or not. : :Leaving aside the general undesirability of testing SRB code by trial and :error, If you did manage to get the SRB scheduled then two interesting :things are happening to you. First you have another independent unit of work :running (the SRB) which will muddy the waters because any error that befalls :the SRB will be reflected back on the TCB you're running under so your :debugging information is going to be quite confusing. : :Frankly you're kind of stumbling around in a coal mine with a flashlight :even trying this. I would usually give a little sermon about all the things :that can go horribly wrong. I will spare you that but here's the rub -- :there's not a lot of chance you're going to suddenly converge on a solution :that works. Tell us what problem you're trying to solve and maybe we can :help you without trashing your system. : :Sent from my iPad : :On Oct 17, 2011, at 10:07 PM, Micheal Butz michealb...@optonline.net :wrote: : : I didn't issue any SVC : : The code blew up under TESTAUTH at the fifth instruction after the : expansion of the SETFRR macro : : I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't abended : on a SVC I abended whitin STM of the SETFRR inst : : -Original Message- : From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On :Behalf : Of Lizette Koehler : Sent: Monday, October 17, 2011 10:54 PM : To: IBM-MAIN@bama.ua.edu : Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH : : Hi, : : : : I am trying to establish a FRR in a TSO command processor program that is : not re- : entrant this is because : : : Later I schedule a
Re: maxsystem in a sysplex - belated heads-up
I have two sysplexes with one or two members not currently running. None show up with D XCF,S,ALL . What I see is lots of detail about the one member that is running. Nothing about the others. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Barbara Nitz nitz-...@gmx.net To: IBM-MAIN@bama.ua.edu Date: 10/18/2011 02:12 AM Subject:Re: maxsystem in a sysplex - belated heads-up Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu The only thing I can do for you is check D XCF,S,ALL when one of the systems has been brought down, but I suppose you have a testplex yourself? Yes, we do. I don't remember ever to have issued this command with the ALL parm when one of the systems was down, but it will be easy to do that once the next IPL comes around. I had also forgotten about the idcams print job. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SRBEPA
In 00e701cc8d19$4d6f9980$e84ecc80$@net, on 10/17/2011 at 06:08 PM, Micheal Butz michealb...@optonline.net said: Page fault that means it does't have to be fixed unless I just don't get it Did you see Jim Mulder's message, ofc7e976b2.bebda8c2-on8525792c.006db3e2-8525792c.006e2...@us.ibm.com? In brief, the SRB has to be fixed but the code does not, unless it will be running disabled. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Chaos feared after UNIX time-zone database is nuked.
In capd5f5q2nw-nhit9llsjjlzyokg0av_q-whbywxv09nbwpp...@mail.gmail.com, on 10/17/2011 at 09:01 PM, John Gilmore johnwgilmore0...@gmail.com said: I am puzzled by this distinction. In general there is no way to convert a time value in a date-independent way; There is a simple way; a raw time value refers to the current day. It is not, of course, suitable for use in files that must be read on a different day, but it is perfectly appropriate for use in human interfaces. You know this. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH
On Tue, Oct 18, 2011 at 10:20 AM, Micheal Butz michealb...@optonline.netwrote: Is all that's required for setting a recovery routine for the SRB is setting a address in SRBFRRA ? http://bama.ua.edu/archives/ibm-main.html At the risk of sending you off on another tangent, yes. But, what would you *DO* with an FRR if you managed to set one? They serve two purposes; 1. Diagnosis: Collect error diagnostic data for subsequent analysis 2. Recovery: Choose to percolate or set up the registers for a retry both of those things are complex and delicate (think of walking on eggshells). If you don't have a very detailed understanding of the recovery environment, you're likely to do more harm than good. If you're going to play with fire, it is best to let your SRB crash and burn, rather than risk doing more harm. Oh and BTW I assume you are aware that (for normal human beings) you CANNOT debug any SRB or FRR under TSO right? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Zone Database Has New Home After Lawsuit
In a6b9336cdb62bb46b9f8708e686a7ea00b038bb...@nrhmms8p02.uicnrh.dom, on 10/18/2011 at 07:05 AM, McKown, John john.mck...@healthmarkets.com said: OK, people we can relax! What stops them from going after ICANN next? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH
In 011b01cc8d43$10639a30$312ace90$@net, on 10/17/2011 at 11:07 PM, Micheal Butz michealb...@optonline.net said: I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't abended on a SVC I abended whitin STM of the SETFRR inst No. You got the ABEND on the breakpoint that TESTAUTH inserted in place of the STM. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH
In 012501cc8d4e$0f098770$2d1c9650$@net, on 10/18/2011 at 12:26 AM, Micheal Butz michealb...@optonline.net said: SRB was the only way to go, Why wouldn't an IRB work? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: expirebv for abars, and deleting the resulting uncataloged tape datasets
On 10/18/2011 11:41 AM, Mike B wrote: Hi, We wish to clean up unwanted abars tape datasets using expirebv and retainversions(n) Listing a test abars group, we know that the oldest version of an agg- group had two datasets and two volsers involved. Running EXPIREBV ABARSVERSIONS AGNAME(ABENDAID) RETAINVERSIONS(0021) DISPLAY showed that it woud UNcatalog the two datasets. I then ran the expirebv with execute, and this morning after rmm housekeeping the two volsers show in RMM as SCRATCH, but when I go into the RMM panels, it shows the 2 datasets are still on the volsers. 1) Must I run the expirebv a second time before these 2 uncataloged datasets go away? (I've seen references in google for running expirebv a 2nd time...1st just marks it uncataloged...2nd run whacks em) Mike, This is not a problem, RMM is WAD. After a volume is scratched, RMM retains the dataset name. When the scratch volume is mounted, RMM checks the dataset name against the tape label. If the datasets don't match, then RMM disallows the mount, since the tape was created outside RMM control. This is a fail-safe to ensure that anyone creating a tape while RMM is RESET or bypassing RMM with EXPDT=98000 does not have their data destroyed. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Chaos feared after UNIX time-zone database is nuked
In response to my query Shmuel wrote: | There is a simple way; a raw time value refers to the current day. It | is not, of course, suitable for use in files that must be read on a | different day, but it is perfectly appropriate for use in human | interfaces. You know this. I do indeed know it. To my wife on the telephone, I may well say, I'll be back at 10:30 or the like. Such statements are insulated from date and time-zone ambiguity because they are local and ephemeral. I would not write a program that had embedded in it the heroic assumption that a time value was a time value for some current day (bad) and time zone (worse), and I do not really think that Shmuel would do so either. The problem here is that 'human interfaces' are not all of a piece, and Shmuel knows this. My interface with my wife of 51 years admits of telegraphic brevity and much apparent but not in fact substantive ambiguity. Computer-system 'human interfaces', on the other hand, must be explicit and as unambiguous as we can make them. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Zone Database Has New Home After Lawsuit
ICANN has said that they will fight tooth-and-nail instead of rolling over. Not that they are guaranteed to win, if it comes to that. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, October 18, 2011 11:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Zone Database Has New Home After Lawsuit In a6b9336cdb62bb46b9f8708e686a7ea00b038bb...@nrhmms8p02.uicnrh.dom, on 10/18/2011 at 07:05 AM, McKown, John john.mck...@healthmarkets.com said: OK, people we can relax! What stops them from going after ICANN next? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DS8800 ESQA bytes
we have arrived at several different answers for this (what I think) is a relatively simple question. More opinions/facts are invited--- for the DS8800, how many bytes in ESQA does each 3390B 3390A take -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BMC CMF vs. IBM RMF
snip--- Well, that was a bad day. ---unsnip- That's a masterpiece of understatement! :-) -snip- But this does not justify the general statement that this never has happnened, nor ever will, with RMF. I bet there will at least be one site that has had a similar experience with RMF? --unsnip- I don't believe I ever made the statement that RMF was perfect. I was, however, assured by RMF Lvl-2 support, that it uses designed interfaces to gather its information. Hooks into existing code using the instruction-replacement technique are strictly verboten. It was that type of hook that caused my problem with CMF. I was also assured that TMF had never led to a system outage; only measurement outages or inconsistencies. ---snip-- We had the same feeling with one product from a third party vendor, that we used in stead of the IBM product. The third party product had several nasty problems, but when I suggestes to convert to the IBM product, my colleague who does most of the SMP work, pointed out that he regularly saw PTFs on the IBM product for similarly nasty problems. unsnip--- Nobody has a monopoly on problems; even the most careful designs can have some pretty nasty failures when circumstances happen that were not considered by the designers. --snip-- No product is bugfree, even IEFBR14 has been enhanced in the past, so stating that one is better than the other should be based on decent investigations. unsnip I submit that enhancements are not necessarily solutions. Even programs with no problems can be enhanced. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS8800 ESQA bytes
On Tue, 18 Oct 2011 11:35:04 -0500, J Ellis jerry.el...@libertymutual.com wrote: we have arrived at several different answers for this (what I think) is a relatively simple question. More opinions/facts are invited--- for the DS8800, how many bytes in ESQA does each 3390B 3390A take Good question. I wonder if it is documented somewhere. The best thing I can offer is a statement in the HCD manual: The size of a UCB is dependent on the device type. For example, a DASD UCB defined below 16 megabytes has approximately 128 bytes below 16 megabytes. The size of the prefix extension is not included because it already exists above 16 megabytes. So I would say approximately 128 bytes each + the prefix. Looking at SYS1.MACLIB(IEFUCBOB) has some good information, including this: SIZE: Device Class Extension : 0 to 256 bytes UCB Common Extension: 32 bytes for all devices UCB Prefix Stub : 8 bytes for all devices UCB Common Segment : 24 bytes for all devices UCB Device Dependent Segment: 0 to 24 bytes for below 16Mb devices. No limit on the size for above 16Mb devices Device Dependent Extension : 0 to 40 bytes I know there are some people on this list that can give a better answer though... Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS SYSLOG observation / thought
Columns 41 through 48 in the z/OS SYSLOG (formatted with a 4 digit year in columns 21-27) have various information in them. For many messages, it is the JES assigned number such as JOB12345. For a commands and command responses it appears to the be console name or for a MLWTO response the continuation number. For an S line it is blank because that means the line is a continuation of the above output line (N or S). But, for WTOs issued by started tasks which are running under the MSTR subsystem, it is blank instead of having the JES jobid (N lines, that is). So there's no way to know which task issued the message. I guess that most of the time, this doesn't really matter. But I was thinking, perhaps poorly, that where the JES jobid would be, wouldn't it be useful to have the ASID of the address space? Perhaps formatted as ASID where is the hex value of the ASID? I am wondering if one of the WTO exits could be used to implement this. I guess that I'll look and see. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS8800 ESQA bytes
My €0.02: WHO CARES? I'm serious. Some thoughts: 1. IMHO UCB size for D8800 is quite the same in size as for good old (real) 3390 connected to 3990 CU. I believe, that UCB size is same for EMC, HDS, IBM, whatever. 2. UCB size is no big problem, since UCBs can reside above 16MB. We don't have serious memory constrainst in 31-bit area. So, who really cares? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PDSE configuration concerns
Hi Ralph, PDSESHARING (EXTENDED) since April 2004 and nothing but good has come of it. PDSE has been very good for us solving performance problems and reducing data management of PDS(s) in our source change management system. Thanks, Sam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ralph Wendt Sent: Thursday, October 13, 2011 1:26 AM To: IBM-MAIN@bama.ua.edu Subject: PDSE configuration concerns All: We have 3 LPARS, with SHARING set to Normal. We would like to change SHARING to Extended. What kind of issues can I expect from implementing this change? How would I perform the fallback? One member at a time, or a sysplex wide IPL? Any relevant comments would be appreciated. Ralph. 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DS6800 and PAV question
Does anyone know if adding PAV (alias) addresses to a configured DS6800 is disruptive of any real devices already configured and initialized on the affected LCU? I seem to recall that with the older sharks (such as ESS 800 or F20 models) that this may have been the case. I seem to recall the disruption could reformat the existing volumes (but this may just be an old bad dream :-) ). Mike Myers Mentor Services Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS6800 and PAV question
W dniu 2011-10-18 20:00, Mike Myers pisze: Does anyone know if adding PAV (alias) addresses to a configured DS6800 is disruptive of any real devices already configured and initialized on the affected LCU? IMHO yes. Usually you have 256 devices per CU. Base and aliases. So, adding aliases means CU reconfiguration, means some device must go to another CU. Since such devices must go offline, it is disruptive. There is further question: is the reformat required to do such reconfiguration? Disruptive means simply offline-online, maybe it causes IPL. Reformat means you LOSE your volumes and have to restore them from backup. My €0.02 -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: expirebv for abars, and deleting the resulting uncataloged tape datasets
On 10/18/2011 2:29 PM, Mike B wrote: On Oct 18, 11:12 am, pinnc...@rochester.rr.com (Pinnacle) wrote: On 10/18/2011 11:41 AM, Mike B wrote: Hi, We wish to clean up unwanted abars tape datasets using expirebv and retainversions(n) Listing a test abars group, we know that the oldest version of an agg- group had two datasets and two volsers involved. Running EXPIREBV ABARSVERSIONS AGNAME(ABENDAID) RETAINVERSIONS(0021) DISPLAY showed that it woud UNcatalog the two datasets. I then ran the expirebv with execute, and this morning after rmm housekeeping the two volsers show in RMM as SCRATCH, but when I go into the RMM panels, it shows the 2 datasets are still on the volsers. 1) Must I run the expirebv a second time before these 2 uncataloged datasets go away? (I've seen references in google for running expirebv a 2nd time...1st just marks it uncataloged...2nd run whacks em) Mike, This is not a problem, RMM is WAD. After a volume is scratched, RMM retains the dataset name. When the scratch volume is mounted, RMM checks the dataset name against the tape label. If the datasets don't match, then RMM disallows the mount, since the tape was created outside RMM control. This is a fail-safe to ensure that anyone creating a tape while RMM is RESET or bypassing RMM with EXPDT=98000 does not have their data destroyed. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives athttp://bama.ua.edu/archives/ibm-main.html- Hide quoted text - - Show quoted text - Hi Tom, I'm not sure what you're telling me.(sorry, I'm tape- illiterate). So, with the 2 uncataloged datasets still on the scratch tape, are you saying that scratch tape is ergo un-usable?? (if so, then I'd imagine some process must still be run to address same). I'm being told though that running expirebv is NOT needed saying Mike, I'm saying it's not a problem, don't do anything. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS6800 and PAV question
Radoslaw: Thanks. My greater concern is loss of data. This system is very new and not into production yet, so an IPL would be minimally disruptive for a while (until after the operating system was installed and configured. Since we are installing the operating system later this week, if it was reformatting the volumes, that would be truly disruptive. Mike On 10/18/2011 02:28 PM, R.S. wrote: W dniu 2011-10-18 20:00, Mike Myers pisze: Does anyone know if adding PAV (alias) addresses to a configured DS6800 is disruptive of any real devices already configured and initialized on the affected LCU? IMHO yes. Usually you have 256 devices per CU. Base and aliases. So, adding aliases means CU reconfiguration, means some device must go to another CU. Since such devices must go offline, it is disruptive. There is further question: is the reformat required to do such reconfiguration? Disruptive means simply offline-online, maybe it causes IPL. Reformat means you LOSE your volumes and have to restore them from backup. My €0.02 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS6800 and PAV question
If you have unused / usassigned addresses on each LCU, you can add PAVs to the end and dynamicly update your I/O gen to use them. On Tue, Oct 18, 2011 at 1:56 PM, Mike Myers m...@mentor-services.com wrote: Radoslaw: Thanks. My greater concern is loss of data. This system is very new and not into production yet, so an IPL would be minimally disruptive for a while (until after the operating system was installed and configured. Since we are installing the operating system later this week, if it was reformatting the volumes, that would be truly disruptive. Mike On 10/18/2011 02:28 PM, R.S. wrote: W dniu 2011-10-18 20:00, Mike Myers pisze: Does anyone know if adding PAV (alias) addresses to a configured DS6800 is disruptive of any real devices already configured and initialized on the affected LCU? IMHO yes. Usually you have 256 devices per CU. Base and aliases. So, adding aliases means CU reconfiguration, means some device must go to another CU. Since such devices must go offline, it is disruptive. There is further question: is the reformat required to do such reconfiguration? Disruptive means simply offline-online, maybe it causes IPL. Reformat means you LOSE your volumes and have to restore them from backup. My €0.02 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS SYSLOG observation / thought
On 18 October 2011 13:29, McKown, John john.mck...@healthmarkets.com wrote: Columns 41 through 48 in the z/OS SYSLOG (formatted with a 4 digit year in columns 21-27) have various information in them. For many messages, it is the JES assigned number such as JOB12345. For a commands and command responses it appears to the be console name or for a MLWTO response the continuation number. For an S line it is blank because that means the line is a continuation of the above output line (N or S). But, for WTOs issued by started tasks which are running under the MSTR subsystem, it is blank instead of having the JES jobid (N lines, that is). So there's no way to know which task issued the message. I guess that most of the time, this doesn't really matter. But I was thinking, perhaps poorly, that where the JES jobid would be, wouldn't it be useful to have the ASID of the address space? Perhaps formatted as ASID where is the hex value of the ASID? I am wondering if one of the WTO exits could be used to implement this. I guess that I'll look and see. Some years ago I looked at putting the UNIX PID in there. It's very easy to retrieve and insert; the problem lies in where to squeeze it in in a way that won't break other programs that know what log lines contain, and that makes it unambiguous what the new field means. Had IBM not used large PIDs (or rather, not encoded two items in each PID), it would've been easy. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS6800 and PAV question
Mike: Thanks, and that has no affect on the previously defined volume contents? Sounds like it just adds the alias addresses to the LCU definition, but no physical disk data needs to be changed, right? Mike On 10/18/2011 03:35 PM, Mike Schwab wrote: If you have unused / usassigned addresses on each LCU, you can add PAVs to the end and dynamicly update your I/O gen to use them. On Tue, Oct 18, 2011 at 1:56 PM, Mike Myersm...@mentor-services.com wrote: Radoslaw: Thanks. My greater concern is loss of data. This system is very new and not into production yet, so an IPL would be minimally disruptive for a while (until after the operating system was installed and configured. Since we are installing the operating system later this week, if it was reformatting the volumes, that would be truly disruptive. Mike On 10/18/2011 02:28 PM, R.S. wrote: W dniu 2011-10-18 20:00, Mike Myers pisze: Does anyone know if adding PAV (alias) addresses to a configured DS6800 is disruptive of any real devices already configured and initialized on the affected LCU? IMHO yes. Usually you have 256 devices per CU. Base and aliases. So, adding aliases means CU reconfiguration, means some device must go to another CU. Since such devices must go offline, it is disruptive. There is further question: is the reformat required to do such reconfiguration? Disruptive means simply offline-online, maybe it causes IPL. Reformat means you LOSE your volumes and have to restore them from backup. My €0.02 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS6800 and PAV question
Correct. And the definitions on the device are static. Once WLM starts re-assigning the PAVs to new UCBs, it is called Dynamic, or if re-assigned with each I/O, Hyper-PAVs. If you need to change I/O addresses, you can change the I/O gen to use new addresses and IPL to use the new addresses. On Tue, Oct 18, 2011 at 2:51 PM, Mike Myers m...@mentor-services.com wrote: Mike: Thanks, and that has no affect on the previously defined volume contents? Sounds like it just adds the alias addresses to the LCU definition, but no physical disk data needs to be changed, right? Mike On 10/18/2011 03:35 PM, Mike Schwab wrote: If you have unused / usassigned addresses on each LCU, you can add PAVs to the end and dynamicly update your I/O gen to use them. On Tue, Oct 18, 2011 at 1:56 PM, Mike Myersm...@mentor-services.com wrote: Radoslaw: Thanks. My greater concern is loss of data. This system is very new and not into production yet, so an IPL would be minimally disruptive for a while (until after the operating system was installed and configured. Since we are installing the operating system later this week, if it was reformatting the volumes, that would be truly disruptive. Mike On 10/18/2011 02:28 PM, R.S. wrote: W dniu 2011-10-18 20:00, Mike Myers pisze: Does anyone know if adding PAV (alias) addresses to a configured DS6800 is disruptive of any real devices already configured and initialized on the affected LCU? IMHO yes. Usually you have 256 devices per CU. Base and aliases. So, adding aliases means CU reconfiguration, means some device must go to another CU. Since such devices must go offline, it is disruptive. There is further question: is the reformat required to do such reconfiguration? Disruptive means simply offline-online, maybe it causes IPL. Reformat means you LOSE your volumes and have to restore them from backup. My €0.02 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Help with Tape Hardware Issue TS3500
I had a hardware failure of some kind on Oct 15. Today I am missing the tape that was indicated in the messages. I looked at the ATL through the web interface and it says it is in the gripper(acc1,g1) ISMF shows the tape as VOLUME MISPLACED. Earlier it had VOLUME UNAVAILABLE. CA-1 shows SCRATCH. When a CA-1 CTSSYNC is run it gets an RC08 on this drive with the following error codes ERROR(S)SCRATCH 300761 REQUEST FAILED RC=012,RS=070,FB= CBR4195I LACS retry possible for job PRODJOB: 603 IEE763I NAME= CBRLLACS CODE= 140376 CBR4000I LACS WAIT permanent error for drive 0A0B. CBR4118I Library ATL0001 drive no longer available. IEE764I END OF CBR4195I RELATED MESSAGES *4569 CBR4196D Job PRODJOB, drive 0A0B, volser SCRTCH, error code 140376. Reply 'R' to retry or 'C' to cancel. *CBR3762E Library VTS0001 intervention required. *CBR3762E Library VTS0001 intervention required. *CBR3762E Library VTS0001 intervention required. *CBR3762E Library VTS0001 intervention required. CBR3776I Volume 300761 inaccessible in library ATL0001. *CBR3762E Library VTS0001 intervention required. *CBR3762E Library ATL0001 intervention required. CBR3751I Device 0A0B in library ATL0001 is unavailable. IEF880I 0A0B NOW OFFLINE BY OAM CBR3776I Volume 300761 inaccessible in library ATL0001. *CBR3762E Library ATL0001 intervention required. We have run the inventory a couple of times and not luck in spotting the errant tape. The Operators have opened up the ATL and manually scanned for the tape. So far it is missing in action. Any ideas where I can go next? The hardware support vendor says they did not remove any tapes when they came in and brought the drive back on line. And the only thing I know the vendor did was run an inventory and bring the A0B drive back online. Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
With PROG06 in DSNEW status, run: //ADRDSSU EXEC PGM=ADRDSSU,REGION=5M, // TIME=1439 ,PARM='TYPRUN=SCAN' //SYSPRINT DD SYSOUT=* //SYSINDD * COPY DATASET(INCLUDE(**)) - INDY( - (PROD06) - )- ALLEXCP - ALLDATA(*) - ADMIN- CATALOG - DELETE - PROCESS(SYS1)- PURGE- SPHERE Which will move everything it can off of PROD06 and keep it in the same SMS pool. Then determine why whatever is left wouldn't move, remove the inhibitor, and move it. When volume is empty, reinit. IMO, any of the other methods suggested include unneeded risk. Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help with Tape Hardware Issue TS3500
Hi Lizette, We used to have a 3494 ATL. We had it for over 10 years. A couple of times, we had a tape go missing with last status of being in the gripper. Both times, we found the tape on the floor of the ATL, once bumped underneath the edge of one of the drives in the ATL and once one the floor by the robot's 'garage'. HTH, Linda - Original Message - From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 18, 2011 12:55:17 PM Subject: Help with Tape Hardware Issue TS3500 I had a hardware failure of some kind on Oct 15. Today I am missing the tape that was indicated in the messages. I looked at the ATL through the web interface and it says it is in the gripper(acc1,g1) ISMF shows the tape as VOLUME MISPLACED. Earlier it had VOLUME UNAVAILABLE. CA-1 shows SCRATCH. When a CA-1 CTSSYNC is run it gets an RC08 on this drive with the following error codes ERROR(S) SCRATCH 300761 REQUEST FAILED RC=012,RS=070,FB= CBR4195I LACS retry possible for job PRODJOB: 603 IEE763I NAME= CBRLLACS CODE= 140376 CBR4000I LACS WAIT permanent error for drive 0A0B. CBR4118I Library ATL0001 drive no longer available. IEE764I END OF CBR4195I RELATED MESSAGES *4569 CBR4196D Job PRODJOB, drive 0A0B, volser SCRTCH, error code 140376. Reply 'R' to retry or 'C' to cancel. *CBR3762E Library VTS0001 intervention required. *CBR3762E Library VTS0001 intervention required. *CBR3762E Library VTS0001 intervention required. *CBR3762E Library VTS0001 intervention required. CBR3776I Volume 300761 inaccessible in library ATL0001. *CBR3762E Library VTS0001 intervention required. *CBR3762E Library ATL0001 intervention required. CBR3751I Device 0A0B in library ATL0001 is unavailable. IEF880I 0A0B NOW OFFLINE BY OAM CBR3776I Volume 300761 inaccessible in library ATL0001. *CBR3762E Library ATL0001 intervention required. We have run the inventory a couple of times and not luck in spotting the errant tape. The Operators have opened up the ATL and manually scanned for the tape. So far it is missing in action. Any ideas where I can go next? The hardware support vendor says they did not remove any tapes when they came in and brought the drive back on line. And the only thing I know the vendor did was run an inventory and bring the A0B drive back online. Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help with Tape Hardware Issue TS3500
Drive, output bin, floor? In a message dated 10/18/2011 3:02:28 P.M. Central Daylight Time, stars...@mindspring.com writes: And the only thing I know the vendor did was run an inventory and bring the A0B drive back online. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
Do not use process(SYS1) w/o excluding the VVDS and the VTOCIX (Check the syntax, Done from memory). COPY DATASET(INCLUDE(**) EXCLUDE(SYS1.VTOCIX.VPROD06, SYS1.VVDS.PROD06) - ) - INDY( - (PROD06) - )- EXCLUDE(SYS1.VTOCIX.VPROD06 - SYS1.VVDS.PROD06) - ALLEXCP - ALLDATA(*) - ADMIN- CATALOG - DELETE - PROCESS(SYS1)- PURGE- SPHERE snip With PROG06 in DSNEW status, run: //ADRDSSU EXEC PGM=ADRDSSU,REGION=5M, // TIME=1439 ,PARM='TYPRUN=SCAN' //SYSPRINT DD SYSOUT=* //SYSINDD * COPY DATASET(INCLUDE(**)) - INDY( - (PROD06) - )- ALLEXCP - ALLDATA(*) - ADMIN- CATALOG - DELETE - PROCESS(SYS1)- PURGE- SPHERE Which will move everything it can off of PROD06 and keep it in the same SMS pool. Then determine why whatever is left wouldn't move, remove the inhibitor, and move it. When volume is empty, reinit. IMO, any of the other methods suggested include unneeded risk. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS SYSLOG observation / thought
John: I think, if my old cobwebby gray matter serves me here, we did that with the Message automation table in Netview.. Each message was tagged , so we knew who issued it. But they also came through the NetVSSI, which might have tagged them prior to hand off to the message table. BTW also on commands from SDSF nothing is there , he is my 1.10 test system (also have 1.11 and 1.12) NC000 ADCD 11291 16:08:00.75 SFORD 0290 D A,L MR000 ADCD 11291 16:08:00.76 SFORD 0090 IEE114I 16.08.00 2011.2 LR 618 0090 JOBS M/S TS USE LR 618 0090 2 00012 1 DR 618 0090 LLA LLA LLA DR 618 0090 VLF VLF VLF DR 618 0090 DLF DLF DLF DR 618 0090 INETD4 STEP1 OMVS DR 618 0090 SDSF SDSF SDSF DR 618 0090 TN3270 TN3270 TN32 DR 618 0090 PORTMAP PORTMAP PMAP ER 618 0090 SFORD IN Scott J Ford Software Engineer http://www.identityforge.com From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 18, 2011 1:29 PM Subject: z/OS SYSLOG observation / thought Columns 41 through 48 in the z/OS SYSLOG (formatted with a 4 digit year in columns 21-27) have various information in them. For many messages, it is the JES assigned number such as JOB12345. For a commands and command responses it appears to the be console name or for a MLWTO response the continuation number. For an S line it is blank because that means the line is a continuation of the above output line (N or S). But, for WTOs issued by started tasks which are running under the MSTR subsystem, it is blank instead of having the JES jobid (N lines, that is). So there's no way to know which task issued the message. I guess that most of the time, this doesn't really matter. But I was thinking, perhaps poorly, that where the JES jobid would be, wouldn't it be useful to have the ASID of the address space? Perhaps formatted as ASID where is the hex value of the ASID? I am wondering if one of the WTO exits could be used to implement this. I guess that I'll look and see. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help with Tape Hardware Issue TS3500
Thanks everyone. We looked high and low in the ATL. Nothing in the gripper, floor, bin, misplaced in the slots. We checked every tape in the ATL Frame (fortunately we are small @800 tapes). So I will have to keep pressing on and seeing if maybe the hardware support vendor put it somewhere we did not think about. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ATTLS configuration
I¹m attempting to enable ATTLS on my z/OS 1.12 and 1.9 systems for the
purpose of running secured NJE. I have installed the z/OS Configuration
Assistant to create the appropriate policies, created certificates on both
systems and placed them into the appropriate rings, and added the TCPCONFIG
TTLS statement.
According to the a SHARE presentation I then had to run some further RACF
commands using TCPIP.SEZAINST(EZARACF) as the starting point. It seems to me
that the order of statements in the job is strange (i.e. when doing the
INITSTACK stuff it refers to users defined further down in the job stream).
Also, I get the messages (below) from the EZARACF job. As far as I can tell
the ADDUSER syntax is correct so I'm not sure why it's complaining. Also, I
assume the REFRESH of RACLIST(SECLABEL) is failing because I've forgotten to
do something with SYSHIGH.
Has anyone gone through this process? If so, did you have a cheat sheet. The
SHARE presentation is good but it does state that it's skipped over some
steps for the sake of keeping the presentation within its time allocation.
ADDUSER NAMED DFLTGRP(OMVSGRP) OMVS(UID(0) HOME('/')) SECLABEL(SYSHIGH)
NOPASSWORD
IKJ56702I INVALID USERID, NAMED
IKJ56701I MISSING OMVS UID+
IKJ56701I MISSING OMVS USER ID (UID), 1-10 NUMERIC DIGITS
READY
PERMIT SYSHIGH CLASS(SECLABEL) ID(NAMED) ACC(READ)
READY
RDEFINE STARTED NAMED.* STDATA(USER(NAMED))
ICH10102I NAMED.* ALREADY DEFINED TO CLASS STARTED.
READY
SETROPTS RACLIST(STARTED) REFRESH
READY
SETROPTS GENERIC(STARTED) REFRESH
READY
SETROPTS RACLIST(SECLABEL) REFRESH
ICH14041I RACLIST REFRESH of class SECLABEL ignored. The class is not active
yet.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
Good point, thank you. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Staller, Allan Sent: Tuesday, October 18, 2011 2:03 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Do not use process(SYS1) w/o excluding the VVDS and the VTOCIX (Check the syntax, Done from memory). COPY DATASET(INCLUDE(**) EXCLUDE(SYS1.VTOCIX.VPROD06, SYS1.VVDS.PROD06) - ) - INDY( - (PROD06) - )- EXCLUDE(SYS1.VTOCIX.VPROD06 - SYS1.VVDS.PROD06) - ALLEXCP - ALLDATA(*) - ADMIN- CATALOG - DELETE - PROCESS(SYS1)- PURGE- SPHERE snip With PROG06 in DSNEW status, run: //ADRDSSU EXEC PGM=ADRDSSU,REGION=5M, // TIME=1439 ,PARM='TYPRUN=SCAN' //SYSPRINT DD SYSOUT=* //SYSINDD * COPY DATASET(INCLUDE(**)) - INDY( - (PROD06) - )- ALLEXCP - ALLDATA(*) - ADMIN- CATALOG - DELETE - PROCESS(SYS1)- PURGE- SPHERE Which will move everything it can off of PROD06 and keep it in the same SMS pool. Then determine why whatever is left wouldn't move, remove the inhibitor, and move it. When volume is empty, reinit. IMO, any of the other methods suggested include unneeded risk. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Chaos feared after UNIX time-zone database is nuked
John, I agree but it#39;s not so cut and dried. When you live and work in two different time zones. Chicago and Indiana (parts) are in two different zones. Friends of mine get their signals mixed at times. They have taken to always specify the local time which works well except the first week or so of daylight savings. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
Hi Esmie, If you take the all of the VSAM datasets off of the volume, you can delete the VVDS (I can send you the IDCAMS if you want) and allocate a new, bigger one on the same volume. Personally, I would not zap a VVDS. I know that some probably would, but not me , I wouldn't. I would stop new allocations. I would move off the data to another volume using a logical copy, not a physical copy - CA-Disk, FDRDSF, DSS . I recommend taking a look at the size of the VTOC and the VTOC index as well. Since the VVDS is too small the others are likely to be too small too. The VVDS should be cleaned out before and deleted BEFORE you re-init the volume. I can help you with the VVDS clean out, if you want. I have done many of them. Do you have QuickRef? Its DASD free space panel will show you the percentage of free space in the VTOC and index. It works with single volume, SMS pool, or volser pattern. It's an easy way to check a bunch of volumes. Having one volume with a too small VVDS sug gests that there are probably more out there. Folks often take the defaults and new folks often code sizes according to the way it is in the book. The more datasets that may be assigned to a volume, the bigger VTOC, VTOC index and VVDS will be needed. It is better to have all three generously sized rather than too small. HTH, Linda From: esmie moo esmie_...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 18, 2011 3:48:23 AM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Linda, I did what you asked. I ran the report and moved 90 dsns from the volume, however the problem still persists. I was told to check OEM option to ZAP the VVDS. I would like to try that out but I am not sure where I should look for it. From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Monday, October 17, 2011 4:06:12 PM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Hi Esmie, If you want to get a look at the contents of the VVDS, you can run this - //STEP1 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * PRINT - INDATASET(SYS1.VVDS.Vvolser) - COUNT(1) It should shed some light on what has filled it up. HTH, Linda - Original Message - From: esmie moo esmie_...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Monday, October 17, 2011 11:59:24 AM Subject: IEC331I 050-030(VVDSFULL, PROD06) Good Afternoon Gentle Readers I am trying to trouble shoot the following problem : IEC331I 050-030(VVDSFULL, PROD06) According to the message error explanation it says that the VVDS is full. When I check via ISPF 3.4 is shows that it is a 1 ext. The VVDS was built at TRACKS(30 1). To fix the problem the doc says to move dsns off that volume. I tried that but the problem persists when the system is trying to allocate a dsn on the volume. Since the volume is SMS managed (phew), I put it at DISNEW. The doc says to backup the volume, and reinitialize it with a larger VVDS. Is there something else I can try before I try the doc's recommendation? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
If it's SMS, the VVDS has data for non-VSAM also. I agree with you. Stop new allocations (DISNEW), Carefully move everything (make take several passes), when it's empty, re-init it and allocate a sufficiently large VVDS on it. I still always allocate a VVDS right after I init a new volume. I do not let the automatic allocation happen. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Tuesday, October 18, 2011 3:42 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Hi Esmie, If you take the all of the VSAM datasets off of the volume, you can delete the VVDS (I can send you the IDCAMS if you want) and allocate a new, bigger one on the same volume. Personally, I would not zap a VVDS. I know that some probably would, but not me , I wouldn't. I would stop new allocations. I would move off the data to another volume using a logical copy, not a physical copy - CA-Disk, FDRDSF, DSS . I recommend taking a look at the size of the VTOC and the VTOC index as well. Since the VVDS is too small the others are likely to be too small too. The VVDS should be cleaned out before and deleted BEFORE you re-init the volume. I can help you with the VVDS clean out, if you want. I have done many of them. Do you have QuickRef? Its DASD free space panel will show you the percentage of free space in the VTOC and index. It works with single volume, SMS pool, or volser pattern. It's an easy way to check a bunch of volumes. Having one volume with a too small VVDS sug gests that there are probably more out there. Folks often take the defaults and new folks often code sizes according to the way it is in the book. The more datasets that may be assigned to a volume, the bigger VTOC, VTOC index and VVDS will be needed. It is better to have all three generously sized rather than too small. HTH, Linda From: esmie moo esmie_...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 18, 2011 3:48:23 AM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Linda, I did what you asked. I ran the report and moved 90 dsns from the volume, however the problem still persists. I was told to check OEM option to ZAP the VVDS. I would like to try that out but I am not sure where I should look for it. From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Monday, October 17, 2011 4:06:12 PM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Hi Esmie, If you want to get a look at the contents of the VVDS, you can run this - //STEP1 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * PRINT - INDATASET(SYS1.VVDS.Vvolser) - COUNT(1) It should shed some light on what has filled it up. HTH, Linda - Original Message - From: esmie moo esmie_...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Monday, October 17, 2011 11:59:24 AM Subject: IEC331I 050-030(VVDSFULL, PROD06) Good Afternoon Gentle Readers I am trying to trouble shoot the following problem : IEC331I 050- 030(VVDSFULL, PROD06) According to the message error explanation it says that the VVDS is full. When I check via ISPF 3.4 is shows that it is a 1 ext. The VVDS was built at TRACKS(30 1). To fix the problem the doc says to move dsns off that volume. I tried that but the problem persists when the system is trying to allocate a dsn on the volume. Since the volume is SMS managed (phew), I put it at DISNEW. The doc says to backup the volume, and reinitialize it with a larger VVDS. Is there something else I can try before I try the doc's recommendation? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at
Re: IEC331I 050-030(VVDSFULL, PROD06)
Allan I sort of agree but I would never ever use process sys1 unless I would knowingly have specific datasets in mind. In the past it#39;s been burned into the process to know exactly what is going to happen. If memory serves me there is a parm on DFDSS to show what it#39;s going to do. I use that to test DFDSS what exactly is going to do. With other products I never had an issue but with DFDSS it always surprised me (grumble). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ATTLS configuration
Neale,
A couple things here, does NAMED exist ? secondly does SECLABEL exist..
Scott J Ford
Software Engineer
http://www.identityforge.com
From: Neale Ferguson ne...@sinenomine.net
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, October 18, 2011 5:37 PM
Subject: ATTLS configuration
I¹m attempting to enable ATTLS on my z/OS 1.12 and 1.9 systems for the
purpose of running secured NJE. I have installed the z/OS Configuration
Assistant to create the appropriate policies, created certificates on both
systems and placed them into the appropriate rings, and added the TCPCONFIG
TTLS statement.
According to the a SHARE presentation I then had to run some further RACF
commands using TCPIP.SEZAINST(EZARACF) as the starting point. It seems to me
that the order of statements in the job is strange (i.e. when doing the
INITSTACK stuff it refers to users defined further down in the job stream).
Also, I get the messages (below) from the EZARACF job. As far as I can tell
the ADDUSER syntax is correct so I'm not sure why it's complaining. Also, I
assume the REFRESH of RACLIST(SECLABEL) is failing because I've forgotten to
do something with SYSHIGH.
Has anyone gone through this process? If so, did you have a cheat sheet. The
SHARE presentation is good but it does state that it's skipped over some
steps for the sake of keeping the presentation within its time allocation.
ADDUSER NAMED DFLTGRP(OMVSGRP) OMVS(UID(0) HOME('/')) SECLABEL(SYSHIGH)
NOPASSWORD
IKJ56702I INVALID USERID, NAMED
IKJ56701I MISSING OMVS UID+
IKJ56701I MISSING OMVS USER ID (UID), 1-10 NUMERIC DIGITS
READY
PERMIT SYSHIGH CLASS(SECLABEL) ID(NAMED) ACC(READ)
READY
RDEFINE STARTED NAMED.* STDATA(USER(NAMED))
ICH10102I NAMED.* ALREADY DEFINED TO CLASS STARTED.
READY
SETROPTS RACLIST(STARTED) REFRESH
READY
SETROPTS GENERIC(STARTED) REFRESH
READY
SETROPTS RACLIST(SECLABEL) REFRESH
ICH14041I RACLIST REFRESH of class SECLABEL ignored. The class is not active
yet.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC331I 050-030(VVDSFULL, PROD06)
Hi Dave, Yes, thanks for the catch on the SMS vol. Esmie did say that the vol was managed. And I agree. I allocate my own generously sized VVDS at the time I init the pack - with a generously sized VTOC and index too. :) The VVDS needs to be removed before re-initing the pack. Otherwise, the catalog entry for the VVDS itself gets left hanging. IDCAMS print, delete noscratch each of the catalog entries in it, delete on the the last. Linda - Original Message - From: Dave Gibney gib...@wsu.edu To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 18, 2011 3:47:25 PM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) If it's SMS, the VVDS has data for non-VSAM also. I agree with you. Stop new allocations (DISNEW), Carefully move everything (make take several passes), when it's empty, re-init it and allocate a sufficiently large VVDS on it. I still always allocate a VVDS right after I init a new volume. I do not let the automatic allocation happen. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Tuesday, October 18, 2011 3:42 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Hi Esmie, If you take the all of the VSAM datasets off of the volume, you can delete the VVDS (I can send you the IDCAMS if you want) and allocate a new, bigger one on the same volume. Personally, I would not zap a VVDS. I know that some probably would, but not me , I wouldn't. I would stop new allocations. I would move off the data to another volume using a logical copy, not a physical copy - CA-Disk, FDRDSF, DSS . I recommend taking a look at the size of the VTOC and the VTOC index as well. Since the VVDS is too small the others are likely to be too small too. The VVDS should be cleaned out before and deleted BEFORE you re-init the volume. I can help you with the VVDS clean out, if you want. I have done many of them. Do you have QuickRef? Its DASD free space panel will show you the percentage of free space in the VTOC and index. It works with single volume, SMS pool, or volser pattern. It's an easy way to check a bunch of volumes. Having one volume with a too small VVDS sug gests that there are probably more out there. Folks often take the defaults and new folks often code sizes according to the way it is in the book. The more datasets that may be assigned to a volume, the bigger VTOC, VTOC index and VVDS will be needed. It is better to have all three generously sized rather than too small. HTH, Linda From: esmie moo esmie_...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 18, 2011 3:48:23 AM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Linda, I did what you asked. I ran the report and moved 90 dsns from the volume, however the problem still persists. I was told to check OEM option to ZAP the VVDS. I would like to try that out but I am not sure where I should look for it. From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Monday, October 17, 2011 4:06:12 PM Subject: Re: IEC331I 050-030(VVDSFULL, PROD06) Hi Esmie, If you want to get a look at the contents of the VVDS, you can run this - //STEP1 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * PRINT - INDATASET(SYS1.VVDS.Vvolser) - COUNT(1) It should shed some light on what has filled it up. HTH, Linda - Original Message - From: esmie moo esmie_...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Monday, October 17, 2011 11:59:24 AM Subject: IEC331I 050-030(VVDSFULL, PROD06) Good Afternoon Gentle Readers I am trying to trouble shoot the following problem : IEC331I 050- 030(VVDSFULL, PROD06) According to the message error explanation it says that the VVDS is full. When I check via ISPF 3.4 is shows that it is a 1 ext. The VVDS was built at TRACKS(30 1). To fix the problem the doc says to move dsns off that volume. I tried that but the problem persists when the system is trying to allocate a dsn on the volume. Since the volume is SMS managed (phew), I put it at DISNEW. The doc says to backup the volume, and reinitialize it with a larger VVDS. Is there something else I can try before I try the doc's recommendation? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html --
Re: maxsystem in a sysplex - belated heads-up
I have two sysplexes with one or two members not currently running. None show up with D XCF,S,ALL . What I see is lots of detail about the one member that is running. Nothing about the others. Skip, thanks for testing that for me. Just as I figured - there isn't really an easy way to find out *what* junk might have accumulated in the sysplex CDS over the years. On the other hand, a D XCF,CPL would faithfully show an ARM CDS that hasn't been around for years, and that isn't used. (Unless that has been silently fixed since we experienced it.) What a mess. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
