Straightforward way to determine hardware architecture level?

[Charles Mills]

Is there a fairly straightforward way to determine the "architecture number"
of the hardware on which a program is actually running? By architecture
level I mean z13 = ARCH(11) and so forth, as supported by C/C++ and I think
now COBOL. By straightforward I mean I do not want to test various feature
bits in the CVT and try to infer the architecture level or try various
instructions and catch the S0C1s. The best I have come up with is to get the
CPUID, get the machine type from there, and use a lookup table, so I am
looking for anything better than that. (Adding two to the assembler
"ZS-level" would be a better way, if that were available somewhere.)

Thanks,

Charles

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

[Charles Mills]

I just got on offline reply. To clarify, I mean for a program to make this
determination programmatically, presumably by an LE call or z/OS control
block chaining.

Charles

[Tony Harminc]

On 25 November 2015 at 11:57, Charles Mills <char...@mcn.org> wrote:
> Is there a fairly straightforward way to determine the "architecture number"
> of the hardware on which a program is actually running? By architecture
> level I mean z13 = ARCH(11) and so forth, as supported by C/C++ and I think
> now COBOL. By straightforward I mean I do not want to test various feature
> bits in the CVT and try to infer the architecture level or try various
> instructions and catch the S0C1s.

Well someone's got to ask: why do you want this number, rather than
just testing the relevant feature bit before you try to use some
instruction or feature? The only thing that comes to my mind is that
you may want to dynamically invoke the C (or COBOL) compiler, passing
it the ARCH(nn), but I think the default is the level of the current
system in any case.

Tony H.

[Charles Mills]

... because I have little control over and no knowledge of the specific instructions the compiler may emit. I only know the ARCH level of the compile.

Here's the background: the product recently S0C1ed on initial execution at a new customer. We quickly figured out the problem was a box older than the target of the build. My boss asked "couldn't we put out a better message than S0C1?" (I think S0C1 is a perfectly good message but I am not the boss.)

Of course, the problem is not totally trivial because it implies that the code answering the question is in fact capable of execution on the box. Yes, I think I have that solved -- I will #pragma OPTIONS (ARCH) the entry module (only runs once per execution, optimization is nearly irrelevant) down to a minimum ARCH level, first doing #define ORIGINALARCH __ARCH__. Then I can compare (original) build ARCH to hardware ARCH and exit gracefully with a natural language diagnostic if the former is greater than the latter.

Hokay?

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
Sent: Wednesday, November 25, 2015 10:16 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

On 25 November 2015 at 11:57, Charles Mills <char...@mcn.org> wrote:
> Is there a fairly straightforward way to determine the "architecture number"
> of the hardware on which a program is actually running? By
> architecture level I mean z13 = ARCH(11) and so forth, as supported by
> C/C++ and I think now COBOL. By straightforward I mean I do not want
> to test various feature bits in the CVT and try to infer the
> architecture level or try various instructions and catch the S0C1s.

Well someone's got to ask: why do you want this number, rather than just testing the relevant feature bit before you try to use some instruction or feature? The only thing that comes to my mind is that you may want to dynamically invoke the C (or COBOL) compiler, passing it the ARCH(nn), but I think the default is the level of the current system in any case.

[Elardus Engelbrecht]

Charles Mills wrote:

>I just got on offline reply.

Amazing you get help so fast! Good for you!

>To clarify, I mean for a program to make this determination programmatically, presumably by an LE call or z/OS control block chaining.

Care to tell us what you could use? By peeking in an address somewhere by chasing the control blocks or using of a service/macro or looking at some parmlib member?

I believe I have seen a way via a command or looking in some parmlib member where you could see the ARCH level...

(I will RTFM of course later.)

Just curious if you don't mind please.

Groete / Greetings
Elardus Engelbrecht

[Charles Mills]

Either a documented API (macro, LE call, callable service) or a reasonably straightforward control block chase is what I picture.

As I indicate, a table of 4-digit model numbers -> ARCH level is not out of the question. 4-digit model is obtainable from CSRSI.

I am currently hitting another problem. I will post that.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
Sent: Wednesday, November 25, 2015 10:57 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

[Bob Shannon]

Why not compile with a level that will work on all machines on which you will run? If you compile with ZS-2 you can run back to a z990. The bad news is that your code will be optimized for a z990.

Bob Shannon
Rocket Software
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsub...@rocketsoftware.com
Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

[Charles Mills]

Because I want (well, customers demand) maximum performance on the machines they typically have, but one or two pesky customers want to run on an older machine.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Bob Shannon
Sent: Wednesday, November 25, 2015 11:23 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

Why not compile with a level that will work on all machines on which you will run? If you compile with ZS-2 you can run back to a z990. The bad news is that your code will be optimized for a z990.

[Bob Shannon]

We have one product that that compiles their code for each architectural level. The initial module is determines the hardware and loads the remainder of the code to match the processor

> but one or two pesky customers want to run on an older machine

So you are saying that all of your customers run on a z13 processor, save one or two of them? I find that pretty hard to believe.

Bob Shannon
Rocket Software
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsub...@rocketsoftware.com
Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

[Elardus Engelbrecht]

Bob Shannon wrote:

>We have one product that that compiles their code for each architectural level. The initial module is determines the hardware and loads the remainder of the code to match the processor

How is your initial module working to determine the ARCH level? If you can't disclose it, it is fine. That is all right. I just find that it good to know it is indeed possible to determine the ARCH level and then go the right way.

>So you are saying that all of your customers run on a z13 processor, save one or two of them? I find that pretty hard to believe.

I can believe that. Think about IBM obsession with backward compatibility. Many customers are standing still with ancient machines until they get money to purchase new machines or "get off mainframe".

Groete / Greetings
Elardus Engelbrecht

[Bob Shannon]

> How is your initial module working to determine the ARCH level? If you can't disclose it, it is fine

It's not my product and I haven’t looked at the code. However, it's simple enough to build a table of processor types with the corresponding ARCH/MACH level.

Bob Shannon
Rocket Software
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsub...@rocketsoftware.com
Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

[Charles Mills]

> So you are saying that all of your customers run on a z13 processor, save one or two of them?

Did I say that? I don't recall saying that. I don't recall mentioning any specific models at all.

FWIW, the bulk of our customers seem to be on EC12's.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Bob Shannon
Sent: Wednesday, November 25, 2015 11:33 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

We have one product that that compiles their code for each architectural level. The initial module is determines the hardware and loads the remainder of the code to match the processor

> but one or two pesky customers want to run on an older machine

So you are saying that all of your customers run on a z13 processor, save one or two of them? I find that pretty hard to believe.

[Kirk Wolf]

Charles,

I agree that there should be a compiler or LE API to do this.

If not:
ARCH levels actually map to a set of required "Facilities" (the Principles
of Operation term).

You can test at the facility bits in the PSAE, mapped by IHAFACL.

Then you could use the documentation on ARCH in the compiler manual to
construct a bit mask for each level.

Then start with the lowest level and search until you find the last one
with all of the required facilities.

Here's my whack at it (but I have no idea if it is accurate; Maybe open an
ETR with IBM to confirm? )

ARCH(5) z-arch base. (Assuming that you know that you are running modern
z/OS in z-arch mode, I would start here)
- FaclZArchInstalled

ARCH(6) long-displacement facility
- FaclLongDisplacement

ARCH(7) (z9) extended-immediate facility, DFP facility (if DFP compiler
option enabled)
- FaclExtendedImmediate

ARCH(8) (z10) general instruction extensions facility, DFP Facility
- FaclGeneralInstExtension
- FaclDFPF

ARCH(9) (z196) high-word facility, the interlocked-access facility, the
load/store-on-condition facility, the distinct-operands-facility and the
population-count facility.
- FaclHighWord
- FaclLoadStoreOnCondition
- FaclDistinctOperands
- FaclPopulationCount

ARCH(10) (xC12) execution-hint facility, the load-and-trap
facility, the miscellaneous-instruction-extension facility, and the
transactional-execution facility.
- FaclMiscInstExt
- FaclExecutionHint
- FaclLoadAndTrap
- FaclTransactionalExecution

