Re: Straightforward way to determine hardware architecture level?

[Jim Mulder]

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

OA47689has closed, and the documentation is available at

http://publibz.boulder.ibm.com/zoslib/pdf/OA47689.pdf

 
  Note that if you do not specify MAXARCH in IEFOPZxx,
then MAXARCH defaults to the architecture level of the machine, so
the MAXARCH displayed by DISPLAY IEFOPZ,STATUS 
will be the architecture level of the machine. 

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



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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Joel C. Ewing]

On 12/03/2015 12:16 PM, Paul Gilmartin wrote:
> On Thu, 3 Dec 2015 10:43:38 -0600, Joel C. Ewing wrote:
>> ...  Because DOS/VS had native support for source and object
>> libraries, those were kept online, but there was no decent native
>> support to effectively submit production job JCL from libraries ...
>>
> Astonishing.  You could RYO editor but not RYO "SUBMIT".
OLE' was envisioned and implemented by one person, James Stevens, the
head of Tech Services at a time when it was a one or two man operation
(I raised the body count to 3) -- he probably created OLE' as late night
entertainment for his own convenience and benefit to make development of
his Mini-Task on-line environment and other utilities less tedious.  It
went company-wide since it significantly improved the efficiency of 40+
programmers versus fiddling with individual cards in a deck.  JCL didn't
get changed as much and Operator's time was considered less valuable;
and since they only picked up the entire job deck and moved it around 
as a unit it wasn't that obvious that a significant amount of time would
be saved by avoiding the use of decks for production JCL. 

OLE' did have the ability to submit jobs to DOS, but the interactive
OLE' work areas assigned to individual users were each a pre-defined
number of "pages" of 24 80-byte records and the total size of all areas
was constrained by the capacity of a 3330. With those space constraints,
the normal practice was to keep in one's OLE' area(s) only data actively
being edited along with some shorter job streams used for testing and
development.  It would have been possible to submit a short batch job
from OLE' to extract a production job stream from a source library and
load it into part of the an OLE' area (as was done for source code
editing), wait for that job to run, and then submit the production job
from OLE'; but by the time an Operator had done that they could have
already loaded a physical deck.  There just didn't seem to be enough
cost-benefit to justify converting JCL from cards to DASD until MVS
changed the equation.
>
>> ... and the
>> company was averse to spending on "unneeded" additional software, so
>> production JCL was created in OLE' but punched and kept on cards for use
>> by Operations.
>>
> The supplies must have been cheap.
My impression was that the volume of new cards was low enough to be a
trivial cost compared to the cost of printer paper, and I never saw a
card filing cabinet wear out.  Maintenance on the card reader/punch
became more of a nuisance and issue after the units aged at least a
decade, but the cost of that was a minor part of the hardware
maintenance contract.
>
>> When we started DOS/VSE to MVS/XA migration in 1985, we were already
>> running the maximum of four, shared-SPOOL DOS/VSE systems under VM ...
>>
> Was that limit imposed by VM or by the DOS/VSE shared spool?  I'd
> suspect the latter.
>
> -- gil
>
Definitely was not a VM limitation.  DOS/VSE had a shared "lock" file to
coordinate library and other inter-system sharing and that file could be
shared by a maximum of four systems (and with four systems one did at
times see performance problems with that drive).  I can't remember at
this point whether the SPOOLER ("POWER"), was limited to four systems
for shared spool because it depended on the "lock" file or whether it
had its own internal design limits as well.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Shmuel Metz (Seymour J.)]

In <028001d12dea$d995b7c0$8cc12740$@mxg.com>, on 12/03/2015
   at 10:51 AM, Barry Merrill  said:

>I can't recall if they were automatically send

You had to order what you wanted.


 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Paul Gilmartin]

On Thu, 3 Dec 2015 10:43:38 -0600, Joel C. Ewing wrote:
>
>...  Because DOS/VS had native support for source and object
>libraries, those were kept online, but there was no decent native
>support to effectively submit production job JCL from libraries ...
>
Astonishing.  You could RYO editor but not RYO "SUBMIT".

>... and the
>company was averse to spending on "unneeded" additional software, so
>production JCL was created in OLE' but punched and kept on cards for use
>by Operations.
> 
The supplies must have been cheap.

>When we started DOS/VSE to MVS/XA migration in 1985, we were already
>running the maximum of four, shared-SPOOL DOS/VSE systems under VM ...
> 
Was that limit imposed by VM or by the DOS/VSE shared spool?  I'd
suspect the latter.

-- gil

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Barry Merrill]

At Purdue University, in 1965, the Share Programming Library (might not be
quite
right name) card decks filled cabinets that were 6 feet tall and about 40
feet
of wall space.  These were the contributed programs and subroutines
available to
all SHARE members.  I can't recall if they were automatically send or had to
be
requested, but I think all possible card decks were in those cabinets.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joel C. Ewing
Sent: Thursday, December 03, 2015 10:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What's a "ton" of JCL? [was:RE: Straightforward way to
determine hardware architecture level?]

