Re: newer opcodes
On Fri, 14 Oct 2011 08:09:08 +0200, Martin Truebner wrote: >Jim, > >>> That's not quite true. << > >I do understand what you said. Would Peters stmt be "full*" true >if a "problem state instructions..." is inserted? > > >* I used "full" to remove/nullify/void/falsify your use of the word >"quite". If this is wrong, I blame it on my lack of knowledge of the >american language. > I'm not sure where you'd want to insert "problem state instructions", Martin. But in any case, both Peter and Jim, as I read their messages, were talking about the operating system itself running on the processors. They were not making statements about which applications (client, or vendor, or IBM) would run on which processors. The OS is very careful to check which instructions and facilities are available and use alternatives as appropriate, but we can't comment on what the applications that run on the OS might do, and whether they will work on specific processors or OS releases. Only the application developers know that. -- Walt Farrell IBM STSM, z/OS Security Design
Re: newer opcodes
Jim, >> That's not quite true. << I do understand what you said. Would Peters stmt be "full*" true if a "problem state instructions..." is inserted? * I used "full" to remove/nullify/void/falsify your use of the word "quite". If this is wrong, I blame it on my lack of knowledge of the american language. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: newer opcodes
Peter Relson/Poughkeepsie/IBM@IBMUS wrote on 10/13/2011 08:08:01 AM: > 10/13/2011 07:35 PM > Subject: > Re: newer opcodes > It is true that all z/OS releases can run on any z/Architecture-capable > machine. > > Peter Relson > z/OS Core Technology Design That's not quite true. While it is true that all z/OS releases run on the oldest z/Architecture-capable machine, and the all *currently supported* z/OS releases can run on any z/Architecture-capable machine, it is not the case that all old, unsupported z/OS releases can run on newer machines. For example, z/OS 1.7 is the oldest release that can run on a z196 or z114, because the IPL will fail without a fix for the problem described by APAR OA30777. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: newer opcodes
On 10/13/2011 5:27 AM, Martin Truebner wrote: Peter, simple rule of thumb: Talking about simple... would it be too much asking to insert (right behind the note about operation exception when not installed) the corresponding bit in STFLEs answer? I agree. This would be a useful addition to the Principles of Operation. I wonder if Dan Greiner monitors this list? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: newer opcodes
On Thu, 13 Oct 2011 08:52:31 -0400 Mike Shaw wrote: > We started doing this exact thing in MVS/QuickRef's > Assembler-oriented data base content. It does save time when you > don't have to go hunt down the STFLE bits. A good example of that little "extra" that ISVs (and PCMs in another time) have to offer to get/maintain market share. Nice product IMHO. Shane ...
Re: newer opcodes
On Thu, Oct 13, 2011 at 8:27 AM, Martin Truebner wrote: > Peter, > > >> simple rule of thumb: > > Talking about simple... would it be too much asking to insert (right > behind the note about operation exception when not installed) the > corresponding bit in STFLEs answer? > > Marty: We started doing this exact thing in MVS/QuickRef's Assembler-oriented data base content. It does save time when you don't have to go hunt down the STFLE bits. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: newer opcodes
Peter, >> simple rule of thumb: Talking about simple... would it be too much asking to insert (right behind the note about operation exception when not installed) the corresponding bit in STFLEs answer? -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: newer opcodes
It is true that all z/OS releases can run on any z/Architecture-capable machine. That leads to a very simple rule of thumb: if the principles of operation shows for an instruction that an operation exception may occur, then you may not use that instruction unless you have determined that the required facility is present. Peter Relson z/OS Core Technology Design
Re: newer opcodes
Everything has been said already. >> [Aside: No facility in recent memory has been more liberating to our >> programmers than the relative-immediate facility.] Y E S. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: newer opcodes
On 2011-10-12 12:22, Edward Jaffe wrote: On 10/12/2011 5:08 AM, Tony Thigpen wrote: Our customers base is VSE. We have customers that are running (in production) old levels back as far as VSE 2.1. We have customers running hardware as far back as MP2000 boxes. Until last year, we actually had a VSE 1.4 customer. When you consider the fact that some of our customers are running non-Y2K compliant systems, it is a little scary! But, they keep sending in the checks. :-) We all have back-level customers. The real question is whether those customers--who won't upgrade their hardware and/or install new releases of the operating system--are upgrading to the latest releases of our software. When I looked at this a few years back, the answer was a resounding "No". Back-level customers were back-level on everything. And, when and if they did upgrade, they tended to upgrade everything at the same time. As long as we continue to support the highest release of our software that did not require newer instructions, the back-level customers continue to get what they pay for (support for their current release and access to new releases should they ever choose to upgrade) and we can develop the latest releases using newer hardware facilities. My internal rule-of-thumb (usually ignored) is to support the minimum hardware level that supports the last z/OS level to go EOS, and likewise the minimum supported z/OS level is the same. (If you need earlier, then you have to pay for it, just like you're doing with IBM, and you probably won't get a new release anyway.) This goes with both assembler (OPTABLE) and C (ARCH/TARGET) code. I haven't looked in about a year, but I'm pretty sure z/OS 1.8 and maybe 1.9 could still run on z800/z900. (In fact, I got a note from my former employer about a month ago concerning an LLH that sneaked into some assembler code in a maintenance branch.) As new releases come out, the release notes say what the minimum hardware and z/OS levels are, and also state that possible future releases may not support these levels. In the case of C, I set the TUNE parameter to one less than the current highest level for the most recent z/OS, because that usually aligns with the most common machine out there in The Real World ™. IIRC, z/VSE can run on even older architecture levels than z800/z900. I've written some assembler macros that simulate newer instructions and are loaded in based on the OPTABLE settings. It's kind of fun, actually, to rewrite newer instructions using only old. [Aside: No facility in recent memory has been more liberating to our programmers than the relative-immediate facility.] Amen. And when I've taught co-workers about the magic of relative branches when they need a new base register, their gratitude is bountiful. Later, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: newer opcodes
On 10/12/2011 5:08 AM, Tony Thigpen wrote: Our customers base is VSE. We have customers that are running (in production) old levels back as far as VSE 2.1. We have customers running hardware as far back as MP2000 boxes. Until last year, we actually had a VSE 1.4 customer. When you consider the fact that some of our customers are running non-Y2K compliant systems, it is a little scary! But, they keep sending in the checks. :-) We all have back-level customers. The real question is whether those customers--who won't upgrade their hardware and/or install new releases of the operating system--are upgrading to the latest releases of our software. When I looked at this a few years back, the answer was a resounding "No". Back-level customers were back-level on everything. And, when and if they did upgrade, they tended to upgrade everything at the same time. As long as we continue to support the highest release of our software that did not require newer instructions, the back-level customers continue to get what they pay for (support for their current release and access to new releases should they ever choose to upgrade) and we can develop the latest releases using newer hardware facilities. [Aside: No facility in recent memory has been more liberating to our programmers than the relative-immediate facility.] -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: newer opcodes
Our customers base is VSE. We have customers that are running (in production) old levels back as far as VSE 2.1. We have customers running hardware as far back as MP2000 boxes. Until last year, we actually had a VSE 1.4 customer. When you consider the fact that some of our customers are running non-Y2K compliant systems, it is a little scary! But, they keep sending in the checks. :-) While there are some sub-features of some of our products that require later levels of z/VSE (which have their own hardware requirements), almost all our code has to run on the older platforms. Tony Thigpen -Original Message - From: Peter Relson Sent: 10/12/2011 07:27 AM Not evil, just can't use them since the customer may not have the hardware support. The current program I am working on requires z/VSE 4 so I was attempting to use some of the halfword-imm stuff. I just picked the wrong instructions. So, again, back to using old instructions. I'm curious. Are there actually customers out there who are running a machine that is older than the minimum required for OS/390 R10 (namely machines which support the initial relative/immediate support)? We know that such customers would not be running a supported level of z/OS, but they might be running something other than z/OS, or something that is no longer supported. Peter Relson z/OS Core Technology Design
Re: newer opcodes
>Not evil, just can't use them since the customer may not have the >hardware support. The current program I am working on requires z/VSE 4 >so I was attempting to use some of the halfword-imm stuff. I just picked >the wrong instructions. So, again, back to using old instructions. I'm curious. Are there actually customers out there who are running a machine that is older than the minimum required for OS/390 R10 (namely machines which support the initial relative/immediate support)? We know that such customers would not be running a supported level of z/OS, but they might be running something other than z/OS, or something that is no longer supported. Peter Relson z/OS Core Technology Design
Re: newer opcodes
Tony Thigpen noted... > We have the following HLASM installed: > HLASM R5.0 2011(PTF UK31916) Tony, HLASM 5.0 has been off service for over a year; upgrade to HLASM 6.0.
Re: newer opcodes
> And I thought that even rel+imm are evil (at least that was the > impression you left me with after our last conversaation about this > very subject) Not evil, just can't use them since the customer may not have the hardware support. The current program I am working on requires z/VSE 4 so I was attempting to use some of the halfword-imm stuff. I just picked the wrong instructions. So, again, back to using old instructions. Tony Thigpen -Original Message - From: Martin Trübner Sent: 10/11/2011 06:34 AM Tony, ZS4 does not work on our HLASM. But ZS4 is what you need. THe instructions you cited are all z10 (or more) First, what is the correct OPTABLE() setting for these instructions? answered Second, I thought the halfword-Imm instructions were available all the way back to the MP3000 days. And I thought that even rel+imm are evil (at least that was the impression you left me with after our last conversaation about this very subject) -- on your question- REL+IMM feature was available then- but did only include MHI, LHI, AHI, CHI in the -IMM-part of the feature. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: newer opcodes
Tony, >> ZS4 does not work on our HLASM. But ZS4 is what you need. THe instructions you cited are all z10 (or more) >> First, what is the correct OPTABLE() setting for these >> instructions? answered >> Second, I thought the halfword-Imm instructions were available all >> the way back to the MP3000 days. And I thought that even rel+imm are evil (at least that was the impression you left me with after our last conversaation about this very subject) -- on your question- REL+IMM feature was available then- but did only include MHI, LHI, AHI, CHI in the -IMM-part of the feature. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: newer opcodes
Hi Tony, UNI works for me. On z/OS at least. Cheers, -- Raphael Dal-Pos / z/OS Support Generali France Assurances DSIO - DIO - IT Infrastructure & Support Saint Denis - Wilo W 03 B2015C rdal...@generali.fr +(33)1-58-38-59-67 or +(33)6.24.33.20.87 -- "MVS: Guilty, until proven innocent !!" RDP 2009 -Message d'origine- De : IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] De la part de Tony Thigpen Envoyé : mardi 11 octobre 2011 12:02 À : ASSEMBLER-LIST@LISTSERV.UGA.EDU Objet : newer opcodes I do my major coding on my pc using the Dignus Assembler. I was moving some working source code to z/VM where production assemblies are performed and am having trouble finding the correct optcode table for the following instructions: CHSI MVHHI CHHSI We have the following HLASM installed: HLASM R5.0 2011(PTF UK31916) I have tried: YOP ZOP ZS3 ZS4 does not work on our HLASM. First, what is the correct OPTABLE() setting for these instructions? Second, I thought the halfword-Imm instructions were available all the way back to the MP3000 days. Am I wrong? Third, in the assembler manual, they state: "The operation codes supported by High Level Assembler are described in the documents listed under "Related Publications (Architecture)" on page 451." Which manual in that section is it refereeing to? None of them seem correct from the title. -- Tony Thigpen