ARCH(11) (z13) vector facility, the decimal floating point
packed conversion facility, the load/store-on-condition facility, and the
conditional-transaction-end facility.
- Facl_VectorExtensionFacility
- FACL_DFPPackedConversion
- FACL_LoadStoreOnCond2
- FACL_CTEND

[Charles Mills]

Kirk -

Thanks much! Certainly worth considering.

I wish IBM were better organized in general around this:
- the C and COBOL compilers use ARCH levels
- the assembler uses ZS- codes which are different numerically
- there is nothing in the PoOp that says "this instruction requires ARCH n." Yes, it says "requires the long displacement facility" but then it is another lookup to see what ARCH and/or machine type that is.

Not the worst problem humanity faces, but I think a poor presentation of important information.

Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf
Sent: Wednesday, November 25, 2015 3:47 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

[Peter Relson]

To answer your question directly: no there is no such way. Could there be,
in the future? Sure. If z/OS base control program were to provide it, it
might not be the compiler ARCH value but might be the machine generation
number (which happens to be +2 over the compiler ARCH level) -- e.g., z13
happens to be "13" (not a big stretch). If LE or a compiler area were to
provide it, then it would more likely be the number that they use.

The problem that you wrote that you were challenged with solving was "

couldn't we put out a better message than S0C1?""

And the answer is for the most part "yes", without requiring an answer to
the question you posed: field the PIC 1 in recovery and deal with it in a
nicer way than you currently do (such as a message, a unique abend/reason
code pair that you document for your product, whatever).

Peter Relson
z/OS Core Technology Design

[Peter Relson]

I wanted to add that the list of facilities mentioned in one of the posts

>ARCH(10) (xC12) execution-hint facility, the load-and-trap
>facility, the miscellaneous-instruction-extension facility, and the
>transactional-execution facility.

leads to some interesting points.

The availability of an instruction on the machine (which the facility bits
indicate) do not necessarily correlate to whether you may use them.
When there is operating system support needed, there are often "function
bits" that an application is expected to use to determine availability.
We have tried to improve the IHAFACL documentation going forward to help
identify those bits that correlate to facility bit(s).

Transactional execution facility is one of interest. It is available only
on certain z/OS releases (z/OS can run on a zEC12 on more releases than
those z/OS releases that support the instruction).

Further, it is not available on any z/OS release if z/OS is running under
VM.

Thus, for example, running on z/OS 2.2 on a zEC12 does not mean that you
can use transactional execution if you might be under VM.
Apparently C/C++ users are supposed to understand this and not try to run
something that is ARCH(10) if running z/OS under VM if they might have
coded something that led the compiler to generate instructions that are
part of the TEF.

[Elardus Engelbrecht]

Peter Relson wrote:

>Further, it is not available on any z/OS release if z/OS is running under VM.

Very interesting. Are there other functions also absent when z/OS is running as a guest under z/VM?

If so, where is that documented?

Many thanks for your excellent posts. I value them all!

TIA!

Groete / Greetings
Elardus Engelbrecht

[Charles Mills]

@Peter, thank you for the direct answer. Yes, I would consider an "ARCH
level," a "ZS- number" or a "marketing architecture number" such as 13 to be
a great answer to my need. As you move your emphasis more from assembler to
compiled languages an ARCH number rather than "op code bits" would be a good
idea IMHO.

Catching the S0C1 is more complicated than it sounds. There is kind of a
chicken and egg problem. The code is 95% in C++. I am trying to avoid
starting in assembler and calling the C main, which would however make this
problem trivial. I have a recovery routine and it works perfectly, knock on
wood. But setting it up and setting up the things it depends on requires
code, there is a problem (not insurmountable, but not easy -- see companion
thread) with compiling some modules at one ARCH level and some at another,
and so the C++ code S0C1s long before it gets its recovery routine set up.
(FWIW, it S0C1ed trying to display its initial "hello" and version number
message.)

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, November 26, 2015 6:12 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

To answer your question directly: no there is no such way. Could there be,
in the future? Sure. If z/OS base control program were to provide it, it
might not be the compiler ARCH value but might be the machine generation
number (which happens to be +2 over the compiler ARCH level) -- e.g., z13
happens to be "13" (not a big stretch). If LE or a compiler area were to
provide it, then it would more likely be the number that they use.

The problem that you wrote that you were challenged with solving was "
couldn't we put out a better message than S0C1?""
And the answer is for the most part "yes", without requiring an answer to
the question you posed: field the PIC 1 in recovery and deal with it in a
nicer way than you currently do (such as a message, a unique abend/reason
code pair that you document for your product, whatever).

[Tony Harminc]

On 26 November 2015 at 09:47, Elardus Engelbrecht

<elardus.e...@sita.co.za> wrote:
> Peter Relson wrote:

>>Further, it [Transactional Execution] is not available on any z/OS release if z/OS is running under VM.

>
> Very interesting. Are there other functions also absent when z/OS is running as a guest under z/VM?

Large (1MB) page support, among several others.

<idle speculation>
I guess (and I have no IBM-internal knowledge whatsoever about this)
that this is all about a three-way battle between Poughkeepsie,
Endicott, and Boeblingen. Pok has never been wild about running z/OS
under VM, and Boeblingen has shifted from VM as the hypervisor they
absolutely needed to make Linux practical, to KVM, and so perceives
that they can do it all on their own. Where does this leave z/VM? In
third place with insufficient resources, I suspect. Maybe little has
changed since the 1970s and 80s that Lynn Wheeler writes of here so
often...
</idle speculation>

Tony H.

[Peter Relson]

>Are there other functions also absent when z/OS is
>running as a guest under z/VM?

>If so, where is that documented?

I'm sure the answer to the first is "yes", and I don't know the answer to
the second.

But if you were to turn the question around and ask "where is it
documented what you can rely on", that question can be answered for the
z/OS releases that have architecture level sets. Those level sets do not
say (although we tend to think of them this way) "z9 machine" (z/OS 2.1)
or "z10 machine" (z/OS 2.2) but instead indicate the list of facilities
which must be present. Those facilities correlate to the machine, but may
not be a complete set.

I'd guess that if z/OS ever level sets to the zEC12, it won't have
transactional execution facility on the list of facilities (unless by then
there is VM support so that it can say "if running with VM release x/y/z",
or unless it chooses to say "only if not running under VM").

The compilers (I hope) -- I've tried asking them and have not gotten much
of an answer -- tend to limit their exploitation of an ARCH level to those
facilities that
-- do not require operating system support (so that if you're running on
the machine it's available)
-- do not require VM support (so that it will work whether running z/OS
native or under VM)
-- are supported by some release of zPDT (so that you'll get correct
results whether running on the machine or the "right" release of zPDT)

For transactional execution, to the extent that the compiler support is to
use the instruction only when the user explicitly codes something to tell
you to do so, then it could be left to the user to provide whatever
suitable run-time test is needed to ensure availability.

Peter Relson
z/OS Core Technology Design

[Kirk Wolf]

Here's a brute force assembler translation of my quick decoding of doc for
"ARCHLEVEL" in the z/OS V2R2 C/C++ UG.

NB: It would be great if someone could get IBM to confirm that these are
the correct FACL bits described by the ARCHLEVEL doc.
It returns "9" as expected on the z196 machine that I am using, so it must
be right ;-)

TITLE '-- Entry / prologue'
*--------------------------------------------------------------------*
* Checks the IBM z/OS PSAE facility bits to return the highest
* ARCHLEVEL that would be supported by the IBM C/C++ compiler
* on the current machine.
*
* Call with standard system linkage; RC=R15 is the ARCH level.
*
* References:
* IBM C/C++ User's Guide
* Principles of Operation
* IHAFACL macro comments
*
* Version: November 28, 2015
*
* Please report bugs or enhancements to author:
* Kirk Wolf
* Dovetailed Technologies
* ki...@dovetail.com
*
* This is free and unencumbered software released into the
* public domain. Anyone is free to copy, modify, publish,
* use, compile, sell or distribute this software for any purpose.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY
* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
* CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
* WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*
*--------------------------------------------------------------------*
CHKARCH CSECT
CHKARCH AMODE 31
CHKARCH RMODE ANY
USING *,R15
SAVE (14,12),,'CHKARCH &SYSDATE. &SYSTIME.'
LR R12,R15
DROP R15 drop temporary base reg
USING CHKARCH,R12 establish our base register

