Re: Slow storage creep in SYSTEM.SYSSTC
In SYSTEM Service Class (for several customers) I think I'm seeing Master Scheduler being said to acquire more storage service over time. Not sure if this is what the OP meant by SYSSTC or not. (Probably not). In my case I suspect this is an anchor point for something Common or Shared above the Bar. Instrumentation I'm using is SMF 30 Interval (2,3) records. And I agree you can control what goes into SYSSTC and can define Report Classes to narrow the doubt if you don't have SMF 30(2,3) to work with. Actually for NON-SWAPPABLE address spaces a Report Class would be much more accurate for REAL storage usage. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Shane Ginnane ibm-m...@tpg.com.au To: IBM-MAIN@LISTSERV.UA.EDU Date: 27/05/2015 04:30 Subject:Re: Slow storage creep in SYSTEM.SYSSTC Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Tue, 26 May 2015 23:25:42 +, Gibney, David wrote: ... I neither have nor really can control what falls into SYSSTC. It's all z/OS. You can, and probably should at least look at some of your heavy hitters. Just tossing it out here for thought on identifying the guilty software? Grab a couple of (system) dumps a couple of weeks apart. Under IPCS run the VSMDATA with OWNCOMM SUMMARY. The Diag Reference has examples of what you'll get. You may be able to see from a quick eyeball where it's going. You can run a getmain/freemain trace, but you really don't want to go there. Running GTF for weeks, then trying to process the output just ain't funny. All else fails, flick me a return business class air ticket, and I'll come have a look. Washington can't be too bad this time of year ;-) Shane ... (all the above presumes you have the DIAGxx member set up already) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How do I display this storage in IPCS (zos/2.1)?
On Tue, 26 May 2015 17:52:20 -0400 Jim Mulder d10j...@us.ibm.com wrote: : From LISTDUMP : COMPDATA(IARHVSHR) : 0200_0010.:0200_00100FFF. :X'1000' bytes described in COMPDATA(IARHVSHR) :LIST 210. :If it is a stand-alone dump, you may need to specify an ASID which is :connected :to the shared memory object of interest. If it is an SVC dump, I think :the ASID :is not used. :LIST 210. COMPDATA(IARHVSHR) should also work. It is a SVC dump directed to a DCB - the current job has issued a .SHAREMEMOBJ and the storage area is included in LIST64. Dump options are SDUMPX DCB=OSVCDDCB, ECB=(@DUMPECB,WRITE), TYPE=FAILRC, LIST64=area, SDATA=(NODEFS,NOALLPSA,NOSQA,NOSUM) I was only able to display it with the COMPDATA keyword. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tailoring SVCDUMP (SDUMPX) on zos/2.1
On Tue, 26 May 2015 19:18:02 -0400 Jim Mulder d10j...@us.ibm.com wrote: :I am trying to issue a tailored SVC dump and am finding that there are :many :absolute storage records filling the dump - many more since zos/1.10 :I specify SDATA=(NODEFS,NOALLPSA,NOSQA) - what more do I need to specify? : How did you determine that there are many absolute storage records? Did :you :count the number of records whose dump record prefix starts with 'DR2 A .' Yes. Also do a LISTDUMP and found more than x'05--' (80M) bytes described in ABSOLUTE. USING SDUMPX directed to a DCB. By changing it to use LIST64 instead of SUMLIST64 and using SDATA=(,NOSUM) reduced the ABSOLUTE to about 28M. The issue is that I try to allocate the output dataset to the size I need (as it must be CONTIG) and found the amount of overhead storage went up quite a bit from zos1.10. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
Just a note - perhaps you haven't at your shop, but you can add to the SYSSTC service class. We put the systems programmers' TSO sessions there, for instance. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, David Allen,Jr Sent: Tuesday, May 26, 2015 6:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Slow storage creep in SYSTEM.SYSSTC We just had a zPCR study. There weren't any real surprises, but the Workload CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor really can control what falls into SYSSTC. It's all z/OS. I recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
Partly true, we have the same setup, but only for the 'standby userid'. It is very tempting for sysprogs to give themselves absolute performance, just because they can, not because they need it. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: 27 May, 2015 15:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow storage creep in SYSTEM.SYSSTC Sure. The sysprogs wanted to try and be sure they could get into the system in times of stress. We run a single LPAR on a machine with two processors, so CICS (our loved one) in a loop can monopolize one and leave the other struggling to service the remaining workloads. We didn't even bother with experimenting with a TSOHOT service class - we felt like we had enough service classes defined already. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, May 27, 2015 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow storage creep in SYSTEM.SYSSTC Greg Shirey wrote: We put the systems programmers' TSO sessions there, for instance. TSO sessions not at TSOHOT, TSOHI, TSOMD, TSOLOW, etc.? Hmmm? Just curious, if you don't mind please. -- 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: Slow storage creep in SYSTEM.SYSSTC
Sure. The sysprogs wanted to try and be sure they could get into the system in times of stress. We run a single LPAR on a machine with two processors, so CICS (our loved one) in a loop can monopolize one and leave the other struggling to service the remaining workloads. We didn't even bother with experimenting with a TSOHOT service class - we felt like we had enough service classes defined already. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, May 27, 2015 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow storage creep in SYSTEM.SYSSTC Greg Shirey wrote: We put the systems programmers' TSO sessions there, for instance. TSO sessions not at TSOHOT, TSOHI, TSOMD, TSOLOW, etc.? Hmmm? Just curious, if you don't mind please. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tailoring SVCDUMP (SDUMPX) on zos/2.1
I specify SDATA=(NODEFS,NOALLPSA,NOSQA) I'd have said that an SVC Dump without SQA is not worth taking. The IPCS processing isn't going to be able to access much of anything. You should probably consider using IEATDUMP. 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: Tailoring SVCDUMP (SDUMPX) on zos/2.1
On Wed, 27 May 2015 07:58:42 -0400 Peter Relson rel...@us.ibm.com wrote: :I specify SDATA=(NODEFS,NOALLPSA,NOSQA) :I'd have said that an SVC Dump without SQA is not worth taking. The IPCS :processing isn't going to be able to access much of anything. :You should probably consider using IEATDUMP. IEATDUMP does not support LIST64 Also, for my purposes, I do not need SQA - I need certain storage blocks. I have IPCS procedures to format what I want. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
There are some sidepaths take from this thread. Yes, you can add workload to SYSSTC, and you should have done so in the past according to recommendations. But this is not the point. Some task in SYSSTC has the creep. You can display the tasks in SYSSTC with the command D A,ALL. Look for SCL=SYSSTC in the display. Then you know which tasks to monitor. In CMF I can start a VSM monitor for selected tasks, I assume RMF can do the same. Run the VSM report weekly and you must be able to find the creep(er). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, David Allen,Jr Sent: 27 May, 2015 1:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Slow storage creep in SYSTEM.SYSSTC We just had a zPCR study. There weren't any real surprises, but the Workload CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor really can control what falls into SYSSTC. It's all z/OS. I recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? Dave Gibney Information Technology Services Washington State University -- 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: Slow storage creep in SYSTEM.SYSSTC
I wouldn't use a command but rather proper regular timestamped information - to get the behaviour. That would be 72-3 for suitably-coded report classes. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 27/05/2015 14:15 Subject:Re: Slow storage creep in SYSTEM.SYSSTC Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU There are some sidepaths take from this thread. Yes, you can add workload to SYSSTC, and you should have done so in the past according to recommendations. But this is not the point. Some task in SYSSTC has the creep. You can display the tasks in SYSSTC with the command D A,ALL. Look for SCL=SYSSTC in the display. Then you know which tasks to monitor. In CMF I can start a VSM monitor for selected tasks, I assume RMF can do the same. Run the VSM report weekly and you must be able to find the creep(er). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, David Allen,Jr Sent: 27 May, 2015 1:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Slow storage creep in SYSTEM.SYSSTC We just had a zPCR study. There weren't any real surprises, but the Workload CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor really can control what falls into SYSSTC. It's all z/OS. I recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? Dave Gibney Information Technology Services Washington State University -- 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
On Wed, 27 May 2015 13:51:23 +, Vernooij, CP wrote: It is very tempting for sysprogs to give themselves absolute performance, just because they can, not because they need it. True 'nuff. As I don't live in any site, I try to placate the troops. When I need to get in and fix things, I get my userid reset. If the ops can't get in and reset me, there are bigger problems. Seen that too of course Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
Still you are looking for the one task that has the creep and therefor you must go down to the details of each individual task. By displaying which tasks run in SYSSTC, you can limit the number of tasks to monitor. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: 27 May, 2015 15:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow storage creep in SYSTEM.SYSSTC I wouldn't use a command but rather proper regular timestamped information - to get the behaviour. That would be 72-3 for suitably-coded report classes. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 27/05/2015 14:15 Subject:Re: Slow storage creep in SYSTEM.SYSSTC Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU There are some sidepaths take from this thread. Yes, you can add workload to SYSSTC, and you should have done so in the past according to recommendations. But this is not the point. Some task in SYSSTC has the creep. You can display the tasks in SYSSTC with the command D A,ALL. Look for SCL=SYSSTC in the display. Then you know which tasks to monitor. In CMF I can start a VSM monitor for selected tasks, I assume RMF can do the same. Run the VSM report weekly and you must be able to find the creep(er). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, David Allen,Jr Sent: 27 May, 2015 1:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Slow storage creep in SYSTEM.SYSSTC We just had a zPCR study. There weren't any real surprises, but the Workload CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor really can control what falls into SYSSTC. It's all z/OS. I recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? Dave Gibney Information Technology Services Washington State University -- 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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
Re: Slow storage creep in SYSTEM.SYSSTC
Greg Shirey wrote: Sure. The sysprogs wanted to try and be sure they could get into the system in times of stress. We run a single LPAR on a machine with two processors, so CICS (our loved one) in a loop can monopolize one and leave the other struggling to service the remaining workloads. We didn't even bother with experimenting with a TSOHOT service class - we felt like we had enough service classes defined already. Thanks. Those loved CICS can get your system with two CPUs for dinner leaving you only with little crumbs to sit with... Your setup seemed realistic to me, thanks for telling. Much appreciated. Sorry, that I can't really contribute to this creeepy thread... ;-) I'll creep out of this thread for now... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
Greg Shirey wrote: Just a note - perhaps you haven't at your shop, but you can add to the SYSSTC service class. Good suggestion. We put the systems programmers' TSO sessions there, for instance. TSO sessions not at TSOHOT, TSOHI, TSOMD, TSOLOW, etc.? Hmmm? Just curious, if you don't mind please. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Check out 104,000 taxpayers have personal info stolen from IRS website - AOL.
_104,000 taxpayers have personal info stolen from IRS website - AOL.com_ (http://www.aol.com/article/2015/05/27/104-000-taxpayers-have-personal-info-st olen-from-irs-website/21187495/?icid=maing-grid7|htmlws-main-bb|dl5|sec1_lnk 2pLid=-830866890) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
Thanks for all the suggestions. I'll look for time to try some of them :) Wish I could just send a ticket Shane, is is fairly nice out there right now. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shane Ginnane Sent: Tuesday, May 26, 2015 8:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow storage creep in SYSTEM.SYSSTC On Tue, 26 May 2015 23:25:42 +, Gibney, David wrote: ... I neither have nor really can control what falls into SYSSTC. It's all z/OS. You can, and probably should at least look at some of your heavy hitters. Just tossing it out here for thought on identifying the guilty software? Grab a couple of (system) dumps a couple of weeks apart. Under IPCS run the VSMDATA with OWNCOMM SUMMARY. The Diag Reference has examples of what you'll get. You may be able to see from a quick eyeball where it's going. You can run a getmain/freemain trace, but you really don't want to go there. Running GTF for weeks, then trying to process the output just ain't funny. All else fails, flick me a return business class air ticket, and I'll come have a look. Washington can't be too bad this time of year ;-) Shane ... (all the above presumes you have the DIAGxx member set up already) -- 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: GENERATED STATEMENT!?
On Wed, 27 May 2015 12:41:36 -0400, David Betten wrote: I[s] there a blank line between SYSMS2 and LOGDD2 statements? I said: From: Paul Gilmartin Date: 05/27/2015 12:37 PM ... (I had no stray data cards.) On 2015-05-27 10:54, J O Skip Robinson wrote: I copy pasted the JCL into a real editor, i.e. ISPF, and noticed an oddity in this line: //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) There is no space between asterisk and ampersand. Could that be right? Yes. On 2015-05-27 10:56, Staller, Allan wrote: Appears to be a missing comma on statement 40 There is not. 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) s/b 40 //SYMS2 DD *,IFSYM,SYMBOLS=(EXECSYS,LOGDD2) ^ HTH, It doesn't On Wed, 27 May 2015 10:25:13 -0700, retired mainframer wrote: Submit the job in hold status and use SDSF to look at the data card(s) in the SYSIN member. Then find that data in the dataset you submitted and determine why it was not recognized as JCL. One common reason is that columns 1 and 2 do not contain // or /*. Even better, copied and pasted from SDSF SJ panel: ... 000172 //* 000173 // EXPORT SYMLIST=* 000174 // SET IFSYM='' (Blank for pre-JES2 2.1.) 000175 // SET SYMVAL='Symbol value longer than name.' 000176 //* 000177 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 000178 Try SYMVAL 000179 Preset LRECL with longer line . 000180 //LOGDD1DD SYSOUT=(,) 000181 //* 000182 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) 000183 Try SYMVAL 000184 Short line 000185 //LOGDD2DD SYSOUT=(,) 000186 //* 000187 // ... Do you see anything wrong? On Wed, 27 May 2015 12:14:42 -0500, John McKown wrote: ... We do this all the time ... Thank you for understanding JCL syntax better than most of the followups. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Debug tool conditional breakpoint in asm
Has Anyone had any success using conditional Break points with debug tool in assembler The following At 435 when(%R4- = 'MIKE') Lead me to believe stop 435 when the contents of Register 4 is equal to MIKE but the code seemed To stop at 435 every time Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tailoring SVCDUMP (SDUMPX) on zos/2.1
:I am trying to issue a tailored SVC dump and am finding that there are :many :absolute storage records filling the dump - many more since zos/1.10 :I specify SDATA=(NODEFS,NOALLPSA,NOSQA) - what more do I need to specify? : How did you determine that there are many absolute storage records? Did :you :count the number of records whose dump record prefix starts with 'DR2 A .' Yes. Also do a LISTDUMP and found more than x'05--' (80M) bytes described in ABSOLUTE. USING SDUMPX directed to a DCB. By changing it to use LIST64 instead of SUMLIST64 and using SDATA=(,NOSUM) reduced the ABSOLUTE to about 28M. The issue is that I try to allocate the output dataset to the size I need (as it must be CONTIG) and found the amount of overhead storage went up quite a bit from zos1.10. The DRPX for SD, SV, CV, and DS records can contain the absolute address of the storage as well as the virtual address. SDUMP has provided the absolute address since z/OS 1.8. For SVC dumps, IPCS maps both the virtual and absolute addresses. LISTDUMP is telling you the amount of storage which is mapped as absolute, which includes the storage which is mapped as both virtual and absolute. So this number will be larger than the amount of storage which was dumped as absolute records. You can do VERBX SUMDUMP to determine the reasons that various areas were included in the SUMDUMP. 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: z/OS Platform Software Products on ... Tape?
Same here, and no problems at all.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jousma, David
Sent: Wednesday, May 20, 2015 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Platform Software Products on ... Tape?
We've been doing ATTLS encrypted receive order's from IBM now for almost a
year. I don’t know how anyone can tamper with that? As for connecting our
mainframe systems to the outside world, we open a firewall connection as
needed, and the connection to IBM can only be established FROM our systems.
Cannot initiate the connection from the outside world coming in.
I feel pretty safe on both counts.
_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, May 20, 2015 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Platform Software Products on ... Tape?
On Mon, 11 May 2015 10:36:56 -0400, John Eells wrote:
If you are still using tape for z/OS platform software delivery (that
is, any product that runs on z/OS, not just z/OS itself), I'd like to
hear from you to understand:
- Why you choose tape for software delivery
Some customers are fearful of network delivery. I see two areas of concern:
o Merely connecting one's core IS engine to the Internet opens an avenue
for tampering. I have little to say on this.
o The installation package itself may have been corrupted en route.
In an SMP/E FROMNETWORK package a strong checksum of each component is compared
to a value in GIMPAF.XML, and a checksum of GIMPAF.XML itself is compared to a
value in the CLIENT data set.
But how is the CLIENT data set itself transmitted? if it's via a channel
comparable to that which carries the payload, then if Eve can counterfeit the
latter she can as easily counterfeit the former.
RECEIVE FROMNTS is worse. There is no CLIENT data set to carry the checksum.
GIMPAF.XML has a suffix which contains a checksum of the preceding code, but
this appears not to be verified:
I can intentionally corrupt it and SMP/E reports no error. But verifying it
would help little; it could be counterfeited as easily as any other part of the
package. I discover, with some reverse engineering, that I can verify the
checksum of GIMPAF.XML with the script:
#! /bin/sh -x
# Doc: Verify SHA-1 hash for GIMPAF.XML
SMPCPATH=/usr/lpp/smp/classes # (Customize.)
SMPJHOME=/usr/lpp/java/J6.0.1 # (Customize.)
PATH=${PATH:+$PATH:}$SMPJHOME/bin export PATH
echo msgDigest file=\GIMPAF.XML\ \
startDelim=\PKGDEF\ endDelim=\/PKGDEF\
terminate |
java -cp $SMPCPATH com.ibm.smp.GIMJVCLT exit #
Could that checksum be transferred via an independent secure channel and be
verified, even by visual inspection?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
==
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to which it is addressed. If you
have received this email in error, please notify the system manager. This
message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this message by mistake and delete
this e-mail from your system. If you are not the intended recipient, you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
Re: SMS primary vsam space allocation
From the listcat -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Friday, May 22, 2015 4:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS primary vsam space allocation Just out of curiosity, how do you know what the primary allocation was at the time the dataset was allocated? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Friday, May 22, 2015 2:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS primary vsam space allocation Hello all, I know this is late on Friday before a three day weekend, however, I'm stumped by a problem. We have some vsam files that have a primary allocation of 398 cyls and a secondary of 398 cyls. The primary extent that is displayed with in a listcat says that it is 11940 wihich is double the primary, secondary extents are 5970 tracks which is correct for 398 cyls. Can someone tell my why this is happening on an SMS managed file. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
I copy pasted the JCL into a real editor, i.e. ISPF, and noticed an oddity in this line: //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) There is no space between asterisk and ampersand. Could that be right? . . . 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 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2015 9:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GENERATED STATEMENT!? In my JESJCL listing I see: ... 33 // EXPORT SYMLIST=* 34 // SET IFSYM='' (Blank for pre-JES2 2.1.) 35 //IFSYMEXPORT EXPSET=GENERATED STATEMENT 36 // SET SYMVAL='Symbol value longer than name.' 37 //SYMVAL EXPORT EXPSET=Symbol value longer than... GENERATED STATEMENT //* 38 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 39 //LOGDD1DD SYSOUT=(,) //* 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) IEFC653I SUBSTITUTION JCL - *,SYMBOLS=(EXECSYS,LOGDD2) 41 //SYSIN DD * GENERATED STATEMENT 42 //LOGDD2DD SYSOUT=(,) //* 43 // Where does 41 //SYSIN DD * GENERATED STATEMENT come from? What does it mean? (I had no stray data cards.) I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
Appears to be a missing comma on statement 40 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) s/b 40 //SYMS2 DD *,IFSYM,SYMBOLS=(EXECSYS,LOGDD2) ^ HTH, snip In my JESJCL listing I see: ... 33 // EXPORT SYMLIST=* 34 // SET IFSYM='' (Blank for pre-JES2 2.1.) 35 //IFSYMEXPORT EXPSET=GENERATED STATEMENT 36 // SET SYMVAL='Symbol value longer than name.' 37 //SYMVAL EXPORT EXPSET=Symbol value longer than... GENERATED STATEMENT //* 38 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 39 //LOGDD1DD SYSOUT=(,) //* 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) IEFC653I SUBSTITUTION JCL - *,SYMBOLS=(EXECSYS,LOGDD2) 41 //SYSIN DD * GENERATED STATEMENT 42 //LOGDD2DD SYSOUT=(,) //* 43 // Where does 41 //SYSIN DD * GENERATED STATEMENT come from? What does it mean? (I had no stray data cards.) /snip I hate JCL! -- gil -- 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: GENERATED STATEMENT!?
On Wed, May 27, 2015 at 11:54 AM, J O Skip Robinson jo.skip.robin...@sce.com wrote: I copy pasted the JCL into a real editor, i.e. ISPF, and noticed an oddity in this line: //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) There is no space between asterisk and ampersand. Could that be right? Sure. If IFSYM is equal to a 0-length string like: // SET IFSYM='' , then the phrase: ,SYMBOLS=(EXECSYS,LOGDD) will abut the * and be recognized as part of the JCL statement as an operator. OTOH, if IFSYM is one or more blanks: // SET IFSYM=' ', then the phrase mentioned will be separated from the * by a space and be recognized as a comment. We do this all the time for DUMMYing out a DD statement: //SYSUT2 DD DUMMY.DSN= If we have a JCL statement: // SET DUMMY='DUMMY,' then the DD is a DD DUMMY. If we have // SET DUMMY='' , then the DD references the appropriate DSN. . . . 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 -- My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
I there a blank line between SYSMS2 and LOGDD2 statements? Have a nice day, Dave Betten z/OS Performance Specialist - HiPODS Open Technology and Cloud Performance IBM Corporation email: bet...@us.ibm.com 1-301-240-3809 IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 05/27/2015 12:37:18 PM: From: Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/27/2015 12:37 PM Subject: GENERATED STATEMENT!? Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In my JESJCL listing I see: ... 33 // EXPORT SYMLIST=* 34 // SET IFSYM='' (Blank for pre-JES2 2.1.) 35 //IFSYMEXPORT EXPSET= GENERATED STATEMENT 36 // SET SYMVAL='Symbol value longer than name.' 37 //SYMVAL EXPORT EXPSET=Symbol value longer than... GENERATED STATEMENT //* 38 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 39 //LOGDD1DD SYSOUT=(,) //* 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) IEFC653I SUBSTITUTION JCL - *,SYMBOLS=(EXECSYS,LOGDD2) 41 //SYSIN DD * GENERATED STATEMENT 42 //LOGDD2DD SYSOUT=(,) //* 43 // Where does 41 //SYSIN DD * GENERATED STATEMENT come from? What does it mean? (I had no stray data cards.) I hate JCL! -- gil -- 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
GENERATED STATEMENT!?
In my JESJCL listing I see: ... 33 // EXPORT SYMLIST=* 34 // SET IFSYM='' (Blank for pre-JES2 2.1.) 35 //IFSYMEXPORT EXPSET=GENERATED STATEMENT 36 // SET SYMVAL='Symbol value longer than name.' 37 //SYMVAL EXPORT EXPSET=Symbol value longer than... GENERATED STATEMENT //* 38 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 39 //LOGDD1DD SYSOUT=(,) //* 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) IEFC653I SUBSTITUTION JCL - *,SYMBOLS=(EXECSYS,LOGDD2) 41 //SYSIN DD * GENERATED STATEMENT 42 //LOGDD2DD SYSOUT=(,) //* 43 // Where does 41 //SYSIN DD * GENERATED STATEMENT come from? What does it mean? (I had no stray data cards.) I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
Submit the job in hold status and use SDSF to look at the data card(s) in the SYSIN member. Then find that data in the dataset you submitted and determine why it was not recognized as JCL. One common reason is that columns 1 and 2 do not contain // or /*. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2015 9:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GENERATED STATEMENT!? In my JESJCL listing I see: ... 33 // EXPORT SYMLIST=* 34 // SET IFSYM='' (Blank for pre-JES2 2.1.) 35 //IFSYMEXPORT EXPSET=GENERATED STATEMENT 36 // SET SYMVAL='Symbol value longer than name.' 37 //SYMVAL EXPORT EXPSET=Symbol value longer than... GENERATED STATEMENT //* 38 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 39 //LOGDD1DD SYSOUT=(,) //* 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) IEFC653I SUBSTITUTION JCL - *,SYMBOLS=(EXECSYS,LOGDD2) 41 //SYSIN DD * GENERATED STATEMENT 42 //LOGDD2DD SYSOUT=(,) //* 43 // Where does 41 //SYSIN DD * GENERATED STATEMENT come from? What does it mean? (I had no stray data cards.) I hate JCL! -- gil -- 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: GENERATED STATEMENT!?
One options I like is the HILITE in EDIT or VIEW for JCL. It will usually show me most of my JCL issues. While in EDIT or VIEW type HILITE on command line, select 11 - JCL Lizette -Original Message- From: retired mainframer retired-mainfra...@q.com Sent: May 27, 2015 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GENERATED STATEMENT!? Submit the job in hold status and use SDSF to look at the data card(s) in the SYSIN member. Then find that data in the dataset you submitted and determine why it was not recognized as JCL. One common reason is that columns 1 and 2 do not contain // or /*. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2015 9:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GENERATED STATEMENT!? In my JESJCL listing I see: ... 33 // EXPORT SYMLIST=* 34 // SET IFSYM='' (Blank for pre-JES2 2.1.) 35 //IFSYMEXPORT EXPSET=GENERATED STATEMENT 36 // SET SYMVAL='Symbol value longer than name.' 37 //SYMVAL EXPORT EXPSET=Symbol value longer than... GENERATED STATEMENT //* 38 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 39 //LOGDD1DD SYSOUT=(,) //* 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) IEFC653I SUBSTITUTION JCL - *,SYMBOLS=(EXECSYS,LOGDD2) 41 //SYSIN DD * GENERATED STATEMENT 42 //LOGDD2DD SYSOUT=(,) //* 43 // Where does 41 //SYSIN DD * GENERATED STATEMENT come from? What does it mean? (I had no stray data cards.) I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS primary vsam space allocation
LISTCAT reports two different details that you seem to be confusing. The number of tracks reported in the first extent listed in the VOLUME section is not the primary allocation. It is possible that the primary allocation could require up to five extents. It also possible for multiple extents to be consolidated into a single extent when they are contiguous. The primary allocation is reported in the SPACE-PRI field of the ALLOCATION section. You also need to look at the SPACE-TYPE field if you want to convert this to tracks. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Wednesday, May 27, 2015 7:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS primary vsam space allocation From the listcat -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Friday, May 22, 2015 4:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS primary vsam space allocation Just out of curiosity, how do you know what the primary allocation was at the time the dataset was allocated? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Friday, May 22, 2015 2:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS primary vsam space allocation Hello all, I know this is late on Friday before a three day weekend, however, I'm stumped by a problem. We have some vsam files that have a primary allocation of 398 cyls and a secondary of 398 cyls. The primary extent that is displayed with in a listcat says that it is 11940 wihich is double the primary, secondary extents are 5970 tracks which is correct for 398 cyls. Can someone tell my why this is happening on an SMS managed file. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: GENERATED STATEMENT!?
If it makes you feel any better, I can reproduce your exact error on my 2.1 system -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2015 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GENERATED STATEMENT!? On Wed, 27 May 2015 12:41:36 -0400, David Betten wrote: I[s] there a blank line between SYSMS2 and LOGDD2 statements? I said: From: Paul Gilmartin Date: 05/27/2015 12:37 PM ... (I had no stray data cards.) On 2015-05-27 10:54, J O Skip Robinson wrote: I copy pasted the JCL into a real editor, i.e. ISPF, and noticed an oddity in this line: //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) There is no space between asterisk and ampersand. Could that be right? Yes. On 2015-05-27 10:56, Staller, Allan wrote: Appears to be a missing comma on statement 40 There is not. 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) s/b 40 //SYMS2 DD *,IFSYM,SYMBOLS=(EXECSYS,LOGDD2) ^ HTH, It doesn't On Wed, 27 May 2015 10:25:13 -0700, retired mainframer wrote: Submit the job in hold status and use SDSF to look at the data card(s) in the SYSIN member. Then find that data in the dataset you submitted and determine why it was not recognized as JCL. One common reason is that columns 1 and 2 do not contain // or /*. Even better, copied and pasted from SDSF SJ panel: ... 000172 //* 000173 // EXPORT SYMLIST=* 000174 // SET IFSYM='' (Blank for pre-JES2 2.1.) 000175 // SET SYMVAL='Symbol value longer than name.' 000176 //* 000177 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 000178 Try SYMVAL 000179 Preset LRECL with longer line . 000180 //LOGDD1DD SYSOUT=(,) 000181 //* 000182 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) 000183 Try SYMVAL 000184 Short line 000185 //LOGDD2DD SYSOUT=(,) 000186 //* 000187 // ... Do you see anything wrong? On Wed, 27 May 2015 12:14:42 -0500, John McKown wrote: ... We do this all the time ... Thank you for understanding JCL syntax better than most of the followups. --gil -- 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: GENERATED STATEMENT!?
From APAR OA45005: Exported symbolic parameters must be set to a value in the job stream after the EXPORT statement. Exported symbol values are resolved to the last value set prior to or within the current job step. JCL Converter processing generates EXPORT EXPSET statements to manage how exported JCL symbol values are resolved. These statements appear in the job log. Reviewing the placement of EXPORT EXPSET statements in the job log may be helpful in understanding exported symbol resolution for a given job. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2015 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GENERATED STATEMENT!? In my JESJCL listing I see: ... 33 // EXPORT SYMLIST=* 34 // SET IFSYM='' (Blank for pre-JES2 2.1.) 35 //IFSYMEXPORT EXPSET=GENERATED STATEMENT 36 // SET SYMVAL='Symbol value longer than name.' 37 //SYMVAL EXPORT EXPSET=Symbol value longer than... GENERATED STATEMENT //* 38 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 39 //LOGDD1DD SYSOUT=(,) //* 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) IEFC653I SUBSTITUTION JCL - *,SYMBOLS=(EXECSYS,LOGDD2) 41 //SYSIN DD * GENERATED STATEMENT 42 //LOGDD2DD SYSOUT=(,) //* 43 // Where does 41 //SYSIN DD * GENERATED STATEMENT come from? What does it mean? (I had no stray data cards.) I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto: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: GENERATED STATEMENT!?
I would use this instead: // SET INSTRM='* ' USE THIS ONE FOR PRE-JES2 2.1 // SET INSTRM='*,' USE THIS ONE FOR JES2 2.1 . . . . //SYMS2 DD INSTRM.SYMBOLS=(EXECSYS,LOGDD2) Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2015 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GENERATED STATEMENT!? In my JESJCL listing I see: ... 33 // EXPORT SYMLIST=* 34 // SET IFSYM='' (Blank for pre-JES2 2.1.) 35 //IFSYMEXPORT EXPSET=GENERATED STATEMENT 36 // SET SYMVAL='Symbol value longer than name.' 37 //SYMVAL EXPORT EXPSET=Symbol value longer than... GENERATED STATEMENT //* 38 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 39 //LOGDD1DD SYSOUT=(,) //* 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) IEFC653I SUBSTITUTION JCL - *,SYMBOLS=(EXECSYS,LOGDD2) 41 //SYSIN DD * GENERATED STATEMENT 42 //LOGDD2DD SYSOUT=(,) //* 43 // Where does 41 //SYSIN DD * GENERATED STATEMENT come from? What does it mean? (I had no stray data cards.) I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEB351I (was : GENERATED STATEMENT!?)
On 2015-05-27 13:46, Gross, Randall [PRI-1PP] wrote: If it makes you feel any better, I can reproduce your exact error on my 2.1 system Misery loves company? And this one: As submitted: //JCLSYMJOB 505303JOB,'Paul Gilmartin', // MSGLEVEL=(1,1),REGION=16385K //* //* Doc: experiment with instream symbol substitution. //* //USERCOUTPUT JESDS=ALL,DEFAULT=YES, // CLASS=R,PAGEDEF=V0648Z,CHARS=GT12 //* // EXPORT SYMLIST=* //* //*.+|+|+|+|+|+|+|+| // SET X='This is a long symbol value.' //STEP1EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=(,) //SYSIN DD DUMMY //SYSUT2DD SYSOUT=(,) //SYSUT1DD *,SYMBOLS=CNVTSYS,DCB=LRECL=222 Lots of data to fill up a line, followed by a long symbol to see X. //*.+|+|+|+|+|+|+|+| // In SYSPRINT: * TOP OF DATA *** DATA SET UTILITY - GENERATE IEB352I WARNING: ONE OR MORE OF THE OUTPUT DCB PARMS COPIED FROM INPUT IEB351I I/O ERROR ,JCLSYM ,STEP1 ,JES ,D,SYSUT1 ,READ ,WRONG LEN RECRD,**,BSAM BOTTOM OF DATA * I might understand it if my coded LRECL weren't ample to hold the line after substitution. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
Would //SYMS2 DD *,DSN=amp;XXIFSYM,SYMBOLS=(EXECSYS,LOGDD2) do? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
That doesn't work either. As I said to Gil off list, the problem appears to be that the JCL parser is generating DD cards for instream data before it does symbol substitution. It should work the other way around: do symbol substitution first then generate DD cards as needed. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Wednesday, May 27, 2015 13:16 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GENERATED STATEMENT!? I would use this instead: // SET INSTRM='* ' USE THIS ONE FOR PRE-JES2 2.1 // SET INSTRM='*,' USE THIS ONE FOR JES2 2.1 . . . . //SYMS2 DD INSTRM.SYMBOLS=(EXECSYS,LOGDD2) Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2015 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GENERATED STATEMENT!? In my JESJCL listing I see: ... 33 // EXPORT SYMLIST=* 34 // SET IFSYM='' (Blank for pre-JES2 2.1.) 35 //IFSYMEXPORT EXPSET=GENERATED STATEMENT 36 // SET SYMVAL='Symbol value longer than name.' 37 //SYMVAL EXPORT EXPSET=Symbol value longer than... GENERATED STATEMENT //* 38 //SYMS1 DD *,SYMBOLS=(EXECSYS,LOGDD1) 39 //LOGDD1DD SYSOUT=(,) //* 40 //SYMS2 DD *IFSYM,SYMBOLS=(EXECSYS,LOGDD2) IEFC653I SUBSTITUTION JCL - *,SYMBOLS=(EXECSYS,LOGDD2) 41 //SYSIN DD * GENERATED STATEMENT 42 //LOGDD2DD SYSOUT=(,) //* 43 // Where does 41 //SYSIN DD * GENERATED STATEMENT come from? What does it mean? (I had no stray data cards.) I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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
PCRE 8.37 for classic z/OS is available
PCRE 8.37 for classic z/OS is available in CBTTAPE.ORG File882 and on zaconsultants.net Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Mysterious U4088-63 from RPTSTG(ON)
I have a C++ program that I am testing that is working perfectly in all
regards except one. When I run it with
//CEEOPTS DD *
RPTSTG(ON)
/*
it ABENDs with U4088-63 which is documented as save area chain corruption. I
can run it with TERMTHDACT(DUMP) or with HEAPCHK(ON,10,0,10,10,1024,0)
without error.
I have isolated the ABEND to a call to a self-written assembler function
called ISAUTH. I execute a printf() immediately before the call but not a
printf() after. I am posting below the entire code of ISAUTH. CDSALEN has a
value of x'60C'. I think other than that the code snippet is self-contained.
The assembler module contains many similar small functions. I know at least
5 of them get called without error.
It used to work. What changed? I added some functions and the module grew to
have addressability problems, so I added an IEABRCX DEFINE. I have eyeballed
the code generated by EDCPRLG and it appears correct -- now with a BRC 15
instead of a B. It would be inconvenient to get the IEABRCX back out of
there as a test.
The function is declared in C++ as extern OS {bool ISAUTH();}. The other
functions are declared similarly.
AMODE 31/XPLINK(NO)
Does anyone have any clues?
ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG=NONE
LARL R12,CZAMISC
USING CZAMISC,R12
*
* *** USING CDSASTOR,R13 Use R13 as base for reentrant store
*
* Issue the TESTAUTH
TESTAUTH FCTN=1
*
* TESTAUTH returns 0 = yes, 4 = no
* We return 1 = yes, 0 = no
SRL R15,2 Convert 4 into 1
LCR R15,R15 Convert 1 into -1
AHI R15,1 Convert 1 into 0 and 0 into 1
*
* *** J Ret_R15Return whatever is in R15
EDCEPIL ,
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
In article 09a301d098e6$0607d120$12177360$@mcn.org you wrote:
(snip)
I have isolated the ABEND to a call to a self-written assembler function
called ISAUTH. I execute a printf() immediately before the call but not a
printf() after. I am posting below the entire code of ISAUTH. CDSALEN has a
value of x'60C'. I think other than that the code snippet is self-contained.
(snip)
It used to work. What changed? I added some functions and the module grew to
have addressability problems, so I added an IEABRCX DEFINE. I have eyeballed
the code generated by EDCPRLG and it appears correct -- now with a BRC 15
instead of a B. It would be inconvenient to get the IEABRCX back out of
there as a test.
Can you post the expansions of EDCPRLG and EDCEPIL?
I presume they do save and restoring of registers, and appropriate
save area linkage, but it would be nice to see the expansion.
The function is declared in C++ as extern OS {bool ISAUTH();}. The other
functions are declared similarly.
AMODE 31/XPLINK(NO)
Does anyone have any clues?
ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG=NONE
LARL R12,CZAMISC
USING CZAMISC,R12
*
* *** USING CDSASTOR,R13 Use R13 as base for reentrant store
*
* Issue the TESTAUTH
TESTAUTH FCTN=1
*
* TESTAUTH returns 0 = yes, 4 = no
* We return 1 = yes, 0 = no
SRL R15,2 Convert 4 into 1
LCR R15,R15 Convert 1 into -1
AHI R15,1 Convert 1 into 0 and 0 into 1
*
* *** J Ret_R15Return whatever is in R15
EDCEPIL ,
-- glen
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
Sure. It's magical mystery code, but sure. 1669 ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG 1670+*** 0 00618 1671+IHB0092DS DSECT 1672+ DSD 1673+ DSCL(120+0) 00080 0 1674+ ORG IHB0092DS 1675+ DSCL(CDSALEN+8) 00614 00614 1676+ ORG 1677+ DS0D 006101678+IHB0092LG EQU *-IHB0092DS-8 00035 01510 1679+CZAMISC CSECT 1680+*-- 1681+ DS0H R:F 008761682+ USING *,15 A7F4 0021008B8 1685+ISAUTH BRC 15,IHB0092B (BC) 1686+* PPA1 constant area 14 1687+ DCAL1(IHB0092N+4-*) offs CE 1688+ DCX'CE' . CEE A0 1689+ DCX'A0' . CEE 10 1690+ DCAL1(0+0+16) . memb 08941691+ DCAL4(IHB0092P) . A( 1692+ DCAL4(0) . A( 06101693+ DCAL4(IHB0092LG)to 00061694+IHB0092N DCAL2(6) . leng C9E2C1E4E3C81695+ DCC'ISAUTH' untr 1696+*-- 1697+* PPA2 constant area 1698+IHB0092P DS0F forc 03 1699+ DCX'03' . memb 00 1700+ DCX'00' . memb 33 1701+ DCX'33' . plis 00 1702+ DCX'00' . CEE 1703+ DCAL4(CEESTART) 1704+ DCAL4(0)A( 08A41705+ DCAL4(IHB0092T) . A( 1706+* 1707+* Time stamp area 1708+IHB0092T DS0F F2F0F1F51709+ DCCL4'2015' . F0F5F2F71710+ DCCL4'0527' . mmdd F2F1F0F7F0F01711+ DCCL6'210700' . hhmm F0F11712+ DCCL2'01' . vers F0F1F0F01713+ DCCL4'0100' . rele 1714+* 1715+IHB0092B DS0H 1716+*** 90EC D00CC 1717+ STM 14,12,12(13) . save 1718+*** 5820 D04C0004C 1719+ L 2,76(,13) get 5800 F01000010 1720+ L 0,16(,15) size 1E021721+ ALR 0,2 old 5500 C00CC 1722+ CL0,12(,12) chec A7D4 0005008D4 1725+ BRC 13,*+10 (BC) 58F0 C07400074 1726+ L 15,116(,12) load 05EF1727+ BALR 14,15 invo 1728+* at this point R0 has the new NAB, R2 58F0 D04800048 1729+ L 15,72(,13) 90F0 204800048 1730+ STM 15,0,72(2) 9210 2000 01731+ MVI 0(2),X'10' 50D0 20044 1732+ ST13,4(,2)back 18D21733+ LR13,2acti 1734+*** 1735+ DROP 15 1736+*** 1756 EDCEPIL , 58D0 D0044 1757+ L 13,4(,13) addre 58E0 D00CC 1758+ L 14,12(,13) resto 982C D01C0001C 1759+ LM2,12,28(13)
Re: Tailoring SVCDUMP (SDUMPX) on zos/2.1
:You should probably consider using IEATDUMP. IEATDUMP does not support LIST64 I hadn't noticed that. It is an unfortunate oversight. We will look into providing that in a future release. 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
