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

Re: Straightforward way to determine hardware architecture level?

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

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

Re: Lrecl

On Sun, 29 Nov 2015 13:20:01 -0500, Shmuel Metz (Seymour J.) wrote: > on 11/28/2015 at 08:21 PM, Paul Gilmartin > >>A supremely stupid default except, perhaps, in that it supports unit >>record devices. > >A DCB OPEN exit would have supported UR eqipment and not have been so >rigid. > Indeed so,

Re: Straightforward way to determine hardware architecture level?

I am not a LOADXX guru but 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

Re: Lrecl

In <1806999179817213.wa.paulgboulderaim@listserv.ua.edu>, on 11/28/2015 at 08:21 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> said: >A supremely stupid default except, perhaps, in that it supports unit >record devices. A DCB OPEN exit would have supported UR

Re: Straightforward way to determine hardware architecture level?

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-

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

Re: IBM Mainframe

2015-11-26 5:51 GMT-06:00 John McKown :​ That's definitely true at the company I'm working for. Basically, the > company wants "ad hoc" workers for some project. But they don't seem to > have any concern about "maintenance" or having people on staff who > understand

Re: Machine Types and Architecture Levels

> AFAIK, the feature bits are not in the CVT, but only in PSA, beginning > at decimal 200. That's where the STFL instruction stores them. > > And for another wrinkle, there is at least one facility bit on the z13 that > is not in that list because it is beyond the 16 bytes that are reserved

Re: IBM Mainframe

Guys, Exactly, a z/OS system isnt a PC ...and not JAVA Scott On Sun, Nov 29, 2015 at 11:37 AM, Ricardo Gomez Ramirez wrote: > 2015-11-26 5:51 GMT-06:00 John McKown :​ > > That's definitely true at the company I'm working for. Basically, the > >

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

Re: User Cats and Replication Sites

Touche. We had a near catastrophic catalog problem some time back. Of course the replicated copy faithfully mirrored the errors, which were procedural rather than structural--tons of vital data deleted by mistake. Still I value mirroring for the classic case of disaster recovery: the production

Re: Machine Types and Architecture Levels

On Sat, 28 Nov 2015 09:17:01 -0800, Charles Mills wrote: >I am dealing with future machines by assuming that anything not in my table >is of an architecture level higher than those I know about. For my >application this is a safe assumption. The problem you have is that the

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

John Gilmore - mo postimgs since 11.05.2015

Somehow I am missing the postings from John Gilmore. Last post I found from 11.05.2015. Ist he retired ? Or, much worse, perhaps died already because of sickness or accident ? -- Mit freundlichen Gruessen / Kind Regards, Leopold Strauss, Team DEV-zOS, T: +43-2236-27551-331

Re: John Gilmore - mo postimgs since 11.05.2015

Leopold Strauss wrote: >Somehow I am missing the postings from John Gilmore. >Last post I found from 11.05.2015. Good catch. There are some other IBM-MAIN members which I also don't see any new postings... >Ist he retired ? Yes, retired a long time ago, but still does working contract work.

Re: Straightforward way to determine hardware architecture level?

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

Re: Lrecl

Paul Gilmartin wrote: >Long ago I dealt with this problem in Assembler. I left LRECL=0 in the DCB. >It would be merged in from either the DSCB or JCL, JCL dominating. I took the >DCB OPEN exit. If the value was still 0, unavailable from either of those >sources, I supplied a default LRECL;

Re: Lrecl

On Sun, 29 Nov 2015 05:26:26 -0600, Elardus Engelbrecht wrote: > >>I don't know how much of this is supported by COBOL except that coding BLOCK >>CONTAINS 0 RECORDS allows SDB to operate. Omitting the BLOCK CONTAINS clause >>is equivalent to coding BLOCK CONTAINS 1 RECORD(S). A supremely

Re: Machine Types and Architecture Levels