TITLE '-- Mainline'
USING FLCESAME,0 PSA/PSAE is at location 0
USING FaclData,FlceFacilitiesList

LA R15,0 Default ARCH(0) - should not occur

* Test ARCH(5)
TM FaclByte0,FaclZArchInstalled
BNO EXIT
LA R15,5 ARCH(5)

* Test ARCH(6)
* long-displacement facility
TM FaclByte2,FaclLongDisplacement
BNO EXIT
LA R15,6 ARCH(6)

* Test ARCH(7) (z9)
* long-displacement facility
TM FaclByte2,FaclExtendedImmediate
BNO EXIT
LA R15,7 ARCH(7)

* Test ARCH(8) (z10)
* extended-immediate facility,
* DFP facility
TM FaclByte4,FaclGeneralInstExtension
BNO EXIT
TM FaclByte5,FaclDFPF
BNO EXIT
LA R15,8 ARCH(8)

* Test ARCH(9) (z196)
* high-word facility,
* interlocked-access facility,
* load/store-on-condition facility,
* distinct-operands-facility,
* population-count facility.
TM FaclByte5,FaclHighWord
BNO EXIT
TM FaclByte5,FaclLoadStoreOnCondition
BNO EXIT
TM FaclByte5,FaclDistinctOperands
BNO EXIT
TM FaclByte5,FaclPopulationCount
BNO EXIT
LA R15,9 ARCH(9)

* Test ARCH(10) (xc12)
* execution-hint facility,
* load-and-trap facility,
* miscellaneous-instruction-extension facility,
* transactional-execution facility.
TM FaclByte6,FaclExecutionHint
BNO EXIT
TM FaclByte6,FaclLoadAndTrap
BNO EXIT
TM FaclByte6,FaclMiscInstExt
BNO EXIT
TM FaclByte9,FaclTransactionalExecution
BNO EXIT
LA R15,10 ARCH(10)

* Test ARCH(11) (z13)
* vector facility, -- should we also check CVTVEF ??
* decimal floating point packed conversion facility,
* load/store-on-condition facility,
* conditional-transaction-end facility
TM FaclByte16,Facl_VectorExtensionFacility
BNO EXIT
TM FaclByte10,FACL_DFPPackedConversion
BNO EXIT
TM FaclByte6,FACL_LoadStoreOnCond2
BNO EXIT
TM FaclByte6,FACL_CTEND
BNO EXIT
LA R15,11 ARCH(11)

TITLE '-- Exit / epilogue'
EXIT DS 0H
L 14,12(0,13) restore return address
RETURN (0,12),RC=(15),T

TITLE '-- Constants / DSECTS'
IHAPSAE ,
IHAFACL ,
YREGS ,
END CHKARCH


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

[Charles Mills]

Wow! Thanks!

And all written in S/360 assembler! Will run on Connor's z890!

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf
Sent: Saturday, November 28, 2015 3:12 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

[Kirk Wolf]

FYI, I noticed that there are some cut/paste errors in the comments (only)
for ARCH(7) and ARCH(8).

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

[Jim Mulder]

IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> wrote on
11/28/2015 06:12:04 PM:

> * Test ARCH(6)
> * long-displacement facility
> TM FaclByte2,FaclLongDisplacement
> BNO EXIT
> LA R15,6 ARCH(6)

I would recommend using FaclLongDisplacementHP
instead of FaclLongDisplacement. The long displacement facility
was eventually retrofitted (via a millicode implementation)
to z800/z900 machines.

Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY

[Mike Schwab]

z900/z800 archlevel(5)
z990/z890 archlevel(6)

On Sat, Nov 28, 2015 at 5:17 PM, Charles Mills <char...@mcn.org> wrote:

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

[Robert Wessel]

On 28 Nov 2015 17:22:43 -0800, d10...@US.IBM.COM (Jim Mulder) wrote:

>IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> wrote on
>11/28/2015 06:12:04 PM:
>
>
>> * Test ARCH(6)
>> * long-displacement facility
>> TM FaclByte2,FaclLongDisplacement
>> BNO EXIT
>> LA R15,6 ARCH(6)
>
> I would recommend using FaclLongDisplacementHP
>instead of FaclLongDisplacement. The long displacement facility
>was eventually retrofitted (via a millicode implementation)
>to z800/z900 machines.

In addition to what Jim said, DFPF was introduced with the z10, but
was retrofitted to the z9 with a microcode update. I don't think this
impacts your code as written, but could be an issue if things are
re-arranged a bit.

[Elardus Engelbrecht]

Kirk Wolf wrote:

>FYI, I noticed that there are some cut/paste errors in the comments (only) for ARCH(7) and ARCH(8).

Nevermind, real Assembler programmers don't bother with comments. ;-)

"Comments? What is that new-fangled thing? They're just making my source listings 'dirty'!" ;-D ;-D ;-D

Your code plus Jim's comment confirmed what an IBMer told me this years ago:

"You set the ARCH level in a parmlib member and z/OS will set a field somewhere in a storage area for later usage."

>> NB: It would be great if someone could get IBM to confirm that these are the correct FACL bits described by the ARCHLEVEL doc. It returns "9" as expected on the z196 machine that I am using, so it must be right ;-)

I will try to test it out on my favourite toys on v1.13 and v2.1 (not v2.2). On a sandbox of course.

For others not really familiar to assembler programs, in Kirk listing there is a line YREGS.

YREGS <-- That is a list of register value declarations/constants. You will have to provide your own list.

My humble thanks to you for providing this little gem!

Groete / Greetings
Elardus Engelbrecht

[Peter Relson]

What is still missing is a reason why someone should want to do this sort
of check. Only with that information could one answer a question such as
"should we also check CVTVEF?". Checking CVTVEF will tell you if the
vector extension facility is present *and* that that operating system is
prepared for you to use it. Seeing CVTVEF on will tell you that you are on
a suitable machine with a suitable operating system; seeing it off
provides no information about the machine itself. If you are looking "may
I use this facility" then you should be looking at the facility bit for
that facility and/or the operating system bit for that facility.

Of course some of the architecture levels will no longer be associated
with supported releases once z/OS 2.1 is the last supported release.

Charles Mills has a reason. But part of that reason is that he's running
in an environment that he cannot control (and hence cannot set a
reasonable recovery environment to accomplish the functionality that he
was challenged to provide). He asked for a specific value. Such a value
might be reasonable for the operating system to provide.

I'm actually curious if you can tell at runtime what C/C++ ARCH level was
this module compiled at. Otherwise, why would you want to know what the
ARCH level would be if you were to compile "now". Perhaps this is instead
a piece of data provided by the module itself, in which case it could
provide "something else" (such as the machine generation number) to
correlate to some new operating-system-provided field.

What are you actually trying to accomplish with the tests of the facility
bits to determine machine? I wouldn't expect that a customer would need to
be told what machine they are using.

Are you bringing in different levels of your product at runtime based on
which machine you find you are running on? If you are, for z/OS 2.2 and up
you might check out the IEFOPZxx support that was mentioned in the z/OS
2.2 announce and that is expected to be available on or about December 10
(documentation will not be available until the general availability, but
this has been disclosed to ISVs).

- Long displacement facility is viewed to be part of z900 (as Jim Mulder
indicated).
- LD High Performance is part of z990.
- Extended immediate - z9
- General Instruction Extension - z10
- Decimal Floating Point - z9
- Decimal Floating Point High Performance - z10
- High word (etc) - z196 -- note that the 4 facilities are all represented
by a single bit, so it would be foolish to test them all individually
- Execution hint - zEC12. Same bit as miscellaneous instructions
extension. Load and trap - not part of any architecture, just another name
for this bit
- Transactional execution - zEC12
- Vector Extension Facility - z13
- DFP Packed - z13
- Load store on cond 2 - z13
- CTEND

But as I had mentioned you will not find the transactional execution
facility bit (or the CVTTX bit) on if running z/OS under VM. So what are
you accomplishing with a test of this bit to indicate some machine? And
the same might be asked for some of the others. The bits (sometimes
coupled with an operating system bit) are in general intended to be used
to answer "is this facility available for my use?".

