On Tue, 26 May 2015 23:25:42 +, Gibney, David wrote:
... I neither have nor really can control what falls into SYSSTC. It's all
z/OS.
You can, and probably should at least look at some of your heavy hitters.
Just tossing it out here for thought on identifying the guilty software?
Grab a
we are using 2094-S54 for installing this RHEL7 .
On Tue, May 26, 2015 at 11:41 AM, גדי בן אבי gad...@malam.com wrote:
It would seem that ' The Linux kernel requires more recent processor
hardware' is the culprit.
What computer are you using?
-Original Message-
From: IBM
IDCAMS PRINT (infile/indataset) HEX will do a hex-only dump of a dataset. The
options are CHAR/DUMP/HEX with DUMP being the default.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
I've had to deal with a couple of PDSE issues with z/OS 2.1 and Fault
Analyzer.
1. Ensure all systems are up to date with PDSE maintenance
2. It's possible that IEBPDSE (the z/OS 2.1 version) against your restored
PDSE will still report problems. Reallocate your PDSE and copy (IEBCOPY)
the
The z9 is 3 or 4 generations old.
I guess that is the problem.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mainframe Mainframe
Sent: Tuesday, May 26, 2015 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/Linux PSW 0BAD
we
It would seem that ' The Linux kernel requires more recent processor hardware'
is the culprit.
What computer are you using?
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mainframe Mainframe
Sent: Tuesday, May 26, 2015 9:09 AM
To:
Hello Group,
When I am booting the RHEL7 z/linux guest , getting below
PSW.
0: Please choose (default will boot in 5 seconds):
00: FCP 681D ATTACHED TO LNXBT1 681D
00: Booting default (linux)...
00: The Linux kernel requires more recent processor hardware
00: HCPGIR450W CP
You can run Subcapacity Planning Tool (SCPT) to help prepare for subcapacity
reporting.
You can, I believe, run the Subcapacity Reporting Tool (SCRT) even if you don't
submit the report.
There is a section of the SCRT spreadsheet report that show the Product Max
Contributors - but note that
Thanks!
Regarding 2: I restored the dataset to another name and then did 2 renames.
IEBPDSE did not report any problems.
Best Regards,
Thomas Berg
___
Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ)
Good point. SE (or HMC) should show list of domains, BUT
1. I can't access the machine now.
2. I can imagine there is microcode update which extends the number of
possible domains.
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2015-05-26 o 06:14, Rob Schramm pisze:
Its always
16 was the number for a long time. Also, why 85? 5 x 17? Where did the
extra 1 come from? I would have expected ... 5 * 16 = 80
On Tue, May 26, 2015, 6:14 AM R.S. r.skoru...@bremultibank.com.pl wrote:
Good point. SE (or HMC) should show list of domains, BUT
1. I can't access the machine now.
On 5/26/2015 at 02:11 AM, *** ** *** gad...@malam.com wrote:
It would seem that ' The Linux kernel requires more recent processor
hardware' is the culprit.
Indeed. RHEL 7 will only run on a z196/114 or later machine.
Mark Post
There is a Linux List that you may wish to join for these types of questions.
If you have not done so, you can join here
Linux http://www2.marist.edu/htbin/wlvindex?LINUX-VM
http://www.marist.edu/htbin/wlvindex?LINUX-390
Here are some more links you might also find
W dniu 2015-05-26 o 13:24, Rob Schramm pisze:
16 was the number for a long time. Also, why 85? 5 x 17? Where did the
extra 1 come from? I would have expected ... 5 * 16 = 80
The 85 is quite obvious: it is current limit of LPARs in z13. So, single
CryptoExpress5S card can serve *all* LPARs
16 was the number for a long time. Also, why 85? 5 x 17? Where did the
extra 1 come from? I would have expected ... 5 * 16 = 80
The number of domains architecturally supported in the CEX5 card itself is
actually 256, which is of course a nice power of 2. However, that is more than
that z
From LISTDUMP
COMPDATA(IARHVSHR)
0200_0010.:0200_00100FFF.
X'1000' bytes described in COMPDATA(IARHVSHR)
LIST 210.
If it is a stand-alone dump, you may need to specify an ASID which is
connected
to the shared memory object of interest. If it is an SVC dump, I
Take a look at this APAR:
http://www-01.ibm.com/support/docview.wss?uid=isg1OA44607
In the APAR it has:
Sparse datasets from release 1.13 or lower and subsequent
updated in R2.1 may cause an index corruption. R2.1 collapse
sparse indexes and it did not delete an empty page in a
particular delete
We just had a zPCR study. There weren't any real surprises, but the Workload
CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC
workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor
really can control what falls into SYSSTC. It's all z/OS.
I
I am trying to issue a tailored SVC dump and am finding that there are
many
absolute storage records filling the dump - many more since zos/1.10
I specify SDATA=(NODEFS,NOALLPSA,NOSQA) - what more do I need to specify?
How did you determine that there are many absolute storage records? Did
From LISTDUMP
COMPDATA(IARHVSHR)
0200_0010.:0200_00100FFF.
X'1000' bytes described in COMPDATA(IARHVSHR)
--
Binyamin Dissen bdis...@dissensoftware.com
20 matches
Mail list logo
