Re: Question on use of LPARNAME, SYSNAME and SMFID
Thanks to all that responded so far. I expected that there is a lot of history behind the decisions and that makes the decisions persistent and difficult to change. Although, as Ed pointed out, being able to be confident because of different values is useful, it’s probably not an option to many. Broadcom also makes an available with is interesting for historical purposes but hardly a value that has merit apart from historical investigation. My current thinking is to simply take the as a combination going forward so that I’ve preserved all three and gained the benefit of the use of a difference between and If anyone has other thoughts I’m all ears. Thanks! Matt Hogstrom m...@hogstrom.org > On Feb 10, 2023, at 5:42 PM, Rob Scott wrote: > > Matt > > Of course the big difference is that SMFID is 4 characters and SYSNAME is 8 > > I know that software vendors often run QA on systems where all three (incl > LPARNAME) are deliberately different to catch any assumptions made in code or > product sample JCL. > > I have seen customers using different values for SMFID and when queried I am > normally told that it relates to historical chargeback and accounting (and > very possible that the reasons for it are forgotten/lost). > > Rob Scott > Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get MetalC "INLINE" report
On 11/02/2023 7:42 am, Farley, Peter wrote: I'd consider this to be a bug in the compiler. The listing pmap should show all source statements, at the place where they are executed. If they are inlined twice, they should be listed twice. That sounds like it would ultimately be confusing. An inlined piece of code might be inlined in hundreds of places. In general, my expectation of optimization is that it happens behind the scenes and doesn't change visible behavior. A huge growth in the compiler listing is probably not what people want. Also, once a piece of code is inlined, other optimizations are opened to the compiler. - The compiler might know some input parameters, so parts of the code are redundant and can be removed, loops can be unrolled etc. - Statements can be reordered - parts of the inlined code might be moved outside loops in the calling code - The compiler might even swap the order of inner/outer loops, so that part of the calling code ends up inside a loop in the inlined section of code These would be very difficult to reflect in a compiler listing (and are the reasons debugging optimized code is problematic). -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get MetalC "INLINE" report
I have CA Intertest Batch and COBOL 6.2 here and I have NEVER been able to stop in ANY statement of an inlined paragraph. But these are production-level programs that are far more complex than your example. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Friday, February 10, 2023 3:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to get MetalC "INLINE" report There are two cases for inlining: 1. The performed paragraph was only performed from one place 2. The performed paragraph was performed from multiple places I just tested CA InterTest Batch with COBOL 6.2 at OPT(2),INLINE. It definitely can stop (i.e. catch a breakpoint) set in case 1. For case 2, it only caught it in one of the places where it was inlined. Note that InterTest Batch runs the application code in a VM. The program I tested is: -- identification division. program-id. cobtest. data division. linkage section. 01 parm pic s9(04) binary. procedure division using parm. mainline section. perform inline. display parm. if parm not = 42 perform inline end-if. display parm. goback. inline section. add parm to parm. *> breakpoint set here compute parm = parm * parm. -- I don't know why this would be different in COBOL 6 than in previous COBOL. IBM COBOL has inlined code for a long time, and there's no difference in the generated code in that respect that I know of. Except for one thing: COBOL 6 is not good at identifying the inlined statements in the compile listing pmap. In the above case, the listing only gives the "add parm to parm" and "computer parm = parm * parm" statements once (where it first is inlined). The second time it is definitely inlining them, but just as generated instructions belonging to the "if parm not = 42" statement. I'd consider this to be a bug in the compiler. The listing pmap should show all source statements, at the place where they are executed. If they are inlined twice, they should be listed twice. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Friday, February 10, 2023 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to get MetalC "INLINE" report AFAIK, not the way inlining works on any z/OS compiler output I have ever seen. Recent versions of Enterprise COBOL, for instance, can inline performed paragraphs (and tell you that they did so) such that no HLL debugger known to me can let you stop inside the inlined code. If you have to debug E.COBOL inlined code you must recompile with the NOINLINE compiler option (or in the worst cases, NOOPT). Peter -- 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: Virtual tape mount error
Re.: IEC518I sfw err stat MLNOMTL MLNOMTL Volume does not reside in this Manual Tape Library. and MLNOTVR No TCDB TVR entry exists for this MTL volume. Just to tie up the loose end, Peter informed me that there was some kind of typo in volume initialization. Regards, Mike Baldwin Cartagena Software Limited Markham, Ontario, Canada https://cartagena.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get MetalC "INLINE" report
There are two cases for inlining: 1. The performed paragraph was only performed from one place 2. The performed paragraph was performed from multiple places I just tested CA InterTest Batch with COBOL 6.2 at OPT(2),INLINE. It definitely can stop (i.e. catch a breakpoint) set in case 1. For case 2, it only caught it in one of the places where it was inlined. Note that InterTest Batch runs the application code in a VM. The program I tested is: -- identification division. program-id. cobtest. data division. linkage section. 01 parm pic s9(04) binary. procedure division using parm. mainline section. perform inline. display parm. if parm not = 42 perform inline end-if. display parm. goback. inline section. add parm to parm. *> breakpoint set here compute parm = parm * parm. -- I don't know why this would be different in COBOL 6 than in previous COBOL. IBM COBOL has inlined code for a long time, and there's no difference in the generated code in that respect that I know of. Except for one thing: COBOL 6 is not good at identifying the inlined statements in the compile listing pmap. In the above case, the listing only gives the "add parm to parm" and "computer parm = parm * parm" statements once (where it first is inlined). The second time it is definitely inlining them, but just as generated instructions belonging to the "if parm not = 42" statement. I'd consider this to be a bug in the compiler. The listing pmap should show all source statements, at the place where they are executed. If they are inlined twice, they should be listed twice. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Friday, February 10, 2023 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to get MetalC "INLINE" report AFAIK, not the way inlining works on any z/OS compiler output I have ever seen. Recent versions of Enterprise COBOL, for instance, can inline performed paragraphs (and tell you that they did so) such that no HLL debugger known to me can let you stop inside the inlined code. If you have to debug E.COBOL inlined code you must recompile with the NOINLINE compiler option (or in the worst cases, NOOPT). Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on use of LPARNAME, SYSNAME and SMFID
Hi, We use different lpar names for our base systems and recovery system. And we use that variable to choose the IPL sequence for each situation. As for smfid and sysname, yes, they usually tend to be the same. Regards Jack On Fri, Feb 10, 2023, 16:16 Matt Hogstrom wrote: > I’m doing some research involving historical SMF data. It’s caused me to > wonder how engineers use the , and symbols. From > what I can see is that in most instances they are the same. LPARNAME > appears to me to have little value in that if may or may not have an > affinity for a z/OS guest in terms of naming. > > and seem to generally correlate. I’m curious if there are > use cases where these are different and what the purpose might be? > > Appreciate any insight / best parties that people are using. > > Matt Hogstrom > m...@hogstrom.org > > A generalist knows less and less about more and more till he knows nothing > about everything > A specialist knows more and more about less and less till he knows > everything about nothing > > > -- > 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: Question on use of LPARNAME, SYSNAME and SMFID
On 2/10/2023 8:15 AM, Matt Hogstrom wrote: I’m doing some research involving historical SMF data. It’s caused me to wonder how engineers use the , and symbols. From what I can see is that in most instances they are the same. LPARNAME appears to me to have little value in that if may or may not have an affinity for a z/OS guest in terms of naming. We ensure all three names are different to minimize confusion about which one you are seeing displayed to you. That applies to JES member names as well... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3420 conversion?
On Fri, 10 Feb 2023 at 13:01, Phil Smith III wrote: Is a 40-year-old tape going to be physically readable? I have no idea, but > wonder. I have some 30-year-plus tapes in the basement, but hope not to > ever > care (and as time marches on, the odds of course reduce.) > I managed to read tapes from around 1972-79 that I had kept in an open carton in my attic through summer heat and winter cold. The only ones I couldn't read turned out to be 800 BPI, and not supported by my drive. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goodbye and thanks for all the fish
Well said Jim. And I know it is appreciated. Bob thought a lot of you. As you know, I first crossed paths with Bob and you back in 2008. We hit it off immediately and I joined you at OPM. I've lost a good friend and mentor. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jim Marshall Sent: Friday, February 10, 2023 9:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Goodbye and thanks for all the fish Bob Richards will be missed by all up here in the greater DC area. When I was the Data Center Technical Lead at the US Office of Personnel Management, 2001-2013, after retiring from the Air Force. I'd read Bob's posts and knew he was well qualified. He and Rebecca were in Atlanta where Bob was working for Suntrust Bank. He was let go and immediately I asked if he would be interested to come to this area and work for my Systems Services contractor. He said yes and he was hired, onsite and got to work in no time. This was in the late 2000s. He worked with the team maintaining our z9BC Parallel Sysplex providing a 24/7 system for the US Federal Retirement & Healthcare Systems and also then OPM did 95% of all the Federal Background Investigations. It was an operation covering the entire world. Bob and the team made my Disaster Recovery Plan come true when they would fully recover our Sysplex at IBM Sterling Forest NY, in 24 hours with only up to 5 seconds of Data loss and be able to run a 72 hour test of our worldwide operation without impacting the 24/7 production systems in DC. Bob did z/OS and really made me look good when the Data Center achieved 5 years of Continuous Operations, including all the Database systems with only unavailability of our system including all applications for 4 hours per week. In 5 years we only had 28 hours of systems unavailability of which 18 hours was due to UPS batteries which were 13 years old; non-IT management would not spring for the money for new batteries until I retired in 2013 and tried to get Bob to apply his 8 years of Air Force service into a Federal Job but he enjoyed what he did and if hired he'd fill my old job which was strictly hands-off despite being an ACE Systems Programmer. Bob knew the end was coming but worked up until a week before it was time. My heart goes out to Rebecca and know she will miss Bob terribly. He was one class act, a knowledgeable professional and fun to be around. He and the team sure did make me look good in the eyes of the CIO, non-IT Management and our retirees of which approximately 500K Federal Retirees are located overseas. Thanks Bob and to Rebecca for supporting him on all those Sunday Mornings from 0500-0900 to do upgrades and changes getting all system up by 0900; speak about pressure Jim Marshall, USAF(Ret) -- 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: Goodbye and thanks for all the fish
Is there a tribute to him at CBTTAPE? From: IBM Mainframe Discussion List on behalf of willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu> Sent: Friday, February 10, 2023 2:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Goodbye and thanks for all the fish Thanks Rebecca for the heartbreaking news. His absence will be felt for years to come by members of this board. His technical knowledge and wit is lost forever.I am sure, some place up there, Robert is smiling down on you and your family.May he rest in place. Willie. On Wednesday, February 8, 2023 at 08:11:02 p.m. EST, Rebecca Richards <049eeae74309-dmarc-requ...@listserv.ua.edu> wrote: Hi All, This is Rebecca Richards. My husband Robert Richards has been an member of this list for many years.I just wanted let you know he died of bladder cancer this past Friday. I wanted to let everyone know Rebecca Richards Sent from Yahoo Mail for iPad On Wednesday, February 8, 2023, 3:17 PM, Wayne Bickerdike wrote: I retired in 2021 but I still maintain an interest here. Good for the brain cells. Managed to lose 3Kgs and reduce my blood pressure :) On Thu, Feb 9, 2023 at 2:11 AM Steve Thompson wrote: > Sorry to see you go. And I too am not a very active member. I > read a lot and learn stuff. > > Hope you enjoy your retirement. Or, un-retirement if that is what > you wish. > > Regards, > Steve Thompson > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goodbye and thanks for all the fish
Thanks Rebecca for the heartbreaking news. His absence will be felt for years to come by members of this board. His technical knowledge and wit is lost forever.I am sure, some place up there, Robert is smiling down on you and your family.May he rest in place. Willie. On Wednesday, February 8, 2023 at 08:11:02 p.m. EST, Rebecca Richards <049eeae74309-dmarc-requ...@listserv.ua.edu> wrote: Hi All, This is Rebecca Richards. My husband Robert Richards has been an member of this list for many years.I just wanted let you know he died of bladder cancer this past Friday. I wanted to let everyone know Rebecca Richards Sent from Yahoo Mail for iPad On Wednesday, February 8, 2023, 3:17 PM, Wayne Bickerdike wrote: I retired in 2021 but I still maintain an interest here. Good for the brain cells. Managed to lose 3Kgs and reduce my blood pressure :) On Thu, Feb 9, 2023 at 2:11 AM Steve Thompson wrote: > Sorry to see you go. And I too am not a very active member. I > read a lot and learn stuff. > > Hope you enjoy your retirement. Or, un-retirement if that is what > you wish. > > Regards, > Steve Thompson > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get MetalC "INLINE" report
On Fri, 10 Feb 2023 12:32:28 -0500, Tony Harminc wrote: >On Fri, 10 Feb 2023 at 12:25, Paul Gilmartin wrote: >... >> when the functions are inlined there is no entry point for them, no FPB or >> FEPM compiler control data generated for them, etc. >> > ... >> That's just wrong. Even if the compiler intends to generate inline code >> for calls to a function, it >> should generate an externally callable entry name, perhaps to an inline >> code body, regardless of >> optimization level. > >Really? What would that be useful for? Pretty much by definition inlined >code doesn't have documented calling conventions (indeed they may well vary >each time the inlined code is emitted depending on context). I suppose it >would be good for there to be an external name for the places the inlined >function is called (an ER style entry), but surely not for the actual >inlined code. > My [mis-]understanding was that when you coded the function, not specified "inline", you intended that it be callable from external translation units, but the compiler frustrated this by willy-nilly making it purely inline. I would expect that if you declared the function in standard fashion (was there a prototype?), the compiler would generate one externally callable instance then generate inline code for calls ad lib. This is similar to the POSIX specification that an implementer may code a standard functions as shell builtins but there must still be instances callable by the exec() family of functions. (Frequently those are implemented as "system( "sh -c " argv[ 0 ] )".) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get MetalC "INLINE" report
I meant to add (but hit Send too soon), I am not as much concerned about *how* the inlining is done as I am in getting the compiler to TELL me that it inlined some functions, and where that was done. It would be nice to be able to bypass some procedural code inside a function when it is inlined as opposed to when it is NOT inlined (or even the reverse, ADD come code when inlined), but I know that is wishful thinking. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Friday, February 10, 2023 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to get MetalC "INLINE" report AFAIK, not the way inlining works on any z/OS compiler output I have ever seen. Recent versions of Enterprise COBOL, for instance, can inline performed paragraphs (and tell you that they did so) such that no HLL debugger known to me can let you stop inside the inlined code. If you have to debug E.COBOL inlined code you must recompile with the NOINLINE compiler option (or in the worst cases, NOOPT). Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, February 10, 2023 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to get MetalC "INLINE" report On Fri, 10 Feb 2023 16:58:49 +, Farley, Peter wrote: >I have been writing some MetalC programs and ran into a case where the normal >OPTIMIZE setting (OPT(2)) provably inlined a couple of small functions. It is >not immediately obvious in the MetalC ASM output, but when the functions are >inlined there is no entry point for them, no FPB or FEPM compiler control data >generated for them, etc. > ... That's just wrong. Even if the compiler intends to generate inline code for calls to a function, it should generate an externally callable entry name, perhaps to an inline code body, regardless of optimization level. SR. The modifier "static" has a flavor of "not external", and might be used to declare an inline-only function. -- 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: 3420 conversion?
Tony, IBM Sterling Forest used to have tape drives dating back to the stone age for just this purpose. No idea what the process is to use them, if indeed they still exist. Is a 40-year-old tape going to be physically readable? I have no idea, but wonder. I have some 30-year-plus tapes in the basement, but hope not to ever care (and as time marches on, the odds of course reduce.) ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3420 conversion?
I have found someone that will convert it. As it's 40 years old, I will report back the success or failure of the conversion. Tony Thigpen M. Ray Mullins wrote on 2/10/23 11:57: The only person that comes to mind is Al Kossow of Bitsavers, but based on your other comment I understand the reluctance of shipping. (He read my old Prime tapes and back when Paul Allen's museum was running, they became the base for their PRIMOS emulations.) On 2023-02-09 17:32, Tony Thigpen wrote: I need a single 3420 tape converted. Anyone know of someone that can do it? Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get MetalC "INLINE" report
AFAIK, not the way inlining works on any z/OS compiler output I have ever seen. Recent versions of Enterprise COBOL, for instance, can inline performed paragraphs (and tell you that they did so) such that no HLL debugger known to me can let you stop inside the inlined code. If you have to debug E.COBOL inlined code you must recompile with the NOINLINE compiler option (or in the worst cases, NOOPT). Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, February 10, 2023 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to get MetalC "INLINE" report On Fri, 10 Feb 2023 16:58:49 +, Farley, Peter wrote: >I have been writing some MetalC programs and ran into a case where the normal >OPTIMIZE setting (OPT(2)) provably inlined a couple of small functions. It is >not immediately obvious in the MetalC ASM output, but when the functions are >inlined there is no entry point for them, no FPB or FEPM compiler control data >generated for them, etc. > ... That's just wrong. Even if the compiler intends to generate inline code for calls to a function, it should generate an externally callable entry name, perhaps to an inline code body, regardless of optimization level. SR. The modifier "static" has a flavor of "not external", and might be used to declare an inline-only function. -- 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: How to get MetalC "INLINE" report
On Fri, 10 Feb 2023 at 12:25, Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Fri, 10 Feb 2023 16:58:49 +, Farley, Peter wrote: > > >I have been writing some MetalC programs and ran into a case where the > normal OPTIMIZE setting (OPT(2)) provably inlined a couple of small > functions. It is not immediately obvious in the MetalC ASM output, but > when the functions are inlined there is no entry point for them, no FPB or > FEPM compiler control data generated for them, etc. > > ... > That's just wrong. Even if the compiler intends to generate inline code > for calls to a function, it > should generate an externally callable entry name, perhaps to an inline > code body, regardless of > optimization level. > Really? What would that be useful for? Pretty much by definition inlined code doesn't have documented calling conventions (indeed they may well vary each time the inlined code is emitted depending on context). I suppose it would be good for there to be an external name for the places the inlined function is called (an ER style entry), but surely not for the actual inlined code. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get MetalC "INLINE" report
On Fri, 10 Feb 2023 16:58:49 +, Farley, Peter wrote: >I have been writing some MetalC programs and ran into a case where the normal >OPTIMIZE setting (OPT(2)) provably inlined a couple of small functions. It is >not immediately obvious in the MetalC ASM output, but when the functions are >inlined there is no entry point for them, no FPB or FEPM compiler control data >generated for them, etc. > ... That's just wrong. Even if the compiler intends to generate inline code for calls to a function, it should generate an externally callable entry name, perhaps to an inline code body, regardless of optimization level. SR. The modifier "static" has a flavor of "not external", and might be used to declare an inline-only function. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How to get MetalC "INLINE" report
I have been writing some MetalC programs and ran into a case where the normal OPTIMIZE setting (OPT(2)) provably inlined a couple of small functions. It is not immediately obvious in the MetalC ASM output, but when the functions are inlined there is no entry point for them, no FPB or FEPM compiler control data generated for them, etc. I tried specifying INLINE(AUTO,REPORT,100,1000) in the compiler PARM input to get the "Inline Report" as documented in the C/C++ User's Guide but I never get an inlined procedure report. Is there some other PARM I need to specify to the compiler to get that report in the SYSPRINT output, or is this another case of a compiler bug, or worse yet "you can't get there from here" because it is MetalC and not plain C? Peter 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: 3420 conversion?
The only person that comes to mind is Al Kossow of Bitsavers, but based on your other comment I understand the reluctance of shipping. (He read my old Prime tapes and back when Paul Allen's museum was running, they became the base for their PRIMOS emulations.) On 2023-02-09 17:32, Tony Thigpen wrote: I need a single 3420 tape converted. Anyone know of someone that can do it? Tony Thigpen -- 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: Question on use of LPARNAME, SYSNAME and SMFID
Matt Of course the big difference is that SMFID is 4 characters and SYSNAME is 8 I know that software vendors often run QA on systems where all three (incl LPARNAME) are deliberately different to catch any assumptions made in code or product sample JCL. I have seen customers using different values for SMFID and when queried I am normally told that it relates to historical chargeback and accounting (and very possible that the reasons for it are forgotten/lost). Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Matt Hogstrom Sent: 10 February 2023 16:16 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question on use of LPARNAME, SYSNAME and SMFID EXTERNAL EMAIL I’m doing some research involving historical SMF data. It’s caused me to wonder how engineers use the , and symbols. From what I can see is that in most instances they are the same. LPARNAME appears to me to have little value in that if may or may not have an affinity for a z/OS guest in terms of naming. and seem to generally correlate. I’m curious if there are use cases where these are different and what the purpose might be? Appreciate any insight / best parties that people are using. Matt Hogstrom m...@hogstrom.org A generalist knows less and less about more and more till he knows nothing about everything A specialist knows more and more about less and less till he knows everything about nothing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question on use of LPARNAME, SYSNAME and SMFID
I’m doing some research involving historical SMF data. It’s caused me to wonder how engineers use the , and symbols. From what I can see is that in most instances they are the same. LPARNAME appears to me to have little value in that if may or may not have an affinity for a z/OS guest in terms of naming. and seem to generally correlate. I’m curious if there are use cases where these are different and what the purpose might be? Appreciate any insight / best parties that people are using. Matt Hogstrom m...@hogstrom.org A generalist knows less and less about more and more till he knows nothing about everything A specialist knows more and more about less and less till he knows everything about nothing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
BPAM and UNIX CCSIDs
From Using Data Sets: //ddname DD PATH='/dir1/dir2/file', ... You can then use BPAM to read files as if they were members of a PDS or PDSE. Suppose the UNIX directory contains members tagged with various CCSIDs. Is there a way to retrieve the CCSID of any member accessed? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goodbye and thanks for all the fish
As a co-worker and friend of Bob's I reiterate every word, when he left Boeing he left a hole there in more ways than one, I had no idea talking to him that he was sick, struggling in any way, he never let it on. his friendship and contribution will surly be missed. thanks Jim for filling in the holes for us. RIP Bob Carmen On 2/10/2023 8:55 AM, Jim Marshall wrote: Bob Richards will be missed by all up here in the greater DC area. When I was the Data Center Technical Lead at the US Office of Personnel Management, 2001-2013, after retiring from the Air Force. I'd read Bob's posts and knew he was well qualified. He and Rebecca were in Atlanta where Bob was working for Suntrust Bank. He was let go and immediately I asked if he would be interested to come to this area and work for my Systems Services contractor. He said yes and he was hired, onsite and got to work in no time. This was in the late 2000s. He worked with the team maintaining our z9BC Parallel Sysplex providing a 24/7 system for the US Federal Retirement & Healthcare Systems and also then OPM did 95% of all the Federal Background Investigations. It was an operation covering the entire world. Bob and the team made my Disaster Recovery Plan come true when they would fully recover our Sysplex at IBM Sterling Forest NY, in 24 hours with only up to 5 seconds of Data loss and be able to run a 72 hour test of our worldwide operation without impacting the 24/7 production systems in DC. Bob did z/OS and really made me look good when the Data Center achieved 5 years of Continuous Operations, including all the Database systems with only unavailability of our system including all applications for 4 hours per week. In 5 years we only had 28 hours of systems unavailability of which 18 hours was due to UPS batteries which were 13 years old; non-IT management would not spring for the money for new batteries until I retired in 2013 and tried to get Bob to apply his 8 years of Air Force service into a Federal Job but he enjoyed what he did and if hired he'd fill my old job which was strictly hands-off despite being an ACE Systems Programmer. Bob knew the end was coming but worked up until a week before it was time. My heart goes out to Rebecca and know she will miss Bob terribly. He was one class act, a knowledgeable professional and fun to be around. He and the team sure did make me look good in the eyes of the CIO, non-IT Management and our retirees of which approximately 500K Federal Retirees are located overseas. Thanks Bob and to Rebecca for supporting him on all those Sunday Mornings from 0500-0900 to do upgrades and changes getting all system up by 0900; speak about pressure Jim Marshall, USAF(Ret) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Carmen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goodbye and thanks for all the fish
Bob Richards will be missed by all up here in the greater DC area. When I was the Data Center Technical Lead at the US Office of Personnel Management, 2001-2013, after retiring from the Air Force. I'd read Bob's posts and knew he was well qualified. He and Rebecca were in Atlanta where Bob was working for Suntrust Bank. He was let go and immediately I asked if he would be interested to come to this area and work for my Systems Services contractor. He said yes and he was hired, onsite and got to work in no time. This was in the late 2000s. He worked with the team maintaining our z9BC Parallel Sysplex providing a 24/7 system for the US Federal Retirement & Healthcare Systems and also then OPM did 95% of all the Federal Background Investigations. It was an operation covering the entire world. Bob and the team made my Disaster Recovery Plan come true when they would fully recover our Sysplex at IBM Sterling Forest NY, in 24 hours with only up to 5 seconds of Data loss and be able to run a 72 hour test of our worldwide operation without impacting the 24/7 production systems in DC. Bob did z/OS and really made me look good when the Data Center achieved 5 years of Continuous Operations, including all the Database systems with only unavailability of our system including all applications for 4 hours per week. In 5 years we only had 28 hours of systems unavailability of which 18 hours was due to UPS batteries which were 13 years old; non-IT management would not spring for the money for new batteries until I retired in 2013 and tried to get Bob to apply his 8 years of Air Force service into a Federal Job but he enjoyed what he did and if hired he'd fill my old job which was strictly hands-off despite being an ACE Systems Programmer. Bob knew the end was coming but worked up until a week before it was time. My heart goes out to Rebecca and know she will miss Bob terribly. He was one class act, a knowledgeable professional and fun to be around. He and the team sure did make me look good in the eyes of the CIO, non-IT Management and our retirees of which approximately 500K Federal Retirees are located overseas. Thanks Bob and to Rebecca for supporting him on all those Sunday Mornings from 0500-0900 to do upgrades and changes getting all system up by 0900; speak about pressure Jim Marshall, USAF(Ret) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3420 conversion?
Classification: Confidential The OP might try Sungard or one of the other BR providers. They usually have older devices available. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Thursday, February 9, 2023 8:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 3420 conversion? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] On Thu, 9 Feb 2023 at 20:33, Tony Thigpen wrote: > I need a single 3420 tape converted. Anyone know of someone that can do it? Buncha questions... Where is the tape, how much of a rush are you in, what's the recording density/tracks, how old is the tape itself, how old is the recording, how bad is it if it gets damaged or lost, how confidential is the data? And what kind of output do you expect? There are still a few services doing this, but fewer than there were a decade or so ago. Mike Baldwin who is on IBM-MAIN might be able to do it for you or point you to a good place near wherever you are. I can do it for no charge, but it may take quite a while since it's just me being a hobbyist and digging out my ancient 9348 drive and plugging it into a Linux box and converting to an AWS file. I have converted quite a few tapes from the early 1970s without problem, but I can offer no guarantee. I would say I'd be near the bottom of your list. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3420 conversion?
There are several companies that specialize in tape conversions such as https://datadesigninc.com/tape-media-data-conversions/ Just search 9 track tape conversions… -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
