James,
As a generalization, queuing for a volume from the same LPAR will increase
as you increase the time that the volume is busy. If you have 9x3390-3 that
at some point in time are 5% busy then you will probably see very little
IOSQ time. Fold them into 1x3390-27 and it will be 45% busy and
All
Thanks for tips on handling xmit within xmit. I missed that.
I did get zip of the sources and here is what I did as test:
1. Unzip
2. Rename all maclib to *.MAC
3. Rename all srclib to *.MLC
4. Run z390 command: ASM SRCLIB\HTTPSUB SYSMAC(MACLIB+MAC)
SYSCPY(MACLIB)
I agree with the IBM presenter. Cache will not make a difference unless
something changes the hit ratio. You really need one of the three varieties of
PAV if you are going to fold volumes at this ratio in an unplanned
manner.
Ron, the point is not whether you need PAV or not.
The IBM'r stated
Hi,
I need some suggestions, or tools, to clear some areas in CSA/ECSA and so
to avoid unplanned IPLs.
Can you help me ?
TIA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED]
Sergio Marques wrote:
Hi,
I need some suggestions, or tools, to clear some areas in CSA/ECSA and so
to avoid unplanned IPLs.
Can you help me ?
TIA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
What level of z/OS are you? Depending on the release, you can specify
DSNTYPE=LARGE if you have set your SMS to accept it.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
esmie moo
Sent: Wednesday, November 05, 2008 8:10 AM
To:
Frank,
We are at RELEASE z/OS 01.09.00. You suggest that I use DSNTYPE=LARGE. I
assume you mean to create a DATACLAS LARGE?
--- On Thu, 11/6/08, Martinez, Frank J [EMAIL PROTECTED] wrote:
From: Martinez, Frank J [EMAIL PROTECTED]
Subject: Re: Problem Allocating DSN - 5000 CYl
To:
Hi.
We have disk 2105 - F20 with 5,2 tera of storage and 4 Giga cache size by
cluster
we want to come to 8 Giga in every cluster but the increase of Cache
Storage is very expensive...
Now, my chief says to me ... it improves the performance of the machine if we
have the cache doubles ..?
Sergio,
Most z/OS monitor products (Omegamon, TMON, MXI G2 etc) include a facility to
release common storage - however unless you have intimate knowledge of the
storage area that you wish to free an unplanned IPL is a very possible outcome
of your release attempt - even if the system reports
On Wed, 5 Nov 2008 08:21:17 -0500, Mark Jacobs wrote:
Sergio Marques wrote:
Hi,
I need some suggestions, or tools, to clear some areas in CSA/ECSA and so
to avoid unplanned IPLs.
Can you help me ?
TIA
There is no really safe way to release allocated CSA/ECSA storage. If
you are sure that it
Our CE wants us to upgrade the MCL level on our z9BC from 63 to 67. We are
running z/OS 1.8 on 3 LPARs. Any concerns that I should be aware of? Has
anybody had any problems with driver 67 on a z9BC?
--
John
--
For IBM-MAIN
Good Morning Gentle Readers,
I am having a tough time trying to allocate a sequential dsn of 5,000 cyls.
There are 3 mod-3 volumes empty. I checked the storage group and all is well.
If I allocate the dsn of 3,000 cyls it works. Do I need to define the dsn as
XTDENDED? I tried several
No, I meant DSNTYPE=LARGE. You also need to read up on the option
BLOCKTOKENSIZE in IGDSMSxx. It is needed if you are going to use the DSNTYPE
parameter when allocating a new large dataset.
This new function started in the 1.7 release.
-Original Message-
From: IBM Mainframe
John,
We had to upgrade to MCL 67 to enable STP on our z9-BC a few months ago.
The only 'issue' I can report is that we were 'forced' to do a POR by
our SE. However, everything worked out and there were no issues - other
than an extended outage.
Regards,
Jasbir Chauhan
-Original
Thx Ted. How does that information change my answer?
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Wednesday, November 05, 2008 2:44 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: [IBM-MAIN] Performance Question - Dynamic
esmie moo wrote:
Frank,
We are at RELEASE z/OS 01.09.00. You suggest that I use DSNTYPE=LARGE. I
assume you mean to create a DATACLAS LARGE?
You can either create a new dataclass with DSNTYPE=LARGE included or
just add the parameter to to DD statement.
--- On Thu, 11/6/08,
Alex, As with others on this list, I am confused and do not know what you
really want.
CBRUXxxx exits are called by OAM for specific events for IBM system managed
tapes. The exits play no part in a VSM environment - so as you switch to
VSM and fewer VTS events happen the exits will be called
It seems that several people have downloaded this file and started work on it,
so I thought it would be a good idea to move it off IBM-MAIN. I have
therefore started a Yahoo Group for interested people to exchange their
experiences. Go to
http://groups.yahoo.com/group/CBT795
and join up.
Thx Ted. How does that information change my answer?
You said some sort ogf PAV.
The OP was asking about *HYPER* PAV.
You did not answer his question.
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff /
Adding cache to an existing storage processor without an identified performance
problem you will solve is going to be hard to justify and amounts to brain
surgery on your existing box that has some amount of risk.
Tools http://www.intellimagic.net like RMF MAGIC and DISK MAGIC can actually
show
Ted,
Don't bust my gonads Ted! Your original response was a timeline, not an
answer. Why do you find it so hard to accept another opinion on a topic?
I agree with the IBM presenter - that is the fact of the matter. I think
HyperPAV is the best, most dynamic of the three methods that should be
Sam,
I could say replace a 2105 with a 9980 (-2 generation) and get better
performance, but that would a bit too naughty on the list :-)
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Knutson, Sam
Sent: Wednesday, November 05, 2008
Alvaro Quintupray B. wrote:
Hi.
We have disk 2105 - F20 with 5,2 tera of storage and 4 Giga cache size by
cluster
we want to come to 8 Giga in every cluster but the increase of Cache
Storage is very expensive...
Now, my chief says to me ... it improves the performance of the machine if
Sigh! - and then I go and forget to change the TO address. Apologies for
those upset with blatant marketing on the list.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the
You're forgiven, Ron... :-)
Ron Hawkins wrote:
Sigh! - and then I go and forget to change the TO address. Apologies for
those upset with blatant marketing on the list.
--
For IBM-MAIN subscribe / signoff / archive
Don't bust my gonads Ted!
I'm not busting anything.
You didn't answer the question.
Your original response was a timeline, not an answer.
My resonse was intended to state that hyper PAVs were not needed. Since it
wasn't a problem when -27's first came out, why is it a problem now?
Why do you
We are at RELEASE z/OS 01.09.00. You suggest that I use DSNTYPE=LARGE. I
assume you mean to create a DATACLAS LARGE?
DSNTYPE=LARGE is the JCL parameter to support extended PS files.
-
Too busy driving to stop for gas!
--
For
Most z/OS monitor products (Omegamon, TMON, MXI G2 etc) include a facility to
release common storage - however unless you have intimate knowledge of the
storage area that you wish to free an unplanned IPL is a very possible outcome
of your release attempt - even if the system reports the
We're not using DSNTYPE=LARGE yet but IIRC, it allows you to allocate a
dataset larger than 65535 tracks on a single volume.
I thought it was stated earlier that the requestor was trying to allocate
a 5000 cylinder dataset and had 3 mod-3 devices - if I've remembered that
details correctly,
Esmie,
Since your are attempting to allocate a multi-volume SAS dataset, please
check the SAS - documentation. In there, you'll find JCL samples and a
description on how to do it.
Regards,
Ulrich Krueger
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
This exchange reminds me of some of the exchanges we used to have in the past
between people I won't mention (Partly because I forgot their names). Some of
the exchanges got heated. I know when I get comments I don't like, instead of
firing off a nasty reply (Ted - this wasn't nasty - I'm not
Since your are attempting to allocate a multi-volume SAS dataset, please
check the SAS - documentation. In there, you'll find JCL samples and a
description on how to do it.
I missed the part about this being a SAS dataset!?! If this is true,
nothing I said earlier will work. Our multi-volume
snip
I could say replace a 2105 with a 9980 (-2 generation) and get better
Performance.
/snip
Ron, you're forgiven. You contributions to this list far outweigh this
small slip.
I concur with you analysis however, why spend money on old technology.
If budgetary considerations allow, by all
Is anyone on the list using a phased maintenance scheme? By this I mean
IPL’ing one LPAR in a Sysplex with a new maintenance level and letting it run
for a week or so before applying the change to the rest of the systems?
I'm interested in hearing experiences (good or bad).
Thanks.
On Wed, 5 Nov 2008 16:33:38 +, Ted MacNEIL wrote:
Your original response was a timeline, not an answer.
My resonse was intended to state that hyper PAVs were not needed. Since it
wasn't a problem when -27's first came out, why is it a problem now?
That's not a logical response. HyperPAV
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Darth Keller
Sent: Wednesday, November 05, 2008 9:57 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Problem Allocating DSN - 5000 CYl
Since your are attempting to allocate a multi-volume
Robert Crawford wrote:
Is anyone on the list using a phased maintenance scheme? By this I mean
IPL’ing one LPAR in a Sysplex with a new maintenance level and letting it run
for a week or so before applying the change to the rest of the systems?
I'm interested in hearing experiences (good
I do the phased/rolling IPL for my maintenance implementation..
I start with my SAND-BOX system where it cooks for month (minimum), then
it moves to my application development system (again for a month) and then
into production systems.
If you need more specifics you can contact me off-list.
At one site we generally IPL all six LPARS to the new SYSRES in the same
outage. 4 can be shut down simultaneously and the other two we cycle one
then the other so there isn't a total outage.
At the other site we IPL three LPARS with the new SYSRES and wait a week
or two to IPL the other five.
We're not using DSNTYPE=LARGE yet but IIRC, it allows you to allocate a
dataset larger than 65535 tracks on a single volume.
I seem to recall that the maximum size of a dataset is 65535, regardless of
how many volumes it resides on.
I don't remember if you have to do anything with SMS to
Ted, sometimes I think your posts are a little too picky. Unfortuneatly, Ron
always responds to your posts as in this thread.
To the list:
I'm sorry.
To Ron:
I neither accepted, nor rejected, your opinion regarding HYPER PAV's, since you
didn't express one in your original response.
You only
I missed the part about this being a SAS dataset!?! If this is true, nothing
I said earlier will work. Our multi-volume SAS datasets are all
outside of SMS due to their special requirements.
If that's so, then you are stuck with thhe 65535 track limit.
I'm not sure if SAS supports LARGE
I concur with you analysis however, why spend money on old technology.
If budgetary considerations allow, by all means spend the money on newer
technology from (insert favorite vendor here).
I tend to agree, but I have a question.
What if the older technology is still under waranty/lease?
Yes it did, Ted. And you quoted it in your first reply to Ron.
This is the last I'm going to say on this.
But, Tom show me where that is, and I'll appologise.
The response I read stated that one of three types of PAV's was needed.
Nowhere, do I recall any statement on hyper PAVs in the response.
then it moves to my application development system (again for a month) and
then into production systems.
I guess it depends on your mainenance philosphy.
Baking maintenance for a month can cause issues of currency of software.
At the last shop I worked at, I got them down to two weeks per
On Wed, 5 Nov 2008 10:58:27 -0600, Robert Crawford
[EMAIL PROTECTED] wrote:
Is anyone on the list using a phased maintenance scheme? By this I mean
IPLing one LPAR in a Sysplex with a new maintenance level and letting it run
for a week or so before applying the change to the rest of the
Isn't that what all (sane) shops do? That is one of the main benefits of a
parallel sysplex environment (rolling IPLs).
I agree.
I think the issue is more of the time between 'bake' (test) and 'serve'
(production).
-
Too busy driving to stop for gas!
On Wed, 5 Nov 2008 11:00:09 -0600, George P. [EMAIL PROTECTED] wrote:
Hi. I am looking for some guidance and assistance with the following. We
wrote a HASX04 when under zOS 1.5. The intent of the exit was to scan JCL,
etc. and perform a security call based upon racroute.
We have migrated
I seem to recall that the maximum size of a dataset is 65535,
regardless of how many volumes it resides on.
Limit for nonvsam, non-extended datasets is 65535 tracks per volume up to
59 volumes.
Regards,
John
--
For IBM-MAIN
JES2 exit processing for exit 4 (and 2 and 3) has been split into 2
parts, one for jobs submitted from BSC and SNA devices (4) and one for
jobs submitted via TCPIP readers and internal readers (54).
So.
1. Yes. If you need an exit 4 you will also need an exit 54. Note also
that the entry
We phase in maintenance on all of our sysplexes (from 2 systems to 10
systems). We try not to let the lag be for too long, but we haven't
really seen any issues with this method.
Jon
Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683
-Original Message-
From: IBM Mainframe Discussion
Limit for nonvsam, non-extended datasets is 65535 tracks per volume up to 59
volumes.
Okay.
I thought there was a control block limitation.
I've never played with non-vsam files that large.
I stand (er, sit) corrected.
-
Too busy driving to stop for gas!
We've ALWAYS done it that way. What's on your mind ??
Robert Crawford wrote:
Is anyone on the list using a phased maintenance scheme? By this I mean
IPL’ing one LPAR in a Sysplex with a new maintenance level and letting it run
for a week or so before applying the change to the rest of the
In a message dated 11/5/2008 11:36:58 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Since, I didn't keep any of this thread, I am going by memory.
I think that's why God invented the archives. Check the archives for what
each of you two said. Copy and paste exact quotes of
I think that's why God invented the archives. Check the archives for what
each of you two said. Copy and paste exact quotes of one another. Then
apologize to each other, or else continue to carry on your feud, PRIVATELY.
Maybe I didn't read the answer correctly, but there's nothing
FYI - starting with SAS Version 8, there are no special requirements in an
SMS environment, as was the case with SAS V6 involving pre-allocating
multi-volume datasets.
I support several very large MICS and MXG SAS environments, all of which
play quite nicely with DFSMS. Also, if you still have
I think that's why God invented the archives.
For some reason, I'm not seeing Ron's posts in the archives,
not in Google Groups version of bit.listserv.ibm-main anyway.
Date: Wed, 5 Nov 2008 14:51:02 -0500
From: [EMAIL PROTECTED]
Subject: Re: Performance Question - Dynamic PAV
To:
In [EMAIL PROTECTED],
on 11/04/2008
at 12:02 PM, Hunkeler Peter (KIUK 3)
[EMAIL PROTECTED] said:
Still not sure I understand. Anyway, maybe you need the INTERPRET
instruction:
No, he just needs to quote his strings.
interpret X = arg(1)
You don't need interpret; value() can set as well as
In [EMAIL PROTECTED], on
11/04/2008
at 11:40 AM, Itschak Mugzach [EMAIL PROTECTED] said:
Look at this:
A='**'
Say Value(A)
REXX is not CLIST. An unquoted token that is not a keyword or lite4ral is
treated as a variable name. If you want to look up the value of A, use
value('A'); the code you
Hi Bill,
I can confirm that the 74.7 record will indeed report data in mixed
environments. Activity as well as buffer overruns and errors for all ports on
the director are reported. Similarly, if your Disk Subsystem supports the
records, the 74.5 and 74.8 RAID Rank and Link statistics can
SyzSpool can attach multiple sub-tasks, and can accept as many files
simultaneously as the JES SAPI Interface can send. Technically it only looks
simultaneous because there are multiple sub-tasks.
We don't use USS services at creation time, not because we aren't aware of
them, but because the
Short answer:
Yes, it needs to be Extended Format... which has a pre-req of SMS-Managed.
As Ted mentioned in one of the replies, a non-EF dataset does indeed have a
limit of 65k tracks.
Best regards,
John Baker
--
For
Ted,
The first six words of the 2nd paragraph of my 1st response to James on this
thread:
I agree with the IBM presenter.
The first six quoted words of your response to me:
I agree with the IBM presenter.
Is there another way to say it?
Ron
Fine. You've now stated that.
Hi Kevin,
WLM is indeed a complex beast. I will not pretend to be able to completely
answer all of your questions here, as there are a number of variables involved,
but I will attempt to provide some insight.
Firstly, there are two algorithms that WLM uses to decide on the assignment
of
We see this 'knee of the curve' issue in FICON environments all the time.
I would investigate the level of concurrency on the channels paths during this
period; perhaps even the overall Disk Subsystem throughput. FICON
elongation is also known as Connect elongation. Bear in mind you need to
On Wed, 5 Nov 2008 23:14:18 -0600, Brian Westerman wrote:
SyzSpool can attach multiple sub-tasks, and can accept as many files
simultaneously as the JES SAPI Interface can send. Technically it only looks
simultaneous because there are multiple sub-tasks.
We don't use USS services at creation
I heartily endorse this methodology (a.ka. rolling maintenance while
delivering continuous or near-continuous service).
I'm still trying to teach a fair number of Japanese customers about the
concept. It's not universally understood yet (in most countries), and it's
a great topic to raise here in
67 matches
Mail list logo
