New applications should exploit storage above the bar as much as
possible, IMHO.
I agree with that point of view; I wish IBM would do as they say!
And what makes you think that they don't, to the extent anyone would care
(i.e., if they use private storage you should not care)? And they can't
- Original Message -
From: John Mattson [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
Sent: Wednesday, July 09, 2008 5:49 PM
Subject: IBM using more below the line storage.
IBM appears to be expanding use of storage below the 16M line,
rather than converting their own
Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Pinnacle
Sent: Friday, July 11, 2008 7:59 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM using more below the line storage.
- Original Message -
From: John Mattson [EMAIL PROTECTED]
Newsgroups
It's been my experience that it's much better to do as they say.
New
applications should exploit storage above the bar as much as
possible,
IMHO.
I agree with that point of view; I wish IBM would do as they say!
-
Too busy driving to stop for gas!
I think that many times at IBM the
Ted MacNEIL [EMAIL PROTECTED] wrote in message
news:715260175-1215667394-cardhu_decombobulator_blackberry.rim.net-5043
[EMAIL PROTECTED]...
Roland, I hate to say this, maybe I'm not clear, but what are you
saying?
our private size on z/OS R9 below is
(MXI VMAP command, IPLINFO from Mark
Ted,
I wrote our private region below the line is about 10M.
Was it to difficult to understand?
Roland
Roland, I hate to say this, maybe I'm not clear, but what are you saying?
--
For IBM-MAIN subscribe / signoff / archive
Roland Schiradin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Ted,
I wrote our private region below the line is about 10M.
Was it to difficult to understand?
Roland
Well, that text did not make the newsgroup.
What I read is:
Quote:
John,
our private size on z/OS
ISP.SISPLPA for instance can be in link list and has some big modules
that are still RM 24.
I use the following usermod:
++USERMOD(name)
/* MOVE LOAD MODULES FROM SISPLPA TO SISPLOAD */
.
In a message dated 7/9/2008 4:50:06 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Looks like a bit of do as I say, not as I do.
It's been my experience that it's much better to do as they say. New
applications should exploit storage above the bar as much as possible, IMHO.
Knutson, Sam wrote:
If your below the line private area decreased it I will step out on a
limb and say no one is monitoring and managing it. We have been able to
grow PVT from a standard 9M to 10M and EPVT as well in the last few
years. IBM is doing good work in the area of Virtual Storage
:[EMAIL PROTECTED] On
Behalf Of Roland Schiradin
Sent: Thursday, July 10, 2008 1:20 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM using more below the line storage.
John,
our private size on z/OS R9 below is
(MXI VMAP command, IPLINFO from Mark Zelden provide the same info)
Area Start
Knutson, Sam wrote:
If your below the line private area decreased it I will step out on a
limb and say no one is monitoring and managing it. We have been able to
grow PVT from a standard 9M to 10M and EPVT as well in the last few
years. IBM is doing good work in the area of Virtual Storage
It's been my experience that it's much better to do as they say. New
applications should exploit storage above the bar as much as possible, IMHO.
I agree with that point of view; I wish IBM would do as they say!
-
Too busy driving to stop for gas!
years. IBM is doing good work in the area of Virtual Storage Constraint
Relief (VSCR).
I would agree that this is an installation problem.
I disagree to the extent that IBM should not be putting new code below the line.
-
Too busy driving to stop for gas!
I haven't seen any evidence in this thread that leads me to believe they have
put any new code below the line.
Ted MacNEIL [EMAIL PROTECTED] 7/10/2008 12:38 PM
I disagree to the extent that IBM should not be putting new code below the line.
-
Too busy driving to stop for gas!
Note that my
I haven't seen any evidence in this thread that leads me to believe they have
put any new code below the line.
Ted MacNEIL [EMAIL PROTECTED] 7/10/2008 12:38 PM
I disagree to the extent that IBM should not be putting new code below the
line.
The very first post was on that very topic.
And, so
On Thu, 10 Jul 2008 17:19:46 +, Ted MacNEIL wrote:
I haven't seen any evidence in this thread that leads me to believe they
have put any new code below the line.
Ted MacNEIL [EMAIL PROTECTED] 7/10/2008 12:38 PM
I disagree to the extent that IBM should not be putting new code below
the
Neither qualify as evidence. A statement in an ETR from the CICS group is
hardly proof that any new code resides below the line.
The OP needs to look very carefully at his LPA list and other system parameters
to determine what caused the change. It may be as simple as having the FLMMOVE
Tom Marchant wrote:
I don't think anyone mentioned yet to check the location of SWA and the UCBs.
UCBs yes. SWA no. SWA is private area ... not common.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL
UCBs yes. SWA no. SWA is private area ... not common.
Hopefully, if they were above the line, they'd stay there and not be regressed
just because they're going to a new release.
-
Too busy driving to stop for gas!
--
For
I found this hard to believe, so I checked with the person responsible
for monitoring virtual storage constraints, who happens to be in my
department and whose office is two from mine. While he does not have
numbers from as long ago as OS/390 R10 (and I don't, either), we would
both be
IBM appears to be expanding use of storage below the 16M line,
rather than converting their own code to 31-bit addressability. Here is
the reply I received when I ETR asked CICS why I could no longer get a
certain DSALIM value in TS22 after going to zos 1.08.
There is
IBM appears to be expanding use of storage below the 16M line,
rather than converting their own code to 31-bit addressability. Here is
the reply I received when I ETR asked CICS why I could no longer get a
certain DSALIM value in TS22 after going to zos 1.08.
There is Common
John Mattson wrote:
IBM appears to be expanding use of storage below the 16M line,
rather than converting their own code to 31-bit addressability. Here is
the reply I received when I ETR asked CICS why I could no longer get a
certain DSALIM value in TS22 after going to zos 1.08.
It appears to me that IBM is assuming that the below the line
storage is now free and available for their use, and rather than going to
31-bit addressing themselves, they are expanding use of 24-bit.
Interesting. Looks like a bit of do as I say, not as I do.
When IBM first came out with
Re: Rejected posting to IBM-MAIN@BAMA.UA.EDU
I sent this only once; I never saw the posting, so I'm re-sending.
It appears to me that IBM is assuming that the below the line
storage is now free and available for their use, and rather than going to
31-bit addressing themselves, they are
using more below the line storage.
IBM appears to be expanding use of storage below the 16M line,
rather than converting their own code to 31-bit addressability. Here is
the reply I received when I ETR asked CICS why I could no longer get a
certain DSALIM value in TS22 after going to zos
On 9 Jul 2008 14:49:57 -0700, in bit.listserv.ibm-main you wrote:
IBM appears to be expanding use of storage below the 16M line,
rather than converting their own code to 31-bit addressability. Here is
the reply I received when I ETR asked CICS why I could no longer get a
certain DSALIM
??
The original poster said In OS/390 2.10 the amount of Common Storage needed by
the system was
smaller than is required by z/os 1.8, to me implying that there was a
migration over 8 MVS releases!!! In addition, a 10M private region is HUGE!
If my assumption on migrating from 2.10 to
The original poster said In OS/390 2.10 the amount of Common Storage needed
by the system was
smaller than is required by z/os 1.8, to me implying that there was a
migration over 8 MVS releases!!!
I really don't understand your response!
Yes, so there was a migration -- so what?
The below
John,
our private size on z/OS R9 below is
(MXI VMAP command, IPLINFO from Mark Zelden provide the same info)
Area Start EndSize(K)
Extended Private 2DF0 7FFF 1344512K
Extended CSA 0C4F6000 2DEF 550952K
Extended MLPA 0C1F8000 0C4F5FFF
Roland, I hate to say this, maybe I'm not clear, but what are you saying?
our private size on z/OS R9 below is
(MXI VMAP command, IPLINFO from Mark Zelden provide the same info)
-
Too busy driving to stop for gas!
--
For
32 matches
Mail list logo