Jim mentioned the "virtual architecture level". There is such a value in
the SCPINFO. Its architectural definition might be enhanced in the future
to provide the "sort of" information that is being asked for. I say "sort
of" because its value range starts at one for z196 (and it will likely
never "skip values" in order to get up to "n" for "machine generation n".
Currently, VAL+10 = machine generation.

Peter Relson
z/OS Core Technology Design

[Charles Mills]

> 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 ...

Thanks for your help and input.

Charles

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

[Charles Mills]

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 ..."

[J O Skip Robinson]

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....@sce.com

[Robert Wessel]

That's just what's specified (or defaulted) for ARCHLVL in your
LOADxx, and doesn't really correspond to the architecture level of the
machine.


On 29 Nov 2015 11:43:48 -0800, Jo.Skip....@SCE.COM (J O Skip

[Charles Mills]

I am not a LOADXX guru but &SYSALVL looks like waaaaaaay too little
granularity. It seems to *stop* at ARCHLVL=2, "z Architecture." My OP was
looking to distinguish *among* recent models -- say z990 to z13.

The basic problem is the C compiler will optimize to give best performance
on, say, a z196 -- but the resulting code S0C1's on a z10. My boss wants
something more user-friendly than a S0C1.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of J O Skip Robinson
Sent: Sunday, November 29, 2015 11:44 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

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...

[Chris Hoelscher]

≫> My boss wants something more user-friendly than a S0C1.

Like a S0C1:) ???

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538
email to list...@listserv.ua.edu<mailto:list...@listserv.ua.edu> with the message: INFO IBM-MAIN


The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.

[J O Skip Robinson]

I get it. There are different meanings of 'architecture level'. You need more granularity. Not knowing the ins and outs of the various control blocks suggested by others, I would take the KISS approach with a table of supported models and what action you would take for each. A substantial but not endless list. Inelegant, but easy(ish) to build and maintain. DISPLAY M=CPU gives detail on CPC family and model number in various formats. If a match is not found in your table, use the highest one you support and issue a warning message. You have to determine this at run time because a program could easily need to run on a machine higher or lower than one it's compiled on.

IEE174I 12.15.00 DISPLAY M 245
PROCESSOR STATUS
ID CPU SERIAL
00 + ssssss2827
01 + ssssss2827
02 +I ssssss2827
03 -
04 -I

CPC ND = 002827.H43.IBM.02.0000000ssssss
CPC SI = 2827.704.IBM.02.0000000000ssssss
Model: H43
CPC ID = 00
CPC NAME = cpc-name
LP NAME = lpar-name LP ID = #
CSS ID = 0
MIF ID = 1

+ ONLINE - OFFLINE . DOES NOT EXIST W WLM-MANAGED
N NOT AVAILABLE

I INTEGRATED INFORMATION PROCESSOR (zIIP)
CPC ND CENTRAL PROCESSING COMPLEX NODE DESCRIPTOR
CPC SI SYSTEM INFORMATION FROM STSI INSTRUCTION
CPC ID CENTRAL PROCESSING COMPLEX IDENTIFIER
CPC NAME CENTRAL PROCESSING COMPLEX NAME
LP NAME LOGICAL PARTITION NAME
LP ID LOGICAL PARTITION IDENTIFIER
CSS ID CHANNEL SUBSYSTEM IDENTIFIER
MIF ID MULTIPLE IMAGE FACILITY IMAGE IDENTIFIER

.
.
.
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....@sce.com

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

I am not a LOADXX guru but &SYSALVL looks like waaaaaaay too little granularity. It seems to *stop* at ARCHLVL=2, "z Architecture." My OP was looking to distinguish *among* recent models -- say z990 to z13.

The basic problem is the C compiler will optimize to give best performance on, say, a z196 -- but the resulting code S0C1's on a z10. My boss wants something more user-friendly than a S0C1.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson
Sent: Sunday, November 29, 2015 11:44 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

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...

[Charles Mills]

Right. Basic problem is program is compiled for z196, customer runs it on
z10.

CSRSI gets the machine type and a lot more. CSRSI is basically a wrapper for
STSI.

I implemented the table approach but have decided to switch to Kirk's
facility bit test approach.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of J O Skip Robinson
Sent: Sunday, November 29, 2015 12:33 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

I get it. There are different meanings of 'architecture level'. You need
more granularity. Not knowing the ins and outs of the various control blocks
suggested by others, I would take the KISS approach with a table of
supported models and what action you would take for each. A substantial but
not endless list. Inelegant, but easy(ish) to build and maintain. DISPLAY
M=CPU gives detail on CPC family and model number in various formats. If a
match is not found in your table, use the highest one you support and issue
a warning message. You have to determine this at run time because a program
could easily need to run on a machine higher or lower than one it's compiled
on.

[Ed Gould]

Charles,

I have been watching this thread and if I am not mistaken you want to
know which instructions are available (or not) at execution time.
I am not knowledgeable of c/c++ but unless you compile the program at
run time (with the correct arch type) you will always get an 0C1 if
you execute the instruction on a machine that is incapable of
executing that instruction. I would suggest that you compile at the
lowest level and therefore should run on all types of the machine. If
you are concerned about "efficiency" there is no real answer and you
are exercising a way to get a medical condition(ulcer). Tell your
boss to either ship the source and compile it whenever the machine
type changes (make the customer do it).
OR just ship at the lowest architected of the Z models or let the
customer do it.
We are probably talking about a few CPU seconds or there unless this
is a MAJOR usage animal. Then I would suggest let the responsibility
lie with the customer.

Ed

[Stevet]

This is why you have specialty routines that you load and if I remember correctly, IDENTIFY.

What is being described is part of the joys of being an ISV.

Imagine, back in the day, of providing code that was sensitive to JES2 releases and Maint changes. My headache w/ ACS/WYLBUR while also handling JES3, RACF, ACF2, etc.

You do what your customers need.

Sent from iPhone - small keyboard fat fingers - expect spellinf errots.

> On Nov 29, 2015, at 7:22 PM, Ed Gould <edgou...@COMCAST.NET> wrote:
>
> Charles,
>
> I have been watching this thread and if I am not mistaken you want to know which instructions are available (or not) at execution time.
> I am not knowledgeable of c/c++ but unless you compile the program at run time (with the correct arch type) you will always get an 0C1 if you execute the instruction on a machine that is incapable of executing that instruction. I would suggest that you compile at the lowest level and therefore should run on all types of the machine. If you are concerned about "efficiency" there is no real answer and you are exercising a way to get a medical condition(ulcer). Tell your boss to either ship the source and compile it whenever the machine type changes (make the customer do it).
> OR just ship at the lowest architected of the Z models or let the customer do it.
> We are probably talking about a few CPU seconds or there unless this is a MAJOR usage animal. Then I would suggest let the responsibility lie with the customer.
>
> Ed
>>

[Timothy Sipples]

Perhaps it's too obvious, but the z/OS release level provides certain
information. Specifically:

1. If you're on z/OS 1.6 or a higher 1.x release, you know you're on a
z900/z800 or higher and cannot be on a 31-bit machine.
2. If you're on z/OS 2.1, you know you're on a z9 or higher.
3. If you're on z/OS 2.2, you know you're on z10 or higher.
4. If you're on a future release of z/OS higher than 2.2, it's reasonable
to assume you're on z10 or higher.

This'd be a first level check, and then you can cautiously "upgrade" the
machine level determination from there. This'd be appropriate, base level
analysis for zPDT and RDTz environments, for example.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
--------------------------------------------------------------------------------------------------------

E-Mail: sip...@sg.ibm.com

[Ed Gould]

On Nov 29, 2015, at 7:17 PM, Stevet wrote:

> This is why you have specialty routines that you load and if I
> remember correctly, IDENTIFY.
>
> What is being described is part of the joys of being an ISV.
>
> Imagine, back in the day, of providing code that was sensitive to
> JES2 releases and Maint changes. My headache w/ ACS/WYLBUR while
> also handling JES3, RACF, ACF2, etc.
>
> You do what your customers need.
>
> Sent from iPhone - small keyboard fat fingers - expect spellinf
> errots.

