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:[email protected]] On Behalf
Of Charles Mills
Sent: Tuesday, April 25, 2023 7:06 AM
To: [email protected]
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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
