Dump 70,72,113 from every system on the z server
Run the following build: MYIN is FB 80
%LET MACKEEP= MACRO _XLA113 _XLA113F % ;
%UTILBLDP(BUILDPDB=NO,USERADD=7072 113,
OUTFILE=MYIN,
WANTSMF=70.1 113.1,
INCLAFTR=ASUM70PR ASUM113);
ased on this.
MSU is also very easy to match to type 72's. Type 72's makes reporting easy
peasy.
Shivang, what tooling are you going to use to do this?
Andreas von Imhof
Capacity & Performance z/OS - zCAP
--
For IBM-
Hi Sri,
It works! Thank you so much!
You made the statements very simple (eazy peazy). Any fool (just like me) can
use it.
The saving:
2.09 million input records
REXX - 9 minutes clock time, 6 minutes CPU (IBM Z15 8561-723)
DFSORT - 9 seconds clock time, 0.78 seconds CPU
Unbelievable!
Ki
Hi Sri
This is great! Thank you!
it's almost there. It only processes the 1st occurrence of "CURRENT PLAN
OPERATION", and outputs 1 record correctly.
There are many occurrences of "CURRENT PLAN OPERATION", and I need a record for
each. Could you please help with the last bit?
Kind regards, Andre
Hi Max
This was my miserable attempt (with various variations).
Just keep getting the very 1st and very last record merged in both //SPLCE and
//OUT1 datasets.
* Top of Data **
+1+2+3+4+5+
Hi
I am trying to create 1 output record from multiple input records. Also the
output record will be reformatted.
I have been trying to get the ICETOOL SPLICE function to work, but alas to no
avail.
Please can someone help?
Reason for wanting to use SORT/ICETOOL is to reduce CPU consumption (c
Despite the fact that we have thousands of volumes we don't take full volume
dumps anywhere, so I cannot give our comparison. We also don't have TAPE
anymore. :-)
Perhaps open a ticket with IBM and let us know what IBM says?
--
Have you looked at the amount of compression that you are getting when
comparing the z14 to the z15?
In our shop SMF data went from about 6:1 compression (z14) to 10:1. This is a
massive improvement.
I do not have the CPU stats, and I also really could not care. Dumps run at
night when we have a
Turning it off in SMFPRMxx is like putting your head in the sand. Turn it off
in the application, just take a look at the install manual. These kind of "new"
applications from IBM can burn a lot of CPU in generating those SMF records.
For example we have IBM's Information Broker. Someone turned o
What Kees has written is correct. My rule of thumb is the faster the CP the
lower the velocity. With CPU upgrades I typically revise the velocity down.
It would help us if you would post a snapshot of the SUM report in RMF III,
then we have all the info and not just a tiny bit and we can help you
10 matches
Mail list logo