Then supply an object deck that has the "special" instructions with
instructions to relink the problem program. Put the burden on the
user. BTW he has not informed us what the timing difference is. I
submit that the most crucial missing part of this discussion is.

Ed

[Steve Thompson]

On 11/29/2015 09:56 PM, Ed Gould wrote:
> On Nov 29, 2015, at 7:17 PM, Stevet wrote:

<SNIPPAGE>

> Then supply an object deck that has the "special" instructions
> with instructions to relink the problem program. Put the burden
> on the user. BTW he has not informed us what the timing
> difference is. I submit that the most crucial missing part of
> this discussion is.
>
> Ed
>

<SNIP>
Perhaps you should ask him for an NDA (Non-Disclosure Agreement)
so he can provide all the proprietary particulars to/for you?

With WYLBUR, I did what you are suggesting. I had the customer(s)
do an assembly of a module that generated offsets to certain
items that WYLBUR needed for running an SRB in the JES2 address
space. The OCO code may have been "patched" via a PTF or two due
to changes in the JES2 code. In this way, WYLBUR wouldn't fall
over, or take out JES.

But, what the OP is doing, is a different animal (from where I sit).

There is a certain customer (whether or not he has the same
problem with the same customer) that asked a specific vendor, for
a specific product, if they would run the C/C++ compiler with a
particular ARCHLEVEL and allow them to test their product (they
were having an UGLY tuning issue).

I suggested to the management of that customer that this could be
a difficult thing for an ISV to do, depending on the number of
customers they have, and what hardware they are all running on.

So what the OP is doing, I am somewhat sympathetic with, having
had to deal with some similar issues as a customer, and as a vendor.

Regards,
Steve Thompson

[Ed Gould]

Steve:

I don't think I asked of him anything a customer wouldn't ask.
Frankly if he would have responded with a 10 percent increase that
would have been good enough (for me as a non customer). The bottom
line are we talking about 1 second or 5000 seconds savings that would
be good enough to decide if his work would save his company. So far
there have been some pretty good answers except for the metrics of
savings.

Ed

[Bob Shannon]

>For others not really familiar to assembler programs, in Kirk listing there is a line YREGS.

>YREGS <-- That is a list of register value declarations/constants. You will have to provide your own list.

YREGS is shipped in SYS1.MACLIB. It only provides equates for GPRs.

Bob Shannon
Rocket Software
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsub...@rocketsoftware.com
Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

[Elardus Engelbrecht]

Bob Shannon wrote:

>YREGS is shipped in SYS1.MACLIB. It only provides equates for GPRs.

Duh, yes, you're right of course.

Thanks for curing my blue Monday ignorance! Much appreciated.

And there is SYS1.MACLIB(IAZYREG), which includes both GPR and Access Registers.

Groete / Greetings
Elardus Engelbrecht

[John McKown]

On Mon, Nov 30, 2015 at 6:29 AM, Bob Shannon <bsha...@rocketsoftware.com>
wrote:

> >For others not really familiar to assembler programs, in Kirk listing
> there is a line YREGS.
>
> >YREGS <-- That is a list of register value declarations/constants.
> You will have to provide your own list.
>
> YREGS is shipped in SYS1.MACLIB. It only provides equates for GPRs.
>

​And there are some others. Such as IAZYREG, which supplies R0..R15 and
AR0..AR15 equates. ​Of course, I prefer mine. It has both the GPRs and ARs,
but has them "typed" properly as well.

ref: https://gist.github.com/JohnArchieMckown/b95ee10fb8ce593d7304

eg:

R0 EQU 0,,,,GR
R1 EQU 1,,,,GR
R2 EQU 2,,,,GR
...
R0_64 EQU 0,,,,GR64
R1_64 EQU 1,,,,GR64
...
R0_32 EQU 0,,,,GR32
R1_32 EQU 1,,,,GR32
...
AR0 EQU 0,,,,AR
AR1 EQU 1,,,,AR

​Of course, my code is "weird" in that I cause HLASM to flag the
instruction:

LG R10,DOUBLE

because, in my case, it should be:

LG R10_64,DOUBLE​

​And so on. Yeah, I'm paranoid even about myself. Hum, maybe _more_ about
myself.​




>
> Bob Shannon
> Rocket Software
>
>
--

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

[Elardus Engelbrecht]

John McKown wrote:

>​... Such as IAZYREG, ...

<Fail-safe Emergency Shields on!>

I believe it should be renamed to LazyRegs... ;-)

<Fail-safe Emergency shields off!>

>​Of course, my code is "weird" in that I cause HLASM to flag the instruction:
> LG R10,DOUBLE
>because, in my case, it should be:
> LG R10_64,DOUBLE​
>​And so on.

Interesting. That is a good way to check your code.

Groete / Greetings
Elardus Engelbrecht

[Charles Mills]

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

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of Ed Gould
Sent: Sunday, November 29, 2015 4:22 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

Charles,

I have been watching this thread and if I am not mistaken you want to know
which instructions are available (or not) at execution time.
I am not knowledgeable of c/c++ but unless you compile the program at run
time (with the correct arch type) you will always get an 0C1 if you execute
the instruction on a machine that is incapable of executing that
instruction. I would suggest that you compile at the lowest level and
therefore should run on all types of the machine. If you are concerned about
"efficiency" there is no real answer and you are exercising a way to get a

medical condition(ulcer). Tell your boss to either ship the source and

compile it whenever the machine type changes (make the customer do it).
OR just ship at the lowest architected of the Z models or let the customer
do it.
We are probably talking about a few CPU seconds or there unless this is a
MAJOR usage animal. Then I would suggest let the responsibility lie with
the customer.

[Elardus Engelbrecht]

Charles Mills wrote:

>Sorry. MSUs are *incredibly* important to some (most?) customers. They are a major buy/no-buy decider.

Indeed. Other questions customers also asked to vendors (from what I know and found out over the years):

- How easy is it to install? With SMP/E (increasingly important) or not?
- Are RACF or ESM called for security? Is the z/OS security sufficient enough or are extra security checks needed?
- Performance - can it distribute workload? CICS, MQ, etc. can do that for example.
- Resource usage, beside MSU, how much memory/disk space/network resources are needed?
- Do you need exits? Yes/No/Optional.
- Support from n-2 to n+2 levels depending where you are now. (and of course the type of machine and ARCH level.)
- If I find a problem, is it easy to report it and get a fix for that?
- Can I easily move from a competitor to YOUR software? Can I fallback to your vendor until you sort yourself out?
- etc. etc. etc.

> Shipping the source is utterly out of the question,

Of course, you have to be crazy if you give away your bread and butter source for all the greedy vultures on this planet.

During my private work years ago, some of my clients want the source [1] for 'security evaluation' or something crappy like that. A simple 'no' as answer and moving on to the next customer resolved that quick.

[1] - Years ago it was told to me that some z/OS vendors gave the source code of SVC routines to satisfy their client paranoia... But generally their statement of integrity is enough of course. Can management read Assembler source listings?

>Seriously, thanks for your input.

And thanks for your input too. It was an interesting thread to all of us here.

Groete / Greetings
Elardus Engelbrecht

[Shmuel Metz , Seymour J.]

In <1A619CDC-A055-40EC...@copper.net>, on 11/29/2015

at 08:17 PM, Stevet <ste...@COPPER.NET> said:

>This is why you have specialty routines that you load and if I
>remember correctly, IDENTIFY.

You don't need IDENTIFY unless you want to use system assisted linkage
to a name other then the name you loaded or the true name.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

[Ed Gould]

Charles:

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.

Ed

[Ed Gould]

On Nov 30, 2015, at 8:32 AM, Elardus Engelbrecht wrote:

> Charles Mills wrote:
> ----------------------SNIP--------------------------------------------

>> Shipping the source is utterly out of the question,
>
> Of course, you have to be crazy if you give away your bread and
> butter source for all the greedy vultures on this planet.
>
> During my private work years ago, some of my clients want the
> source [1] for 'security evaluation' or something crappy like that.
> A simple 'no' as answer and moving on to the next customer resolved
> that quick.
>
> [1] - Years ago it was told to me that some z/OS vendors gave the
> source code of SVC routines to satisfy their client paranoia... But
> generally their statement of integrity is enough of course. Can
> management read Assembler source listings?

