Re: ACS routine imbed/include function?
So I probably mixed some historical info in my memory. It would be nice to have, e.g. for dsname- of volser-filtlists used in more than one routine. However, there are not many enhancements in ACS routines the last decades, so I expect this will remain a wish. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, July 12, 2013 20:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? Sorry about the garble. The include function available to ACS routines is that of the editor. There is still value to a separate member(s) for common code, FILTLIST in particular. But it is a manual function to pull them into each member before compiling. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, July 12, 2013 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? I will be interested in the answer. I know you cannot have more than 255 entire in one filtlist. But I was not aware of any include function Lizette -Original Message- From: Gibney, Dave gib...@wsu.edu Sent: Jul 12, 2013 9:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? As of z/OS a do by hand function. Would be useful as part of the ACS language :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Friday, July 12, 2013 5:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ACS routine imbed/include function? Hello group, I vaguely remember reading, quite some time ago, about a function to imbed/include coding into ACS routines. E.g. if you have large filtlists, you code them in a separate member on your ACSsource and have them read (included) into your ACS routine at compile time. The advantage would be, that you keep the coding more readable and that you can maintain the list on one place and include it into several ACS routines. I would like to use this now, but cannot find any documentation about it. Was I mistaken and did I confuse it with some other function or can someone point me to the correct place to learn more about it? Thanks, Kee -- 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: Dynamic LPA Services
On Sun, 14 Jul 2013 17:19:09 -0400 Richard Verville r.vervi...@videotron.ca wrote: :John Gilmore-There is no need for further assertions that things :that manifestly do work may not or for something less than clarity :about, for example, the fact that AMODE(64) code is faster than :AMODE(31) code. :Are you saying that AMODE(64) is faster than AMODE(31) ? If so, why would that be ? Depending on how the box is built, to handle tri-mode may require a check of addresses versus the AMODE on most instructions. There may be a preference to 64 to improve performance in products that are used for benchmarks. Of course, there may be 3 different engines -- 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
Ted talk: George Dyson at the birth of the computer
I found this very fun to listen to, and thought to share it. I particularly liked the work notes from the people building and programming the computers in the 50's. Kind regards, Lindy http://www.ted.com/talks/george_dyson_at_the_birth_of_the_computer.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The amazing disappearing mainframe.
On Sun, 14 Jul 2013 18:30:46 -0400, John respake: I see no evidence that the mainframe is going the way of the dodo. What is happening, outside China and several other new markets, is that 1) the number of small- and middling-sizeed mainframe shops is dropping steadily and 2) that many of the remaining large and very large shops are continuing to grow in size. None of which gives me succour. Times is tuff, and management seemingly has not the wit to recognise they have to pay for the skills they need. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ACS routine imbed/include function?
Vernooij, CP wrote: So I probably mixed some historical info in my memory. It would be nice to have, e.g. for dsname- of volser-filtlists used in more than one routine. However, there are not many enhancements in ACS routines the last decades, so I expect this will remain a wish. You've got my curiousity turned on and I searched my *ss off since your first post! It was indeed a long time I saw any announcement for ACS enhancements if at all. But then I wonder if you were thinking about 'COPYFILT macro: COPYLIB facility for FILTLISTs'. Granted that is for initial SMS setup. On the otherside, I wonder if you were refering to FILTERDD in DFDSS. There you can probably concatenate at your leisure... Hmmm, perhaps time for a Share thing? Think of it: one set of Include/exclude for DB2 folks, another for other dbas, etc. 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: SMF record - IPADDR
I think this would be resisted by IBM. There are too many basically separate products which produce SMF records. Some even the same SMF record number, such as 110 for CICS and DB2. But what we _might_ be able to convince IBM to do is to create a Web bookshelf, similar to the z/OS Messages and Codes bookshelf, which would contain a entry for every IBM manual which documented the SMF record(s) produced by every IBM product which produces those records. This would be much simpler than a single manual. And it would be searchable just like the Messages and Codes bookshelf is. On Mon, Jul 15, 2013 at 12:08 AM, Roger W. Suhr suhr...@gmail.com wrote: I'd vote for both. All IBM product SMF records type 0-200 should be documented in the SMF manual. Roger S. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Sunday, July 14, 2013 11:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF record - IPADDR Which bring up the question... Where should the layout of SMF records reside, SMF manual, each product manual or ? Anyone have an opinion which way? Ed ps: Arguments on both sides are reasonable although personally I think the SMF manual as it central to all products. On Jul 14, 2013, at 7:47 AM, Mike Stayton wrote: The SMF Type 106, 118 and 119 record layouts are in: z/OS V1R13.0 Comm Svr: IP Programmer's Guide and Reference SC31-8787-14 E.0 Appendix E. Type 119 SMF records http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1d3b1/ E.0 Mike Stayton z/OS Communications Server -- 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 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? 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: The amazing disappearing mainframe.
Management today, especially in large companies, seem to have no investment in the company itself, on a long term basis. They know that they need to get their pay off quickly (before they are replaced) and that reducing cost will get them money in their pockets faster. So there is little incentive to have a really long term view point. A perversion of Matthew 6:34 Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own. On Mon, Jul 15, 2013 at 4:17 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: On Sun, 14 Jul 2013 18:30:46 -0400, John respake: I see no evidence that the mainframe is going the way of the dodo. What is happening, outside China and several other new markets, is that 1) the number of small- and middling-sizeed mainframe shops is dropping steadily and 2) that many of the remaining large and very large shops are continuing to grow in size. None of which gives me succour. Times is tuff, and management seemingly has not the wit to recognise they have to pay for the skills they need. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? 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: SMF record - IPADDR
IMO, the problem with SMF records is not the documentation. I would like to see IBM publish some sort of machine-readable schema document (say, in XML or JSON) for each record that describes the structure and datatypes in each record. Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Jul 15, 2013 at 8:37 AM, John McKown john.archie.mck...@gmail.comwrote: I think this would be resisted by IBM. There are too many basically separate products which produce SMF records. Some even the same SMF record number, such as 110 for CICS and DB2. But what we _might_ be able to convince IBM to do is to create a Web bookshelf, similar to the z/OS Messages and Codes bookshelf, which would contain a entry for every IBM manual which documented the SMF record(s) produced by every IBM product which produces those records. This would be much simpler than a single manual. And it would be searchable just like the Messages and Codes bookshelf is. On Mon, Jul 15, 2013 at 12:08 AM, Roger W. Suhr suhr...@gmail.com wrote: I'd vote for both. All IBM product SMF records type 0-200 should be documented in the SMF manual. Roger S. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Sunday, July 14, 2013 11:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF record - IPADDR Which bring up the question... Where should the layout of SMF records reside, SMF manual, each product manual or ? Anyone have an opinion which way? Ed ps: Arguments on both sides are reasonable although personally I think the SMF manual as it central to all products. On Jul 14, 2013, at 7:47 AM, Mike Stayton wrote: The SMF Type 106, 118 and 119 record layouts are in: z/OS V1R13.0 Comm Svr: IP Programmer's Guide and Reference SC31-8787-14 E.0 Appendix E. Type 119 SMF records http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1d3b1/ E.0 Mike Stayton z/OS Communications Server -- 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 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- 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: SMF record - IPADDR
While I agree it would be nice to have more consumable data formats I don't agree documentation isn't a major problem: As someone who spends a lot of time with the raw data all sorts of questions come up that the documentation doesn't address, mainly of provenance and interpretation. A concordance of SMF record mappings would be great, but detail would need to be added to the current field descriptions. A large task, I'd say. 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: Kirk Wolf k...@dovetail.com To: IBM-MAIN@listserv.ua.edu, Date: 07/15/2013 02:50 PM Subject:Re: SMF record - IPADDR Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu IMO, the problem with SMF records is not the documentation. I would like to see IBM publish some sort of machine-readable schema document (say, in XML or JSON) for each record that describes the structure and datatypes in each record. Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Jul 15, 2013 at 8:37 AM, John McKown john.archie.mck...@gmail.comwrote: I think this would be resisted by IBM. There are too many basically separate products which produce SMF records. Some even the same SMF record number, such as 110 for CICS and DB2. But what we _might_ be able to convince IBM to do is to create a Web bookshelf, similar to the z/OS Messages and Codes bookshelf, which would contain a entry for every IBM manual which documented the SMF record(s) produced by every IBM product which produces those records. This would be much simpler than a single manual. And it would be searchable just like the Messages and Codes bookshelf is. On Mon, Jul 15, 2013 at 12:08 AM, Roger W. Suhr suhr...@gmail.com wrote: I'd vote for both. All IBM product SMF records type 0-200 should be documented in the SMF manual. Roger S. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Sunday, July 14, 2013 11:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF record - IPADDR Which bring up the question... Where should the layout of SMF records reside, SMF manual, each product manual or ? Anyone have an opinion which way? Ed ps: Arguments on both sides are reasonable although personally I think the SMF manual as it central to all products. On Jul 14, 2013, at 7:47 AM, Mike Stayton wrote: The SMF Type 106, 118 and 119 record layouts are in: z/OS V1R13.0 Comm Svr: IP Programmer's Guide and Reference SC31-8787-14 E.0 Appendix E. Type 119 SMF records http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1d3b1/ E.0 Mike Stayton z/OS Communications Server -- 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 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- 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 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: SMF record - IPADDR
Nice idea. Would need some new low level node. Perhaps SXMLSMF? Or SJSONSMF. I'm not an expert in either, but the relocatable, possibly repeating, sections might be a bit difficult to document. Perhaps a DTD is needed as well. SDTDSMF and ADTDSMF in what appears to be IBM's current SMP/E naming convention. On Mon, Jul 15, 2013 at 8:50 AM, Kirk Wolf k...@dovetail.com wrote: IMO, the problem with SMF records is not the documentation. I would like to see IBM publish some sort of machine-readable schema document (say, in XML or JSON) for each record that describes the structure and datatypes in each record. Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Jul 15, 2013 at 8:37 AM, John McKown john.archie.mck...@gmail.comwrote: I think this would be resisted by IBM. There are too many basically separate products which produce SMF records. Some even the same SMF record number, such as 110 for CICS and DB2. But what we _might_ be able to convince IBM to do is to create a Web bookshelf, similar to the z/OS Messages and Codes bookshelf, which would contain a entry for every IBM manual which documented the SMF record(s) produced by every IBM product which produces those records. This would be much simpler than a single manual. And it would be searchable just like the Messages and Codes bookshelf is. On Mon, Jul 15, 2013 at 12:08 AM, Roger W. Suhr suhr...@gmail.com wrote: I'd vote for both. All IBM product SMF records type 0-200 should be documented in the SMF manual. Roger S. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Sunday, July 14, 2013 11:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF record - IPADDR Which bring up the question... Where should the layout of SMF records reside, SMF manual, each product manual or ? Anyone have an opinion which way? Ed ps: Arguments on both sides are reasonable although personally I think the SMF manual as it central to all products. On Jul 14, 2013, at 7:47 AM, Mike Stayton wrote: The SMF Type 106, 118 and 119 record layouts are in: z/OS V1R13.0 Comm Svr: IP Programmer's Guide and Reference SC31-8787-14 E.0 Appendix E. Type 119 SMF records http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1d3b1/ E.0 Mike Stayton z/OS Communications Server -- 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 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- 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 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? 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: SMF record - IPADDR
In 003801ce8119$55b87300$01295900$@com, on 07/15/2013 at 12:08 AM, Roger W. Suhr suhr...@gmail.com said: I'd vote for both. All IBM product SMF records type 0-200 should be documented in the SMF manual. Alternatively, the SMF and control blocks manuals should have links[1] to the appropriate product manuals. [1] In a usable form, e.g., a PDF should allow copying or selecting the URL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ACS routine imbed/include function?
Bingo! This is what I had stored many years ago somewhere in migrated memory: the COPYFILT macro. It is not completely automatic, but it takes only one command to fire the automation of updating multiple tables in multiple routines. I will have a look at it again to see if it helps me this time. A function like the FILTERDD would even be more convenient. And,by the way, if someone is making up a wishlist for ACS routines: subroutines would be very helpful and also a substring function (find and replace), like in: when (mgmtclas eq B2DA)set mgtmclas = B1DA. This now takes 15 WHEN clauses for each of the values. Thanks, Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, July 15, 2013 15:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? Vernooij, CP wrote: So I probably mixed some historical info in my memory. It would be nice to have, e.g. for dsname- of volser-filtlists used in more than one routine. However, there are not many enhancements in ACS routines the last decades, so I expect this will remain a wish. You've got my curiousity turned on and I searched my *ss off since your first post! It was indeed a long time I saw any announcement for ACS enhancements if at all. But then I wonder if you were thinking about 'COPYFILT macro: COPYLIB facility for FILTLISTs'. Granted that is for initial SMS setup. On the otherside, I wonder if you were refering to FILTERDD in DFDSS. There you can probably concatenate at your leisure... Hmmm, perhaps time for a Share thing? Think of it: one set of Include/exclude for DB2 folks, another for other dbas, etc. 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 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: SMF record - IPADDR
Martin, I'm sorry that I wasn't clear. I'm not arguing for different data formats for SMF. I'm saying that we need something other than Assembler DSECTs as a metadata description. Say for example that there were a standard metadata document (maybe in XML or JSON) that *described* all of the SMF records. This could then be translated into code in your favorite programming language so that all SMF records could be decoded (with substructures, etc). Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Jul 15, 2013 at 8:55 AM, Martin Packer martin_pac...@uk.ibm.comwrote: While I agree it would be nice to have more consumable data formats I don't agree documentation isn't a major problem: As someone who spends a lot of time with the raw data all sorts of questions come up that the documentation doesn't address, mainly of provenance and interpretation. A concordance of SMF record mappings would be great, but detail would need to be added to the current field descriptions. A large task, I'd say. 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: Kirk Wolf k...@dovetail.com To: IBM-MAIN@listserv.ua.edu, Date: 07/15/2013 02:50 PM Subject:Re: SMF record - IPADDR Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu IMO, the problem with SMF records is not the documentation. I would like to see IBM publish some sort of machine-readable schema document (say, in XML or JSON) for each record that describes the structure and datatypes in each record. Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Jul 15, 2013 at 8:37 AM, John McKown john.archie.mck...@gmail.comwrote: I think this would be resisted by IBM. There are too many basically separate products which produce SMF records. Some even the same SMF record number, such as 110 for CICS and DB2. But what we _might_ be able to convince IBM to do is to create a Web bookshelf, similar to the z/OS Messages and Codes bookshelf, which would contain a entry for every IBM manual which documented the SMF record(s) produced by every IBM product which produces those records. This would be much simpler than a single manual. And it would be searchable just like the Messages and Codes bookshelf is. On Mon, Jul 15, 2013 at 12:08 AM, Roger W. Suhr suhr...@gmail.com wrote: I'd vote for both. All IBM product SMF records type 0-200 should be documented in the SMF manual. Roger S. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Sunday, July 14, 2013 11:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF record - IPADDR Which bring up the question... Where should the layout of SMF records reside, SMF manual, each product manual or ? Anyone have an opinion which way? Ed ps: Arguments on both sides are reasonable although personally I think the SMF manual as it central to all products. On Jul 14, 2013, at 7:47 AM, Mike Stayton wrote: The SMF Type 106, 118 and 119 record layouts are in: z/OS V1R13.0 Comm Svr: IP Programmer's Guide and Reference SC31-8787-14 E.0 Appendix E. Type 119 SMF records http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1d3b1/ E.0 Mike Stayton z/OS Communications Server -- 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 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- 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 Unless stated otherwise above: IBM United Kingdom Limited -
Re: Buffering: stdout vs. stderr?
Gil,
Maybe that is one of the enhancements ? :-)
Actually this seems to be an issue with the stream buffering strategy.
See the C/C++ RTL Ref for setvbuf(). Maybe you need to explicitly call
setvbuf() for stdout/stderr with __LIBASCII ??
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Tue, Jul 9, 2013 at 6:12 PM, Paul Gilmartin paulgboul...@aim.com wrote:
My test program, isbuffer.c:
/* Doc: demonstrate buffering of stdout and stderr */
#include stdio.h
int main( void ) {
int I;
for ( I = 0; I5; I++ ) {
fprintf( stdout, Record %2d to stdout\n, I );
fprintf( stderr, Record %2d to stderr\n, I ); }
return( 0 ); }
... when compiled and executed with the C/C++ compiler on z/OS 1.13 prints:
SPPG@MVS3:136$ cd ../OS390
SPPG@MVS3:138$ gmake isbuffer amp; ./isbuffer
gmake: `isbuffer' is up to date.
Record 0 to stdout
Record 0 to stderr
Record 1 to stdout
Record 1 to stderr
Record 2 to stdout
Record 2 to stderr
Record 3 to stdout
Record 3 to stderr
Record 4 to stdout
Record 4 to stderr
... the writes to stdout and stderr come out interleaved, in the order
in which they were executed. However, when I compile in Enhanced
ASCII mode and link with xplink, I get:
SPPG@MVS3:145$ cd ../ASCII
SPPG@MVS3:146$ gmake isbuffer amp; ./setascii ./isbuffer
unset LC_CTYPE; \
c99 -I.. -D_ALL_SOURCE -Wa,ASA,RENT -Wl,xplink,EDIT=NO -Wc,dll,ascii
-o isbuffer isbuffer.o /usr/lib/Xaw.x /usr/lib/SM.x /usr/lib/ICE.x
/usr/lib/X11.x -lcurses
Record 0 to stderr
Record 1 to stderr
Record 2 to stderr
Record 3 to stderr
Record 4 to stderr
Record 0 to stdout
Record 1 to stdout
Record 2 to stdout
Record 3 to stdout
Record 4 to stdout
... all the writes to stderr come out first, and stdout appears to be
using a lazy buffer. Is this documented? Is there a standard
involved? Or just a good argument for issuing prompts to stderr
rather than to stdout in an interactive program? (Or for using
fflush().)
-- 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: ACS routine imbed/include function?
On Mon, 15 Jul 2013 16:05:06 +0200, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: Bingo! This is what I had stored many years ago somewhere in migrated memory: the COPYFILT macro. Ag! Yet another good pun about to be migrated in my flaky memory... ;-) You're welcome. Thanks! I will have a look at it again to see if it helps me this time. Let us know if it helps you indeed. A function like the FILTERDD would even be more convenient. Agreed! 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: Benchmark of Relative instructions vers Base+displacement ones
I remember when I first was disabused of the quaint notion that the CPU performance of a batch z/OS application could be measured in a deterministic manner, here on this very list some years ago. The implications of processor pipelining and branch prediction and AGI and cache lines had just not sunk into my thick Irish head before that time. I well remember my sincere and aggravated frustration that performance measurement had been reduced to statistical averages. I was at that time engaged in an active and crucial CPU reduction exercise for my employer, and having the ability to perform deterministic measurement would have made my job then SO much easier. I am still at least mildly upset that we can no longer accurately measure or predict performance, but only produce statistical estimates. OTOH, having seen the kind of processor-specific, pipeline-optimized instruction generation that the current C/C++ compiler back end can produce (and that hopefully the new COBOL back end will produce as well), I am more sanguine about our ability as programmers to produce fast, efficient code for our employers. However, it would be extraordinarily helpful if IBM commissioned a Redpaper or two about application programming paradigms and design patterns (in more than one application language) so that current and future mainframe coding practitioners could keep current with the tremendous hardware enhancements that have been and are being brought into our world, will we, nil we. Or perhaps such desiderata have already been written and I am just ignorant of their availability? Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Wednesday, July 10, 2013 2:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Benchmark of Relative instructions vers Base+displacement ones Charles Mills wrote: In other words, if one had to venture a *guess* it would be that the immediate instructions were in practice a heck of a lot faster. (Don't know that this sort of issue is relevant to the relative versus branch/displacement comparison.) snip This is a performance question, right? So it depends. (Yes, I know you knew that.) And I'm not a performance expert, nor did I stay in a well-known hotel last night. But I'll venture out on this branch anyway, to say... That John hit the nail on the head when he said that processors have gotten a lot faster than memory. To put this into perspective, since the 3168-3 processor came out in the 1970's the cost of a cache-miss real memory access when counted in machine cycles has risen over 400x. (That's not a typo. It's really more than a factor of four hundred.) That some of our compilers are maximizing the use of immediate and register operands to some extent just for this reason. Although the path length is theoretically longer for some of these strings of instructions, they avoid memory accesses often enough that on a practical level they are faster. That it's time for everyone to be thinking of memory accesses the way we've thought about I/O accesses for half a century. Avoid, buffer, prestage...etc. And, finally, that the branch instruction itself does not stand alone. One must load a register to use it as a base in order to establish addressability, and load another to use it as a displacement register, and Load instructions can cause real memory (vs. cache) accesses. So, it seems to me there can be some applicability to relative branch as well. -- 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
Re: ACS routine imbed/include function?
Kees, Could you expand on the 15 WHEN clauses? Provide a snippet? How does the * vs. % not help? Are you really parsing it down that granularly? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Monday, July 15, 2013 7:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? Bingo! This is what I had stored many years ago somewhere in migrated memory: the COPYFILT macro. It is not completely automatic, but it takes only one command to fire the automation of updating multiple tables in multiple routines. I will have a look at it again to see if it helps me this time. A function like the FILTERDD would even be more convenient. And,by the way, if someone is making up a wishlist for ACS routines: subroutines would be very helpful and also a substring function (find and replace), like in: when (mgmtclas eq B2DA)set mgtmclas = B1DA. This now takes 15 WHEN clauses for each of the values. Thanks, Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, July 15, 2013 15:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? Vernooij, CP wrote: So I probably mixed some historical info in my memory. It would be nice to have, e.g. for dsname- of volser-filtlists used in more than one routine. However, there are not many enhancements in ACS routines the last decades, so I expect this will remain a wish. You've got my curiousity turned on and I searched my *ss off since your first post! It was indeed a long time I saw any announcement for ACS enhancements if at all. But then I wonder if you were thinking about 'COPYFILT macro: COPYLIB facility for FILTLISTs'. Granted that is for initial SMS setup. On the otherside, I wonder if you were refering to FILTERDD in DFDSS. There you can probably concatenate at your leisure... Hmmm, perhaps time for a Share thing? Think of it: one set of Include/exclude for DB2 folks, another for other dbas, etc. 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: Benchmark of Relative instructions vers Base+displacement ones
Peter Farley's lament is understandable, but it is important to [better] understand that all scientific and engineering questions are statistical in character and that they become so increasingly as a subject advances. Deterministic, Newtonian methods served physics well in the 17th century; but the question is there or is there not a Higgs Boson must be and is being addressed statistically. (The tentative answer is yes.) Performance measurement has reached this stage. Non-statistical questions only mislead; such measurements are experiments that must be designed explicitly and in advance. As Sir Ronald Fisher put the matter begin extract To consult the statistician after an experiment is finished is often merely to ask him to conduct a post mortem. He can perhaps say what the experiment died of. /end extract 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: Buffering: stdout vs. stderr?
On Mon, 15 Jul 2013 09:23:40 -0500, Kirk Wolf wrote: Maybe that is one of the enhancements ? :-) Exoskeletal enhancement? Is there any rationale for making the ASCII behavior different from the EBCDIC? Actually this seems to be an issue with the stream buffering strategy. See the C/C++ RTL Ref for setvbuf(). Maybe you need to explicitly call setvbuf() for stdout/stderr with __LIBASCII ?? In fact, setvbuf( stdout, NULL, _IONBF, 4096 ); repairs the lazy buffering. Surprisingly, _IOLBF lacks that effect. Feels like a bug? loc. cit.: _IOLBF Line buffering is used for text stream I/O and terminal I/O. The buffer is flushed when a newline character is used (text stream), when the buffer is full, or when input is requested (terminal). The value for size must be greater than 0. Hmmm. On a hunch, I added ...\025 to the end of each format string. Now, the buffer gets flushed, even with _IOLBF. Ah! It's that kind of bug. Guess what I hate! Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ACS routine imbed/include function?
Hi, What we do to get around this is to use ISPF skeletons (with a bit of REXX involved) which we run as part of a two stop batch process using Naviquest. Within the REXX, we build a table of our DB2 systems, and then the skeleton has )DOT constructions to loop around building those 15 WHEN clauses in a standard way. The first step works out the next suffix for the routine, builds it into a work dataset, and sure SUPERC to compare to the existing (current) routine (which we review to make sure there is no unexpected change). Having reviewed that, the next step copies into the production ACS routines dataset, and does the translate and validate. The activation is then done manually after the two jobs are run. We don't really have local content, although there are a little extra )SEL type inclusions by sysplex in the infrastructure part of the skeleton (the ACS code is thus in some way standard across all our life-cycle sysplexes). Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Dow Benelux B.V. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: 15 July 2013 16:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? Bingo! This is what I had stored many years ago somewhere in migrated memory: the COPYFILT macro. It is not completely automatic, but it takes only one command to fire the automation of updating multiple tables in multiple routines. I will have a look at it again to see if it helps me this time. A function like the FILTERDD would even be more convenient. And,by the way, if someone is making up a wishlist for ACS routines: subroutines would be very helpful and also a substring function (find and replace), like in: when (mgmtclas eq B2DA)set mgtmclas = B1DA. This now takes 15 WHEN clauses for each of the values. Thanks, Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, July 15, 2013 15:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? Vernooij, CP wrote: So I probably mixed some historical info in my memory. It would be nice to have, e.g. for dsname- of volser-filtlists used in more than one routine. However, there are not many enhancements in ACS routines the last decades, so I expect this will remain a wish. You've got my curiousity turned on and I searched my *ss off since your first post! It was indeed a long time I saw any announcement for ACS enhancements if at all. But then I wonder if you were thinking about 'COPYFILT macro: COPYLIB facility for FILTLISTs'. Granted that is for initial SMS setup. On the otherside, I wonder if you were refering to FILTERDD in DFDSS. There you can probably concatenate at your leisure... Hmmm, perhaps time for a Share thing? Think of it: one set of Include/exclude for DB2 folks, another for other dbas, etc. 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 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: Missing HSM backups
A new wrinkle and possibly related. I have a job that creates two GDGs in the same Management Class. Both should be backed up. However, one gets backed up while the other doesn't. The backup for the first shows up in HSM's job logs at the point of backup but the second is entirely absent from HSM logs. Even if HSM is having trouble backing up a dataset, shouldn't it be showing up in the job logs? David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David G. Schlecht Sent: Wednesday, July 03, 2013 11:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Missing HSM backups Cheers Mainframe’s Finest, I’m going batty over this or perhaps already have. I have a management class that works for recent data but fails intermittently at the moment of performance. About half the datasets lose their backups around day 50. I have date-derived dataset names that get backups once created but after ~50 days the backups start to disappear. Doing a Listcat ,the problem datasets show LBAKUP of .000.. Listcat also verifies that the datasets all have the correct classes and storage group. Since the backups disappear, HSM refuses to delete the expired datasets. There are no references to the problem datasets in the HSM job logs other than an occasional PARTREL. Anyone seen anything like this or have any suggestions on where to look next? The management class and storage group definitions follow: Expire after Days Non-usage . : 35 Expire after Date/Days . . . . : 35 Retention Limit . . . . . . . : 35 Partial Release . . . . . . : YES Migration Attributes Primary Days Non-usage . : 3 Level 1 Days Date/Days . : 5 Command or Auto Migrate . : COMMAND Backup Attributes, Backup frequency . . . . . . . . . . . : 0 Number of backup versions . . . . . . . : 3 (Data Set Exists), Number of backup versions . . . . . . . : 2 (Data Set Deleted), Retain days only backup version . . . . : 70 (Data Set Deleted), Retain days extra backup versions . . . : 35 Admin or User Command Backup . . . . . : BOTH Auto Backup . . . . . . . . . . . . . . : YES Backup copy technique . . . . . . . . . : STANDARD STORAGE GROUP Auto Migrate . . P Auto Backup . . Y Auto Dump . . . N Overflow . . . . N Guaranteed Backup Frequency . . . . . . NOLIMIT David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov This communication, including any attachments, may contain confidential information and is intended only for the individual or entity to which it is addressed. Any review, dissemination or copying of this communication by anyone other than the intended recipient is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and delete all copies of the original message. -- 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: Missing HSM backups
David, Is it possible that your time window for DFHSM backups is not long enough for the incremental backups to complete? Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David G. Schlecht Sent: Monday, July 15, 2013 9:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Missing HSM backups A new wrinkle and possibly related. I have a job that creates two GDGs in the same Management Class. Both should be backed up. However, one gets backed up while the other doesn't. The backup for the first shows up in HSM's job logs at the point of backup but the second is entirely absent from HSM logs. Even if HSM is having trouble backing up a dataset, shouldn't it be showing up in the job logs? David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing HSM backups
Interesting thought. Let me check it out. David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ulrich Krueger Sent: Monday, July 15, 2013 9:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Missing HSM backups David, Is it possible that your time window for DFHSM backups is not long enough for the incremental backups to complete? Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David G. Schlecht Sent: Monday, July 15, 2013 9:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Missing HSM backups A new wrinkle and possibly related. I have a job that creates two GDGs in the same Management Class. Both should be backed up. However, one gets backed up while the other doesn't. The backup for the first shows up in HSM's job logs at the point of backup but the second is entirely absent from HSM logs. Even if HSM is having trouble backing up a dataset, shouldn't it be showing up in the job logs? David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record - IPADDR
I would like to see world peace and an end to hunger. g Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Monday, July 15, 2013 6:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF record - IPADDR IMO, the problem with SMF records is not the documentation. I would like to see IBM publish some sort of machine-readable schema document (say, in XML or JSON) for each record that describes the structure and datatypes in each record. 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: Missing HSM backups
We have two lpars plexed, sharing DASD and catalogs and run HSM on each. Lpar-1 is supposed to handle the backups. Lpar-1: AUTOBACKUPSTART(1700 1800 1900) Lpar-2: AUTOBACKUPSTART( ) Backups start at 17:00 and typically end around 17:11, hence, it seems sufficient time is provided. David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ulrich Krueger Sent: Monday, July 15, 2013 9:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Missing HSM backups David, Is it possible that your time window for DFHSM backups is not long enough for the incremental backups to complete? Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David G. Schlecht Sent: Monday, July 15, 2013 9:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Missing HSM backups A new wrinkle and possibly related. I have a job that creates two GDGs in the same Management Class. Both should be backed up. However, one gets backed up while the other doesn't. The backup for the first shows up in HSM's job logs at the point of backup but the second is entirely absent from HSM logs. Even if HSM is having trouble backing up a dataset, shouldn't it be showing up in the job logs? David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ACS routine imbed/include function?
My sample size must be too small to be significant, but it seems that over the past decade or two, that vast majority of ACS administrators I've spoken to would love to have some sort of facility which would allow sharing common source code between the ACS routines. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Monday, July 15, 2013 3:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? So I probably mixed some historical info in my memory. It would be nice to have, e.g. for dsname- of volser-filtlists used in more than one routine. However, there are not many enhancements in ACS routines the last decades, so I expect this will remain a wish. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, July 12, 2013 20:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? Sorry about the garble. The include function available to ACS routines is that of the editor. There is still value to a separate member(s) for common code, FILTLIST in particular. But it is a manual function to pull them into each member before compiling. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Lizette Koehler Sent: Friday, July 12, 2013 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? I will be interested in the answer. I know you cannot have more than 255 entire in one filtlist. But I was not aware of any include function Lizette -Original Message- From: Gibney, Dave gib...@wsu.edu Sent: Jul 12, 2013 9:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? As of z/OS a do by hand function. Would be useful as part of the ACS language :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Friday, July 12, 2013 5:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ACS routine imbed/include function? Hello group, I vaguely remember reading, quite some time ago, about a function to imbed/include coding into ACS routines. E.g. if you have large filtlists, you code them in a separate member on your ACSsource and have them read (included) into your ACS routine at compile time. The advantage would be, that you keep the coding more readable and that you can maintain the list on one place and include it into several ACS routines. I would like to use this now, but cannot find any documentation about it. Was I mistaken and did I confuse it with some other function or can someone point me to the correct place to learn more about it? Thanks, Kee -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Buffering: stdout vs. stderr?
Gil, I agree; that sounds like a defect (or enhancement? :-) On Mon, Jul 15, 2013 at 10:38 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Mon, 15 Jul 2013 09:23:40 -0500, Kirk Wolf wrote: Maybe that is one of the enhancements ? :-) Exoskeletal enhancement? Is there any rationale for making the ASCII behavior different from the EBCDIC? Actually this seems to be an issue with the stream buffering strategy. See the C/C++ RTL Ref for setvbuf(). Maybe you need to explicitly call setvbuf() for stdout/stderr with __LIBASCII ?? In fact, setvbuf( stdout, NULL, _IONBF, 4096 ); repairs the lazy buffering. Surprisingly, _IOLBF lacks that effect. Feels like a bug? loc. cit.: _IOLBF Line buffering is used for text stream I/O and terminal I/O. The buffer is flushed when a newline character is used (text stream), when the buffer is full, or when input is requested (terminal). The value for size must be greater than 0. Hmmm. On a hunch, I added ...\025 to the end of each format string. Now, the buffer gets flushed, even with _IOLBF. Ah! It's that kind of bug. Guess what I hate! Thanks, 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: Benchmark of Relative instructions vers Base+displacement ones
In 985915eee6984740ae93f8495c624c6c2319af4...@jscpcwexmaa1.bsg.ad.adp.com, on 07/15/2013 at 11:01 AM, Farley, Peter x23353 peter.far...@broadridge.com said: I remember when I first was disabused of the quaint notion that the CPU performance of a batch z/OS application could be measured in a deterministic manner, There's deterministic and there's usefully deterministic. Back when IBM was still publishing instruction timings, there was a progression to increasingly complex timing formulae. There was also the issue that the time ranking of two code sequences would vary by model. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Benchmark of Relative instructions vers Base+displacement ones
Whatever their timing formulas or model-dependant behavior, in the old days of non-pipelined or minimally-pipelined CPU engines you ran your batch application program once with the appropriate test data using the production load module on an unloaded or lightly loaded machine, then you ran it once more with the same test data using a changed version of the same load module on that same machine, and you could compare the timing of those two jobs to see if you had improved or worsened that program's performance characteristics. Two tests and done, and good enough for all but the most finicky measurements (or for ISV code, which had to run on many varying models -- they always had a tougher job measuring useful performance characteristics, BTDTGTTS). Now you run each version multiple times (some say 10 or more, others say 5) and take an average of the numbers to make that same comparison or it's not good enough. But as I said previously, I know that's just the way it is now, so I live with it. It's just part of the job today. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, July 15, 2013 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Benchmark of Relative instructions vers Base+displacement ones In 985915eee6984740ae93f8495c624c6c2319af4...@jscpcwexmaa1.bsg.ad.adp.com, on 07/15/2013 at 11:01 AM, Farley, Peter x23353 said: I remember when I first was disabused of the quaint notion that the CPU performance of a batch z/OS application could be measured in a deterministic manner, There's deterministic and there's usefully deterministic. Back when IBM was still publishing instruction timings, there was a progression to increasingly complex timing formulae. There was also the issue that the time ranking of two code sequences would vary by model. -- 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
Re: SMF record - IPADDR
I could agree with that too. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, July 15, 2013 9:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF record - IPADDR In 003801ce8119$55b87300$01295900$@com, on 07/15/2013 at 12:08 AM, Roger W. Suhr suhr...@gmail.com said: I'd vote for both. All IBM product SMF records type 0-200 should be documented in the SMF manual. Alternatively, the SMF and control blocks manuals should have links[1] to the appropriate product manuals. [1] In a usable form, e.g., a PDF should allow copying or selecting the URL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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