On 12/02/2015 11:09 PM, Ed Gould wrote:
> On Dec 2, 2015, at 2:58 PM, Joel C. Ewing wrote:
>
>> I just weighed the one almost-full box of some old programs and data 
>> cards that I have retained for show-and-tell over the years, and it 
>> is a little over 8 lbs.  Since the cards have holes punched, have 
>> some lighter cardboard spacers, and new cards pack more tightly, I 
>> would estimate 10 lbs as a better approximation for a box of 2000 
>> unused cards.
>>
>> Before we started conversion from DOS/VSE to MVS in 1985, all our 
>> production JCL was on cards in several card filing cabinets.  My 
>> recollection is that a cabinet drawer could hold around two boxes of 
>> cards, so the maximum capacity of one cabinet might have been on the 
>> order of 40 boxes of cards.  We could easily have had somewhere in 
>> the neighborhood of 0.5 - 1.0 tons of cards containing JCL.  A larger 
>> shop might literally have had several tons of JCL.
>> Joel C. Ewing
>
>
> Joel:
> Interesting. I have never worked in a shop (last say 45 years) where 
> there was that much punched cards. There were some cases where the 
> programmer submitted boxes of cards for one time update to a source 
> lib and maybe 5 or so JCL cards. Production was similar one or two job 
> cards a joblib and exec and then probably either a /* or // card.
>
> None of the shops I have ever worked in used that much JCL PERIOD.
>
> This does not include a very few jobs that had "data" cards mind you.
> Those types of jobs were rare and were handled as a card to tape on 
> the dos side and used a tape on the MFT/MVT side.
>
> Ed
>
>
When I came on-board in 1978,  all program development and maintenance and
test job submission, except for one or two Luddite-programmer holdouts who
still edited source decks,  was done from IBM 3277's using a home-grown
On-Line Editor (OLE') system running under a home-grown multi-tasking
("Mini-Task") interactive environment, which supported multiple interactive
on-line applications in a single DOS/VS job partition.  Because DOS/VS had
native support for source and object libraries, those were kept online, but
there was no decent native support to effectively submit production job JCL
from libraries and the company was averse to spending on "unneeded"
additional software, so production JCL was created in OLE' but punched and
kept on cards for use by Operations. 

At one time the company had been a service bureau.  That was no longer the
case when I arrived -- by then it was just the DP subsidiary of Arkansas
Best Corp -- but they continued to support and do processing for former
service-bureau customers who chose to stay.  That meant, for example, that
there might be many different payroll, accounts payable, accounts
receivable, etc.  JCL job decks executing essentially the same programs but
with different parameters and files.  So our ratio of JCL images to program
source images might have been higher than typical.

When we started DOS/VSE to MVS/XA migration in 1985, we were already running
the maximum of four, shared-SPOOL DOS/VSE systems under VM and all on-line
applications had by then been converted to run under CICS. 
We converted to VM/XA  (I think still called "VM Migration Aid" at the
time) to also support MVS/XA.  As primary technical support for MVS, the
very  first "production" application I created under MVS was to set up a
TSO/ISPF application to allow operators to submit DOS production JCL from an
efficiently-blocked MVS PDS library under MVS using an MVS VM virtual card
punch feeding a DOS VM virtual ca

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Joel C. Ewing]

On 12/02/2015 11:09 PM, Ed Gould wrote:
> On Dec 2, 2015, at 2:58 PM, Joel C. Ewing wrote:
>
>> I just weighed the one almost-full box of some old programs and data
>> cards that I have retained for show-and-tell over the years, and it is a
>> little over 8 lbs.  Since the cards have holes punched, have some
>> lighter cardboard spacers, and new cards pack more tightly, I would
>> estimate 10 lbs as a better approximation for a box of 2000 unused
>> cards.
>>
>> Before we started conversion from DOS/VSE to MVS in 1985, all our
>> production JCL was on cards in several card filing cabinets.  My
>> recollection is that a cabinet drawer could hold around two boxes of
>> cards, so the maximum capacity of one cabinet might have been on the
>> order of 40 boxes of cards.  We could easily have had somewhere in the
>> neighborhood of 0.5 - 1.0 tons of cards containing JCL.  A larger shop
>> might literally have had several tons of JCL.
>> Joel C. Ewing
>
>
> Joel:
> Interesting. I have never worked in a shop (last say 45 years) where
> there was that much punched cards. There were some cases where the
> programmer submitted boxes of cards for one time update to a source
> lib and maybe 5 or so JCL cards. Production was similar one or two job
> cards a joblib and exec and then probably either a /* or // card.
>
> None of the shops I have ever worked in used that much JCL PERIOD.
>
> This does not include a very few jobs that had "data" cards mind you.
> Those types of jobs were rare and were handled as a card to tape on
> the dos side and used a tape on the MFT/MVT side.
>
> Ed
>
>
When I came on-board in 1978,  all program development and maintenance
and test job submission, except for one or two Luddite-programmer
holdouts who still edited source decks,  was done from IBM 3277's using
a home-grown On-Line Editor (OLE') system running under a home-grown
multi-tasking ("Mini-Task") interactive environment, which supported
multiple interactive on-line applications in a single DOS/VS job
partition.  Because DOS/VS had native support for source and object
libraries, those were kept online, but there was no decent native
support to effectively submit production job JCL from libraries and the
company was averse to spending on "unneeded" additional software, so
production JCL was created in OLE' but punched and kept on cards for use
by Operations. 

At one time the company had been a service bureau.  That was no longer
the case when I arrived -- by then it was just the DP subsidiary of
Arkansas Best Corp -- but they continued to support and do processing
for former service-bureau customers who chose to stay.  That meant, for
example, that there might be many different payroll, accounts payable,
accounts receivable, etc.  JCL job decks executing essentially the same
programs but with different parameters and files.  So our ratio of JCL
images to program source images might have been higher than typical.

When we started DOS/VSE to MVS/XA migration in 1985, we were already
running the maximum of four, shared-SPOOL DOS/VSE systems under VM and
all on-line applications had by then been converted to run under CICS. 
We converted to VM/XA  (I think still called "VM Migration Aid" at the
time) to also support MVS/XA.  As primary technical support for MVS, the
very  first "production" application I created under MVS was to set up a
TSO/ISPF application to allow operators to submit DOS production JCL
from an efficiently-blocked MVS PDS library under MVS using an MVS VM
virtual card punch feeding a DOS VM virtual card reader.  Not only did
that finally eliminate all the cabinets with JCL card decks, but it made
all production JCL easily accessible for analysis and conversion during
the subsequent migration process.

Without further empirical data points to establish the typical effect on
weight of the average holes per card I guess a more precise conversion
factor isn't possible, but it appears the likely bounds at this point are
1 ton JCL cards ~= 400,000 to 666,666  80-byte JCL images.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Ed Gould]

On Dec 2, 2015, at 2:58 PM, Joel C. Ewing wrote:


I just weighed the one almost-full box of some old programs and data
cards that I have retained for show-and-tell over the years, and it  
is a

little over 8 lbs.  Since the cards have holes punched, have some
lighter cardboard spacers, and new cards pack more tightly, I would
estimate 10 lbs as a better approximation for a box of 2000 unused  
cards.


Before we started conversion from DOS/VSE to MVS in 1985, all our
production JCL was on cards in several card filing cabinets.  My
recollection is that a cabinet drawer could hold around two boxes of
cards, so the maximum capacity of one cabinet might have been on the
order of 40 boxes of cards.  We could easily have had somewhere in the
neighborhood of 0.5 - 1.0 tons of cards containing JCL.  A larger shop
might literally have had several tons of JCL.
Joel C. Ewing



Joel:
Interesting. I have never worked in a shop (last say 45 years) where  
there was that much punched cards. There were some cases where the  
programmer submitted boxes of cards for one time update to a source  
lib and maybe 5 or so JCL cards. Production was similar one or two  
job cards a joblib and exec and then probably either a /* or // card.


None of the shops I have ever worked in used that much JCL PERIOD.

This does not include a very few jobs that had "data" cards mind you.  
Those types of jobs were rare and were handled as a card to tape on  
the dos side and used a tape on the MFT/MVT side.


Ed

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Shmuel Metz (Seymour J.)]

In
,
on 12/02/2015
   at 05:33 PM, J O Skip Robinson  said:

>One urban legend (not necessarily fiction) is an explanation for the
>curious layout in EBCDIC coding.

UL? It's well documented. See, e.g., IBM System/360 Principles of
Operation, A22-6821-7[1], Appendix F, USASCII-8 and EBCDIC Charts, p.
150.2

>Of course there is one more hex value in the neighborhood than 
>there are letters in English, but why jump from D9 to E2 instead 
>of using E1 - E8? The story I heard in computer school is that the
>EBCDIC ultimately derived from the punch card layout.

As is implicit in the name, EBCDIC derives from BCD, which in turn
derive from the card encodings.

[1]
http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Ward, Mike S]

Yea, you still have to feed the punch. :)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Tuesday, December 01, 2015 5:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine 
hardware architecture level?]

On Tue, Dec 1, 2015 at 2:41 PM, Barry Merrill  wrote:

> I think a box of 2000 IBM cards is on the order of 6 pounds, so a TON 
> of JCL cards would be 333 boxes, or about 666,666 card images.
>
> But, the useful weight is zero, since we only use the holes.
>
> Barry
>
> 
Since this is a thread well suited to reminiscence, I will relay this story.

My father managed a very large IBM data center in the 70's.   Huge floor
space, and a very large room to store blank punched cards.
One of the systems programmers who worked there was a cranky joke-ster.
He would read every month in the company newsletter about monetary employee 
suggestion awards handed out for suggestions that he thought were silly and 
banal.

Like:
- there is an extra phone on some desk that is not needed
- unnecessary copies of some large daily report were being printed
- 

The companies policy was that employee suggestions would be reviewed, first by 
corporate, and then by the line manager in charge of implementation.
The employee would get a cash award based on some percentage of the first 
year's savings.

My father gets a call one day from a very excited guy in corporate.
He says that this systems programmer has submitted a suggestion that will save 
many tens of thousands of dollars a year in the data center.
The suggestion was something like:

=
We store millions of blank punched cards so that they are available when needed 
for the data center.

I have designed and written two assembler programs (see listings attached) that 
allow us to eliminate this storage requirement.

- The first program allows us to read and store a "master image" of a single 
blank punched card, electronically, on spinning magnetic disk.

- The second program can be run, whenever needed, to punch out blank cards from 
the image stored on disk.  A parameter card specifies the count of how many 
blank cards to punch.

...
=

My father had to gently explain to the corporate guy how he had been suckered.

Cheers,

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Shmuel Metz (Seymour J.)]

In
,
on 12/01/2015
   at 10:51 PM, Mike Schwab  said:

>Or a small flash drive of 64M to 2G.

Are they still making those?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Joel C. Ewing]

I just weighed the one almost-full box of some old programs and data
cards that I have retained for show-and-tell over the years, and it is a
little over 8 lbs.  Since the cards have holes punched, have some
lighter cardboard spacers, and new cards pack more tightly, I would
estimate 10 lbs as a better approximation for a box of 2000 unused cards.

Before we started conversion from DOS/VSE to MVS in 1985, all our
production JCL was on cards in several card filing cabinets.  My
recollection is that a cabinet drawer could hold around two boxes of
cards, so the maximum capacity of one cabinet might have been on the
order of 40 boxes of cards.  We could easily have had somewhere in the
neighborhood of 0.5 - 1.0 tons of cards containing JCL.  A larger shop
might literally have had several tons of JCL.
Joel C. Ewing

On 12/01/2015 02:41 PM, Barry Merrill wrote:
> I think a box of 2000 IBM cards is on the order of 6 pounds,
> so a TON of JCL cards would be 333 boxes, or about 666,666
> card images.
>
> But, the useful weight is zero, since we only use the holes.
>
> Barry
>
>
> Herbert W. "Barry" Merrill, PhD
> President-Programmer
> MXG Software
> Merrill Consultants
> 10717 Cromwell Drive
> Dallas, TX 75229-5112
> ba...@mxg.com
> Fax:  214 350 3694 - Still works, received as email
> Tel:  214 351 1966 - Unreliable, please use email
>
> www.mxg.comHomePage: FAQ answers most questions
> ad...@mxg.com  License Forms, Invoice, Payment, ftp information
> supp...@mxg.comTechnical Issues 
> MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Tuesday, December 01, 2015 1:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: What's a "ton" of JCL? [was:RE: Straightforward way to determine
> hardware architecture level?]
>
> Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or so
> years ago) had over 250,000 members in the production applications JCL
> libraries.
>
> Not sure how much of that was obsolete at the time, but the batch operations
> control product they used had vast quantities of data as well.
>
> I think that counts as a "ton" or 2 . . . :)
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Tuesday, December 01, 2015 9:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Straightforward way to determine hardware architecture level?
>
> 
>
> . . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how
> much JCL is a "ton" anyway?).
>
> --


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Doug]

Everyone pull that Write Punch and Silver patches and a box of cards..Grins

.

On Dec 2, 2015, at 12:33, J O Skip Robinson  wrote:

One urban legend (not necessarily fiction) is an explanation for the curious 
layout in EBCDIC coding. We have

A - I as C1 - C9
J - R as D1 - D9
S - Z as E2 - E9

Of course there is one more hex value in the neighborhood than there are 
letters in English, but why jump from D9 to E2 instead of using E1 - E8? The 
story I heard in computer school is that the EBCDIC ultimately derived from the 
punch card layout. To represent a letter, a card required both a 'zone' punch 
in one of the first three rows at the top plus a 'digit' punch further down in 
the same column. The first group of letters used the top zone row and so on 
through the alphabet. The last group of letters worked off the third zone row. 
The story goes that early punch equipment and card stock were imprecise and 
flimsy. In order to avoid having to deal with two vertically adjacent 
punches--third zone row plus first digit row--the code was constructed to skip 
the 1 digit for the letter S. Since a gap was needed anyhow, this was the ideal 
place for it. 

I love this story too much to challenge it.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, December 02, 2015 8:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What's a "ton" of JCL? [was:RE: Straightforward way to 
determine hardware architecture level?]

> On Wed, 2 Dec 2015 10:02:01 -0600, Dana Mitchell wrote:
> 
>> On Tue, 1 Dec 2015 23:03:59 +, J O Skip Robinson wrote:
>> 
>> (This whole season feels like Friday.) A doughnut, on the other hand, 
>> requires the hole for its very definition. The hole supplies no mass or 
>> nutritional value, but without it the thing is not a doughnut. By contrast a 
>> punch card requires the solid part to give the holes meaning; they would 
>> otherwise collapse into gibberish. 
> 
> In school we verified that if you multi-punch every possible punch out 
> of a card, the result is indeed very fragile.  But it was fun to dupe
> 
This could inspire a Retro engineering project:  Given the constraint of 
required mechanical strength, devise an encoding that maximizes information 
density.  Akin to GCR:

   https://en.wikipedia.org/wiki/Group_code_recording

(How much does the hole diminish the mechanical strength of the bagel?)

-- gil


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

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

Re: Straightforward way to determine hardware architecture level?

[Dana Mitchell]

On Wed, 2 Dec 2015 17:44:38 +, J O Skip Robinson  
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

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

Re: Straightforward way to determine hardware architecture level?

[John McKown]

On Wed, Dec 2, 2015 at 11:44 AM, J O Skip Robinson  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.

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.

​



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

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

Re: Straightforward way to determine hardware architecture level?

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

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

In
,
on 12/01/2015
   at 10:57 PM, J O Skip Robinson  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

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

Re: Straightforward way to determine hardware architecture level?

[Shmuel Metz (Seymour J.)]

In
,
on 12/01/2015
   at 10:57 PM, J O Skip Robinson  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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[J O Skip Robinson]

One urban legend (not necessarily fiction) is an explanation for the curious 
layout in EBCDIC coding. We have

A - I as C1 - C9
J - R as D1 - D9
S - Z as E2 - E9

Of course there is one more hex value in the neighborhood than there are 
letters in English, but why jump from D9 to E2 instead of using E1 - E8? The 
story I heard in computer school is that the EBCDIC ultimately derived from the 
punch card layout. To represent a letter, a card required both a 'zone' punch 
in one of the first three rows at the top plus a 'digit' punch further down in 
the same column. The first group of letters used the top zone row and so on 
through the alphabet. The last group of letters worked off the third zone row. 
The story goes that early punch equipment and card stock were imprecise and 
flimsy. In order to avoid having to deal with two vertically adjacent 
punches--third zone row plus first digit row--the code was constructed to skip 
the 1 digit for the letter S. Since a gap was needed anyhow, this was the ideal 
place for it. 

I love this story too much to challenge it.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, December 02, 2015 8:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What's a "ton" of JCL? [was:RE: Straightforward way to 
determine hardware architecture level?]

On Wed, 2 Dec 2015 10:02:01 -0600, Dana Mitchell wrote:

>On Tue, 1 Dec 2015 23:03:59 +, J O Skip Robinson wrote:
>
>>(This whole season feels like Friday.) A doughnut, on the other hand, 
>>requires the hole for its very definition. The hole supplies no mass or 
>>nutritional value, but without it the thing is not a doughnut. By contrast a 
>>punch card requires the solid part to give the holes meaning; they would 
>>otherwise collapse into gibberish. 
>
>In school we verified that if you multi-punch every possible punch out 
>of a card, the result is indeed very fragile.  But it was fun to dupe
> 
This could inspire a Retro engineering project:  Given the constraint of 
required mechanical strength, devise an encoding that maximizes information 
density.  Akin to GCR:

https://en.wikipedia.org/wiki/Group_code_recording

(How much does the hole diminish the mechanical strength of the bagel?)

-- gil


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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Paul Gilmartin]

On Wed, 2 Dec 2015 10:02:01 -0600, Dana Mitchell wrote:

>On Tue, 1 Dec 2015 23:03:59 +, J O Skip Robinson wrote:
>
>>(This whole season feels like Friday.) A doughnut, on the other hand, 
>>requires the hole for its very definition. The hole supplies no mass or 
>>nutritional value, but without it the thing is not a doughnut. By contrast a 
>>punch card requires the solid part to give the holes meaning; they would 
>>otherwise collapse into gibberish. 
>
>In school we verified that if you multi-punch every possible punch out of a 
>card, the result is indeed very fragile.  But it was fun to dupe
> 
This could inspire a Retro engineering project:  Given the constraint of 
required mechanical
strength, devise an encoding that maximizes information density.  Akin to GCR:

https://en.wikipedia.org/wiki/Group_code_recording

(How much does the hole diminish the mechanical strength of the bagel?)

-- gil

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Dana Mitchell]

On Tue, 1 Dec 2015 23:03:59 +, J O Skip Robinson  
wrote:

>(This whole season feels like Friday.) A doughnut, on the other hand, requires 
>the hole for its very definition. The hole supplies no mass or nutritional 
>value, but without it the thing is not a doughnut. By contrast a punch card 
>requires the solid part to give the holes meaning; they would otherwise 
>collapse into gibberish. 
>

In school we verified that if you multi-punch every possible punch out of a 
card, the result is indeed very fragile.  But it was fun to dupe

Dana

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Ed Gould]

On Dec 1, 2015, at 10:54 PM, Mike Schwab wrote:


Correction.  16 IBM 350 disk drives, each weighing a ton.  Is that
what Tennessee Ernie Ford was singing about?


Yea but what about the power requirements and the architectural  
building requirements?


Ed

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Mike Schwab]

Correction.  16 IBM 350 disk drives, each weighing a ton.  Is that
what Tennessee Ernie Ford was singing about?

On Tue, Dec 1, 2015 at 10:51 PM, Mike Schwab  wrote:
> 666K cards at 80 bytes per is 53,333,280.
> A IBM 350 for a RAMAC 305 weighs over a ton and hold 5 million 6 bit
> characters 3.5MB.
> So you would need 15 of those.
> Or a PC hard disk drive from 1994 of 60MB.
> Or about 30 3.5 floppy disks.
> Or a small flash drive of 64M to 2G.
> Or a micro SD card of 2G.
>
>
>
> On Tue, Dec 1, 2015 at 2:41 PM, Barry Merrill  wrote:
>> I think a box of 2000 IBM cards is on the order of 6 pounds,
>> so a TON of JCL cards would be 333 boxes, or about 666,666
>> card images.
>>
>> But, the useful weight is zero, since we only use the holes.
>>
>> Barry
>>
>>
>> Herbert W. "Barry" Merrill, PhD
>> President-Programmer
>> MXG Software
>> Merrill Consultants
>> 10717 Cromwell Drive
>> Dallas, TX 75229-5112
>> ba...@mxg.com
>> Fax:  214 350 3694 - Still works, received as email
>> Tel:  214 351 1966 - Unreliable, please use email
>>
>> www.mxg.comHomePage: FAQ answers most questions
>> ad...@mxg.com  License Forms, Invoice, Payment, ftp information
>> supp...@mxg.comTechnical Issues
>> MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/
>>
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Farley, Peter x23353
>> Sent: Tuesday, December 01, 2015 1:59 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: What's a "ton" of JCL? [was:RE: Straightforward way to determine
>> hardware architecture level?]
>>
>> Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or so
>> years ago) had over 250,000 members in the production applications JCL
>> libraries.
>>
>> Not sure how much of that was obsolete at the time, but the batch operations
>> control product they used had vast quantities of data as well.
>>
>> I think that counts as a "ton" or 2 . . . :)
>>
>> Peter
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Peter Relson
>> Sent: Tuesday, December 01, 2015 9:30 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Straightforward way to determine hardware architecture level?
>>
>> 
>>
>> . . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how
>> much JCL is a "ton" anyway?).
>>
>> --
>>
>> This message and any attachments are intended only for the use of the
>> addressee and may contain information that is privileged and confidential.
>> If the reader of the message is not the intended recipient or an authorized
>> representative of the intended recipient, you are hereby notified that any
>> dissemination of this communication is strictly prohibited. If you have
>> received this communication in error, please notify us immediately by e-mail
>> and delete the message and any attachments from your system.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email
>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?



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

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Mike Schwab]

666K cards at 80 bytes per is 53,333,280.
A IBM 350 for a RAMAC 305 weighs over a ton and hold 5 million 6 bit
characters 3.5MB.
So you would need 15 of those.
Or a PC hard disk drive from 1994 of 60MB.
Or about 30 3.5 floppy disks.
Or a small flash drive of 64M to 2G.
Or a micro SD card of 2G.



On Tue, Dec 1, 2015 at 2:41 PM, Barry Merrill  wrote:
> I think a box of 2000 IBM cards is on the order of 6 pounds,
> so a TON of JCL cards would be 333 boxes, or about 666,666
> card images.
>
> But, the useful weight is zero, since we only use the holes.
>
> Barry
>
>
> Herbert W. "Barry" Merrill, PhD
> President-Programmer
> MXG Software
> Merrill Consultants
> 10717 Cromwell Drive
> Dallas, TX 75229-5112
> ba...@mxg.com
> Fax:  214 350 3694 - Still works, received as email
> Tel:  214 351 1966 - Unreliable, please use email
>
> www.mxg.comHomePage: FAQ answers most questions
> ad...@mxg.com  License Forms, Invoice, Payment, ftp information
> supp...@mxg.comTechnical Issues
> MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Tuesday, December 01, 2015 1:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: What's a "ton" of JCL? [was:RE: Straightforward way to determine
> hardware architecture level?]
>
> Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or so
> years ago) had over 250,000 members in the production applications JCL
> libraries.
>
> Not sure how much of that was obsolete at the time, but the batch operations
> control product they used had vast quantities of data as well.
>
> I think that counts as a "ton" or 2 . . . :)
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Tuesday, December 01, 2015 9:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Straightforward way to determine hardware architecture level?
>
> 
>
> . . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how
> much JCL is a "ton" anyway?).
>
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by e-mail
> and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Straightforward way to determine hardware architecture level?

[Tony Harminc]

On 1 December 2015 at 17:57, J O Skip Robinson 
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.

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

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

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Ed Gould]

Paul:

A Bank I used to work for had "tons" of credit card (remember the  
days when they issued a receipt  w/carbon paper and a "card" in the  
back ?
They read them in (scanned?) I never saw that part of the operation  
other than they wheeled carts of cards through the computer room. I  
*vaguely* remember a MES for a card reader to read them. I *think*  
these were scanned though. .


Ed

On Dec 1, 2015, at 3:14 PM, Paul Gilmartin wrote:


On Tue, 1 Dec 2015 14:41:58 -0600, Barry Merrill wrote:


I think a box of 2000 IBM cards is on the order of 6 pounds,
so a TON of JCL cards would be 333 boxes, or about 666,666
card images.

But, the useful weight is zero, since we only use the holes.

But as XKCD once said, "Four boxes of punch cards ought to be  
enough for anyone."


https://what-if.xkcd.com/63/

My memory of carrying around file trays (3, IIRC, when I was  
younger) is "more".


A little Googling says 2.42 g/card.  WAG, I think.

But you could keep it on micro SD cards.

-- gil

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


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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Kirk Wolf]

On Tue, Dec 1, 2015 at 2:41 PM, Barry Merrill  wrote:

> I think a box of 2000 IBM cards is on the order of 6 pounds,
> so a TON of JCL cards would be 333 boxes, or about 666,666
> card images.
>
> But, the useful weight is zero, since we only use the holes.
>
> Barry
>
> 
Since this is a thread well suited to reminiscence, I will relay this story.

My father managed a very large IBM data center in the 70's.   Huge floor
space, and a very large room to store blank punched cards.
One of the systems programmers who worked there was a cranky joke-ster.
He would read every month in the company newsletter about monetary employee
suggestion awards handed out for suggestions that he thought were silly and
banal.

Like:
- there is an extra phone on some desk that is not needed
- unnecessary copies of some large daily report were being printed
- 

The companies policy was that employee suggestions would be reviewed, first
by corporate, and then by the line manager in charge of implementation.
The employee would get a cash award based on some percentage of the first
year's savings.

My father gets a call one day from a very excited guy in corporate.
He says that this systems programmer has submitted a suggestion that will
save many tens of thousands of dollars a year in the data center.
The suggestion was something like:

=
We store millions of blank punched cards so that they are available when
needed for the data center.

I have designed and written two assembler programs (see listings attached)
that allow us to eliminate this storage requirement.

- The first program allows us to read and store a "master image" of a
single blank punched card, electronically, on spinning magnetic disk.

- The second program can be run, whenever needed, to punch out blank cards
from the image stored on disk.  A parameter card specifies the count of how
many blank cards to punch.

...
=

My father had to gently explain to the corporate guy how he had been
suckered.

Cheers,

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[zMan]

But there are "bagels" that have no holes. OTOH, some of us don't really
consider them bagels; one poster on some forum said her husband called them
RBUs -- Round Bread Units.

And if you've ever had real New York or Montreal bagels, you'll know why
folks make that distinction.

OTOH, RBUs make better *sandwiches*, since they're not so tough.

Even some mainframers like them. <== requisite relevance injection

On Tue, Dec 1, 2015 at 6:03 PM, J O Skip Robinson 
wrote:

> (This whole season feels like Friday.) A doughnut, on the other hand,
> requires the hole for its very definition. The hole supplies no mass or
> nutritional value, but without it the thing is not a doughnut. By contrast
> a punch card requires the solid part to give the holes meaning; they would
> otherwise collapse into gibberish.
>
> .
> .
> .
> 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.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Barry Merrill
> Sent: Tuesday, December 01, 2015 12:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: What's a "ton" of JCL? [was:RE: Straightforward
> way to determine hardware architecture level?]
>
> I think a box of 2000 IBM cards is on the order of 6 pounds, so a TON of
> JCL cards would be 333 boxes, or about 666,666 card images.
>
> But, the useful weight is zero, since we only use the holes.
>
> Barry
>
>
> Herbert W. "Barry" Merrill, PhD
> President-Programmer
> MXG Software
> Merrill Consultants
> 10717 Cromwell Drive
> Dallas, TX 75229-5112
> ba...@mxg.com
> Fax:  214 350 3694 - Still works, received as email
> Tel:  214 351 1966 - Unreliable, please use email
>
> www.mxg.comHomePage: FAQ answers most questions
> ad...@mxg.com  License Forms, Invoice, Payment, ftp information
> supp...@mxg.comTechnical Issues
> MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Tuesday, December 01, 2015 1:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: What's a "ton" of JCL? [was:RE: Straightforward way to determine
> hardware architecture level?]
>
> Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or
> so years ago) had over 250,000 members in the production applications JCL
> libraries.
>
> Not sure how much of that was obsolete at the time, but the batch
> operations control product they used had vast quantities of data as well.
>
> I think that counts as a "ton" or 2 . . . :)
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Tuesday, December 01, 2015 9:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Straightforward way to determine hardware architecture level?
>
> 
>
> . . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how
> much JCL is a "ton" anyway?).
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[J O Skip Robinson]

(This whole season feels like Friday.) A doughnut, on the other hand, requires 
the hole for its very definition. The hole supplies no mass or nutritional 
value, but without it the thing is not a doughnut. By contrast a punch card 
requires the solid part to give the holes meaning; they would otherwise 
collapse into gibberish. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barry Merrill
Sent: Tuesday, December 01, 2015 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What's a "ton" of JCL? [was:RE: Straightforward way to 
determine hardware architecture level?]

I think a box of 2000 IBM cards is on the order of 6 pounds, so a TON of JCL 
cards would be 333 boxes, or about 666,666 card images.

But, the useful weight is zero, since we only use the holes.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, December 01, 2015 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What's a "ton" of JCL? [was:RE: Straightforward way to determine 
hardware architecture level?]

Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or so 
years ago) had over 250,000 members in the production applications JCL 
libraries.

Not sure how much of that was obsolete at the time, but the batch operations 
control product they used had vast quantities of data as well.

I think that counts as a "ton" or 2 . . . :)

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Tuesday, December 01, 2015 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?



. . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how much 
JCL is a "ton" anyway?).

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

Re: Straightforward way to determine hardware architecture level?

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

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

On 12/01/2015 10:27 AM, Tom Marchant wrote:
> On Tue, 1 Dec 2015 12:52:05 +, 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


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

Re: Straightforward way to determine hardware architecture level?

[Steve Thompson]

On 12/01/2015 10:27 AM, Tom Marchant wrote:

On Tue, 1 Dec 2015 12:52:05 +, 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

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

Re: Straightforward way to determine hardware architecture level?

[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.robin...@sce.com>
December 1, 2015 at 4:19 PM
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.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
On Behalf Of Tom Marchant

Sent: Tuesday, December 01, 2015 7:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware 
architecture level?



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 lists...@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 'phish...@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


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

Re: Straightforward way to determine hardware architecture level?

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, December 01, 2015 7:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture 
level?

On Tue, 1 Dec 2015 12:52:05 +, 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


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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Paul Gilmartin]

On Tue, 1 Dec 2015 14:41:58 -0600, Barry Merrill wrote:

>I think a box of 2000 IBM cards is on the order of 6 pounds,
>so a TON of JCL cards would be 333 boxes, or about 666,666
>card images.
>
>But, the useful weight is zero, since we only use the holes.
> 
But as XKCD once said, "Four boxes of punch cards ought to be enough for 
anyone."

https://what-if.xkcd.com/63/

My memory of carrying around file trays (3, IIRC, when I was younger) is "more".

A little Googling says 2.42 g/card.  WAG, I think.

But you could keep it on micro SD cards.

-- gil

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Barry Merrill]

I think a box of 2000 IBM cards is on the order of 6 pounds,
so a TON of JCL cards would be 333 boxes, or about 666,666
card images.

But, the useful weight is zero, since we only use the holes.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Tuesday, December 01, 2015 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What's a "ton" of JCL? [was:RE: Straightforward way to determine
hardware architecture level?]

Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or so
years ago) had over 250,000 members in the production applications JCL
libraries.

Not sure how much of that was obsolete at the time, but the batch operations
control product they used had vast quantities of data as well.

I think that counts as a "ton" or 2 . . . :)

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, December 01, 2015 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?



. . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how
much JCL is a "ton" anyway?).

--

This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized
representative of the intended recipient, you are hereby notified that any
dissemination of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail
and delete the message and any attachments from your system.

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

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

What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Farley, Peter x23353]

Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or so 
years ago) had over 250,000 members in the production applications JCL 
libraries.

Not sure how much of that was obsolete at the time, but the batch operations 
control product they used had vast quantities of data as well.

I think that counts as a "ton" or 2 . . . :)

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Tuesday, December 01, 2015 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?



. . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how much 
JCL is a "ton" anyway?).

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Straightforward way to determine hardware architecture level?

[Tom Marchant]

On Tue, 1 Dec 2015 12:52:05 +, 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

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

Re: Straightforward way to determine hardware architecture level?

[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


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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

[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 – unsubscr...@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.

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

Re: Straightforward way to determine hardware architecture level?

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



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

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

Re: Straightforward way to determine hardware architecture level?

[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: sipp...@sg.ibm.com

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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

[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  wrote:

> I am not a LOADXX guru but &SYSALVL looks like waaay 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-MAIN@LISTSERV.UA.EDU] On
> Behalf Of J O Skip Robinson
> Sent: Sunday, November 29, 2015 11:44 AM
> To: IBM-MAIN@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...
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Straightforward way to determine hardware architecture level?

[Shmuel Metz (Seymour J.)]

In
,
on 11/30/2015
   at 11:44 PM, J O Skip Robinson  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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On
Behalf Of David L. Craig
Sent: Monday, November 30, 2015 4:24 PM
To: IBM-MAIN@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?

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

Re: Straightforward way to determine hardware architecture level?

[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?
-- 

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_

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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

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

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

Seriously, thanks for your input.

Charles


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

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ed Gould
Sent: Monday, November 30, 2015 2:34 PM
To: IBM-MAIN@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.

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

Re: Straightforward way to determine hardware architecture level?

[Ed Gould]

Chis:

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

Ed

On Nov 30, 2015, at 2:15 PM, Blaicher, Christopher Y. wrote:


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: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@listserv.ua.edu] On Behalf Of Ed Gould

Sent: Monday, November 30, 2015 2:49 PM
To: IBM-MAIN@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.


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


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

Re: Straightforward way to determine hardware architecture level?

[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
On Nov 30, 2015, at 2:15 PM, Charles Mills wrote:

I would call it event-oriented. Millions of events per day per LPAR  
at some

sites.

Customers pay "extra" so to speak for CPU savings because the  
alternative is
paying more to IBM and other vendors based on MSU peaks, and  
eventually a
hardware upgrade with the implied additional software costs. If you  
are not

aware of that mentality then you are not in the trenches of modern ISV
software sales.

Here's the product we are talking about:
https://correlog.com/solutions-and-services/sas-correlog- 
mainframe.html


Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@listserv.ua.edu] On

Behalf Of Ed Gould
Sent: Monday, November 30, 2015 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture  
level?


Charles:

On Nov 30, 2015, at 7:59 AM, Charles Mills wrote:


Sorry. MSUs are *incredibly* important to some (most?) customers.
They are a
major buy/no-buy decider. I cannot ship z900 code and shrug my
shoulders about performance on a z13. IBM (as an example) has come to
realize that customers are not willing to run S/390 instruction set
COBOL executables on a z13  -- witness the Binary Optimizer. I get
paid to be concerned about this stuff and I take the  
responsibility to

live my life in a way that avoids ulcers. Shipping the source is
utterly out of the question, both for intellectual property reasons
and because at more and more customers even coding a Rexx script is
beyond the local programming abilities:
they could
never compile the code successfully -- and many are so busy
(understaffed?)
they would not be willing to take the time even if they could.

At some sites we process millions of events per day per LPAR. A
millisecond per event is thousands of CPU seconds per day.


let the responsibility lie with the customer


Customers basically pay us to take that responsibility.


I don't know what your company sells and wonder why anyone would  
pay "extra"

for a few seconds of cpu savings gain.
I suspect you (or your management) is making a mountain out of a  
mole hill.
Isn't the main idea for any product to run transparently an any Z  
Compatible

CPU?
Saving a few seconds is not conducive to any real life situation  
unless it

is a transaction oriented system.
So if its not transaction oriented then don't worry be happy.

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


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

Re: Straightforward way to determine hardware architecture level?

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

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



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

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

Re: Straightforward way to determine hardware architecture level?

[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: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Gould
Sent: Monday, November 30, 2015 2:49 PM
To: IBM-MAIN@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.

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

Re: Straightforward way to determine hardware architecture level?

[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 

Charles

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

Charles:

On Nov 30, 2015, at 7:59 AM, Charles Mills wrote:

> Sorry. MSUs are *incredibly* important to some (most?) customers.  
> They are a
> major buy/no-buy decider. I cannot ship z900 code and shrug my 
> shoulders about performance on a z13. IBM (as an example) has come to 
> realize that customers are not willing to run S/390 instruction set 
> COBOL executables on a z13  -- witness the Binary Optimizer. I get 
> paid to be concerned about this stuff and I take the responsibility to 
> live my life in a way that avoids ulcers. Shipping the source is 
> utterly out of the question, both for intellectual property reasons 
> and because at more and more customers even coding a Rexx script is 
> beyond the local programming abilities:
> they could
> never compile the code successfully -- and many are so busy
> (understaffed?)
> they would not be willing to take the time even if they could.
>
> At some sites we process millions of events per day per LPAR. A 
> millisecond per event is thousands of CPU seconds per day.
>
>> let the responsibility lie with the customer
>
> Customers basically pay us to take that responsibility.

I don't know what your company sells and wonder why anyone would pay "extra"
for a few seconds of cpu savings gain.
I suspect you (or your management) is making a mountain out of a mole hill.
Isn't the main idea for any product to run transparently an any Z Compatible
CPU?
Saving a few seconds is not conducive to any real life situation unless it
is a transaction oriented system.
So if its not transaction oriented then don't worry be happy.

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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

[Ed Gould]

Charles:

On Nov 30, 2015, at 7:59 AM, Charles Mills wrote:

Sorry. MSUs are *incredibly* important to some (most?) customers.  
They are a
major buy/no-buy decider. I cannot ship z900 code and shrug my  
shoulders
about performance on a z13. IBM (as an example) has come to realize  
that
customers are not willing to run S/390 instruction set COBOL  
executables on
a z13  -- witness the Binary Optimizer. I get paid to be concerned  
about

this stuff and I take the responsibility to live my life in a way that
avoids ulcers. Shipping the source is utterly out of the question,  
both for
intellectual property reasons and because at more and more  
customers even
coding a Rexx script is beyond the local programming abilities:  
they could
never compile the code successfully -- and many are so busy  
(understaffed?)

they would not be willing to take the time even if they could.

At some sites we process millions of events per day per LPAR. A  
millisecond

per event is thousands of CPU seconds per day.


let the responsibility lie with the customer


Customers basically pay us to take that responsibility.


I don't know what your company sells and wonder why anyone would pay  
"extra" for a few seconds of cpu savings gain.
I suspect you (or your management) is making a mountain out of a mole  
hill.
Isn't the main idea for any product to run transparently an any Z  
Compatible CPU?
Saving a few seconds is not conducive to any real life situation  
unless it is a transaction oriented system.

So if its not transaction oriented then don't worry be happy.

Ed




you will always get an 0C1 if you execute the instruction on a  
machine

that is incapable of executing that instruction

No argument there! 

Seriously, thanks for your input.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@listserv.ua.edu] On

Behalf Of Ed Gould
Sent: Sunday, November 29, 2015 4:22 PM
To: IBM-MAIN@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.

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


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

Re: Straightforward way to determine hardware architecture level?

[Shmuel Metz (Seymour J.)]

In <1a619cdc-a055-40ec-9821-4337587d6...@copper.net>, on 11/29/2015
   at 08:17 PM, Stevet  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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

[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! 

Seriously, thanks for your input.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ed Gould
Sent: Sunday, November 29, 2015 4:22 PM
To: IBM-MAIN@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.

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

Re: Straightforward way to determine hardware architecture level?

[Elardus Engelbrecht]

John McKown wrote:

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



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




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

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

Re: Straightforward way to determine hardware architecture level?

[John McKown]

On Mon, Nov 30, 2015 at 6:29 AM, Bob Shannon 
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   0GR
R1   EQU   1GR
R2   EQU   2GR
...
R0_64EQU   0GR64
R1_64EQU   1GR64
...
R0_32EQU   0GR32
R1_32EQU   1GR32
...
AR0  EQU   0AR
AR1  EQU   1AR

​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

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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

[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 – unsubscr...@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.

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

Re: Straightforward way to determine hardware architecture level?

[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
On Nov 29, 2015, at 9:46 PM, Steve Thompson wrote:


On 11/29/2015 09:56 PM, Ed Gould wrote:

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





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



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

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


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

Re: Straightforward way to determine hardware architecture level?

[Steve Thompson]

On 11/29/2015 09:56 PM, Ed Gould wrote:

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





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



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

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

Re: Straightforward way to determine hardware architecture level?

[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



On Nov 29, 2015, at 7:22 PM, Ed Gould   
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




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


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

Re: Straightforward way to determine hardware architecture level?

[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: sipp...@sg.ibm.com

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

Re: Straightforward way to determine hardware architecture level?

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

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

Re: Straightforward way to determine hardware architecture level?

[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
On Nov 29, 2015, at 4:18 PM, Charles Mills wrote:

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- 
m...@listserv.ua.edu] On

Behalf Of J O Skip Robinson
Sent: Sunday, November 29, 2015 12:33 PM
To: IBM-MAIN@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.

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


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

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On
Behalf Of J O Skip Robinson
Sent: Sunday, November 29, 2015 12:33 PM
To: IBM-MAIN@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. 

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

Re: Straightforward way to determine hardware architecture level?

[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  + ss2827   
01  + ss2827   
02  +Iss2827   
03  -  
04  -I 
   
CPC ND = 002827.H43.IBM.02.000ss   
CPC SI = 2827.704.IBM.02.00ss
 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 EXISTW WLM-MANAGED 
N NOT AVAILABLE
   
IINTEGRATED 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 IDLOGICAL 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.robin...@sce.com

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

I am not a LOADXX guru but &SYSALVL looks like waaay 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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Sunday, November 29, 2015 11:44 AM
To: IBM-MAIN@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...

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

Re: Straightforward way to determine hardware architecture level?

[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 lists...@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.

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

Re: Straightforward way to determine hardware architecture level?

[Charles Mills]

I am not a LOADXX guru but &SYSALVL looks like waaay 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-MAIN@LISTSERV.UA.EDU] On
Behalf Of J O Skip Robinson
Sent: Sunday, November 29, 2015 11:44 AM
To: IBM-MAIN@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...

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

Re: Straightforward way to determine hardware architecture level?

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

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

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

Charles

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

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

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

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

Charles

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

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

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

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Sunday, November 29, 2015 7:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

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 

Re: Straightforward way to determine hardware architecture level?

[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


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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

[Mike Schwab]

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

On Sat, Nov 28, 2015 at 5:17 PM, Charles Mills  wrote:
> 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-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Kirk Wolf
> Sent: Saturday, November 28, 2015 3:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Straightforward way to determine hardware architecture level?
>
> 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
> *k...@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.'
>  LRR12,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
>
>  LAR15,0   Default ARCH(0) - should not occur
>
> *  Test ARCH(5)
>  TMFaclByte0,FaclZArchInstalled
>  BNO   EXIT
>  LAR15,5   ARCH(5)
>
> *  Test ARCH(6)
> *  long-displacement facility
>  TMFaclByte2,FaclLongDisplacement
>  BNO   EXIT
>  LAR15,6   ARCH(6)
>
> *  Test ARCH(7) (z9)
> *  long-displacement facility
>  TMFaclByte2,FaclExtendedImmediate
>  BNO   EXIT
>  LAR15,7   ARCH(7)
>
> *  Test ARCH(8) (z10)
> *  extended-immediate facility,
> *  DFP facility
>  TMFaclByte4,FaclGeneralInstExtension
>  BNO   EXIT
>  TMFaclByte5,FaclDFPF
>  BNO   EXIT
>  LAR15,8   ARCH(8)
>
> *  Test ARCH(9) (z196)
> *  high-word facility,
> *  interlocked-access facility,
> *  load/store-on-condition facility,
> *  distinct-operands-facility,
> *  population-count facility.
>  TMFaclByte5,FaclHighWord
>  BNO   EXIT
>  TMFaclByte5,FaclLoadStoreOnCondition
>  BNO   EXIT
>  TMFaclByte5,FaclDistinctOperands
>  BNO   EXIT
>  TMFaclByte5,FaclPopulationCount
>  BNO   EXIT
>  LAR15,9   ARCH(9)
>
> *  Test ARCH(10) (xc12)
> *  execution-hint facility,
> *  load-and-trap facility,
> *  miscellaneous-instruction-extension facility,
> *  transactional-execution facility.
>  TMFaclByte6,FaclExecutionHint
>  BNO   EXIT
>  TMFaclByte6,FaclLoadAndTrap
>  BNO   EXIT
>  TMFaclByte6,FaclMiscInstExt
>  BNO   EXIT
>  TMFaclByte9,FaclTransactionalExecution
>  BNO   EXIT
>  LAR15,10   ARCH(10)
>
> *  Test ARCH(11) (z13)
> *  vector facility,  -- should we also check CVTVEF ??
> *  deci

Re: Straightforward way to determine hardware architecture level?

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 
11/28/2015 06:12:04 PM:


> *  Test ARCH(6)
> *  long-displacement facility
>  TMFaclByte2,FaclLongDisplacement
>  BNO   EXIT
>  LAR15,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




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

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

On Sat, Nov 28, 2015 at 5:17 PM, Charles Mills  wrote:

> 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-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Kirk Wolf
> Sent: Saturday, November 28, 2015 3:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Straightforward way to determine hardware architecture level?
>
> 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
> *k...@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.'
>  LRR12,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
>
>  LAR15,0   Default ARCH(0) - should not occur
>
> *  Test ARCH(5)
>  TMFaclByte0,FaclZArchInstalled
>  BNO   EXIT
>  LAR15,5   ARCH(5)
>
> *  Test ARCH(6)
> *  long-displacement facility
>  TMFaclByte2,FaclLongDisplacement
>  BNO   EXIT
>  LAR15,6   ARCH(6)
>
> *  Test ARCH(7) (z9)
> *  long-displacement facility
>  TMFaclByte2,FaclExtendedImmediate
>  BNO   EXIT
>  LAR15,7   ARCH(7)
>
> *  Test ARCH(8) (z10)
> *  extended-immediate facility,
> *  DFP facility
>  TMFaclByte4,FaclGeneralInstExtension
>  BNO   EXIT
>  TMFaclByte5,FaclDFPF
>  BNO   EXIT
>  LAR15,8   ARCH(8)
>
> *  Test ARCH(9) (z196)
> *  high-word facility,
> *  interlocked-access facility,
> *  load/store-on-condition facility,
> *  distinct-operands-facility,
> *  population-count facility.
>  TMFaclByte5,FaclHighWord
>  BNO   EXIT
>  TMFaclByte5,FaclLoadStoreOnCondition
>  BNO   EXIT
>  TMFaclByte5,FaclDistinctOperands
>  BNO   EXIT
>  TMFaclByte5,FaclPopulationCount
>  BNO   EXIT
>  LAR15,9   ARCH(9)
>
> *  Test ARCH(10) (xc12)
> *  execution-hint facility,
> *  load-and-trap facility,
> *  miscellaneous-instruction-extension facility,
> *  transactional-execution facility.
>  TMFaclByte6,FaclExecutionHint
>  BNO   EXIT
>  TMFaclByte6,FaclLoadAndTrap
>  BNO   EXIT
>  TMFaclByte6,FaclMiscInstExt
>  BNO   EXIT
>  TMFaclByte9,FaclTransactionalExecution
>  BNO   EXIT
>  LAR15,10   ARCH(10)
&

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Saturday, November 28, 2015 3:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

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
*k...@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.'
 LRR12,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

 LAR15,0   Default ARCH(0) - should not occur

*  Test ARCH(5)
 TMFaclByte0,FaclZArchInstalled
 BNO   EXIT
 LAR15,5   ARCH(5)

*  Test ARCH(6)
*  long-displacement facility
 TMFaclByte2,FaclLongDisplacement
 BNO   EXIT
 LAR15,6   ARCH(6)

*  Test ARCH(7) (z9)
*  long-displacement facility
 TMFaclByte2,FaclExtendedImmediate
 BNO   EXIT
 LAR15,7   ARCH(7)

*  Test ARCH(8) (z10)
*  extended-immediate facility,
*  DFP facility
 TMFaclByte4,FaclGeneralInstExtension
 BNO   EXIT
 TMFaclByte5,FaclDFPF
 BNO   EXIT
 LAR15,8   ARCH(8)

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

*  Test ARCH(10) (xc12)
*  execution-hint facility,
*  load-and-trap facility,
*  miscellaneous-instruction-extension facility,
*  transactional-execution facility.
 TMFaclByte6,FaclExecutionHint
 BNO   EXIT
 TMFaclByte6,FaclLoadAndTrap
 BNO   EXIT
 TMFaclByte6,FaclMiscInstExt
 BNO   EXIT
 TMFaclByte9,FaclTransactionalExecution
 BNO   EXIT
 LAR15,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
 TMFaclByte16,Facl_VectorExtensionFacility
 BNO   EXIT
 TMFaclByte10,FACL_DFPPackedConversion
 BNO   EXIT
 TMFaclByte6,FACL_LoadStoreOnCond2
 BNO   EXIT
 TMFaclByte6,FACL_CTEND
 BNO   EXIT
 LAR15,11   ARCH(11)

 TITLE '-- Exit / epilogue'
EXIT DS0H
 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 Technolog

Re: Straightforward way to determine hardware architecture level?

[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
*k...@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.'
 LRR12,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

 LAR15,0   Default ARCH(0) - should not occur

*  Test ARCH(5)
 TMFaclByte0,FaclZArchInstalled
 BNO   EXIT
 LAR15,5   ARCH(5)

*  Test ARCH(6)
*  long-displacement facility
 TMFaclByte2,FaclLongDisplacement
 BNO   EXIT
 LAR15,6   ARCH(6)

*  Test ARCH(7) (z9)
*  long-displacement facility
 TMFaclByte2,FaclExtendedImmediate
 BNO   EXIT
 LAR15,7   ARCH(7)

*  Test ARCH(8) (z10)
*  extended-immediate facility,
*  DFP facility
 TMFaclByte4,FaclGeneralInstExtension
 BNO   EXIT
 TMFaclByte5,FaclDFPF
 BNO   EXIT
 LAR15,8   ARCH(8)

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

*  Test ARCH(10) (xc12)
*  execution-hint facility,
*  load-and-trap facility,
*  miscellaneous-instruction-extension facility,
*  transactional-execution facility.
 TMFaclByte6,FaclExecutionHint
 BNO   EXIT
 TMFaclByte6,FaclLoadAndTrap
 BNO   EXIT
 TMFaclByte6,FaclMiscInstExt
 BNO   EXIT
 TMFaclByte9,FaclTransactionalExecution
 BNO   EXIT
 LAR15,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
 TMFaclByte16,Facl_VectorExtensionFacility
 BNO   EXIT
 TMFaclByte10,FACL_DFPPackedConversion
 BNO   EXIT
 TMFaclByte6,FACL_LoadStoreOnCond2
 BNO   EXIT
 TMFaclByte6,FACL_CTEND
 BNO   EXIT
 LAR15,11   ARCH(11)

 TITLE '-- Exit / epilogue'
EXIT DS0H
 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

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

Re: Straightforward way to determine hardware architecture level?

[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


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

Re: Straightforward way to determine hardware architecture level?

[Tony Harminc]

On 26 November 2015 at 09:47, Elardus Engelbrecht
 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.


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


Tony H.

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

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, November 26, 2015 6:12 AM
To: IBM-MAIN@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).

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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

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

Peter Relson
z/OS Core Technology Design


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

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


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

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Wednesday, November 25, 2015 3:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

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

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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Shannon
Sent: Wednesday, November 25, 2015 11:33 AM
To: IBM-MAIN@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.

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

Re: Straightforward way to determine hardware architecture level?

[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 – unsubscr...@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.

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

Re: Straightforward way to determine hardware architecture level?

[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

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

Re: Straightforward way to determine hardware architecture level?

[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 – unsubscr...@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.

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

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Shannon
Sent: Wednesday, November 25, 2015 11:23 AM
To: IBM-MAIN@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.

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

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 – unsubscr...@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.

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

Re: Straightforward way to determine hardware architecture level?

[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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, November 25, 2015 10:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

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

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

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

Re: Straightforward way to determine hardware architecture level?

[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

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