ARM contention
Hello Experts, In of my Sandbox system, we had a situation where ARM held the TCPIP address space. Due to which OSA got deactivated and I had to recycle. Is there a way to prevent this situation in future. Apology, I couldn't capture the error message. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ARM contention
Have you reviewed SYSLOG or the HMC? Have you looked at LOGREC? Did you do an SVC dump (any will do)? Without knowing the chain of events, it is hard to understand what occurred. If you still have the syslog from then, or the Logrec, or any SVC DUMP, you can try to piece together the events that lead to this issue. A good practice is to always take an SVC or SAD dump before starting recovery steps. Especially if you want to do troubleshooting later. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Saturday, February 08, 2014 3:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ARM contention Hello Experts, In of my Sandbox system, we had a situation where ARM held the TCPIP address space. Due to which OSA got deactivated and I had to recycle. Is there a way to prevent this situation in future. Apology, I couldn't capture the error message. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM Data Access (and SYSB-II)
John McKown writes: But it does not refute the z/OS is hard to get data out of thoughts because it induces the see, if data access on z/OS were easy, we'd have access to _current_ data and not need to be doing all this data duplication into an easy to access system like MS SQL Server. As I suspect you're already aware, there are many industry standard ways to access current, live VSAM data from arbitrary desktop tool X and/or application server Y. Unfortunately none of those methods are available in combination with infinite organizational inertia. I'm not a miracle worker. :-) Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex Common Time Source
Shane opines: Bloody typical. I posit that my reply was detailed, helpful, truthful, and complete. I'll leave it at that. Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Automating SAD
Hello Group, We have been taking a z/OS SAD to a dasd in our shop and it is also little time consuming since the LPAR in a wait state has to wait for re-ipl until the SAD process completes. I have been reading through : http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.e0zk100%2Fiplsad.htm Just curious about other Shop practise. How is the SAD completion time is reduced ? Could someone throw light on the best practices or some efficient process followed at your shops. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automating SAD
Jake, What verion(s) of z/OS are you working with? It would help to know what level you are asking about Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Saturday, February 08, 2014 7:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Automating SAD Hello Group, We have been taking a z/OS SAD to a dasd in our shop and it is also little time consuming since the LPAR in a wait state has to wait for re-ipl until the SAD process completes. I have been reading through : http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r 13.e 0zk100%2Fiplsad.htm Just curious about other Shop practise. How is the SAD completion time is reduced ? Could someone throw light on the best practices or some efficient process followed at your shops. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automating SAD
On 2/8/2014 6:31 AM, Jake anderson wrote: Could someone throw light on the best practices or some efficient process followed at your shops. My advice is to use multiple DASD data sets to get as much parallel I/O as possible. Also, human interaction is responsible for tremendous delays. Eliminate as many prompts as possible and use AUTOIPL in DIAGxx to make it all happen automagically. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex Common Time Source
On Sat, 8 Feb 2014 20:27:09 +0800, Timothy Sipples sipp...@sg.ibm.com wrote: Shane opines: Bloody typical. I posit that my reply was detailed, helpful, truthful, and complete. I'll leave it at that. Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com Reminds me of an old joke, (of which there are several variations)::-) A small, 14-seat plane is circling for a landing in Atlanta. It's totally fogged in, zero visibility, and suddenly there's a small electrical fire in the cockpit which disables all of the instruments and the radio. The pilot continues circling, totally lost, when suddenly he finds himself flying next to a tall office building. He rolls down the window (this particular airplane happens to have roll-down windows) and yells to a person inside the building, Where are we? The person responds In an airplane! The pilot then banks sharply to the right, circles twice, and makes a perfect landing at Atlanta International. As the passengers emerge, shaken but unhurt, one of them says to the pilot, I'm certainly glad you were able to land safely, but I don't understand how the response you got was any use. Simple, responded the pilot. I got an answer that was completely accurate and totally irrelevant to my problem, so I knew it had to be the IBM building. -- Dale R. Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSB-II
On Fri, 7 Feb 2014 07:17:54 -0600, John McKown john.archie.mck...@gmail.com wrote: The problem with data access here is that _all_ our data is stored in VSAM KSDS data sets. As opposed to, say, Windows where it is on MS-SQL Server and Oracle databases. So every time the users want a data extract, they must request that a program be written and then run. The resulting extract file must then be downloaded so that the data can be put in the proper place. Either in an SQL database, or maybe the user can use it directly. This makes ad hoc requests very difficult compared to just developing an SQL SELECT which can not only retrieve data, but also do some aggregation. Or can be integrated into an .NET program which the person, or a developer, can write faster than we can get a new COBOL program written and run. This thanks to the fact that z/OS has _good_ change control which is _enforced_. I don't know how they do Windows development. But, in any case, writing COBOL using ISPF in a compile/run/debug loop is much slower than using a Windows IDE. No, we won't get RD/z. Too expensive. John McKown John, I'm sure part of the reason your company wouldn't convert to DB2 is the amount of changes that would be required to the COBOL programs, (as well as spending money on an obsolete platform :-) ). There is a relatively new product from IBM called CICS VSAM Transparency. From the announcement letter: CICS VSAM Transparency (CICS VT) for z/OS, V2.1 enables the migration of data from VSAM files to DB2 tables. It ensures continued access to the data in DB2, without modification to the CICS or batch VSAM application programs and with only minor changes to CICS and batch configurations, and job control (using JCL). It claims that you can convert VSAM to DB2 without having to make any program changes, (just CICS Region changes and Batch JCL changes). This would obviously make the data available for SQL queries and allow COBOL programs to be changed in a controlled manner from using VSAM to directly calling DB2. After all programs/regions/JCL were converted to DB2, CICS VSAM Transparency could be removed, (SYSB II would no longer be required also). Just thought I would mention it in case someone else is looking for a solution to VSAMs lack of sharing and access from non-mainframe systems. If anyone needs more information, GIYF. -- Dale R. Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Implicit VVDS creation
Aside from the how of creating your own VVDS, I'm concerned about the why. OK, if an existing VVDS fills up, that's a why. Otherwise, you might consider creating your own VVDS at the outset if the default size or location is likely not appropriate for the volume. For example, a huge volume like a Mod-54 or any that will likely hold a myriad of small data sets might well need a larger VVDS. OTOH a volume for JES, page, or XCF data sets will likely never need more than a minuscule VVDS. As for location, in a distant galaxy long ago, SLED DASD liked VTOC and VVDS (did that exist then?) located in the middle of the volume to minimize head movement. (Nod if you agree.) That practice no longer makes sense in the era of RAID, so generally aim for the lowest address possible. Especially for JES and page volumes, location or size of VTOC and VVDS can reduce the usable space for very large single-extent data sets. In these cases, very small VTOC and VVDS (if needed) should be scrunched into the first few tracks. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Cosby, Bob - OCFO bob.co...@nfc.usda.gov To: IBM-MAIN@LISTSERV.UA.EDU, Date: 02/07/2014 11:04 AM Subject:Re: Implicit VVDS creation Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Just ran into a situation where the VVDS was filling up; 10,10 was not working. Our DBMB group was installing DB2 V10 which has to be SMS managed and were placing hundred of DSNs on one mod-3. So I INIT'ed them as INIT UNIT(560D) VOLID(DBJ555) VTOC(1,0,60) VFY(TS560D) - INDEX(0,1,14) STGR -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, February 06, 2014 12:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re:group Implicit VVDS creation Yes. step1 is ICKDSF. Step2 creates VVDS. On Thu, Feb 6, 2014 at 11:22 AM, David G. Schlecht dschle...@admin.nv.govwrote: Does anyone still build VVDS datasets explicitly when initializing volumes? I understand that the default allocation for a new VVDS is CYLS(10 10) which saves me from having to rebuild the VVDS if it fills up. What is everyone else doing with VVDS datasets? Is there still a valid argument for building them explicitly? David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSB-II
Two reasons we don't get DB2. 1. It costs money. 2. I.T. management despises z/OS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Implicit VVDS creation
As for location, in a distant galaxy long ago, SLED DASD liked VTOC and VVDS (did that exist then?) located in the middle of the volume to minimize head movement. (Nod if you agree.) That pra It stopped nattering long before RAID came out. 3380-K was when IBM stopped recommending it. Sent from my BlackBerry 10 smartphone on the Bell network. Original Message From: Skip Robinson Sent: Saturday, February 8, 2014 14:12 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Implicit VVDS creation Aside from the how of creating your own VVDS, I'm concerned about the why. OK, if an existing VVDS fills up, that's a why. Otherwise, you might consider creating your own VVDS at the outset if the default size or location is likely not appropriate for the volume. For example, a huge volume like a Mod-54 or any that will likely hold a myriad of small data sets might well need a larger VVDS. OTOH a volume for JES, page, or XCF data sets will likely never need more than a minuscule VVDS. As for location, in a distant galaxy long ago, SLED DASD liked VTOC and VVDS (did that exist then?) located in the middle of the volume to minimize head movement. (Nod if you agree.) That practice no longer makes sense in the era of RAID, so generally aim for the lowest address possible. Especially for JES and page volumes, location or size of VTOC and VVDS can reduce the usable space for very large single-extent data sets. In these cases, very small VTOC and VVDS (if needed) should be scrunched into the first few tracks. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Cosby, Bob - OCFO bob.co...@nfc.usda.gov To: IBM-MAIN@LISTSERV.UA.EDU, Date: 02/07/2014 11:04 AM Subject: Re: Implicit VVDS creation Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Just ran into a situation where the VVDS was filling up; 10,10 was not working. Our DBMB group was installing DB2 V10 which has to be SMS managed and were placing hundred of DSNs on one mod-3. So I INIT'ed them as INIT UNIT(560D) VOLID(DBJ555) VTOC(1,0,60) VFY(TS560D) - INDEX(0,1,14) STGR -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, February 06, 2014 12:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re:group Implicit VVDS creation Yes. step1 is ICKDSF. Step2 creates VVDS. On Thu, Feb 6, 2014 at 11:22 AM, David G. Schlecht dschle...@admin.nv.govwrote: Does anyone still build VVDS datasets explicitly when initializing volumes? I understand that the default allocation for a new VVDS is CYLS(10 10) which saves me from having to rebuild the VVDS if it fills up. What is everyone else doing with VVDS datasets? Is there still a valid argument for building them explicitly? David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
