I'm reaching back a long way to stretch the notion of 'straightforward', but here goes. When I was a novice sysprog, my shop had an Amdahl. MVS at that time predated 'system product'. (Way back.) IBM shipped a new level of MVS that executed instructions not present our Amdahl. Amdahl responded by shipping some code that was loaded early in IPL to accommodate the new instructions. The code would trap a S0C1, determine if it were a new instruction, and if so, 'fix' it. Some instructions were considered unnecessary; others needed to be simulated. Unnecessary instructions were NOOPed in memory; a simulated instruction was replaced in memory with a direct branch to the simulation routine. As time went on after an IPL, there were fewer and fewer S0C1s to deal with.
So what about taking a similar approach with an all-architecture product? Write it to run on the latest hardware and trap the S0C1s that occur on older hardware, then simulate the unexecutable instruction with something 'traditional'. Whew. Sounds like a lot of work, but you would have a truly universal product. . . . 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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Monday, November 30, 2015 5:59 AM To: [email protected] Subject: (External):Re: Straightforward way to determine hardware architecture level? 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. > you will always get an 0C1 if you execute the instruction on a machine that is incapable of executing that instruction No argument there! <g> Seriously, thanks for your input. Charles <snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
