Re: XLC architecture level question
> where do you put it and what else do you do? Ray and David have half of the answer. Specifically, you put it in a constructor for a static class instance. The first "user code" that C++ runs -- before int main() -- is static class constructors. What else do you do? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of M. Ray Mullins Sent: Wednesday, April 26, 2023 10:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC architecture level question Since this is C++, I'd stick it in a constructor for main, or (less desirable) main::init(). No LE games needed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XLC architecture level question
Since this is C++, I'd stick it in a constructor for main, or (less desirable) main::init(). No LE games needed. Cheers, Ray On 2023-04-25 14:26, Charles Mills wrote: Setting ARCH is like playing Blackjack or Twenty-one: guess too low and it is sub-optimal; guess too high and you bust. Note that everything we have said here about ARCH and TUNE applies equally to COBOL as to C/C++. Of course if you are writing programs for in-house use your universe of machines to support is much smaller. The classic error is forgetting about your DR machine. At CorreLog we managed to ship a C++ build to someone who was too back-level for our ARCH. So George -- any of you who know George know that he is a good guy but a yell-er -- yelled at me that the S0C1 was totally unacceptable -- we needed an error message. I pointed out that SYSTEM COMPLETION CODE=0C1 *is* an error message, but he was not having that. So I wrote some assembler code and C++ to compare the compiled ARCH level -- you can retrieve it with __ARCH__ -- and put out our own message if there were a conflict. Obviously you need to do that just as early in your run process as possible or the train will have already left the station and run into a wall. Here's an exercise for the readers. If you want to insert some code into a C++ module such that it will run just as early as possible during the run processing, where do you put it and what else do you do? (Hint: "right after int main(int argc, char* argv[]) and cross your fingers" are NOT the right answers.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, April 25, 2023 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC architecture level question ARCH level is a "problem" I have dealt with for 12 or so years. I say "problem" in quotes because it is not much of a problem -- you only have to revisit it once every two years, and even then it is not an urgent problem. So you don't need a solution that runs on autopilot -- you can just revisit your decision every two years or so. You need a management policy. The one I have advocated to my management is "we will support the oldest hardware supported by the oldest supported release of z/OS." I point out that while there may be lots of customers out there running z9's, they probably are not buying a whole lot of OEM products. Currently that would be ARCH(10), representing the zB/EC12, supported by z/OS V2R4. Once V2R4 goes out of service it would become -- 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: XLC architecture level question
On 26/4/23 05:26, Charles Mills wrote: Setting ARCH is like playing Blackjack or Twenty-one: guess too low and it is sub-optimal; guess too high and you bust. We have products that build using multiple ARCH options and dynamically load code for the target architecture at runtime. Here's an exercise for the readers. If you want to insert some code into a C++ module such that it will run just as early as possible during the run processing, where do you put it and what else do you do? (Hint: "right after int main(int argc, char* argv[]) and cross your fingers" are NOT the right answers.) Off the top of my head you can use a CEEBINT LE initialization exit, although this is 31-bit non-XPLINK so a legacy solution. In C++ you can simply use static initialization and run code in a C++ class constructor after defining the class in file scope. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, April 25, 2023 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC architecture level question ARCH level is a "problem" I have dealt with for 12 or so years. I say "problem" in quotes because it is not much of a problem -- you only have to revisit it once every two years, and even then it is not an urgent problem. So you don't need a solution that runs on autopilot -- you can just revisit your decision every two years or so. You need a management policy. The one I have advocated to my management is "we will support the oldest hardware supported by the oldest supported release of z/OS." I point out that while there may be lots of customers out there running z9's, they probably are not buying a whole lot of OEM products. Currently that would be ARCH(10), representing the zB/EC12, supported by z/OS V2R4. Once V2R4 goes out of service it would become -- 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: XLC architecture level question
SWAG, so I won't be surprised to be dead wrong: As an INCLUDE in the SYSIN to the binder with an ENTRY statement naming the CSECT you include. Your inserted code then has to branch to the "real" main entry point for C++, whatever that may be (I've not written or run any C++ on z/OS so I can’t be sure what that may be -- V(CEEMAIN) maybe?). Possibly may need to ORDER your new CSECT first and let the binder default to the first CSECT as the entry point? Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, April 25, 2023 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC architecture level question Setting ARCH is like playing Blackjack or Twenty-one: guess too low and it is sub-optimal; guess too high and you bust. Note that everything we have said here about ARCH and TUNE applies equally to COBOL as to C/C++. Of course if you are writing programs for in-house use your universe of machines to support is much smaller. The classic error is forgetting about your DR machine. At CorreLog we managed to ship a C++ build to someone who was too back-level for our ARCH. So George -- any of you who know George know that he is a good guy but a yell-er -- yelled at me that the S0C1 was totally unacceptable -- we needed an error message. I pointed out that SYSTEM COMPLETION CODE=0C1 *is* an error message, but he was not having that. So I wrote some assembler code and C++ to compare the compiled ARCH level -- you can retrieve it with __ARCH__ -- and put out our own message if there were a conflict. Obviously you need to do that just as early in your run process as possible or the train will have already left the station and run into a wall. Here's an exercise for the readers. If you want to insert some code into a C++ module such that it will run just as early as possible during the run processing, where do you put it and what else do you do? (Hint: "right after int main(int argc, char* argv[]) and cross your fingers" are NOT the right answers.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, April 25, 2023 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC architecture level question ARCH level is a "problem" I have dealt with for 12 or so years. I say "problem" in quotes because it is not much of a problem -- you only have to revisit it once every two years, and even then it is not an urgent problem. So you don't need a solution that runs on autopilot -- you can just revisit your decision every two years or so. You need a management policy. The one I have advocated to my management is "we will support the oldest hardware supported by the oldest supported release of z/OS." I point out that while there may be lots of customers out there running z9's, they probably are not buying a whole lot of OEM products. Currently that would be ARCH(10), representing the zB/EC12, supported by z/OS V2R4. Once V2R4 goes out of service it would become -- 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: XLC architecture level question
Setting ARCH is like playing Blackjack or Twenty-one: guess too low and it is sub-optimal; guess too high and you bust. Note that everything we have said here about ARCH and TUNE applies equally to COBOL as to C/C++. Of course if you are writing programs for in-house use your universe of machines to support is much smaller. The classic error is forgetting about your DR machine. At CorreLog we managed to ship a C++ build to someone who was too back-level for our ARCH. So George -- any of you who know George know that he is a good guy but a yell-er -- yelled at me that the S0C1 was totally unacceptable -- we needed an error message. I pointed out that SYSTEM COMPLETION CODE=0C1 *is* an error message, but he was not having that. So I wrote some assembler code and C++ to compare the compiled ARCH level -- you can retrieve it with __ARCH__ -- and put out our own message if there were a conflict. Obviously you need to do that just as early in your run process as possible or the train will have already left the station and run into a wall. Here's an exercise for the readers. If you want to insert some code into a C++ module such that it will run just as early as possible during the run processing, where do you put it and what else do you do? (Hint: "right after int main(int argc, char* argv[]) and cross your fingers" are NOT the right answers.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, April 25, 2023 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC architecture level question ARCH level is a "problem" I have dealt with for 12 or so years. I say "problem" in quotes because it is not much of a problem -- you only have to revisit it once every two years, and even then it is not an urgent problem. So you don't need a solution that runs on autopilot -- you can just revisit your decision every two years or so. You need a management policy. The one I have advocated to my management is "we will support the oldest hardware supported by the oldest supported release of z/OS." I point out that while there may be lots of customers out there running z9's, they probably are not buying a whole lot of OEM products. Currently that would be ARCH(10), representing the zB/EC12, supported by z/OS V2R4. Once V2R4 goes out of service it would become -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XLC architecture level question
ARCH level is a "problem" I have dealt with for 12 or so years. I say "problem" in quotes because it is not much of a problem -- you only have to revisit it once every two years, and even then it is not an urgent problem. So you don't need a solution that runs on autopilot -- you can just revisit your decision every two years or so. You need a management policy. The one I have advocated to my management is "we will support the oldest hardware supported by the oldest supported release of z/OS." I point out that while there may be lots of customers out there running z9's, they probably are not buying a whole lot of OEM products. Currently that would be ARCH(10), representing the zB/EC12, supported by z/OS V2R4. Once V2R4 goes out of service it would become ARCH(11). But it is a Product Management decision, not a techie decision. (Do note that minimum ARCH levels do NOT change with every release: V2R4 and V2R3 were both ARCH(10), a two-ARCH leap from V2R2). How much does it matter? If yours is compute-intensive application that churns along all day, then it is probably important. For other situations it may be less important. You might want to do some benchmarks. And! There is a companion option, TUNE. Check that one out! Here's the good news. It's not like, say, a decision to start using EXR in your assembler code, where the way back requires real work. Let's say you settle on ARCH(10). And then let's say that in six months your SVP of Sales comes running in and says "I have a $300K opportunity if we can support a z9!!!" All you would have to do is change to ARCH(7) and do a build. It is just a management decision whether it is worth the bother to do the build, test and distribute. There is no real development "effort." Also, a cheat sheet: "marketing number" (like z16) is 2 greater than ARCH and 6 greater than HLASM ZS-n. IOW, z16 is ARCH(14) and ZS-10. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Monday, April 24, 2023 2:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC architecture level question Thank you! Does that default change periodically? I suppose it must-is it always such that the default supports the oldest currently supported -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XLC architecture level question
Gil wrote: >A default of "oldest currently supported" is of little use on the day >before end of support for that version. Better would be a form to >specify "whatever version for which support is guaranteed for N days >from the current date." Akin to the "find ... -mtime n". Eh? Why is it "of little use"? It's slightly suboptimal, but at least you're not going to release something that doesn't work. What did you mean? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XLC architecture level question
On Mon, 24 Apr 2023 17:40:16 -0400, Phil Smith III wrote: > >Thank you! Does that default change periodically? I suppose it must-is it >always such that the default supports the oldest currently supported >hardware? What we don't want to do is upgrade the compile and break our >product for our customers. We can explicitly specify ARCH(10) now, but then >WE have to remember to update it. If the design is to always support what >IBM supports, we can stop worrying about it. > A default of "oldest currently supported" is of little use on the day before end of support for that version. Better would be a form to specify "whatever version for which support is guaranteed for N days from the current date." Akin to the "find ... -mtime n". -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XLC architecture level question
Linda Chui wrote: >My colleague validated this issue. Yes, this is a documentation error. >The default should be the same as the ARCH option description >mentioned (page 63). We have notified our content editor to >update/correct our docs. >Thanks for bringing this to our attention. Thank you! Does that default change periodically? I suppose it must-is it always such that the default supports the oldest currently supported hardware? What we don't want to do is upgrade the compile and break our product for our customers. We can explicitly specify ARCH(10) now, but then WE have to remember to update it. If the design is to always support what IBM supports, we can stop worrying about it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XLC architecture level question
On Mon, 24 Apr 2023 11:24:25 -0400, Phil Smith III wrote: >SC14-7307-40, the z/OS 2.4 XL C/C++ User's Guide, says on PDF page 63 that >ARCH(10) is the default. However, on PDF page 580, it also says: >Architecture target is set according to the last-found instance of the >-qarch compiler option, provided that the specified -qarch setting is >compatible with the compiler mode setting. If the -qarch option is not set, >the compiler assumes a -qarch setting of 5. > >and it repeats that 5 is the default several times. My first thought was >that maybe it's different when run under USS, but my listing (with no >explicit ARCH) includes: >*ARCH(10) >so I'm thinking it's a doc error. Anyone know better? Or am I fatally >confusing something here? > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Hi Phil, My colleague validated this issue. Yes, this is a documentation error. The default should be the same as the ARCH option description mentioned (page 63). We have notified our content editor to update/correct our docs. Thanks for bringing this to our attention. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
