How about compiling at all ARCHLEVELs, then letting the installation pick which level to install. Have the install program issue a warning if the current machine does not meet the ARCHLEVEL selected.
On Mon, Nov 30, 2015 at 2:15 PM, Charles Mills <charl...@mcn.org> wrote: > I would call it event-oriented. Millions of events per day per LPAR at some > sites. > > Customers pay "extra" so to speak for CPU savings because the alternative is > paying more to IBM and other vendors based on MSU peaks, and eventually a > hardware upgrade with the implied additional software costs. If you are not > aware of that mentality then you are not in the trenches of modern ISV > software sales. > > Here's the product we are talking about: > https://correlog.com/solutions-and-services/sas-correlog-mainframe.html > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Gould > Sent: Monday, November 30, 2015 11:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Straightforward way to determine hardware architecture level? > > Charles: > > On Nov 30, 2015, at 7:59 AM, Charles Mills wrote: > >> Sorry. MSUs are *incredibly* important to some (most?) customers. >> They are a >> major buy/no-buy decider. I cannot ship z900 code and shrug my >> shoulders about performance on a z13. IBM (as an example) has come to >> realize that customers are not willing to run S/390 instruction set >> COBOL executables on a z13 -- witness the Binary Optimizer. I get >> paid to be concerned about this stuff and I take the responsibility to >> live my life in a way that avoids ulcers. Shipping the source is >> utterly out of the question, both for intellectual property reasons >> and because at more and more customers even coding a Rexx script is >> beyond the local programming abilities: >> they could >> never compile the code successfully -- and many are so busy >> (understaffed?) >> they would not be willing to take the time even if they could. >> >> At some sites we process millions of events per day per LPAR. A >> millisecond per event is thousands of CPU seconds per day. >> >>> let the responsibility lie with the customer >> >> Customers basically pay us to take that responsibility. > > I don't know what your company sells and wonder why anyone would pay "extra" > for a few seconds of cpu savings gain. > I suspect you (or your management) is making a mountain out of a mole hill. > Isn't the main idea for any product to run transparently an any Z Compatible > CPU? > Saving a few seconds is not conducive to any real life situation unless it > is a transaction oriented system. > So if its not transaction oriented then don't worry be happy. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