On Sat, 28 Nov 2015 09:17:01 -0800, Charles Mills wrote: > Is there a way to determine the architecture level of a zPDT >instance other than by testing feature bits in the CVT? AFAIK, the feature bits are not in the CVT, but only in PSA, beginning at decimal 200. That's where the STFL

Re: John Gilmore - mo postimgs since 11.05.2015

Elardus and Leopold, I didnt realize John had retired. I know many of are older for sure. Thank you for the posting.. Scott On Sun, Nov 29, 2015 at 6:06 AM, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > Leopold Strauss wrote: > > >Somehow I am missing the postings from John

Re: John Gilmore - mo postimgs since 11.05.2015

On Sun, Nov 29, 2015 at 10:11:27AM +0100, Leopold Strauss wrote: > Somehow I am missing the postings from John Gilmore. > > Last post I found from 11.05.2015. > > Ist he retired ? > > Or, much worse, perhaps died already because of sickness or accident ? I've had a pleasure to exchange a mail

REXX to know the CPU and MSU consumption.

I am currently programming a REXX to let me know the current consumption of my system MSU and the 4HRA. So far I have achieved: - Get the SysName - Get the model and type - Capacity defined for the LPAR's MSU - 4HRA - And whether the LPAR is capped or not The rexx I would not have invented it, I

Re: IBM Mainframe

Unfortunately, where I work if it isn't a Windows PC it just isn't a real computer. /Tom Kern On 11/29/2015 13:09, Scott Ford wrote: Guys, Exactly, a z/OS system isnt a PC ...and not JAVA Scott On Sun, Nov 29, 2015 at 11:37 AM, Ricardo Gomez Ramirez wrote: 2015-11-26

Re: REXX to know the CPU and MSU consumption.

So an internet search with IBM CALCULATE MSU produced the following entry. See if it helps http://www.ibm-mainframes.com/viewtopic.php?f=35=351 Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ricardo Gomez > Sent:

Re: REXX to know the CPU and MSU consumption.

http://2000clicks.com/links/Computers/IBMMainframeHistory/mipsmvs.htm In a message dated 11/29/2015 5:45:50 P.M. Central Standard Time, rica...@gomezr.com writes: Thanks for your answer. Certainly some parts of my rexx were from Mark’s IPL Info but it doesn’t have the value that I’m

Re: Straightforward way to determine hardware architecture level?

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

Re: REXX to know the CPU and MSU consumption.

https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprindex?OpenDocument https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprITRzOSv2r1?OpenDocument On Sun, Nov 29, 2015 at 8:09 PM, Ed Finnell <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: >

Re: Straightforward way to determine hardware architecture level?

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

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

Re: Straightforward way to determine hardware architecture level?

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

Re: Straightforward way to determine hardware architecture level?

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

Re: Straightforward way to determine hardware architecture level?

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

Re: REXX to know the CPU and MSU consumption.

Thanks for your answer. Certainly some parts of my rexx were from Mark’s IPL Info but it doesn’t have the value that I’m looking for, it is “Current MSU used by Lpar” Regards > El 29/11/2015, a las 2:36 p.m., Lizette Koehler > escribió: > > Some side notes: > > If

Re: Lrecl

On Sun, 29 Nov 2015 05:26:26 -0600, Elardus Engelbrecht wrote: > >>Long ago I dealt with this problem in Assembler. I left LRECL=0 in the DCB. >>It would be merged in from either the DSCB or JCL, JCL dominating. I took the >>DCB OPEN exit. If the value was still 0, unavailable from either of

Re: REXX to know the CPU and MSU consumption.

Some side notes: If you were not aware, there is a TSO-REXX list that covers all things REXX. Also, you can review what Mark Zelden wrote in his IPLINFO REXX. To join TSO-REXX if you have not done so, use this URL TSO REXXhttp://www2.marist.edu/htbin/wlvindex?TSO-REXX To review code