E:

There are other vendors that ship source (at one time CA did) and not
for just their SVC's but executed programs.
In fact I debugged a source program that did not work with SWA above
the line.
I don't know of any current vendor off the top of my head that does
ship source but then they don't try to do what John is trying to do
either .

Ed

[Charles Mills]

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

[Blaicher, Christopher Y.]

Ed,
When you work on a product that can amount to a significant percentage of the workload on a system, even micro-seconds count.
When I worked at a package delivery company, we looked at how to cut a thousandth or a ten-thousandth of a second from a transaction. When you are dealing with things that happen 10 to 40 million times a day, it matters.
It's called upgrade avoidance.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234 | M: 512-627-3803
E: cbla...@syncsort.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Ed Gould
Sent: Monday, November 30, 2015 2:49 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

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.

Ed

________________________________



ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.

[Mike Schwab]

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.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

[Ed Gould]

Charles:

Then the issue *IS* correct and *IS* appropriate. I am suggesting
that if the discussion had started out with that understanding a lot
of electrons would have been saved.

Ed

[Ed Gould]

Chis:

I understand NOW but that was not discussed in the open question.

Ed

[Charles Mills]

You know you're damned if you do and damned if you don't.

If I had started the question with "I am the principal developer for a
product that integrates z/OS with SIEMs" then I risk thread drift/hijacking
into "why would anyone want to do that?/what's a SIEM?/why would we care
what your product does?"

Frankly, I think I am entitled to ask "is there a way to do X?" without
explaining why I want to do X. I could turn this around and say that you
might have asked what the software did before criticizing the question.

Not trying to start a flame war. Hard to "smile" in an e-mail but trust me,
I am smiling. Thanks for your input. Thanks for everyone's input.
(Especially you, Kirk!)

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of Ed Gould
Sent: Monday, November 30, 2015 2:34 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

Charles:

Then the issue *IS* correct and *IS* appropriate. I am suggesting that if
the discussion had started out with that understanding a lot of electrons
would have been saved.

[J O Skip Robinson]

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
JO.Skip....@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Monday, November 30, 2015 5:59 AM
To: IBM-...@LISTSERV.UA.EDU
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>

[Charles Mills]

Interesting. That makes sense. I've got a better method anyway, but you know
what IBM says now? I just happened to run into this a few minutes ago. (From
the Nov. 2012 PoOp)

Programming Note: Prior to the introduction of
z/Architecture, determination of the presence of a
facility was often accomplished by means of a trial
execution of an instruction. If an operation exception
was not recognized during the trial execution, then it
could be assumed that the facility was present.

Similarly, certain instructions provide a query function
to determine the availability of other functions of
the instruction or related instructions. However, a
program might attempt to determine the availability of
a particular function by trial execution of the function.

With the advent of facility and function indications in
z/Architecture, the technique of trial execution should
be avoided - particularly if a workload may be relocated
to another system in which a facility's instructions
may not be present. In such an environment,
STORE FACILITY LIST EXTENDED (STFLE) or an
instruction's query or test function may provide a
more accurate indication of facilities and functions
that are available on all systems in the computing
environment.

Charles

[David L. Craig]

On 15Nov30:1354-0600, Ed Gould wrote:

> On Nov 30, 2015, at 8:32 AM, Elardus Engelbrecht wrote:
>
> >Charles Mills wrote:
> >----------------------SNIP--------------------------------------------
> >>Shipping the source is utterly out of the question,
> >
> >Of course, you have to be crazy if you give away your bread and butter
> >source for all the greedy vultures on this planet.
> >
> >During my private work years ago, some of my clients want the source [1]
> >for 'security evaluation' or something crappy like that. A simple 'no' as
> >answer and moving on to the next customer resolved that quick.
> >
> >[1] - Years ago it was told to me that some z/OS vendors gave the source
> >code of SVC routines to satisfy their client paranoia... But generally
> >their statement of integrity is enough of course. Can management read
> >Assembler source listings?
>
> E:
>
> There are other vendors that ship source (at one time CA did) and not for
> just their SVC's but executed programs.
> In fact I debugged a source program that did not work with SWA above the
> line.
> I don't know of any current vendor off the top of my head that does ship
> source but then they don't try to do what John is trying to do either .
>
> Ed

Then there's source escrow that no longer seems to be available to
customers that are betting their businesses on the continued support
of a software facility. I guess the bean counters believe it is
less expensive to perish with the software than to paddle the canoe
or identify and migrate to another product. Does such planning fall
within the purview of "business continuity" these days?
--
<not cent from sell>
May the LORD God bless you exceedingly abundantly!

Dave_Craig______________________________________________
"So the universe is not quite as you thought it was.
You'd better rearrange your beliefs, then.
Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_________________

[Charles Mills]

David, we had this same discussion back in May of 2014. Here is what I wrote
then:

The usual term for this is "source code escrow." A third party holds the
code with a contract that says that if the vendor goes out of business or
fails in some way then you get the source code. The third party charges, and

so the vendor may charge you.

There are two or three HUGE problems with source code escrow:

1. Thing about your own programs. You hire a guy or gal. You sit him or her
down with all of the documentation and relevant tools and help from your
experienced people. How long before he or she is productive? Three months?
Now, suppose this vendor product blows up and it turns out the vendor is out

of business. You are going to go to court, get the software from the escrow
agent, get the necessary platforms and tools -- and fix the bug, all quickly

enough to make a difference to your business?

2. Unless you have an elaborate verification process, what if you get the
source code and discover that through malice or oversight, the source code
is five versions back out of date and missing three critical include files?

3. A contract that says "we will do X in the future" -- in this case, give
you access to our source code -- is what is called an "executory contract."
Bankruptcy courts are very reluctant to enforce executory contracts because
the whole point of bankruptcy is tear up whatever came before and give the
debtor a fresh start.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On

Behalf Of David L. Craig
Sent: Monday, November 30, 2015 4:24 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

Then there's source escrow that no longer seems to be available to customers
that are betting their businesses on the continued support of a software
facility. I guess the bean counters believe it is less expensive to perish
with the software than to paddle the canoe or identify and migrate to
another product. Does such planning fall within the purview of "business
continuity" these days?

[Ed Gould]

On Nov 30, 2015, at 5:44 PM, J O Skip Robinson wrote:

> 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.

---------------SNIP-------------------

Then there is the "other" story. A well known southern university
were being told that they had to go AMDAHL. The manager cooked up a
program that ran poorly on AMDAHL and the IBM it ran perfectly (of
course).
They used that justification to pick IBM.

Ed

[Shmuel Metz , Seymour J.]

In
<SN1PR0101MB15208BA0E...@SN1PR0101MB1520.prod.exchangelabs.com>,
on 11/30/2015

at 11:44 PM, J O Skip Robinson <Jo.Skip....@SCE.COM> said:

>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.

Are you sure that you aren't thinking of MVS/SE?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

[Kirk Wolf]

And, &SYSALVL, could only give you information about the machine that you
were assembling on, not the one that you were running on.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Sun, Nov 29, 2015 at 2:10 PM, Charles Mills <char...@mcn.org> wrote:

> I am not a LOADXX guru but &SYSALVL looks like waaaaaaay too little
> granularity. It seems to *stop* at ARCHLVL=2, "z Architecture." My OP was
> looking to distinguish *among* recent models -- say z990 to z13.
>
> The basic problem is the C compiler will optimize to give best performance
> on, say, a z196 -- but the resulting code S0C1's on a z10. My boss wants
> something more user-friendly than a S0C1.

>
> Charles
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of J O Skip Robinson
> Sent: Sunday, November 29, 2015 11:44 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Straightforward way to determine hardware architecture level?
>

> 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...

[Ed Gould]

On Nov 30, 2015, at 5:54 PM, Charles Mills wrote:
> ----------------SNIP-------------------------------------

> With the advent of facility and function indications in
> z/Architecture, the technique of trial execution should
> be avoided - particularly if a workload may be relocated
> to another system in which a facility's instructions
> may not be present. In such an environment,
> STORE FACILITY LIST EXTENDED (STFLE) or an
> instruction's query or test function may provide a
> more accurate indication of facilities and functions
> that are available on all systems in the computing
> environment.

