Diagnosing VTOC error
Hello Group, I have few volumes while browsing it via ISPF 3.4 interface it shows VTOC error. I don't have a deep knowledge on storage side but any pointers to diagnose would really help me in referring some manuals or links. Any Advises or pointers would be really appreciated much. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Diagnosing VTOC error
One or more presses on PF1 will give more detailed information. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Friday, November 16, 2012 11:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Diagnosing VTOC error Hello Group, I have few volumes while browsing it via ISPF 3.4 interface it shows VTOC error. I don't have a deep knowledge on storage side but any pointers to diagnose would really help me in referring some manuals or links. Any Advises or pointers would be really appreciated much. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Diagnosing VTOC error
Hi, Sorry I didnt not post the PF1 result. It shows like OBTAIN return code = '12' Jake On Fri, Nov 16, 2012 at 4:00 PM, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: One or more presses on PF1 will give more detailed information. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Friday, November 16, 2012 11:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Diagnosing VTOC error Hello Group, I have few volumes while browsing it via ISPF 3.4 interface it shows VTOC error. I don't have a deep knowledge on storage side but any pointers to diagnose would really help me in referring some manuals or links. Any Advises or pointers would be really appreciated much. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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...@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
Re: Diagnosing VTOC error
Feeding this message to Google returns: 12(X'0C'): A permanent I/O error was encountered or an unexpected error return code was received from CVAF. Is there something in SYSLOG? Maybe your VTOC index is disabled? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Friday, November 16, 2012 11:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Diagnosing VTOC error Hi, Sorry I didnt not post the PF1 result. It shows like OBTAIN return code = '12' Jake On Fri, Nov 16, 2012 at 4:00 PM, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: One or more presses on PF1 will give more detailed information. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Friday, November 16, 2012 11:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Diagnosing VTOC error Hello Group, I have few volumes while browsing it via ISPF 3.4 interface it shows VTOC error. I don't have a deep knowledge on storage side but any pointers to diagnose would really help me in referring some manuals or links. Any Advises or pointers would be really appreciated much. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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...@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 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SRB Again
Wayne Driscoll's responses were all on target. What am I confused about is why you thought you needed wait/post, particularly since the interface provides no way for you to identify the ECB. I read somewhere that storage reference by an SRB had to be in common storage. I surely hope this was not in IBM documentation. It is certainly untrue. (I thought the task recovery routines would create a dump but they didn’t) If your recovery routine got control and asked for a dump, then a dump would be created. So one quickly concludes that your recovery routine did not get control. SRB to task percolation of abends does not apply to a SYNCH=YES SRB since the completion status of the SRB can be ascertained from the available IEAMSCHD keywords. Your example and FRR show you are coding for a non-reentrant program. While not intrinsically a problem, certainly atypical. RETREGS=YES,FRESDWA=YES, The first is unnecessary (and has no effect) for an FRR. The second is simply not applicable to an FRR. DUMP=YES This has no effect for an SRB (it applies only to ESTAE-type recovery) SDATA=(NOSQA,RGN,CSA) A dump without SQA is unlikely to be helpful (and possibly not even readable). Much of the data needed to analyze a dump is in SQA (such as the ASCB/ASSB). Similarly a dump without LSQA is unlikely to be helpful (you'll probably find that your site has set things up so that dumps automatically get SQA and possibly LSQA. I don't know if your NOSQA would override that. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS terminated abruptly caused an outage
I would imagine that it is precisely because it is unexpected that it is somewhat unlikely it is related to anything you did unless you ran some program that has an error that overlaid some key storage. The dump will indicate what truly was unexpected. That is about as much as can be said. I dont see anything as such in LOGREC Really? if there was a dump, unless taken out of mainline, there almost certainly would have been a logrec entry that corresponded to the recovery entry. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TRKFMT problem
Hi all I tried use TRKFMT option to erase volume. I used this options: ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0 TIME: 09:13:25 TRKFMT UNITADDRESS(7640) VERIFY(PU7640) - ERASEDATA - FROMRANGE(10,0) TORANGE(1000,0) ICK00700I DEVICE INFORMATION FOR 7640 IS CURRENTLY AS FOLLOWS: PHYSICAL DEVICE = 3390 STORAGE CONTROLLER = 2105 STORAGE CONTROL DESCRIPTOR = E8 DEVICE DESCRIPTOR = 0C ADDITIONAL DEVICE INFORMATION = 4835 TRKS/CYL = 15, # PRIMARY CYLS = 10017 ICK04000I DEVICE IS IN SIMPLEX STATE ICK00091I 7640 NED= 2105. .EMC.06.00050482 everything works fine but if I change TORANGE(1000,0) to TORANGE(1500,0) everything works fine for a while and then my job has got wait state and nothing happens. I noticed that job works fine until it receives 137K EXCP for TORANGE(1500,0) and more cyls when it achieves 137K EXCP stops, so I have to cancel: STEPNAME PROCSTEPRC EXCP TRKFMT*S222 137K for TORANGE(1000,0) is OK: STEPNAME PROCSTEPRC EXCP TRKFMT 00 118K Could someone tell me what I am doing wrong ? Thank you very much in advance. -- Pozdrawiam/Best regards, Rafal Hanzel Programista systemowy, Dział Badań i Rozwoju Systemów Komputerowych Zakład Elektronicznej Techniki Obliczeniowej w Katowicach Spółka z o.o. 40-158 Katowice, ul. Owocowa 1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Thursday, November 15, 2012 5:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: New way to do UCB lookups ... I'm curious about the purported risk of a 'moving device'. In order to make a significant change to a device--especially UCB address--the volume has to be offline or else the dynamic ACTIVATE fails. There is a way, and it's not very difficult, of doing I/O to an offline device. The device has to have been varied offline but not yet have all of its channel paths varied offline. If there is at least one connected path remaining to a device, then authorized code can do I/O to it. Code like this probably should serialize on the appropriate resource before doing its I/O to an offline device. At least the UCB should be PINned before trying to do the I/O. However, some programmers seem to think that the probability of having the last path varied out from under an I/O request is so remote that the need to serialize is ignored in order to get the code working faster. I am not one who thinks so, as I have seen it happen to my code. Yes, there is some overhead in PINning the UCB. There is also a huge headache waiting to happen if the UCB is not serialized by PINning and then the UCB is somehow changed, the device has its last online path varied offline, or the UCB is deleted, meaning its storage is FREEMAINed and possibly reused instantly by some other process needing a small piece of virtual storage. Sometimes this headache has caused a reIPL of a system. How much overhead does a reIPL cost the entire data center in order to save a fraction of a millisecond in order to serialize properly because the reIPL will probably not have to happen? Write the PIN and UNPIN code once, get it debugged, then encapsulate it in a simple macro so you don't have to look it up in the book each time you want to use it again. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
Sam Golob and I assess some risks differently. The American military in Iraq and Afghanistan have built elaborate protective screens well above their major buildings. These screens are designed to detonate mortar shells fired at the roofs of these buildings before they land on them. I have not elected to screen my own house in this way; equally, I have not reinforced its roof against purple cows falling from the sky; I have judged that these two risks are exiguous here in Massachusetts. If the house were in Kabul I should perhaps make a different judgment, at least about the mortar shells. All risk assessments are and must be situational. Consider now two dispatchables, T and U. If T attempts to traverse a list while U is updating it---adding an element to or deleting one from that list---two unfortunate events may well occur, are certain to occur in that long run in which we shall all be dead. The first is that T will traverse only a portion of the list uneventfully, and the second is that T will end up in storage that is not a part of the list, with ABEND the likely result. Serialization was invented to address this class of problems. We can make programs reentrant. Control blocks, on the other hand, are and will remain serially reusable. A minimal requirement for their integrity is that two dispatchables not access one of them concurrently. None of this is very controversial in general, but different people are all but certain to assess risks differently in different particular cases. My view is that we are dealing here with well understood risks that are entirely avoidable and that there is thus no excuse for incurring them. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
A minimal requirement for their integrity is that two dispatchables not access one of them concurrently. Absolutely. we are dealing here with well understood risks that are entirely avoidable and that there is thus no excuse for incurring them At a higher level no one has mentioned the risk of using an undocumented interface to do something for which documented services are available. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
On 16/11/2012 2:16 AM, Anne Lynn Wheeler wrote: IBM has z196 benchmark with peak of 2m IOPS with 104 FICON channels, 14 storage subsystems, and 14 system assist processors. It mentions that the 14 SAPs are capable of peak 2.2m SSCH/sec running at 100% cpu busy, but recommends SAPs run at 70% or less (i.e. 1.5m SSCH/sec). there is also a recent emulex announcement single fibre-channel for e5-2600 capable of over one millions IOPS (compared to z196 peak of 2m IOPS using 104 FICON channels) It's difficult for most mainframers to fathom commodity servers capable of doing that kind of I/O. In the Xeon E5 architecture Intel created a new technology called DDIO which substantially reduces I/O latencies so all of those dual/quad socket servers just chomp it all up without waiting to be fed. Throw in an emulex HBA and you're cooking with gas! The speeds and feeds are mighty impressive, the first 16GBs PCIe-3 implementation to hit the market. When you consider that the high-end POWER boxes and mainframes only got PCIe-2 last year it's interesting to see how it will evolve. One things for sure, the squatty boxes can do the I/O and with virtualization they may seem attractive to a lot of companies for a whole plethora of workloads. It's a clear and present danger to the high-end RISC boxes. It's still hard to imagine mainframe customers jumping ship anytime soon. New applications like high frequency trading will almost certainly be deployed on x86 platforms. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA Common services ENF Monitor reporting high CPU time
The reason the ENF/CICS APARs will have greater affect on regions running STGPROT=NO is that the SPKAs were being performed regardless of the current execution key. The ENF/CICS code needs to access its own control blocks which are allocated in key 8 storage so the SPKAs were being executed even if the transaction was already running in key 8. For transactions running USERKEY(9) in STGPROT=YES regions, the SPKA to key 8 still needs to be performed and performance monitoring tools such as the Strobe report noted above will show the same behavior as running without the ENF/CICS APARs. Rick Kazaks CA Technologies Principal Software Engineer CA Common Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
re: http://www.garlic.com/~lynn/2012o.html#25 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee attached is item from today I did in linkedin mainframe ... work I had done for channel extender in 1980 then also start to show up for fibre-channel in the late 80s. Then nearly 30yrs later (after the 1980 work), TCW does some similar stuff for FICON ... resulting in about three times improvement over original FICON ... and starting to come a little closer to the base fibre-channel in throughput. Part of the issue is that as bit transfer rate increases ... say go from about 16mbits/sec to 16gbits/sec ... a factor of thousand times ... w/o a corresponding increase in block size (say from 4kbyte to 4mbytes) ... transfer time per block decreases by a factor of thousand and end-to-end latency begins to play increasingly significant role. original 1988 fibre-channel started to address with totally asynchronous operation (between outgoing commands packages and returning results). the attached references both faster controller reduces channel busy and (implies) download channel packages as single operation to remote end as part of channel extender and latency compensation (reduce/eliminate number of end-to-end operations latency for commands and data transfer i.e. somewhat TCW implementation for FICON). a variation on the channel busy shows up with the extremely slow processor in the 3880 controller and 3090 channels. The 3880 channel busy time for disk operation was significantly larger than anticipated by the 3090 group ... to compensate they had to significantly increase the number of channels ... which added TCM and increased manufacturing costs (there were jokes about 3090 group billing the 3880 group for the increased 3090 manufacturing cost ... so it came out of 3880 profit margin, not 3090 profit margin). The significant increase in 3090 channels (to compensate for slow 3880 processor and high channel busy) contributed to the myth of all those channels contributing responsible for higher aggregate I/O throughput (they did, but not in the sense that marketing was trying to imply). from linkedin mainframe: thorton cray did the cdc6600 ... cray went on to found cray research and thorton went on to found network systems (along with a couple other cdc engineers) ... which produced HYPERChannel. In 1980, IBM's STL was bursting at the seams and they decided to move 300 from the IMS group to off-site building. The IMS group had tested remote 3270 support (back into STL datacenter) but found it totally unacceptable (they were use to vm/cms local channel attached 3270s ... significantly better than mvs 3270 of any kind). I got dragged into doing HYPERChannel channel-extender support utilizing collins digital radio microwave link. This turned out to provide 3270 response indistinguishable from what they were use to (and since the HYPERChannel A220 adapters had lower channel busy than 3270 controllers for identical operations, some of the STL datacenter 370/168s performance improved). This somewhat resulted in becoming the corporate HYPERChannel expert ... for both internal as well as customer installations. I got to go to Network Systems hdqtrs periodically and meet with their top people. Not long afterwards, the FE IMS support group in Boulder was being moved to a new building and were faced with similar options and also chose HYPERChannel channel extender. In that case, optical infrared modems were chosen situated on the roofs of the two buildings. There was some concern of signal loss during winter snow storms ... but the only significant case was small increase in bit-error rate during a white-out storm when employees weren't able to get into work. later I did the IBM TCP/IP product enhancements for RFC1044 support. The standard product got about 44kbytes/sec throughput using nearly full 3090 processor. In some tuning tests of RFC1044 support at Cray Research, I got sustained channel speed throughput between 4341 and Cray ... using only modest amount of 4341 processor (about 500 times improvement in the bytes moved per instruction executed). other past posts in this thread: http://www.garlic.com/~lynn/2012l.html#56 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#57 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#59 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#70 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#81 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#87 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#88 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#90 Blades
Re: Diagnosing VTOC error
The last time I experienced this it was because the VTOCIX dataset was corrupted. I think I fixed it by running ICKDSF with BUILDIX DDNAME(ddname) OSVTOC NOPURGE followed by BUILDIX DDNAME(ddname) IXVTOC :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Jake anderson :: Sent: Friday, November 16, 2012 2:23 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Diagnosing VTOC error :: :: Hello Group, :: :: I have few volumes while browsing it via ISPF 3.4 interface it shows :: VTOC :: error. I don't have a deep knowledge on storage side but any pointers :: to :: diagnose would really help me in referring some manuals or links. :: :: Any Advises or pointers would be really appreciated much. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Z196 and z/OS 1.4
But that was three years ago, and my memory isn't as sharp as it once was. Well, unless we are talking about dialog from Star Trek (The Original Series), or TV and radio commercial jingles from the 1960s. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY roflmao I represent that remark - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SVC ESRTABLE contents
I need to find out which entries in the user part of the TYPE-3 ESR (SVC 109) table are in use so that duplicate use can be avoided. Using SHOWZOS I have the following entries that are of interest two of my systems that run the program that uses SVC 109 ESR # 206. # EP DescType# EP Desc Type . . 52 819E565C -T3 53 85FA7910 P IDICSVCR T3 54 819E565C -T3 55 819E565C - T3 206 80D6D000 P IGX00206 T3207 819E565C - T3 208 819E565C -T3209 819E565C - T3 Numbers 52-55 are the highest in the IBM range and there are no higher numbers in use. I know what 206 represents and how it got there. What I would like to understand is what the entries for 207, 208 and 209 represent. The EP address is, I think, the IGXERROR entry point. since the same address is used in all the IBM part of the ESR TABLE (below 200) that do not have modules identified Could this mean that at some stage some routine has set up and used 207 - 209 then withdrawn the code and reset the EP address? If this is the case, then of course 207-209 have to be considered as 'in use' by 'something' until I can find out definitely what used them. I could not find modules IGX00207, IGX00208, or IGX00209 in LPA or LINKLIST. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SVC ESRTABLE contents
When choosing an SVC slot, I look for five in a row that all point to the same address. I then presume that address is IGCERROR, and I take one for my own use. That works for the SVC table. I've never investigated the ESR table. On Nov 16, 2012 2:29 PM, Anthony Fletcher flet...@nz1.ibm.com wrote: I need to find out which entries in the user part of the TYPE-3 ESR (SVC 109) table are in use so that duplicate use can be avoided. Using SHOWZOS I have the following entries that are of interest two of my systems that run the program that uses SVC 109 ESR # 206. # EP DescType# EP Desc Type . . 52 819E565C -T3 53 85FA7910 P IDICSVCR T3 54 819E565C -T3 55 819E565C - T3 206 80D6D000 P IGX00206 T3207 819E565C - T3 208 819E565C -T3209 819E565C - T3 Numbers 52-55 are the highest in the IBM range and there are no higher numbers in use. I know what 206 represents and how it got there. What I would like to understand is what the entries for 207, 208 and 209 represent. The EP address is, I think, the IGXERROR entry point. since the same address is used in all the IBM part of the ESR TABLE (below 200) that do not have modules identified Could this mean that at some stage some routine has set up and used 207 - 209 then withdrawn the code and reset the EP address? If this is the case, then of course 207-209 have to be considered as 'in use' by 'something' until I can find out definitely what used them. I could not find modules IGX00207, IGX00208, or IGX00209 in LPA or LINKLIST. -- 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
Re: SVC ESRTABLE contents
On Fri, 16 Nov 2012 13:28:02 -0600, Anthony Fletcher flet...@nz1.ibm.com wrote: I need to find out which entries in the user part of the TYPE-3 ESR (SVC 109) table are in use so that duplicate use can be avoided. Using SHOWZOS I have the following entries that are of interest two of my systems that run the program that uses SVC 109 ESR # 206. # EP DescType# EP Desc Type . . 52 819E565C -T3 53 85FA7910 P IDICSVCR T3 54 819E565C -T3 55 819E565C - T3 206 80D6D000 P IGX00206 T3207 819E565C - T3 208 819E565C -T3209 819E565C - T3 Numbers 52-55 are the highest in the IBM range and there are no higher numbers in use. I know what 206 represents and how it got there. What I would like to understand is what the entries for 207, 208 and 209 represent. The EP address is, I think, the IGXERROR entry point. since the same address is used in all the IBM part of the ESR TABLE (below 200) that do not have modules identified Could this mean that at some stage some routine has set up and used 207 - 209 then withdrawn the code and reset the EP address? If this is the case, then of course 207-209 have to be considered as 'in use' by 'something' until I can find out definitely what used them. I could not find modules IGX00207, IGX00208, or IGX00209 in LPA or LINKLIST. SHOWMVS seems to display many that aren't in use - but not all. I'd have to go through the code and find out why it decides to display those.I double checked with code I wrote for IPLINFO and MXI and I get the same results with both for those that are unused. Yes, if the address is IGXERROR it is not in use. At least that is how my code decides. 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
Saying that I running Sam's UCBLOOK or SHOWZOS in an unauthorized state, can be traversing one of these chains, encounter an element disappearing, and initiate an I/O or any other action which results in more than an abend of my SHOWMVS/UCBLOOK? Anything that actually could lead to something as drastic as an IPL? Surely such a failure of system integrity would be APARable. Even if the interface is not GUPI. Integrity is not enforced by documentation :) Although a screwdriver is generally preferred to drive a screw, there are times when expedience or need indicates a hammer will do the job adequately for the specific situation. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Shannon Sent: Friday, November 16, 2012 7:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: New way to do UCB lookups A minimal requirement for their integrity is that two dispatchables not access one of them concurrently. Absolutely. we are dealing here with well understood risks that are entirely avoidable and that there is thus no excuse for incurring them At a higher level no one has mentioned the risk of using an undocumented interface to do something for which documented services are available. Bob Shannon Rocket Software -- 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
Re: New way to do UCB lookups
Sam's code uses the official z/OS's UCB lookup table, so I don't think this code traverses any chain of control blocks. I would guess that it traverses the lookup table, whose location remains constant (unless an IODF change happens, perhaps) but possibly the contents of any given cell in the table might change. The contents of the cell would somehow be used to find the address of the UCB. To know exactly how the lookup table is used to look up the UCB address, see Sam's code (which I have not done). The reIPL I referred to happened in the mid-1980s, and may well have been due to an operator's panicking rather than any APAR-able design defect in MVS/XA. My code used the system service LSPACE to query a device without first having done anything to ensure that the device did not lose its last available channel path. LSPACE back then did 3 or 4 EXCPs sequentially to the device (interrogating the VTOC, mostly, as I remember). Somewhere in between two of these EXCPs the last path went away, then the next EXCP happened and device allocation got hung up (I don't remember the details). I was told that the only way the data center could regain the use of the device involved was to reIPL, which they did since they felt they needed the device. That was the beginning of my education in doing I/O to an offline device. I don't remember now if my code was running authorized or not. Like John Gilmore, I believe that one should always follow all the guidelines in IBM's documentation about serialization, environmental requirements (cross-address space, protect key, addressing mode, etc.), etc., unless the code is being used for one's own learning experience. And most especially if the code is being distributed in a commercial product or even as an unsupported sample program in the public domain. However, PINning a UCB is an authorized function, Sam's code runs unauthorized, so Sam's code cannot serialize on each UCB. I personally would rather use UCBLOOK to run through all the UCBs in any code that I expected to be taken seriously. But finding the ULUT and how to use it would certainly be a fun project (see learning experience above). IBM's UCBLOOK service obviously has some way of serializing properly. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, November 16, 2012 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: New way to do UCB lookups Saying that I running Sam's UCBLOOK or SHOWZOS in an unauthorized state, can be traversing one of these chains, encounter an element disappearing, and initiate an I/O or any other action which results in more than an abend of my SHOWMVS/UCBLOOK? Anything that actually could lead to something as drastic as an IPL? Surely such a failure of system integrity would be APARable. Even if the interface is not GUPI. Integrity is not enforced by documentation :) Although a screwdriver is generally preferred to drive a screw, there are times when expedience or need indicates a hammer will do the job adequately for the specific situation. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Shannon Sent: Friday, November 16, 2012 7:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: New way to do UCB lookups A minimal requirement for their integrity is that two dispatchables not access one of them concurrently. Absolutely. we are dealing here with well understood risks that are entirely avoidable and that there is thus no excuse for incurring them At a higher level no one has mentioned the risk of using an undocumented interface to do something for which documented services are available. Bob Shannon Rocket Software -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Diagnosing VTOC error
Hi Jake, Is this volume online to another lpar? Perhaps its vtoc was extended or clipped or the volume was re-initialized from the other lpar? I have seen the obtain error in these circumstances. You could vary off/on from the lpar where you are seeing the obtain error or you can run ickdsf refvtoc. HTH, Linda Sent from my iPhone On Nov 16, 2012, at 2:37 AM, Jake anderson justmainfra...@gmail.com wrote: Hi, Sorry I didnt not post the PF1 result. It shows like OBTAIN return code = '12' Jake On Fri, Nov 16, 2012 at 4:00 PM, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: One or more presses on PF1 will give more detailed information. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Friday, November 16, 2012 11:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Diagnosing VTOC error Hello Group, I have few volumes while browsing it via ISPF 3.4 interface it shows VTOC error. I don't have a deep knowledge on storage side but any pointers to diagnose would really help me in referring some manuals or links. Any Advises or pointers would be really appreciated much. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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...@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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Which SMFDUMP program?
On Fri, 16 Nov 2012 14:55:05 -0600, Jeff Holst jeff.ho...@fiserv.com wrote: I was looking for the SMFDUMP program and thought I rememebered that it was on the CBT tape. And indeed it is. In fact, I found two versions of the program, in files 684 and 686. They appear to have the same origins, but the two programs are a bit different. The dates of last updates appear to be 2004 for 684 and 2006 for 686, should that make a difference to anyone. I have seen a number of references in the archives to the version in file 686. Is this considered to be the superior version? Jeff Holst I'm not going to look, but make sure one or both has this required change from OS/390 2.8 that I made to my version in 2000. WTO TEXT=(MSG1,MSG2),MF=(E,MSG007) ISSUE MSG WAS CHANGED TO: WTO TEXT=((MSG1,),(MSG2,)),MF=(E,MSG007) -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SVC ESRTABLE contents
What Bob didn't say there was that it is up to you to know which are used and which are available within the customer range. All ISV products that I know of allow you to tell them which routing number to use, even though the product may come with a default. Chris Blaicher Senior Software Engineer, Software Services Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Shannon Sent: Friday, November 16, 2012 3:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SVC ESRTABLE contents I need to find out which entries in the user part of the TYPE-3 ESR (SVC 109) table are in use so that duplicate use can be avoided. 200-255 are reserved for customers. I know this because I wrote the requirement which was accepted by IBM. Bob Shannon Rocket Software NFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-volume SMS file allocation
Jean Louis, I'm sorry if my advice led you astray. I know I had a solution for this many years ago, and it used to work fine for multi volume SAS datasets. I trying to find some time to do some testing to remind myself of how this worked. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DEBERT Jean-Louis Sent: Tuesday, November 13, 2012 11:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] multi-volume SMS file allocation Mike Schwab wrote: snip The DSORG=PS limits the dataset to the 64K Tracks, and goes to the next volume if the next extent would exceed that value. end snip Are you sure of that (that it would force a change of volume when exceeding 64k tracks or whatever the limit per volume is) ??? If true, yes, I could depend simply on secondary allocation, and not have the problem with RLSE on allocated-but-non-used primary extents. -- 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
Re: SVC ESRTABLE contents
What Bob didn't say there was that it is up to you to know which are used and which are available within the customer range. Yep. My bad. If you have MXI or a similar product from another vendor this is easy to see. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEAMBDLG and SYSLOGD
Why does IEAMBDLG skip OPERLOG entries created by USS? SYS1.SAMPLIVB(IEAMDBLG) - - - - - - - - - - - - - - - - - - 487 Line(s) not Displayed 046010 * $L2=DCRA990 HBB7730 050525 PDKX: Skip MDB if MDB has been sent * 046020 * from USS* - - - - - - - - - - - - - - - - - - - 56 Line(s) not Displayed 050300 * NOTG (a) Add support for USS Msg Integration to write @L2A* * Messages to operlog. @L2A* - - - - - - - - - - - - - - - - - - 774 Line(s) not Displayed 124310 TMMDBCMSC2,MDBCOPON Has MDB been sent from USS ?@L2A 124311 BOCOPYLOOPskip MDB if it is @L2A - - - - - - - - - - - - - - - - - - 1411 Line(s) not Displayed We are sending selected SYSLOGD records to /dev/operlog and SDSF displays the records just fine. However, IEAMDBLG does not copy them. I commented the two instructions and the records are copied fine. Is there some form of USS records that may cause a problem? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAMBDLG and SYSLOGD
Subject: IEAMBDLG and SYSLOGD Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Why does IEAMBDLG skip OPERLOG entries created by USS? SYS1.SAMPLIB(IEAMDBLG) - - - - - - - - - - - - - - - - - - 487 Line(s) notDisplayed 046010 * $L2=DCRA990 HBB7730 050525 PDKX: Skip MDB if MDB has been sent * 046020 * from USS * - - - - - - - - - - - - - - - - - - - 56 Line(s) notDisplayed 050300 * NOTG (a) Add support for USS Msg Integration to write @L2A* * Messages to operlog. @L2A* - - - - - - - - - - - - - - - - - - 774 Line(s) notDisplayed 124310 TMMDBCMSC2,MDBCOPON Has MDB been sent from USS? @L2A 124311 BOCOPYLOOPskip MDB if it is @L2A - - - - - - - - - - - - - - - - - - 1411 Line(s) notDisplayed We are sending selected SYSLOGD records to /dev/operlog and SDSF displays the records just fine. However, IEAMDBLG does not copy them. I commented the two instructions and the records are copied fine. Is there some form of USS records that may cause a problem? I don't know. The programmer (PDKX) identified by the change activity flagging is no longer in the IBM internal directory. It might be this person: http://www.linkedin.com/pub/akash-desai/5/681/683 Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
I don't quite understand this thread, but I find it interesting in that I'd like to understand it. Are you saying, that you can put some sort of lock on a control block, so that when you update it, you know that nobody else has updated it? I am not sure if this is apples and giraffes, but I wrote a Rexx exec and ISPF panel to show ASCB and related control blocks for a given job that shows all about timeouts. I hit the enter, and my Rexx and ISPF fields change accordingly. Sometimes I hit enter and see weird garbage in there. No matter. I just hit enter again and all is well. I assume the garbage in some of the fields is due to the control blocks being in some unknown state. But if I hit enter and see, for example, 5 things, and somebody updates and adds one or takes one away, then when I hit enter again, I'll see the updated list. I see how long I have to wait for a 522, or I see that the job is exempt from timeout. That won't change. If someone adds something new just a millisecond from when I look for it, how is that different from updating a database table? You might say to lock it for update. I may say that I want to read the row, then lock it and update it just if it is has changed. In that case I know if it has changed. I'm not trying to be smart, I only want to understand what is the real issue. The only thing I can think of is that if multiple control blocks are chained together, or somehow are related, that I don't want to read one while the other is updated. Can I read these control blocks with Rexx? If so, maybe I'll give it a go when I have some free moments. Kind regards, Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Tuesday, November 13, 2012 11:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: New way to do UCB lookups Jim Mulder's point is very well taken indeed. Traversing a dynamic list without serialization on the assumption that since you do not plan to change it no one else will is a mug's game. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Which SMFDUMP program?
Considering the year differences I would stick with the new one. One place I was at was using an old (we are talking 1990's) on that had a nasty bug. I had too much on my plate to go after the newer one (that fixed the bug). Since the problem only happened when the system was being z eod'd and either the operators were too slow to catch it or another slang term that I shouldn't use. If the date was say 2011 or there abouts I would probably use the one from 2006 unless the comments on what it fixed pertained to the latest release. Ed On Nov 16, 2012, at 3:00 PM, Mark Zelden wrote: On Fri, 16 Nov 2012 14:55:05 -0600, Jeff Holst jeff.ho...@fiserv.com wrote: I was looking for the SMFDUMP program and thought I rememebered that it was on the CBT tape. And indeed it is. In fact, I found two versions of the program, in files 684 and 686. They appear to have the same origins, but the two programs are a bit different. The dates of last updates appear to be 2004 for 684 and 2006 for 686, should that make a difference to anyone. I have seen a number of references in the archives to the version in file 686. Is this considered to be the superior version? Jeff Holst I'm not going to look, but make sure one or both has this required change from OS/390 2.8 that I made to my version in 2000. WTO TEXT=(MSG1,MSG2),MF=(E,MSG007) ISSUE MSG WAS CHANGED TO: WTO TEXT=((MSG1,),(MSG2,)),MF=(E,MSG007) -- 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...@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
