failback will never
achieve.
I'm reminded of something I heard once along the lines of "We back up to
restore, not to just have a copy."
Ron Hawkins
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) | m: +61 400029610 | h: +61
387399252 | email: ron.hawk...@ipsicsopt.com
-Original Me
Give that man a cigar!!!
Ron Hawkins
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) | m: +61 400029610 | h: +61
387399252 | email: ron.hawk...@ipsicsopt.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Vernooij, Kees (ITOP NM) - KLM
Sent: Friday, 15 February
datasets you need to watch the TIOT.
Ron Hawkins
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m: +61 400029610 | h: +61 387399252 | f: +1 4087912585 | email:
ron.hawk...@ipsicsopt.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joel C. Ewing
Sent: Friday, 8 March
NB if the underlying volumes are thin provisioned, then the unused space is not
using any capacity.
Worth considering if it makes your migration simpler.
Ron Hawkins
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m: +61 400029610 | h: +61 387399252 | f: +1 4087912585 | email:
ron.hawk
the E10 and F20 out of the door.
I think it was more like last to market in IBM's case.
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Pommie
to different strings.
Prepared to be corrected.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of R.S.
Sent: Monday, 20 May 2019 05:05
To: IBM-MAIN@LISTSERV.UA.E
Repro and rename.
It may just be me, but when I see COPY used, I think DFSMSdss.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Seymour J Metz
Sent
00850800
1 DEVICE(S) MET THE SELECTION CRITERIA
0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING
The information is also available on in the Type 74 subtype 1 and 5 records,
and the RMFPP Cache Summary report.
RON HAWKINS
Director
an get the HTC specific model
information, and more.
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Martin Packer
Sent: Monday, 20 May 2019 19:08
To
I always thought JES2 resolved relative GDG numbers during job initiation.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Wednesday, 27 May 2020 11:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] GDG relative number updates
Hi
I have ha
Sort it first with the SUM FIELDS=NONE option.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Ron
Thomas
Sent: Wednesday, 22 May 2019 08:26
To: IBM-MAIN
.
What am I missing?
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Ron
Thomas
Sent: Wednesday, 22 May 2019 09:02
To: IBM-MAIN@LISTSERV.UA.EDU
en there would be 300 records generated
If 100 copies of each unique key then there would be 200 records generated
I'd have to RTFM to figure out the INPUT you provided, so I am relying on the
description.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4
Ken,
You need to reformat the logical volume, and mount it as an FCP device.
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Ken Bloom
Sent: Saturday
Assuming you used DFSMSdss, you could start here.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/lnxdiv6.htm,
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From
Jesse,
I may be late to the party, but did you look at using DISKCOMP on from CBT?
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jesse 1 Robinson
Sent
I would have thought SAS is your friend.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jesse 1 Robinson
Sent: Thursday, 27 June 2019 07:44
To: IBM-MAIN
Paul,
The problem is not SAS or MXG.
It means you have an out-of-sequence or missing segment of a spanned record
in the file.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe
, I believe you can introduce relational constraints to
SAS indexed files.
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Baron Carter
Sent: Monday
http://www.navydp.com/phpBB3/viewtopic.php?t=115
I checked the video twice when they talked about the FirstRand I on one of the
navy ships, and did not hear them say it was a legend.
Interesting that Australia used them in the telegram messaging systems.
RON HAWKINS
Director, Ipsicsopt Pty Ltd
are a few, unsubstantiated
references to failures sending the drum through a wall(s).
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
William Donzelli
, and the same
restrictions apply, even when you are running CA MII. In this regard, CA MII
neither enhances nor restricts PDSE sharing."
I think you are between a rock and a hard place. Perhaps reverting to
PDSESHARING(NORMAL) and using DISP=OLD to avoid the sharing error.
RON HAWKIN
Linked in is fine by me. It is about as US-centric as FB.(Only Americans think
they're the only ones using it 😊 )
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion Lis
compression and encryption are sure to be performed in the right
sequence.
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Phil Smith III
Sent: Tuesday, 6 August
Phil,
FPE - I learn a bit more every day.
That would be an improvement over a random cypher, but wouldn't the length
and repeatability of the data patterns after encryption negatively affect
LZW compression, along with deduplication?
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 62
ggest you
enhance IEFACTRT to provide the information or dig around CBT for an up to
date SMF type 30 report program.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On B
onary.
However, from what you explain, prefixes on account numbers, like the first
four of a credit card number, would no longer be the same for groups of
records, so that would mean some loss of repeatability.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 408
if you spend more than 60 calendar days
in the state. Tell that to someone from Nevada.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent
year at least as well.
If for some unforeseen we blow the 60 days, who is going to pay the employee's
tax in California? If they were at 50 days and visited the amusement parks in
LA for 1.5 weeks they've blown it.
And that's the main reason it was mothballed and made ad hoc.
Ro
Not all boomerangs come back.
Not all who throw a boomerang can make it come back.
Take it from an Aussie that has unsuccessfully thrown a few boomerangs.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message
Where?
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mike Schwab
Sent: Friday, 23 August 2019 01:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN
unforeseen circumstance
blows the 60 days.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mike Schwab
Sent: Friday, 23 August 2019 02:04
To: IBM-MAIN@LISTSERV.UA.E
All,
Could it be that the EOF mark on the file is a DADSM function outside of the
control of the program, and that is why there is no SMF record from an
unopened, empty data set?
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1
good starting point to test
the hypotheses.
Do you have any additional ideas that would add to what and how SMF
recording occurs when allocating a file with IEFBR14?
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original
Fred,
Have a look outside the nine dots at what the other vendors are offering.
There is more than one way to skin a cat, and the IBM products and services are
not necessarily the best or most cost-effective way to get the job done.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m
, but they were
supporting GDPS services on those platforms 12 months ago, so IBM is not the
only choice, even if you go the GDPS automation route.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM
flow on to replication.
Move out of the past, and stop fooling ourselves that EOS is erasing anything,
and optimise it to obfuscate the data from CKD host only, as that is all it is
doing anyway.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 |
separately from the actual track contents.
Thanks for asking Kees, and making me exercise some brain cells. If I am wrong
on anything, I hope someone will educate me.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original
Jesse,
Nowadays you would still be long gone, but depending on media, pool occupancy,
and page migration, there will likely be large areas of in the clear content,
unless accessed by CKD.
Next time, ask your vendor about disk scrubbing.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705
class for these jobs?
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Shivang Sharma
Sent: Sunday, 22 September 2019 19:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subjec
I like the scientific phraseology: four-fifths of five-eighths of FA.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
David Spiegel
Sent: Tuesday, 24
track geometry makes life easier, even with SDB.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Allan Staller
Sent: Monday, 23 September 2019 22:35
To: IBM
But of course you follow up that journaling with CLPA at IPL...
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jim Mulder
Sent: Tuesday, 24 September 2019
Kees,
Possibly a redundant and risky method, given the ease and granularity of the
DFSMS approach.
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Radoslaw,
Isn't this also the case for VSAM when you lose your OS with the files open?
I may be out of date or have a lapse in memory, but I recall a file journaling
option that allowed CICS to roll forward/back updates to a file with LSR
buffered writes.
It could be just another senior moment
Lizette,
True, but...
Have ever noticed the same search on Google can give you different results?
It's a synchronization problem.
Would that work for credit card balances?
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizett
Lizette (OP),
I would not recommend going to 32K as a blocking factor. Generically
speaking, all three vendor emulate a CKD track, allocating up to 64KiB of
space for every track.
Whether you use a regular formatted volume, or thin provisioning (DP-VOL in
Hitachi speak), if you write a 32K
Cameron,
I have forgotten more than I knew, and searching manuals no longer comes easy.
Someone earlier mentioned using REPRO to decrypt the file as you back it up.
DF/dss will use REPRO for a logical backup, and the backup file is not
encrypted.
The question then is, "When restoring, does DF/
Skip,
Is there a case here for taking regular snapshots of your UCATs and other small
critical datasets?
Using persistent FlashCopy the UCATs or their volumes could be copied every
hour and retained for quick receovery.
30 days' worth of hourly copies of a 1000 Cyl UCAT would use less than 1GB
Jesse,
Round trip delay time is the same on ESCON and Fiber Channel, but the
mother-may-I nature of ESCON protocols used to pump-up the droop factor, even
at 10km. Fiber Channel links changed the viability of synchronous at metro
distances substantially.
Personally, I think that the myth of ze
Radslaw,
Have you confused a few things when explaining the difference between
synchronous and asynchronous, and ESCON compared to FICON?
Buffer credits are synonymous to DIBs, and a large number of buffer credits
provided by Fiber Channel switches allowed the connection to be full of frames
e
You have asked me and I have said nothing.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Savor, Thomas (Alpharetta)
Sent: Thursday, June 7, 2018 9:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] OT: Rap music (was Re: opinion: multi-platform program
desi
5:15 PM Ron hawkins wrote:
>
> Radslaw,
>
> Have you confused a few things when explaining the difference between
> synchronous and asynchronous, and ESCON compared to FICON?
>
> Buffer credits are synonymous to DIBs, and a large number of buffer credits
> provided by Fiber
Async PPRC
ESCON is synchronous, where after sending a buffer, it would wait for
acknowledgement before sending the next buffer.
FICON is async, where it sends buffer after buffer without waiting.
If it doesn't get an acknowledgement within a certain time frame it would
resend the lost buffe
lti-platform program
design)
On 9/06/2018 7:03 AM, Ron hawkins wrote:
> You have asked me and I have said nothing.
Are they lyrics from a Barnsey song?
>
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Savor, Thomas (Alpharetta)
> Sent: Thursday,
Thanks,
Tom Savor
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ron hawkins
Sent: Saturday, June 09, 2018 3:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT: Rap music (was Re: opinion: multi-platform program design)
You ha
Richard,
You used 1.6GB of virtual storage.
How much paging did the address do? There's no free lunch, and page faults
will increase the TCB time for an address.
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Way, Richard
Sent:
On
Behalf Of Ron Hawkins
Sent: Wednesday, July 26, 2017 5:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REGION=0M leads to CPU through the roof
Richard,
You used 1.6GB of virtual storage.
How much paging did the address do? There's no free lunch, and page faults
will increase the TCB tim
nutes.
I suspect that the application built a table. Spent wasted time searching
it.
Sent from my iPhone
> On Jul 27, 2017, at 6:50 PM, Ron Hawkins
wrote:
>
> Charles,
>
> YES I AGREE, storage nowadays can do a lot of paging, and support a
> CEC easily burning 11 minutes
] REGION=0M leads to CPU through the roof
Turn on a monitor while the step is running? With 12 min of CPU, there is time
to dig into it.
Rob
On Fri, Jul 28, 2017, 4:10 AM Ron Hawkins wrote:
> Gerhard,
>
> Now what if the searching you describe was a sequential scan of said
> ta
Then tell me why my overseas banks contacting me to provide details under FBAR.
What's good for the goose...
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Saturday, August 12, 2017 2:06 PM
To: IBM-MAIN@LISTSERV.U
Bruce,
You used to have access to SAS and MXG. Have you looked at this as an
alternative to processing RACFICE?
If you use the TYPS80A member, I think you can piece together what you are
looking for. For example, the ADDUSER command is type80 subtype 10, and
therefore TYPE8010 in the PDB.
Som
Kirk,
Auribus teneo lupum.
Sharing SMS managed outside of SMS is on the cardinal sins of SMS.
It is more than just aid to allocation, but also an enabler of function. If
your LPAR doesn't read the NVR, then your open is dead in the water, right?
Ron
-Original Message-
From: IBM Mainfr
FDRMOVE anyone.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jesse 1 Robinson
Sent: Friday, January 5, 2018 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Accessing 65536 devices
We have device count reduction on ou
Arun,
Strobe gives you a lot more information than this little tidbit.
I cannot answer your specific questions, but you mention that the 2nd dataset
is skip sequential. Is there some chance that someone has set this up to be
accessed as LSR with SMS or Batch/LSR?
If you can estimate the number
Mike and Arun,
I think the assumption here is that there is that there are no records in the
second file (skip sequential) that are being accessed more than once by a
foreign key from the first file. If that is the case, then I think it makes
sense that a sorted copy of the first file using the
Mike,
The 2nd part of your reply will require 3390-A to support DVE.
Hopefully, that is all that used for new DASD subsystems, for a few years now.
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mike Schwab
Sent: Saturday, Ja
Arun,
Would you share the whole strobe report?
You can send it to me directly as an attachment.
Standard VSAM and FICON does not chain across cylinder boundaries. 1 cyl = 1
CA, and with CISZ 26K there are 30 CI in a CA/cyl. Ipso facto you read 30 CI
per SSCH. This increases with zHPF.
-Or
Gerhard,
He has BUFNI=120, so I don't think the occasional misses on the 2nd level
index set are a root cause.
It would show up in strobe as high IO to the index rather than data
component, or he has, I hope, looked at the type 64 and 42 subtype 6
records.
Ron
-Original Message-
From:
So what is the max number of records processed per skip sequential access?
However many CI that is, you should set BUFND to be that times 2.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Arun Venkatratnam
Sent: Sunday, January 7, 20
Arun,
OK, looking at the full strobe report, if I read it correctly, converting to
sequential processing may not be the most efficient way to process this. Both
files have 32.4M records, but you only touch 4.9M records in each file when the
program executes. You are touching around 15% of the t
Last time I looked they were all 3390-9... (GD&R).
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mazer Ken G
Sent: Tuesday, January 9, 2018 4:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Number of Cylinders per Volume
While
With Hitachi DP-Vols each 7 cyl control area manages 1113 cyls of usable
space per volume. The 3390-A volumes, however, do not have to be allocated
in units of 1113 cyls. You can specify any custom size volume you want in
cylinder units.
The 1120 cyls is allocated in 672 track pages, and the 7 cyl
All,
My history with z/OS is more about performance and tuning, rather than
hardcore sysprogging.
Tuning is almost always about doing it a new way, and I only wish there were
more newbies in this field with no preconceived ideas about how it has
always worked. Back when I was not Mr Congeniality
normal considerations..
> but since writes are done to cache.. isn't it the foremost attribute
these
> days?
>
> Rob Schramm
> On Jan 3, 2014 4:15 PM, "Ron Hawkins" wrote:
>
> > Art,
> >
> > Channels paths, ports, Front End Directors and ports a
Ed,
You're original question to the list, and I quote verbatim: " Is the owner
of IBM-MAIN alive or dead?"
Darren's first sentence in his response: " Yes, Ed, I'm still alive. "
What part of your original question was not answered?
Ron
> -Original Message-
> From: IBM Mainframe Discuss
I wish they fix the ISMF panels to be whole screen length on a 60 line
screen first...
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Joel C. Ewing
> Sent: Friday, January 24, 2014 7:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subje
Radoslaw,
One of the problems I see with Host based overwrite is that you can only
overwrite the current location of the logical volume.
If you are using IBM's Eazytier, or Hitachi's HDT you really do not know the
past location of the chunks of the volume, only the last location. The same
problem
Can you release extents on legacy VSAM dataset?
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Sunday, February 16, 2014 6:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Was: Imp
Bill,
Think EAV volume...
I just had a lot of fun with this very scenario building DEFRAG experiments.
2x1 track dataset, and then delete every second dataset across 256 volumes.
Who would have thought that the UCAT size would be my biggest problem (5
million datasets).
Ron
> -Origi
Bob,
It's usually simpler to specify UNIT=(3390,7) and forget the VOL parm
altogether. An explicit unit count is not ignored for SMS managed datasets.
I used to use ACC/SRS to force all DSORG=PS datasets to be allocated with a
unit count of 5 - solved my X37 nightmares big time.
Blew TIOT in a f
Shai,
I'd hazard a guess that shops using some type of thin provisioning would
simply make the volume the maximum size supported by the controller, even if
the planned to just put the JES2 Checkpoint on the volume.
In this case a 10 CYL dataset on a 262K CYL volume is not a problem, or a
waste.
I recall it was 1/3 of the way in, and the idea was nuked by cache (3880-13/23).
No point clustering your busiest datasets together 1/3 or 1/2 of the way into
the volume when they are usually cache resident. You create a nice quiet area
on the platter for seeking between those less busy datasets
That sounds like GTFPARS.
It used to read a GTF trace and generate IEHLIST for the volumes it found. It
used to generate a kewl seek histogram, and a dataset seek activity report you
could use to tune the location of your busiest datasets.
I used to tune SYSRES dataset positions using this, but
Bobby,
>From our default IEAIOSnn member.
MIH DASD=01:00
HYPERPAV=YES
ZHPF=YES
Individual addresses can be used to override these values.
Ron
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Herring, Bobby
> S
Radoslaw,
I always thought that HDP or Eazytier would render this feature useless, but
who knows.
There was a Share presentation two years ago by the development team that
talked about this and some of the details of the mechanism.
My recollection is that a Storage Class with an MSR of 3ms would
Bill,
The problem for you is that changing the DATACLAS to one with EA, or
changing the existing DATACLAS to support EA will not change the attributes
of the files already allocated.
Think of DATACLAS as JCL DD statement. It described the attributes of the
dataset to be allocated. Those attribute
I did exactly this shop wide for VSAM KSDS in 1997. It was a seamless change.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John McKown
> Sent: Wednesday, April 16, 2014 10:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [I
Because 1.14 would not sit well with the Cantonese...
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Nims,Alva John (Al)
> Sent: Friday, April 25, 2014 10:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Beyond the
Reminds me of a Hong Kong building I was living in.
The floors went 11, 12, 12a, 14, 15...
Which was strange seeing 14 is unlucky for the Cantonese (that's twice I've
used this - boring...)
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> O
t: Tuesday, April 29, 2014 11:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Beyond the EC12
>
> Ron Hawkins wrote:
>
> >Reminds me of a Hong Kong building I was living in.
> >The floors went 11, 12, 12a, 14, 15...
>
> Weird. If you tru
All,
Shmuel's reply prompts me to suggest that you consider what lies outside the
nine dots.
Firstly, would you consider thin provisioning of the installation volumes and
SYSRES? This will get you onto 3390-A for these volumes using any size you
want. Why is this good? Because DVE is also good
Yeah, what he said.
>
> This goes along with my response to this thread: people are still piddling
> around with mod 9's and even mod 3's? Once dynamic pooling became
> available on our Hitachi VSP I reconfigured all our volumes to mod 54's.
I've
> provisioned volumes with 120% of the array's phy
k subsystems do this. Don't think my new DS8870 does, but don't
> know if it was an option.
>
> Ken
> On Thu, May 1, 2014 at 4:53 PM, Ron Hawkins
> wrote:
>
> > Yeah, what he said.
> >
> > >
> > > This goes along with my response to this th
Shane,
Well that's not true. You can mix your basic volumes with HDP 3390-V volumes in
the same array group. We've done this to see how it would be reported by RMF
and it works just peachy. I hope he isn't from HDS :-(
There's nothing in the microcode that prevents this. You can make every arra
Victor,
If I understand problem at the root of your questions, you are trying to speed
up DFSMSdss logical dumps, especially for compressed PS-E data sets.
>From your questions you are focusing on the tape output rate as the gating
>factor for the elapsed time of the dump, but have you looked a
Juergen,
You need to allow for some double accounting of unchanged pages on AUX.
While it may not be at the root of what you are seeing, pages that are paged in
from AUX and are not changed will remain on AUX.
There is some growth in AUX over time because of this. I have no measurement,
but I
No it's not faster.
DFSMSdss calls repro under the covers for most VSAM data set copy operations,
but buffering is limited to whatever was used when the data set was defined.
I hope everyone uses a large BUFSP or BUFND value for REPRO (like >849920).
Ron
> -Original Message-
> From: IB
Gary,
I may be having a senior moment but I think I have seen this when there are a
lot of logical dumps starting that all hit the same catalog. Even your
INCLUDE(**) is going to spend a big hunk of time searching the catalogs and
volumes for datasets before it starts to dump anything.
My poss
ct: Re: [IBM-MAIN] z/OS 1.13 ADRDSSU ECB WAIT
>
> On Thu, 19 Jun 2014 05:47:40 -0700, Ron Hawkins wrote:
>
> >Gary,
> >
> >I may be having a senior moment but I think I have seen this when there
> are a lot of logical dumps starting that all hit the same catalog. Ev
1 - 100 of 254 matches
Mail list logo