Charles:

While that may have been a "backdoor" way of doing things, I believe
IBM introduced the concept of the SU Bit String which I believe was
meant to be a "programming interface" now if my memory is correct was
for figuring out which FMID (selectable unit) was installed. The
interface was specifically for software that was installed. During
that time frame the only "hardware" that was really installable was
the vector facility (if memory serves me, I could be wrong) and I
think there was a SU for that even. We never had it so I have no
first hand knowledge. IBM did drop that somewhere in the early 1980's
(approximately). I know we were semi celebratory because we were
tired of assembling the nuc for some trivial function like DEMF.

So in the past there was at least one other interface to figure out
the hardware that was installed.

Ed

[Timothy Sipples]

Mike Schwab wrote:
>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.

I like the core of your idea. All levels might be too much to manage (7
model generations with IBM's currently supported z/OS releases), but
shipping this trio could make commercial sense (as an example):

Level C: Runs on all IBM supported z/OS releases (currently z900/z800
systems or higher)
Level B: Runs on most recent three model generations (currently z196, z114,
zEC12, zBC12, and z13)
Level A: Runs on current model generation (currently z13)

Level A, B, or C could be chosen based on a parameter, post installation.
That'd be safer for DR purposes, for example.

Level C is "universal," Level B is "all possible Parallel Sysplex system
configurations incorporating the current model," and Level A is "current
model." Level B is also "performance optimized during migration steps to
current model," and Level A is also "performance optimized for current
model."

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com

[John Eells]

Ed Gould wrote:
> On Nov 30, 2015, at 5:54 PM, Charles Mills wrote:
>> ----------------SNIP-------------------------------------
>> With the advent of facility and function indications in
>> z/Architecture, the technique of trial execution should
>> be avoided - particularly if a workload may be relocated
>> to another system in which a facility's instructions
>> may not be present. In such an environment,
>> STORE FACILITY LIST EXTENDED (STFLE) or an
>> instruction's query or test function may provide a
>> more accurate indication of facilities and functions
>> that are available on all systems in the computing
>> environment.
>
>
> Charles:
>
> While that may have been a "backdoor" way of doing things, I believe IBM
> introduced the concept of the SU Bit String which I believe was meant to
> be a "programming interface" now if my memory is correct was for
> figuring out which FMID (selectable unit) was installed. The interface
> was specifically for software that was installed. During that time frame
> the only "hardware" that was really installable was the vector facility
> (if memory serves me, I could be wrong) and I think there was a SU for
> that even. We never had it so I have no first hand knowledge. IBM did

> drop that somewhere in the early 1980's(approximately). I know we were

> semi celebratory because we were tired of assembling the nuc for some
> trivial function like DEMF.
>
> So in the past there was at least one other interface to figure out the
> hardware that was installed.

<snip>

The SU Bit String was built by (IIRC) GENERATE causing the IHASUBIT
macro to use other macros. Macros setting zeroes were shipped, to be
replaced by macros that set ones when different components were
installed. Nowhere was hardware directly involved, as this was a
software installation time change,

The SU Bit String had been frozen for quite a while when I came along
and caused IHASUBIT and its associated macros to be removed from the
(then) MVS/ESA SP Version 4 product after System Generation was finally
withdrawn in all its flavors.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

[Bob Shannon]

> Amdahl responded by shipping some code that was loaded early in IPL to accommodate the new instructions

SE and SP Assist. They trapped the abend in the FLIH. I remember it well.

Bob Shannon
Rocket Software
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsub...@rocketsoftware.com
Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

[Tom Marchant]

On Mon, 30 Nov 2015 22:36:37 -0600, Kirk Wolf wrote:

>And, &SYSALVL, could only give you information about the machine that you
>were assembling on, not the one that you were running on.

No. &SYSALVL indicates the architecture level of the machine, as specified at IPL
time in the LOADxx member. The only value it can have on currently supported
releases of z/OS is "2", meaning that the machine was IPLed in z/Architecture mode.
IIRC it is there because the IPL process is different in z/Architecture mode than it
is in ESA/390 mode.

--
Tom Marchant

[Peter Relson]

>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.

You might find forthcoming APAR OA47689 PTF UA90982 of interest. This is
likely to be on or about December 10.
It is likely that no additional information will be available until that
time.

Instead of "installation pick" it might be "installation tells the system
what is available, and the system picks", and the system complains only
when none of the available things can be used on the machine (e.g,. what
is available is "zEC12 version and z13 version" but you're running on
"z10").

This usage is not the primary intent of the APAR so it might not meet your
needs, but then again it might suffice.

One use of the APAR is to help you with migrating from Cobol 4 to Cobol 5
without changing a ton of JCL (how much JCL is a "ton" anyway?).

Peter Relson
z/OS Core Technology Design

[Tom Marchant]

On Tue, 1 Dec 2015 12:52:05 +0000, Bob Shannon wrote:

>> Amdahl responded by shipping some code that was loaded early in IPL to
>>accommodate the new instructions
>
>SE and SP Assist. They trapped the abend in the FLIH. I remember it well.

That's SE Assist. And it led to the design on the 580 series of computers that
provided a third state of operation called (IIRC) System state. The 580 design
included hardware to virtualize the user's processor.

The code that ran in System state was called Macrocode and it was loaded
from the console processor into memory that was outside of the memory
available to customers. Macrodode routines emulated new instructions.

A side benefit of all that was that it made Multiple Domain Facility possible.
The hardware that supported the virtualization included additional registers for
the use of Macrocode and other facilities that made MDF quite efficient.

--
Tom Marchant

[J O Skip Robinson]

Timeframe was 1980 plus or minus. I was a true novice sysprog and kept an arm's length from OS innards. It was during that two-year gig that MVS/SP was announced, so not likely available just yet. I only remember being impressed with the clever workaround that kept the Amdahl useful.

P.S. The same machine had a load button on the system keyboard. One day an operator's purse fell over and caused a midmorning IPL. Amdahl installed a little box around the button. They were clever folks. ;-)

.
.
.
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....@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: Tuesday, December 01, 2015 7:27 AM
To: IBM-...@LISTSERV.UA.EDU

[Mark Jacobs - Listserv]

We had an operator named Sheldon, who had the habit of resting his elbow
on the POR? button on the console keyboard (3033 maybe). After this
happened a couple of times we installed a pill box cover over the button
and named it the "Sheldon Shield".

Mark Jacobs

> J O Skip Robinson <mailto:Jo.Skip....@SCE.COM>
> December 1, 2015 at 4:19 PM

> That's SE Assist. And it led to the design on the 580 series of
> computers that provided a third state of operation called (IIRC)
> System state. The 580 design included hardware to virtualize the
> user's processor.
>
> The code that ran in System state was called Macrocode and it was
> loaded from the console processor into memory that was outside of the
> memory available to customers. Macrodode routines emulated new
> instructions.
>
> A side benefit of all that was that it made Multiple Domain Facility
> possible.
> The hardware that supported the virtualization included additional
> registers for the use of Macrocode and other facilities that made MDF
> quite efficient.
>
> --
> Tom Marchant
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

> Please be alert for any emails that may ask you for login information
> or directs you to login via a link. If you believe this message is a
> phish or aren't sure whether this message is trustworthy, please send
> the original message as an attachment to 'phis...@timeinc.com'.
>

--

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison

[Steve Thompson]

On 12/01/2015 10:27 AM, Tom Marchant wrote:
> On Tue, 1 Dec 2015 12:52:05 +0000, Bob Shannon wrote:
>
>>> Amdahl responded by shipping some code that was loaded early in IPL to
>>> accommodate the new instructions
>>
>> SE and SP Assist. They trapped the abend in the FLIH. I remember it well.
>
> That's SE Assist. And it led to the design on the 580 series of computers that
> provided a third state of operation called (IIRC) System state. The 580 design
> included hardware to virtualize the user's processor.
>
> The code that ran in System state was called Macrocode and it was loaded
> from the console processor into memory that was outside of the memory
> available to customers. Macrodode routines emulated new instructions.
>
> A side benefit of all that was that it made Multiple Domain Facility possible.
> The hardware that supported the virtualization included additional registers for
> the use of Macrocode and other facilities that made MDF quite efficient.
>

If I remember correctly, that led to FAM (a part of Macrocode),
Fast Assist Mode. It allowed Amdahl to emulate instructions
rather rapidly -- both on the machine and building the
instruction emulation to install on machines.

I do remember a very interesting thing that Amdahl did: MVCIN

It was implemented on those machines, but not on the IBM 3090s.
Which caused me a problem on a VSE to MVS migration, because I
needed that inverse move. When I was working at Amdahl I was
amazed at how that had been implemented.

I miss those days.

Regards,
Steve Thompson

[J O Skip Robinson]

MVCIN was indeed a useful instruction. I encountered it (IIRC) on a 4381. I assumed that, like typical new instructions, it would stick around for the duration. I was later shocked to discover that it had been abandoned on a siding somewhere along the railway to the future. Probably still there somewhere in Nebraska with a smudged bar code.

.
.
.
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....@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Steve Thompson
Sent: Tuesday, December 01, 2015 2:05 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture level?

[Ed Gould]

On Dec 1, 2015, at 3:19 PM, J O Skip Robinson wrote:

> Timeframe was 1980 plus or minus. I was a true novice sysprog and
> kept an arm's length from OS innards. It was during that two-year
> gig that MVS/SP was announced, so not likely available just yet. I
> only remember being impressed with the clever workaround that kept
> the Amdahl useful.
>
> P.S. The same machine had a load button on the system keyboard. One
> day an operator's purse fell over and caused a midmorning IPL.
> Amdahl installed a little box around the button. They were clever
> folks. ;-)
>
> .
> .

