I confess to not having slogged through this thread, but from the beginning 
I've wondered why no one has suggested the static system symbol &SYSALVL. 
System symbols can be queried from pretty much any environment. They're set 
automatically at IPL. Maybe OP needs more detail...

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Sunday, November 29, 2015 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture 
level?

Two corrections:

1. At several points in this thread I think I may have said "facility bits in 
the CVT." I wuz of course confused. Make that "facility bits in the PSA."

2. My last bullet below is muddled. Make that "before I start relying on
ARCH(12) and therefore need to distinguish it from ARCH(11). As I am currently 
tentatively relying on ARCH(9) I have about six years ..."

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Sunday, November 29, 2015 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

> Charles Mills has a reason. But part of that reason is that he's 
> running
...

Right. And dealing with imperfect co-workers dealing with imperfect information 
from sales and pre-sales and a boss who says "can't we give them a nice message 
rather than a S0C1?" 

 > I'm actually curious if you can tell at runtime what C/C++ ARCH level was 
 > this module compiled at

Per the U/G, "[The C macro] __ARCH__ is predefined to the integer value of the 
ARCH compiler option." That is what I am using.

> What are you actually trying to accomplish with the tests of the 
> facility
bits to determine machine?

I like Kirk's approach. I have code that works now using CSRSI and a machine 
type lookup table, but I think I am going to switch to  Kirk's approach because
- I think it should work more reliably for zPDT and Hercules. (I know z/OS is 
not licensed for Hercules, but I hear rumors that some people may be running it 
there, and my job is writing code that works, not enforcing IBM's license terms.
- I think it may be a better solution under VM.
- It is a somewhat better approach for the situation where code written and 
shipped today is running on some future IBM machine. My current code says "if 
you don't recognize the type, it must be new and therefore okay." Kirk's 
approach will presumably return ARCH(11) for an ARCH(12) machine. All I need to 
do is update Kirk's code before I start relying on ARCH(13) and therefore need 
to distinguish it from ARCH(12). As I am currently tentatively relying on 
ARCH(9) I have about eight years ...

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to