Hi there,
We are in the process of going to z10 hardware and I am looking for possible
WLM consequences. I found that when using Hyperdispath, it is a good thing
to keep track of the velocities because they can be influenced by this feature.
Any other ideas or tips are welcome.
Thanks in
Hi chris,
Thank you for helping me (as you did in the past)
I am no longer - for decades now - a CICS specialist but I have seen in a
recent thread in this list I think which allows CICS to pass print data to
JES2
from where there is a product which uses IP-based protocols to an IP
also posted to DB2-L
Hi listers,
I assume that there are some people on this list who use z/OS as DB
server for SAP. My customer plans the migration in the subject and I'm
looking for information on how much the dasd space may increase in
percent with this upgrade. The customer will not use
Always check your velocity goals when changing hardware. Those can be
affected by the differences in hardware speed. You response time goals
should be OK.
Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632
-Original Message-
From: IBM Mainframe
Glenn,
*
I am building a first copy of a stand alone sysres, commonly called a mini z/OS
and I would like SMS to come up in a null configuration.
*
I have found RTFM guidelines for setting up a MINIMAL configuration but no
specifications for a NULL configuration. Am I missing something or do I
On Wed, 3 Mar 2010 17:19:27 -0600, Glen Gasior glen.manages@gmail.com
wrote:
*
I am building a first copy of a stand alone sysres, commonly called a mini z/OS
and I would like SMS to come up in a null configuration.
*
I have found RTFM guidelines for setting up a MINIMAL configuration but no
On Thu, 4 Mar 2010 08:21:03 -0600, Mark Zelden mzel...@flash.net wrote:
(with snippage)
Anyway, a null configuration is one where you allocate an empty ACDS and
COMMDS and have an IGDSMSxx member that points to them and start
SMS via IEFSSNxx.
I always thought a null configuration was what
Matan
I'm working through some suitable definitions for you as samples - with
explanations - and including some guidance on HIS. Apart from the DLUR part
of the VTAM definitions and anything to do with HIS, what I am offering is
based on what I have working at a customer where I provide
*
Thank you that is all that I need and I will also look at the two pack examples
while I am working. I will report any interesting results. This will be on a
z10
BC, with a DS8100 (2107). I am going to try the null configuration for the
first
test.
*
Each day I run a Compress, Release, and Defrag on each volume in my SMS DASD
Storage group. Some of the volumes still remain pretty fragmented. Is
there a way to defrag the Storage Group?
--
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace
Sent: Thursday, March 04, 2010 12:23 PM
To: IBM-MAIN@bama.ua.edu
Subject: Defrag
Each day I run a Compress, Release, and Defrag on each volume
in my SMS DASD
Storage
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of McKown, John
Sent: Thursday, March 04, 2010 12:31 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag
-Original Message-
From: IBM Mainframe Discussion List
Well it's not a performance issue I'm trying to resolve. It's simply having
the volumes so fragmented that users sometimes have a hard time finding the
amount of space they need in 16 extents.
On Thu, Mar 4, 2010 at 1:30 PM, McKown, John
john.mck...@healthmarkets.comwrote:
-Original
What kind of z10 are you moving to? Subcapacity and 1 book models
may not be good candidates for HiperDispatch, and could actually
cause greif. Also, do you plan to turn HD on for all LPARs? Are
you running z/VM in any LPAR. HD certainly can be beneficial for
large n-way, multi-book z/OS
Some might argue that fragmentation breeds fragmentation. Perhaps your root
problem is that there needs to be more space. If new allocations can be
satisfied with fewer extents in the first place.
Plus, you are paying quite a performance price with all of that file shuffling.
DASD is
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace
Sent: Thursday, March 04, 2010 12:40 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag
Well it's not a performance issue I'm trying to resolve.
It's simply having
the
The DASD is so fast any more that we don't think it is worth the time to do
defrags on volumes.
DASD performance is NOT the only reason for defrags, not that it's one to worry
about anymore.
What about files restricted to single volumes (PDS[E])?
Small storage groups?
Volumes with such small
You might want to consider getting somewhat more aggressive with dfHSM
migration. This will free up space, reduce extents required,.
Also consider DVC in the SMS STORCLAS.
The historical pattern of DSN access (in most shops) is write/read once
and fageddaboudit.
HTH,
snip
Well it's not a
Everything is cheap when you can afford it.
On Thu, Mar 4, 2010 at 1:48 PM, Hal Merritt hmerr...@jackhenry.com wrote:
Plus, you are paying quite a performance price with all of that file
shuffling. DASD is cheap.
--
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee,
I'll research DVC. Thanks.
On Thu, Mar 4, 2010 at 1:59 PM, Staller, Allan allan.stal...@kbm1.comwrote:
You might want to consider getting somewhat more aggressive with dfHSM
migration. This will free up space, reduce extents required,.
Also consider DVC in the SMS STORCLAS.
The
On Thu, 4 Mar 2010 10:23:57 -0600, David Cartwright dcartwri...@ymail.com
wrote:
On Thu, 4 Mar 2010 08:21:03 -0600, Mark Zelden mzel...@flash.net wrote:
(with snippage)
Anyway, a null configuration is one where you allocate an empty ACDS and
COMMDS and have an IGDSMSxx member that points to
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL
Sent: Thursday, March 04, 2010 12:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag
The DASD is so fast any more that we don't think it is worth
the time to do defrags
Steve,
That's not exactly correct. It's 16 extents for 59 volumes and then you're
done. John's answer is the solution for your problem. ACC and STOP-X37 users
have known this for 30 years.
I have no idea what reclaiming space in the VTOC is.
Ron
But how does this solve problems for
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace
Sent: Thursday, March 04, 2010 1:00 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag
Everything is cheap when you can afford it.
On Thu, Mar 4, 2010 at 1:48 PM, Hal
In that case, Mark, it appears to me that your storage group must be running
rather full and could probably benefit from adding a few more volumes,
specifically 3390-9 or larger volumes. Or perhaps you should review your
DFHSM ML1/ML2 migration criteria and migrate old datasets to reclaim some
I mentioned PDS type datasets in my original post, but didn't say much else.
We have a separate storage group for them. But we don't create and delete
large numbers of PDSes as a rule, so we can manage their storage by hand.
What about developer libraries?
You don't leave them in their general
Mark,
For most datasets the Dynamic Volume count solves your problem by allowing
the dataset to dynamically extend to additional volumes.
Of course your users could always do something obvious like allocate larger
Primary and Secondary space so they don't need 16 extents...
Ron
-Original
But I don't know an easy, automated, reliable way to get it done. Run DFDSS
defrags hourly, every 8 hours, every day, ... ?
We used to run it frequently, daily, half-daily, and by shift.
But, with a fragmentation index.
The first time was slow, but each subsequent run sped up.
Also, we would
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins
Sent: Thursday, March 04, 2010 1:06 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag
Steve,
That's not exactly correct. It's 16 extents for 59 volumes
and then you're
On the other hand, the suggestion to allow a dataset to grow to multi-volume
sounds like a good idea (as it would eliminate space-related abends), albeit
perhaps just a stop-gap measure.
It's not a stop-gap, imo.
I consider it a best practice, especially in production.
-
Too busy driving to
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL
Sent: Thursday, March 04, 2010 1:10 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag
I mentioned PDS type datasets in my original post, but
didn't say much else. We have
Ted,
DFSMShsm should be set up to migrate/recall these PDS/PDS-E when they exceed
some extent threshold I used to use eight extents. This compresses the
dataset and consolidates all the extents to single, sometimes larger primary
extent.
I used to use the General Pool for all TSO related
I hate defrag. Hate it with a passion. Scheduled defrags usually mean the
Storage Admin needs a little help and guidance...
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
Ted MacNEIL
Sent: Thursday, March 04, 2010 11:13 AM
To:
DFSMShsm should be set up to migrate/recall these PDS/PDS-E when they exceed
some extent threshold I used to use eight extents.
This compresses the
dataset and consolidates all the extents to single, sometimes larger primary
extent.
I used to use the General Pool for all TSO related datasets
I hate defrag. Hate it with a passion. Scheduled defrags usually mean the
Storage Admin needs a little help and guidance...
I disagree.
It could be lack of DASD.
As I've said, use of fragmentation indeces reduces the impact.
After awhile, defrags are in, out, and done.
It's an insurance policy,
On Thu, 4 Mar 2010 13:04:19 -0600, Mark Zelden mzel...@flash.net wrote:
On Thu, 4 Mar 2010 10:23:57 -0600, David Cartwright dcartwri...@ymail.com
wrote:
On Thu, 4 Mar 2010 08:21:03 -0600, Mark Zelden mzel...@flash.net wrote:
(with snippage)
Anyway, a null configuration is one where you
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins
Sent: Thursday, March 04, 2010 1:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag
I hate defrag. Hate it with a passion. Scheduled defrags
usually mean the
Storage
I agree wholeheartedly!
Out of the 78TB I have, I have only one volume that ever needs to be defragged
(every couple months). It's got tens of thousands of tiny datasets being
constantly being created/archived/recalled/deleted.
Ron Hawkins ron.hawkins1...@sbcglobal.net 3/4/2010 2:36 PM
I
David,
I always thought a null configuration was what you got if there was no IGDSMSxx
member, that's what I remember from one-pack systems but I cannot test it now.
I think that is just not running/starting SMS. Is this an option anymore?
Running SMS with a null configuration is running with
I agree wholeheartedly!
I don't. It's a tool. Use it when necessary.
Out of the 78TB I have, I have only one volume that ever needs to be defragged
(every couple months).
You're fortunate.
Not all of us have the luxury.
Don't get me wrong.
Defrag, as evil as it may be, is still a valid tool.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ron Hawkins
Sent: Thursday, March 04, 2010 1:06 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag
Steve,
That's not exactly correct. It's 16 extents for 59 volumes and then
you're
done. John's
Allowing growth to span volumes may be a good thing, but don't forget that that
may fry your backup/recovery/DR strategy.
Many use full volume dump/restore as a foundation. Unless -all- of the volumes
are dumped at a single point of consistency (POC), then you'll have corrupted
datasets. With
If you are allowed (or can) do multi-volume, then yes, you get 16 [max] per
volume for 59 volumes.
As long as the dataset (non-extended) is 64K (binary) or less in tracks.
Whichever limit you reach wins (or loses -- depends on your perspective).
-
Too busy driving to stop for gas!
Easy, use FlashCopy (or equivalent).
Hal Merritt hmerr...@jackhenry.com 3/4/2010 3:39 PM
Allowing growth to span volumes may be a good thing, but don't forget that that
may fry your backup/recovery/DR strategy.
Many use full volume dump/restore as a foundation. Unless -all- of the volumes
No, actually, Flashcopy is still a PIT volume copy unless you are using
consistency groups. True, the window for corruption may be somewhat smaller, it
still exists.
BTDT.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Scott
Hi Mark,
We rarely defrag anything and until recently we had very little DASD. Most of
our batch processes allocate to a single work pool. All allow multi-file
allocations. Every night, a CA-Disk process runs to pick up the previous day's
datasets from the workpool and mov e them to a
Thompson, Steve wrote:
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ron Hawkins
Sent: Thursday, March 04, 2010 1:06 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag
Steve,
That's not exactly correct. It's 16 extents for 59 volumes and
Allowing growth to span volumes may be a good thing, but don't forget that
that may fry your backup/recovery/DR strategy.
Not if you are aware of spanned datasets and do your homework.
We've done it for years.
-
Too busy driving to stop for gas!
True, the window for corruption may be somewhat smaller, it still exists.
So, what you're saying is that you'd better be able to handle the kind of
datasets you're allowing to be allocated.
-
Too busy driving to stop for gas!
Right. Not only be ready, but include extra testing at your next DR exercise
just to be sure.
I suppose there are various ways to deal with the issue, but first step is
awareness. Striping and multi volume extents can make a full volume dump worse
than a waste of time.
-Original
I think I may have finally come upon a valid justification for a separate
UAT, QA LPAR; maybe the only justification.
You can only have one instance of Security, RACF, ACF2, TSS, in an LPAR,
z/OS Domain, at any one time.
Since, for QA testing, the need is to mirror PROD Security so that the
In blu149-w59c200c736c4c1c3a435eba1...@phx.gbl, on 03/01/2010
at 01:47 PM, Dave Salt ds...@hotmail.com said:
With a little extra effort he could support lowercase characters, just as
he could also support TSO commands that won't fit on a single command
line. In other words,
No. You're not
In blu149-w539568df98dc392b6d7170a1...@phx.gbl, on 03/02/2010
at 12:45 AM, Dave Salt ds...@hotmail.com said:
I think we're just using a different interpretation of 'case sensitive'.
Most ISPF panels convert input to uppercase, so dialogs test for
uppercase commands. But if ISPF panels
In f255efe0ecf08c4a9c1db6aff42354170ea81...@ch2wpmail1.na.ds.ussco.com,
on 03/02/2010
at 06:51 AM, Chase, John jch...@ussco.com said:
IIRC, it wasn't called Warp until v4..
For small values of 4. The shrinkwrap sequence ran 2.1, Warp 3, Warp
Connect, Warp 4.
--
Shmuel (Seymour
In listserv%201003011135143435.0...@bama.ua.edu, on 03/01/2010
at 11:35 AM, Paul Gilmartin paulgboul...@aim.com said:
I deem it a design flaw that the case conversion is performed before the
TSO escape is recognized, rather than after.
I would see it as a hideous design decision to make upper
In 4b8d1cbe.4080...@bremultibank.com.pl, on 03/02/2010
at 03:12 PM, R.S. r.skoru...@bremultibank.com.pl said:
However I absolutely don't remember any BLUE screen on OS/2,
Would you settle for a blue box? ;-)
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
Ted
I went three years without running defrag on a development system that
usually ran 3-15% free space. I just got really good at SMS and ACC/SRS and
employed similar rules in production.
We had applications using symbolics to specify small/medium/large/huge for
space in JCL and ACC would
Ted,
Did you miss the word scheduled. Your having a different conversation.
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
Ted MacNEIL
Sent: Thursday, March 04, 2010 12:15 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN]
Did you miss the word scheduled.
No, I didn't.
Your having a different conversation.
What you missed, or so it seems, is frag index.
Besides, I can't do test during non-test times and prod during non-prod times
without scheduling.
What I said was that the index reduces the impact.
I never
On Thu, Mar 4, 2010 at 6:21 PM, George Henke gahe...@gmail.com wrote:
However, it still begs the question, why have LPARs at all, because
separate Security DBs *can* be configured in separate Virtual Machines
Even with VM, there are cases where the complete isolation of LPARs is useful
for
In general, z/OS shops prefer the control offered by LPAR. As a long-time
VMer, I see that as heresy, but I do understand the underlying argument that
says I don't have to administer PR/SM the same way I have to administer z/VM.
And, you have one less skill set requirement!
Give me a
On Thu, Mar 4, 2010 at 8:39 PM, Ted MacNEIL eamacn...@yahoo.ca wrote:
And, you have one less skill set requirement!
Give me a performance anayst, a sysprog, and a hardware guy.
With them I can set up a multiple LPAR environment.
Do it with z/VM in the mix, and I need another SYSPROG.
VM
Then use consistency groups. You don't need them for DB2 though - with
FRBACKUP, and since DB2 is 99% of my data, I'm good. I backup 20TB of
production data every night to tape, no big deal. The point is there are
plenty of tools available - multi-volume datasets are no big deal, you have
Let me get this straight: You think this is a valid argument when applied to
security, but somehow thought that the same argument applied to OS
maintenance/release was somehow refuted?
George Henke gahe...@gmail.com 03/04/10 6:22 PM
I think I may have finally come upon a valid justification
Ted,
No mate, you put your own words in your own mouth.
Ron: I hate scheduled Defrags
Scott: I agree wholeheartedly
Ted: I don't. It's a tool. Use it when necessary.
So you agree with scheduled defrags, but only when necessary.
Ted: (Later) Don't do unnatural acts just
So you agree with scheduled defrags, but only when necessary.
Schedule always.
Defrag when necessary.
In other words, if the frag index doesn't require a defrag, don't do it.
But, let the programme figure it out.
I see no problem with running a defrag every half-hour, as extreme as that may
--
From: Thompson, Steve
Subject: Re: Defrag
AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM,
etc.). If you are allowed (or can) do multi-volume, then yes, you get 16
[max] per volume for 59 volumes.
Reclaiming space in the
I will be out of the office starting 03/04/2010 and will not return until
03/05/2010.
I will be out of the office on Friday, March 5th. I will return on Monday,
March 8th. Thanks.
HCSC Company Disclaimer
The information contained in this communication is confidential, private,
proprietary,
From: Ted MacNEIL eamacn...@yahoo.ca
To: IBM-MAIN@bama.ua.edu
Sent: Thu, March 4, 2010 2:14:52 PM
Subject: Re: Defrag
I agree wholeheartedly!
I don't. It's a tool. Use it when necessary.
Out of the 78TB I have, I have only one volume that ever needs to be
Microsoft: Don't press F1 key in Windows XP
http://www.computerworld.com/s/article/9164038/Microsoft_Don_t_press_F1_key_in_Windows_XP
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
I will be out of the office starting 05/03/2010 and will not return until
16/03/2010.
Please contact mvs_reque...@national.com.au if your request is urgent.
This e-mail is sent by or on behalf of the named sender identified above.
If:
(a) you do not wish to receive any e-mail marketing
Oh dear - I feel a bit guilty just trying to answer the original
question, but anyway here's how we do it.
We use the tools System Automation and MXI in the process, and what we
do is at every JES2 shutdown (i.e. pre-IPL shutdown as far as intent
goes, and our IPLs are monthly), we run an SA REXX
72 matches
Mail list logo
