Re: Determining required z/series hardware level - REVISED
Here is how to do an "earliest support for each opcode" document if anyone wants to pick up where I left off. - IIRC the assembler will generate a list of valid opcodes for the specified ZS- level. (If I am mistaken then stop reading now.) You want to generate such a list for each ZS-level you are interested in. - Load the opcodes supported by z14, z13, etc. each into a column in Excel. - Load the opcodes supported by z15 into a column on a spreadsheet page. Then in the adjacent column do a lookup in the columns described in the preceding bullet. If not found anywhere else, then say z15. If found only in the z14 column, then say z14. And so forth. Now you have a spreadsheet with every opcode and the earliest machine that supports it. - Convert that into a PDF or some similar format for sharing. - If you are more comfortable with Rexx than with Excel what I describe could be done with Rexx. Substitute "stem variable" for "column" in my directions. Or PL/I. Or your favorite language. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, December 11, 2020 7:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED Tachyon Web page says last updated 05/29/2010 11:06:28 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, December 9, 2020 4:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED On Wed, 9 Dec 2020 at 10:53, Charles Mills wrote: > > I have been thinking about this. It is a daunting project. I once set out to > develop a simple list of opcodes with their required minimum hardware level. > I wanted to be able to answer questions of the form "management wants this > product to be able to run on a z9. Can I use AHI?" In fact I think I asked > for help on this list, and promised to share any results. I abandoned the > effort! I decided it was easier just to code AHI and assemble with ZS-5 or > whatever and see if I got an error. That list is obviously just one > component of your product. There has been a list at http://www.tachyonsoft.com/inst390o.htm for many years. I'm not at all sure it's maintained these days, but I use it frequently as a quick reference. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
Tachyon Web page says last updated 05/29/2010 11:06:28 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, December 9, 2020 4:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED On Wed, 9 Dec 2020 at 10:53, Charles Mills wrote: > > I have been thinking about this. It is a daunting project. I once set out to > develop a simple list of opcodes with their required minimum hardware level. > I wanted to be able to answer questions of the form "management wants this > product to be able to run on a z9. Can I use AHI?" In fact I think I asked > for help on this list, and promised to share any results. I abandoned the > effort! I decided it was easier just to code AHI and assemble with ZS-5 or > whatever and see if I got an error. That list is obviously just one > component of your product. There has been a list at http://www.tachyonsoft.com/inst390o.htm for many years. I'm not at all sure it's maintained these days, but I use it frequently as a quick reference. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
On Wed, 9 Dec 2020 at 10:53, Charles Mills wrote: > > I have been thinking about this. It is a daunting project. I once set out to > develop a simple list of opcodes with their required minimum hardware level. > I wanted to be able to answer questions of the form "management wants this > product to be able to run on a z9. Can I use AHI?" In fact I think I asked > for help on this list, and promised to share any results. I abandoned the > effort! I decided it was easier just to code AHI and assemble with ZS-5 or > whatever and see if I got an error. That list is obviously just one > component of your product. There has been a list at http://www.tachyonsoft.com/inst390o.htm for many years. I'm not at all sure it's maintained these days, but I use it frequently as a quick reference. On the more general matter of analysing a load module/PO/UNIX file and classifying the opcodes found therein, I think this is pretty much an AI project. Surely it engages the Halting Problem for the general case. Given sufficient non-code (data) space within the module, it is very likely that some of the data will be interpreted as instructions, and notably many of the instructions having their first byte in the range of EBCDIC letters are from the newer architecture levels. There are some other problems. In a few cases the behaviour of existing instructions has been expanded with an architectural level. Notably the Long Displacement Facility added use of a previously unused byte in around 50 existing instructions to go from a 12-bit unsigned to a 20-bit signed displacement. This isn't insurmountable; finding just one such instruction with a non-zero DH field means that that facility is required. And this facility is pretty old now (2003), so unlikely to not be required. The Interlocked-Access Facility 1 (2010) and 2 (2012) each turned some existing instructions into interlocked-update ones. This included old standbyes like NI, OI, and XI. There is no way to tell from the instruction itself if the program is relying on the new behaviour. The ETF2-Enhancement Facility (2005) added meaning to a bit in the existing TRxx instructions (TROO, TROT, TRTO, and TRTT).. And there are very CISC facilities like the Message-Security-Assists that are more like library calls that support many subfunctions than like even the previous most complex instructions. A program can issue a query to find out if a function is supported, or just assume that it is, so analysis of such code would require data flow analysis or finding a hard-coded function that was introduced at a particular level. And then there is the EXecute instruction (actually two of them now). Typically this is used to put the length into an MVC or CLC or the like. Occasionally it has been used to put the SVC number into an SVC or the mask into a TM. But given that part of the opcode in some instruction formats is in the second byte, it's quite possible to change the target instruction itself. So e.g. if you EX a STCK (B205) with the execute register containing X'40', you will instead execute a SQDR (Square Root short HFP) instruction (B245). This would be fine material for an obfuscated programming contest, and is of course unlikely to be found in real-life code. But who knows - maybe code obfuscators (human or software) have used it to "protect" their code. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
A better approach would be displaying the required architectural level.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Tuesday, December 8, 2020 11:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED
There is always the approach of running the program. ABEND S0C1 indicates
that you need a newer box (or better programmers).
I suppose an arguably good corporate standard might be to require embedding
the required ARCH level in programs as a readable EBCDIC constant.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Hochee
Sent: Tuesday, December 8, 2020 6:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED
Thanks all, yet again, for all the excellent ideas! These IBM- listservs are
a truly fine resource. ('the power of many brains working!') I will
probably end up doing some flavor of opcode evaluation, and assumed, maybe
erroneously, that opcode evaluation would be simpler/cleaner to implement
than parsing or scanning source (which is available). I generally feel more
comfortable working with machine/product outputs rather than the curveballs
humans sometimes throw.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
I have been thinking about this. It is a daunting project. I once set out to
develop a simple list of opcodes with their required minimum hardware level.
I wanted to be able to answer questions of the form "management wants this
product to be able to run on a z9. Can I use AHI?" In fact I think I asked
for help on this list, and promised to share any results. I abandoned the
effort! I decided it was easier just to code AHI and assemble with ZS-5 or
whatever and see if I got an error. That list is obviously just one
component of your product.
If you can possibly live with just analyzing LE-enabled programs, and if the
LE "header" has this information, then you should really consider living
with just that. That is a well-defined project. The information might be in
the manual LE Vendor Interfaces.
If you do want to proceed as you described, then you might look for the
source for a disassembler as a starting point. Is there one on the CBT tape?
Much of what a disassembler does is characterizing each byte as either an
opcode or other than an opcode -- and that, plus the "list" of my first
paragraph above, is pretty much your product.
There are at least four "systems" for characterizing hardware levels: the
machine marketing number (z9, z10, etc.), SYSSTATE ARCHLVL, the ARCH()
option supported by the LE-enabled compilers, and the assembler ZS- levels.
If it were me I would embrace ARCH(), but perhaps that is just me. The
problems with the machine marketing numbers that you suggest are (a.) IBM
could change direction at any moment: the next machine might not be the z16
but rather the Whizzer2000; and (b.) the z196 kind of messes up the scheme.
The problem with ARCHLVL is IIRC that it is not granular enough. ARCH() and
ZS- are equivalent; if you prefer one over the other, use it.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Hochee
Sent: Tuesday, December 8, 2020 6:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED
Thanks all, yet again, for all the excellent ideas! These IBM- listservs are
a truly fine resource. ('the power of many brains working!') I will
probably end up doing some flavor of opcode evaluation, and assumed, maybe
erroneously, that opcode evaluation would be simpler/cleaner to implement
than parsing or scanning source (which is available). I generally feel more
comfortable working with machine/product outputs rather than the curveballs
humans sometimes throw.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
Just wanted to add to my earlier post. The disassembler provided with the
Assembler Toolkit is now part of HLASM and shipped as load module ASMADOP
in SYS1.MIGLIB. Looks like this was done with APAR PQ27453 back in 1999!
Regards,
Peter Van Dyke
HCL Software
On Wed, 9 Dec 2020 at 10:54, Mike Hochee wrote:
> Thanks all, yet again, for all the excellent ideas! These IBM- listservs
> are a truly fine resource. ('the power of many brains working!') I will
> probably end up doing some flavor of opcode evaluation, and assumed, maybe
> erroneously, that opcode evaluation would be simpler/cleaner to implement
> than parsing or scanning source (which is available). I generally feel more
> comfortable working with machine/product outputs rather than the curveballs
> humans sometimes throw.
>
> Best,
> Mike
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Hochee
> Sent: Tuesday, December 8, 2020 5:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> Warning! This is a fake (spoofed) message. DO NOT TRUST!
>
> Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'
>
> Hi,
>
> I'm looking for a utility/program which is capable of reading a z/OS
> executable, whether an lmod or program object, or unbound object code, and
> examining it for hardware/architecture level compatibility. I'm not
> specifically referring to the ARCLVL of on the SYSSTATE macro, although I
> know there is some correspondence, but rather to the set of unprivileged
> instructions introduced at a particular hardware architecture levels.
> Apologies in advance for any imprecise/inaccurate terminology.
>
> For example, let's say I happen to know that the most recently introduced
> z/Series instruction used by a particular executable is the AHI
> instruction, then I would expect this utility/program to output 'G10',
> suggesting the minimum hardware architecture required to support execution.
>
> I understand things are not always black/white in this area and could be
> clouded by instruction facility requirements, etc..
>
> Thanks in advance for any suggestions, guidance.
>
> Mike
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
There is always the approach of running the program. ABEND S0C1 indicates
that you need a newer box (or better programmers).
I suppose an arguably good corporate standard might be to require embedding
the required ARCH level in programs as a readable EBCDIC constant.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Hochee
Sent: Tuesday, December 8, 2020 6:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED
Thanks all, yet again, for all the excellent ideas! These IBM- listservs are
a truly fine resource. ('the power of many brains working!') I will
probably end up doing some flavor of opcode evaluation, and assumed, maybe
erroneously, that opcode evaluation would be simpler/cleaner to implement
than parsing or scanning source (which is available). I generally feel more
comfortable working with machine/product outputs rather than the curveballs
humans sometimes throw.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
Thanks all, yet again, for all the excellent ideas! These IBM- listservs are a
truly fine resource. ('the power of many brains working!') I will probably end
up doing some flavor of opcode evaluation, and assumed, maybe erroneously, that
opcode evaluation would be simpler/cleaner to implement than parsing or
scanning source (which is available). I generally feel more comfortable working
with machine/product outputs rather than the curveballs humans sometimes throw.
Best,
Mike
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mike Hochee
Sent: Tuesday, December 8, 2020 5:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED
Warning! This is a fake (spoofed) message. DO NOT TRUST!
Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'
Hi,
I'm looking for a utility/program which is capable of reading a z/OS
executable, whether an lmod or program object, or unbound object code, and
examining it for hardware/architecture level compatibility. I'm not
specifically referring to the ARCLVL of on the SYSSTATE macro, although I know
there is some correspondence, but rather to the set of unprivileged
instructions introduced at a particular hardware architecture levels. Apologies
in advance for any imprecise/inaccurate terminology.
For example, let's say I happen to know that the most recently introduced
z/Series instruction used by a particular executable is the AHI instruction,
then I would expect this utility/program to output 'G10', suggesting the
minimum hardware architecture required to support execution.
I understand things are not always black/white in this area and could be
clouded by instruction facility requirements, etc..
Thanks in advance for any suggestions, guidance.
Mike
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
There is certainly code that uses, e.g., STFLE, and checks the result. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mike Schwab [mike.a.sch...@gmail.com] Sent: Tuesday, December 8, 2020 7:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED Is the facility to check for the facility bits often present in load modules? I. E. a certain opcode or SVC call? Then hou could look at the bits being checked. On Tue, Dec 8, 2020 at 6:11 PM Seymour J Metz wrote: > > Some new feature added new bit to, e.g., control registers, parameters, > tables. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Peter Van Dyke [pdvand...@gmail.com] > Sent: Tuesday, December 8, 2020 6:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Determining required z/series hardware level - REVISED > > If there isn't a ready made solution available, the High Level Assembler > Toolkit has a disassembler utility which could provide the input to a new > tool that scans the assembler instructions and matches them to the hardware > level. The IBM File Manager 'View Load Module' or VLM function can also > disassemble CSECTs. VLM is also able to provide information such as the > compiler used to create a CSECT and the compiler options used such as the > ARCH setting. > > Regards, > Peter Van Dyke > HCL Software > > On Wed, 9 Dec 2020 at 07:27, Charles Mills wrote: > > > "Version of the compiler" is not sufficient to answer "what hardware level > > is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11, > > 12 or 13. So the object code might run on a z10, or it might require a z15, > > or anything in-between. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Farley, Peter x23353 > > Sent: Tuesday, December 8, 2020 3:17 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Determining required z/series hardware level - REVISED > > > > It's not foolproof, but for both HLL's and assembler the COBANALZ program > > in > > CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess > > at > > the compiler or assembler version that generated the code. From that you > > could extrapolate the minimum hardware level required based on the > > announcement letter for that release of each language's compiler. Crude, > > but possible, though COBANLZ does not handle "unbound object code", only > > executables (load module or P.O.). > > > > For HLL compilers that allow you to generate the pseudo-assembler > > equivalent > > of the compiled code, you can analyze the compiler listing for instruction > > uses, but if you only have executable code, obviously that is no help. > > > > For executable-only (no source or listing available) assembler, you would > > need to decode the executable into instructions and data (not trivial by > > any > > means) to build a list of instructions used. An instruction trace program > > like TRACE390 in CBT file 391 could help there, assuming you have the files > > and JCL needed to run the program once through the trace program. The > > trace > > output would provide you with a list of instructions executed to analyze > > for > > hardware level. The caveat there is that AFAIK CBT file 391 has not been > > updated in quite a while and lacks many of the newer z-architecture > > instructions, not least the whole suite of vector instructions. > > > > Running any kind of instruction trace has the caveat that not all > > instruction paths are guaranteed to be executed, and there could easily be > > instructions requiring a higher architecture level hiding in un-executed > > code. > > > > In general, if all you have is executable code, I would call this one of > > those "hard problems". > > > > Peter > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of > > Mike Hochee > > Sent: Tuesday, December 8, 2020 5:50 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Determining required z/series hardware level - REVISED > > > > Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' > > > > Hi, > > > > I'm looking for a utili
Re: Determining required z/series hardware level - REVISED
Yeah, disassemblers are not magic. There is a loss of information going from source code to object code, and there is no tool that magically makes that information reappear. I am not familiar with File Manager. I am looking at example "Load Module Information" for a load module compile with the IBM C++ compiler with ARCH specified, and I do not see the ARCH displayed by File Manager. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Tuesday, December 8, 2020 3:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED As one who has actually used the Assembler Toolkit disassembler for "lost source, lost listings" cases, I would warn anyone looking to use it that it requires quite a lot of customization and experimentation with multiple utility options for each executable you need to analyze, and many repeated runs until you get something truly usable out of it. It works, but it makes you work too, and work quite hard. Not having IBM File Manager available to me, I can’t speak to its accuracy or usability. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
Is the facility to check for the facility bits often present in load modules? I. E. a certain opcode or SVC call? Then hou could look at the bits being checked. On Tue, Dec 8, 2020 at 6:11 PM Seymour J Metz wrote: > > Some new feature added new bit to, e.g., control registers, parameters, > tables. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Peter Van Dyke [pdvand...@gmail.com] > Sent: Tuesday, December 8, 2020 6:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Determining required z/series hardware level - REVISED > > If there isn't a ready made solution available, the High Level Assembler > Toolkit has a disassembler utility which could provide the input to a new > tool that scans the assembler instructions and matches them to the hardware > level. The IBM File Manager 'View Load Module' or VLM function can also > disassemble CSECTs. VLM is also able to provide information such as the > compiler used to create a CSECT and the compiler options used such as the > ARCH setting. > > Regards, > Peter Van Dyke > HCL Software > > On Wed, 9 Dec 2020 at 07:27, Charles Mills wrote: > > > "Version of the compiler" is not sufficient to answer "what hardware level > > is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11, > > 12 or 13. So the object code might run on a z10, or it might require a z15, > > or anything in-between. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Farley, Peter x23353 > > Sent: Tuesday, December 8, 2020 3:17 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Determining required z/series hardware level - REVISED > > > > It's not foolproof, but for both HLL's and assembler the COBANALZ program > > in > > CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess > > at > > the compiler or assembler version that generated the code. From that you > > could extrapolate the minimum hardware level required based on the > > announcement letter for that release of each language's compiler. Crude, > > but possible, though COBANLZ does not handle "unbound object code", only > > executables (load module or P.O.). > > > > For HLL compilers that allow you to generate the pseudo-assembler > > equivalent > > of the compiled code, you can analyze the compiler listing for instruction > > uses, but if you only have executable code, obviously that is no help. > > > > For executable-only (no source or listing available) assembler, you would > > need to decode the executable into instructions and data (not trivial by > > any > > means) to build a list of instructions used. An instruction trace program > > like TRACE390 in CBT file 391 could help there, assuming you have the files > > and JCL needed to run the program once through the trace program. The > > trace > > output would provide you with a list of instructions executed to analyze > > for > > hardware level. The caveat there is that AFAIK CBT file 391 has not been > > updated in quite a while and lacks many of the newer z-architecture > > instructions, not least the whole suite of vector instructions. > > > > Running any kind of instruction trace has the caveat that not all > > instruction paths are guaranteed to be executed, and there could easily be > > instructions requiring a higher architecture level hiding in un-executed > > code. > > > > In general, if all you have is executable code, I would call this one of > > those "hard problems". > > > > Peter > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of > > Mike Hochee > > Sent: Tuesday, December 8, 2020 5:50 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Determining required z/series hardware level - REVISED > > > > Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' > > > > Hi, > > > > I'm looking for a utility/program which is capable of reading a z/OS > > executable, whether an lmod or program object, or unbound object code, and > > examining it for hardware/architecture level compatibility. I'm not > > specifically referring to the ARCLVL of on the SYSSTATE macro, although I > > know there is some correspondence, but rather to the set of unprivileged > > instructions introduced a
Re: Determining required z/series hardware level - REVISED
Some new feature added new bit to, e.g., control registers, parameters, tables. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Van Dyke [pdvand...@gmail.com] Sent: Tuesday, December 8, 2020 6:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED If there isn't a ready made solution available, the High Level Assembler Toolkit has a disassembler utility which could provide the input to a new tool that scans the assembler instructions and matches them to the hardware level. The IBM File Manager 'View Load Module' or VLM function can also disassemble CSECTs. VLM is also able to provide information such as the compiler used to create a CSECT and the compiler options used such as the ARCH setting. Regards, Peter Van Dyke HCL Software On Wed, 9 Dec 2020 at 07:27, Charles Mills wrote: > "Version of the compiler" is not sufficient to answer "what hardware level > is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11, > 12 or 13. So the object code might run on a z10, or it might require a z15, > or anything in-between. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Farley, Peter x23353 > Sent: Tuesday, December 8, 2020 3:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Determining required z/series hardware level - REVISED > > It's not foolproof, but for both HLL's and assembler the COBANALZ program > in > CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess > at > the compiler or assembler version that generated the code. From that you > could extrapolate the minimum hardware level required based on the > announcement letter for that release of each language's compiler. Crude, > but possible, though COBANLZ does not handle "unbound object code", only > executables (load module or P.O.). > > For HLL compilers that allow you to generate the pseudo-assembler > equivalent > of the compiled code, you can analyze the compiler listing for instruction > uses, but if you only have executable code, obviously that is no help. > > For executable-only (no source or listing available) assembler, you would > need to decode the executable into instructions and data (not trivial by > any > means) to build a list of instructions used. An instruction trace program > like TRACE390 in CBT file 391 could help there, assuming you have the files > and JCL needed to run the program once through the trace program. The > trace > output would provide you with a list of instructions executed to analyze > for > hardware level. The caveat there is that AFAIK CBT file 391 has not been > updated in quite a while and lacks many of the newer z-architecture > instructions, not least the whole suite of vector instructions. > > Running any kind of instruction trace has the caveat that not all > instruction paths are guaranteed to be executed, and there could easily be > instructions requiring a higher architecture level hiding in un-executed > code. > > In general, if all you have is executable code, I would call this one of > those "hard problems". > > Peter > > -----Original Message- > From: IBM Mainframe Discussion List On Behalf > Of > Mike Hochee > Sent: Tuesday, December 8, 2020 5:50 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Determining required z/series hardware level - REVISED > > Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' > > Hi, > > I'm looking for a utility/program which is capable of reading a z/OS > executable, whether an lmod or program object, or unbound object code, and > examining it for hardware/architecture level compatibility. I'm not > specifically referring to the ARCLVL of on the SYSSTATE macro, although I > know there is some correspondence, but rather to the set of unprivileged > instructions introduced at a particular hardware architecture levels. > Apologies in advance for any imprecise/inaccurate terminology. > > For example, let's say I happen to know that the most recently introduced > z/Series instruction used by a particular executable is the AHI > instruction, > then I would expect this utility/program to output 'G10', suggesting the > minimum hardware architecture required to support execution. > > I understand things are not always black/white in this area and could be > clouded by instruction facility requirements, etc.. > > Thanks in advance for any suggestions, guidance. > > Mike > -- > > This message and any attachments are intended only for the use of the &
Re: Determining required z/series hardware level - REVISED
As one who has actually used the Assembler Toolkit disassembler for "lost source, lost listings" cases, I would warn anyone looking to use it that it requires quite a lot of customization and experimentation with multiple utility options for each executable you need to analyze, and many repeated runs until you get something truly usable out of it. It works, but it makes you work too, and work quite hard. Not having IBM File Manager available to me, I can’t speak to its accuracy or usability. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Van Dyke Sent: Tuesday, December 8, 2020 6:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED If there isn't a ready made solution available, the High Level Assembler Toolkit has a disassembler utility which could provide the input to a new tool that scans the assembler instructions and matches them to the hardware level. The IBM File Manager 'View Load Module' or VLM function can also disassemble CSECTs. VLM is also able to provide information such as the compiler used to create a CSECT and the compiler options used such as the ARCH setting. Regards, Peter Van Dyke HCL Software On Wed, 9 Dec 2020 at 07:27, Charles Mills wrote: > "Version of the compiler" is not sufficient to answer "what hardware > level is required?" For example, COBOL 6.3 lets you specify ARCH() 8, > 9, 10, 11, > 12 or 13. So the object code might run on a z10, or it might require a > z15, or anything in-between. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Farley, Peter x23353 > Sent: Tuesday, December 8, 2020 3:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Determining required z/series hardware level - REVISED > > It's not foolproof, but for both HLL's and assembler the COBANALZ > program in CBT file 321 will give you (in the SUMMARY DD output) a > pretty good guess at the compiler or assembler version that generated > the code. From that you could extrapolate the minimum hardware level > required based on the announcement letter for that release of each > language's compiler. Crude, but possible, though COBANLZ does not > handle "unbound object code", only executables (load module or P.O.). > > For HLL compilers that allow you to generate the pseudo-assembler > equivalent of the compiled code, you can analyze the compiler listing > for instruction uses, but if you only have executable code, obviously > that is no help. > > For executable-only (no source or listing available) assembler, you > would need to decode the executable into instructions and data (not > trivial by any > means) to build a list of instructions used. An instruction trace > program like TRACE390 in CBT file 391 could help there, assuming you > have the files and JCL needed to run the program once through the > trace program. The trace output would provide you with a list of > instructions executed to analyze for hardware level. The caveat there > is that AFAIK CBT file 391 has not been updated in quite a while and > lacks many of the newer z-architecture instructions, not least the > whole suite of vector instructions. > > Running any kind of instruction trace has the caveat that not all > instruction paths are guaranteed to be executed, and there could > easily be instructions requiring a higher architecture level hiding in > un-executed code. > > In general, if all you have is executable code, I would call this one > of those "hard problems". > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Mike Hochee > Sent: Tuesday, December 8, 2020 5:50 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Determining required z/series hardware level - REVISED > > Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' > > Hi, > > I'm looking for a utility/program which is capable of reading a z/OS > executable, whether an lmod or program object, or unbound object code, > and examining it for hardware/architecture level compatibility. I'm > not specifically referring to the ARCLVL of on the SYSSTATE macro, > although I know there is some correspondence, but rather to the set of > unprivileged instructions introduced at a particular hardware architecture > levels. > Apologies in advance for any imprecise/inaccurate terminology. > > For example, let's say I happen to know that the most recently > introduced z/Series instruction used by a particular executable is the > AHI instruction, then I would expect this utility/program to output > 'G10', suggesting the minimum hardware ar
Re: Determining required z/series hardware level - REVISED
True, and also true for the XLC and PL1 compilers. I did say "crude", and I meant it. OTOH, if the executable is an HLL from one of the more recent compiler levels which use LE control blocks, ARCHLVL output can be found (or added to) the very detailed HLL information that CONANALZ can/could generate in its SYSPRINT output stream. SMOP. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, December 8, 2020 6:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED EXTERNAL EMAIL "Version of the compiler" is not sufficient to answer "what hardware level is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11, 12 or 13. So the object code might run on a z10, or it might require a z15, or anything in-between. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Tuesday, December 8, 2020 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED It's not foolproof, but for both HLL's and assembler the COBANALZ program in CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess at the compiler or assembler version that generated the code. From that you could extrapolate the minimum hardware level required based on the announcement letter for that release of each language's compiler. Crude, but possible, though COBANLZ does not handle "unbound object code", only executables (load module or P.O.). For HLL compilers that allow you to generate the pseudo-assembler equivalent of the compiled code, you can analyze the compiler listing for instruction uses, but if you only have executable code, obviously that is no help. For executable-only (no source or listing available) assembler, you would need to decode the executable into instructions and data (not trivial by any means) to build a list of instructions used. An instruction trace program like TRACE390 in CBT file 391 could help there, assuming you have the files and JCL needed to run the program once through the trace program. The trace output would provide you with a list of instructions executed to analyze for hardware level. The caveat there is that AFAIK CBT file 391 has not been updated in quite a while and lacks many of the newer z-architecture instructions, not least the whole suite of vector instructions. Running any kind of instruction trace has the caveat that not all instruction paths are guaranteed to be executed, and there could easily be instructions requiring a higher architecture level hiding in un-executed code. In general, if all you have is executable code, I would call this one of those "hard problems". Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Hochee Sent: Tuesday, December 8, 2020 5:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' Hi, I'm looking for a utility/program which is capable of reading a z/OS executable, whether an lmod or program object, or unbound object code, and examining it for hardware/architecture level compatibility. I'm not specifically referring to the ARCLVL of on the SYSSTATE macro, although I know there is some correspondence, but rather to the set of unprivileged instructions introduced at a particular hardware architecture levels. Apologies in advance for any imprecise/inaccurate terminology. For example, let's say I happen to know that the most recently introduced z/Series instruction used by a particular executable is the AHI instruction, then I would expect this utility/program to output 'G10', suggesting the minimum hardware architecture required to support execution. I understand things are not always black/white in this area and could be clouded by instruction facility requirements, etc.. Thanks in advance for any suggestions, guidance. Mike -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff /
Re: Determining required z/series hardware level - REVISED
If there isn't a ready made solution available, the High Level Assembler Toolkit has a disassembler utility which could provide the input to a new tool that scans the assembler instructions and matches them to the hardware level. The IBM File Manager 'View Load Module' or VLM function can also disassemble CSECTs. VLM is also able to provide information such as the compiler used to create a CSECT and the compiler options used such as the ARCH setting. Regards, Peter Van Dyke HCL Software On Wed, 9 Dec 2020 at 07:27, Charles Mills wrote: > "Version of the compiler" is not sufficient to answer "what hardware level > is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11, > 12 or 13. So the object code might run on a z10, or it might require a z15, > or anything in-between. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Farley, Peter x23353 > Sent: Tuesday, December 8, 2020 3:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Determining required z/series hardware level - REVISED > > It's not foolproof, but for both HLL's and assembler the COBANALZ program > in > CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess > at > the compiler or assembler version that generated the code. From that you > could extrapolate the minimum hardware level required based on the > announcement letter for that release of each language's compiler. Crude, > but possible, though COBANLZ does not handle "unbound object code", only > executables (load module or P.O.). > > For HLL compilers that allow you to generate the pseudo-assembler > equivalent > of the compiled code, you can analyze the compiler listing for instruction > uses, but if you only have executable code, obviously that is no help. > > For executable-only (no source or listing available) assembler, you would > need to decode the executable into instructions and data (not trivial by > any > means) to build a list of instructions used. An instruction trace program > like TRACE390 in CBT file 391 could help there, assuming you have the files > and JCL needed to run the program once through the trace program. The > trace > output would provide you with a list of instructions executed to analyze > for > hardware level. The caveat there is that AFAIK CBT file 391 has not been > updated in quite a while and lacks many of the newer z-architecture > instructions, not least the whole suite of vector instructions. > > Running any kind of instruction trace has the caveat that not all > instruction paths are guaranteed to be executed, and there could easily be > instructions requiring a higher architecture level hiding in un-executed > code. > > In general, if all you have is executable code, I would call this one of > those "hard problems". > > Peter > > -----Original Message- > From: IBM Mainframe Discussion List On Behalf > Of > Mike Hochee > Sent: Tuesday, December 8, 2020 5:50 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Determining required z/series hardware level - REVISED > > Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' > > Hi, > > I'm looking for a utility/program which is capable of reading a z/OS > executable, whether an lmod or program object, or unbound object code, and > examining it for hardware/architecture level compatibility. I'm not > specifically referring to the ARCLVL of on the SYSSTATE macro, although I > know there is some correspondence, but rather to the set of unprivileged > instructions introduced at a particular hardware architecture levels. > Apologies in advance for any imprecise/inaccurate terminology. > > For example, let's say I happen to know that the most recently introduced > z/Series instruction used by a particular executable is the AHI > instruction, > then I would expect this utility/program to output 'G10', suggesting the > minimum hardware architecture required to support execution. > > I understand things are not always black/white in this area and could be > clouded by instruction facility requirements, etc.. > > Thanks in advance for any suggestions, guidance. > > Mike > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error
Re: Determining required z/series hardware level - REVISED
"Version of the compiler" is not sufficient to answer "what hardware level is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11, 12 or 13. So the object code might run on a z10, or it might require a z15, or anything in-between. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Tuesday, December 8, 2020 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED It's not foolproof, but for both HLL's and assembler the COBANALZ program in CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess at the compiler or assembler version that generated the code. From that you could extrapolate the minimum hardware level required based on the announcement letter for that release of each language's compiler. Crude, but possible, though COBANLZ does not handle "unbound object code", only executables (load module or P.O.). For HLL compilers that allow you to generate the pseudo-assembler equivalent of the compiled code, you can analyze the compiler listing for instruction uses, but if you only have executable code, obviously that is no help. For executable-only (no source or listing available) assembler, you would need to decode the executable into instructions and data (not trivial by any means) to build a list of instructions used. An instruction trace program like TRACE390 in CBT file 391 could help there, assuming you have the files and JCL needed to run the program once through the trace program. The trace output would provide you with a list of instructions executed to analyze for hardware level. The caveat there is that AFAIK CBT file 391 has not been updated in quite a while and lacks many of the newer z-architecture instructions, not least the whole suite of vector instructions. Running any kind of instruction trace has the caveat that not all instruction paths are guaranteed to be executed, and there could easily be instructions requiring a higher architecture level hiding in un-executed code. In general, if all you have is executable code, I would call this one of those "hard problems". Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Hochee Sent: Tuesday, December 8, 2020 5:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' Hi, I'm looking for a utility/program which is capable of reading a z/OS executable, whether an lmod or program object, or unbound object code, and examining it for hardware/architecture level compatibility. I'm not specifically referring to the ARCLVL of on the SYSSTATE macro, although I know there is some correspondence, but rather to the set of unprivileged instructions introduced at a particular hardware architecture levels. Apologies in advance for any imprecise/inaccurate terminology. For example, let's say I happen to know that the most recently introduced z/Series instruction used by a particular executable is the AHI instruction, then I would expect this utility/program to output 'G10', suggesting the minimum hardware architecture required to support execution. I understand things are not always black/white in this area and could be clouded by instruction facility requirements, etc.. Thanks in advance for any suggestions, guidance. Mike -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
So the utility would loop through the object code looking for opcodes, and when it found one it would know the required hardware level, and keep track of the maximum found? Interesting idea. I have never heard of such a utility, but it could be attempted. Finding op codes is an imperfect science because it is hard sometimes to tell an opcode from other data. And of course some of the newer instructions are not "just an opcode" -- there are other bits besides the first 8 that specify the particular instruction. If the programs are compiled by a modern compiler I suspect the compiled ARCH level may be in the LE control blocks, but that is just a guess. It that were the case, and that were sufficient, then this is a fairly easy project, and certainly a well-defined project that could be done "perfectly" (as opposed to "imperfect science"). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Hochee Sent: Tuesday, December 8, 2020 2:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' Hi, I'm looking for a utility/program which is capable of reading a z/OS executable, whether an lmod or program object, or unbound object code, and examining it for hardware/architecture level compatibility. I'm not specifically referring to the ARCLVL of on the SYSSTATE macro, although I know there is some correspondence, but rather to the set of unprivileged instructions introduced at a particular hardware architecture levels. Apologies in advance for any imprecise/inaccurate terminology. For example, let's say I happen to know that the most recently introduced z/Series instruction used by a particular executable is the AHI instruction, then I would expect this utility/program to output 'G10', suggesting the minimum hardware architecture required to support execution. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
It's not foolproof, but for both HLL's and assembler the COBANALZ program in CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess at the compiler or assembler version that generated the code. From that you could extrapolate the minimum hardware level required based on the announcement letter for that release of each language's compiler. Crude, but possible, though COBANLZ does not handle "unbound object code", only executables (load module or P.O.). For HLL compilers that allow you to generate the pseudo-assembler equivalent of the compiled code, you can analyze the compiler listing for instruction uses, but if you only have executable code, obviously that is no help. For executable-only (no source or listing available) assembler, you would need to decode the executable into instructions and data (not trivial by any means) to build a list of instructions used. An instruction trace program like TRACE390 in CBT file 391 could help there, assuming you have the files and JCL needed to run the program once through the trace program. The trace output would provide you with a list of instructions executed to analyze for hardware level. The caveat there is that AFAIK CBT file 391 has not been updated in quite a while and lacks many of the newer z-architecture instructions, not least the whole suite of vector instructions. Running any kind of instruction trace has the caveat that not all instruction paths are guaranteed to be executed, and there could easily be instructions requiring a higher architecture level hiding in un-executed code. In general, if all you have is executable code, I would call this one of those "hard problems". Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Hochee Sent: Tuesday, December 8, 2020 5:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' Hi, I'm looking for a utility/program which is capable of reading a z/OS executable, whether an lmod or program object, or unbound object code, and examining it for hardware/architecture level compatibility. I'm not specifically referring to the ARCLVL of on the SYSSTATE macro, although I know there is some correspondence, but rather to the set of unprivileged instructions introduced at a particular hardware architecture levels. Apologies in advance for any imprecise/inaccurate terminology. For example, let's say I happen to know that the most recently introduced z/Series instruction used by a particular executable is the AHI instruction, then I would expect this utility/program to output 'G10', suggesting the minimum hardware architecture required to support execution. I understand things are not always black/white in this area and could be clouded by instruction facility requirements, etc.. Thanks in advance for any suggestions, guidance. Mike -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10' Hi, I'm looking for a utility/program which is capable of reading a z/OS executable, whether an lmod or program object, or unbound object code, and examining it for hardware/architecture level compatibility. I'm not specifically referring to the ARCLVL of on the SYSSTATE macro, although I know there is some correspondence, but rather to the set of unprivileged instructions introduced at a particular hardware architecture levels. Apologies in advance for any imprecise/inaccurate terminology. For example, let's say I happen to know that the most recently introduced z/Series instruction used by a particular executable is the AHI instruction, then I would expect this utility/program to output 'G10', suggesting the minimum hardware architecture required to support execution. I understand things are not always black/white in this area and could be clouded by instruction facility requirements, etc.. Thanks in advance for any suggestions, guidance. Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Determining required z/series hardware level
Hi, I'm looking for a utility/program which is capable of reading a z/OS executable, whether an lmod or program object, or unbound object code, and examining it for hardware/architecture level compatibility. I'm not specifically referring to the ARCLVL of on the SYSSTATE macro, although I know there is some correspondence, but rather to the set of unprivileged instructions introduced at a particular hardware architecture levels. Apologies in advance for any imprecise/inaccurate terminology. For example, let's say I happen to know that the most recently introduced z/Series instruction used by a particular executable is the AHI instruction, then I would expect this utility/program to output 'G9', suggesting the minimum hardware architecture required to support execution. I understand things are not always black/white in this area and could be clouded by instruction facility requirements, etc.. Thanks in advance for any suggestions, guidance. Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