> .SKIP:

We had a MP168 and one of the ops hung her purse on the EPO switch.
Needless to say a box was quickly installed after her purse caused a
EPO,.

Ed

[Tony Harminc]

On 1 December 2015 at 17:57, J O Skip Robinson <Jo.Skip....@sce.com>
wrote:

> MVCIN was indeed a useful instruction. I encountered it (IIRC) on a 4381.
> I assumed that, like typical new instructions, it would stick around for
> the duration. I was later shocked to discover that it had been abandoned on
> a siding somewhere along the railway to the future. Probably still there
> somewhere in Nebraska with a smudged bar code.

It was a special feature (RPQ?) on some early 168-era machines for Middle
East customers. Then it appeared as a standard on the 4300 ("E series")
series, but not on the higher end ("H series") machines. And finally,
somewhere in the 1990s iirc, it became an S/390 standard. It's been there
ever since, and continues in zArch.

It is indeed useful for things other than RTL (right to left) language
processing. I've used it to do "smart" line splitting at word boundaries by
setting things up for a TRT. Now that TRTR is generally available there's
less reason to use MVCIN for this kind of thing.

Tony H.

[Robert Wessel]

MVCIN is now a part of the 64-bit base. I don't remember if it was
optional in the XA/ESA days.


On 1 Dec 2015 14:57:52 -0800, Jo.Skip....@SCE.COM (J O Skip

[Shmuel Metz , Seymour J.]

In
<SN1PR0101MB1520A1ECD...@SN1PR0101MB1520.prod.exchangelabs.com>,
on 12/01/2015

at 10:57 PM, J O Skip Robinson <Jo.Skip....@SCE.COM> said:

>MVCIN was indeed a useful instruction. I encountered it (IIRC) on a
>4381. I assumed that, like typical new instructions, it would stick
>around for the duration. I was later shocked to discover that it had
>been abandoned on a siding somewhere along the railway to the future.
>Probably still there somewhere in Nebraska with a smudged bar code.

It's present in ECPS:VSE PoOps, XA PoOps, ESA/370 PoOps, ESA/390 PoOps
and z PoOps; that looks like sticking around to me. I don't know what
the story is on the 3090.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

[J O Skip Robinson]

I'm grateful to this thread for the news that MVCIN lives on. When it disappeared on the 3090--talk about unexpected S0C1--I did a brief RIP and never looked for it again. MVCIN allowed you to reverse a string and use TRT to find stuff that would otherwise have required a backwards loop search. Very handy.

.
.
.
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....@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.)
Sent: Tuesday, December 01, 2015 6:25 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture level?

In
<SN1PR0101MB1520A1ECD...@SN1PR0101MB1520.prod.exchangelabs.com>,
on 12/01/2015
at 10:57 PM, J O Skip Robinson <Jo.Skip....@SCE.COM> said:

>MVCIN was indeed a useful instruction. I encountered it (IIRC) on a
>4381. I assumed that, like typical new instructions, it would stick
>around for the duration. I was later shocked to discover that it had
>been abandoned on a siding somewhere along the railway to the future.
>Probably still there somewhere in Nebraska with a smudged bar code.

It's present in ECPS:VSE PoOps, XA PoOps, ESA/370 PoOps, ESA/390 PoOps and z PoOps; that looks like sticking around to me. I don't know what the story is on the 3090.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

[John McKown]

On Wed, Dec 2, 2015 at 11:44 AM, J O Skip Robinson <Jo.Skip....@sce.com
> wrote:

> I'm grateful to this thread for the news that MVCIN lives on. When it
> disappeared on the 3090--talk about unexpected S0C1--I did a brief RIP and
> never looked for it again. MVCIN allowed you to reverse a string and use
> TRT to find stuff that would otherwise have required a backwards loop
> search. Very handy.
>

​You might want to look at the TRTR and TRTRE instructions in the -10 POPS.
<quote instruction="TRTRE">
The argument characters of the first operand are
used to select function codes from a function-code
table designated by general register 1. For TRANS-
LATE AND TEST EXTENDED, the argument charac-
ters are processed in a left-to-right direction; for
TRANSLATE AND TEST REVERSE EXTENDED,
the argument characters are processed in a right-to-
left direction. When a nonzero function code is
selected, it is inserted in general register R2, the
related argument address is placed in general regis-
ter R1 , and the first-operand length in general register
R1 + 1 is decremented by the number of bytes pro-
cessed. The operation proceeds until a nonzero func-
tion code is encountered, the end of the first operand
is reached, or a CPU-determined number of charac-
ters have been processed, whichever occurs first.
The result is indicated in the condition code.

</quote>​

>
> .
> .
> .
> J.O.Skip Robinson
>

--

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

[Dana Mitchell]

On Wed, 2 Dec 2015 17:44:38 +0000, J O Skip Robinson <Jo.Skip....@SCE.COM> wrote:

>I'm grateful to this thread for the news that MVCIN lives on. When it disappeared on the 3090--talk about unexpected S0C1--I did a brief RIP and never looked for it again. MVCIN allowed you to reverse a string and use TRT to find stuff that would otherwise have required a backwards loop search. Very handy.
>

I noticed the disappearance of MVCIN going from 4341 to 3083. I used it in a CICS program for precisely that reason, removing trailing blanks from print lines, back when line speeds were so slow that this made quite a big difference.

Dana

[Robert Wessel]

On 2 Dec 2015 09:35:40 -0800, shmuel+...@PATRIOT.NET (Shmuel Metz

, Seymour J.) wrote:

>In
><SN1PR0101MB1520A1ECD...@SN1PR0101MB1520.prod.exchangelabs.com>,
>on 12/01/2015
> at 10:57 PM, J O Skip Robinson <Jo.Skip....@SCE.COM> said:
>
>>MVCIN was indeed a useful instruction. I encountered it (IIRC) on a
>>4381. I assumed that, like typical new instructions, it would stick
>>around for the duration. I was later shocked to discover that it had
>>been abandoned on a siding somewhere along the railway to the future.
>>Probably still there somewhere in Nebraska with a smudged bar code.
>
>It's present in ECPS:VSE PoOps, XA PoOps, ESA/370 PoOps, ESA/390 PoOps
>and z PoOps; that looks like sticking around to me. I don't know what
>the story is on the 3090.
>

In at least some of those, it's listed as being part of the "Move
Inverse Feature", so while architecturally defined, not necessarily
implemented on every machine. That's no longer the case for the 64
bit machines.