Re: IRA400E

2010-10-28 Thread Bruce Hewson
Hi Sharon,

seem similar with multiple concurrent copy sessionswhen the quantity of 
disk updates exceeded the rate at which data was being written to tape

flow control problem...


you need to confirm that your data paths out of your SDM lpar are sufficient 
to contain the volume of data arriving!


Regards
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2010-10-28 Thread Paolo Cacciari
Sharon,

in my opinion, this is a "too much buffer usage" symtom for your XRC 
complex.

The total amount of fixed buffers for your four SDM sessions is very close
(or maybe exceeds) the amount of REAL memory assigned to SDM LPAR.

This problem maybe originated by many sources:

- spike on writes on your primary dasd subsystems; 
- performance problem on your journal dasd subsystem;
- performance problem on your secondary dasd subsystem;
- too much fixed buffers for your LPAR real storage amount.

If you have XRC/PM active, you can see what happened looking at history 
data.

Anyway, you can get a regular look to your SDM environment, using XRC 
commands
to monitor delays.

Hope this helps.

Ciao

Paolo Cacciari - IBM Italy BCRS datacenter

-

Sharon wrote.

Has anyone seen this on your SDM (SYSTEM DATA MOVER) lpars?

IRA400E 04,PAGEABLE STORAGE SHORTAGE 
*IRA404I ANTAS001 ASID 0131 OWNS 386726 PAGES, 326911 
FIXED, 
 158567 FIXED IN SHORTAGE AREA 
*IRA404I ANTAS003 ASID 0140 OWNS 388012 PAGES, 311695 
FIXED, 
 114506 FIXED IN SHORTAGE AREA 
*IRA404I ANTAS004 ASID 013E OWNS 382314 PAGES, 340669 
FIXED, 
 114061 FIXED IN SHORTAGE AREA 
*IRA404I ANTAS002 ASID 0024 OWNS 387917 PAGES, 340053 
FIXED, 
 002642 FIXED IN SHORTAGE AREA 
*IRA404I *MASTER* ASID 0001 OWNS 006377 PAGES, 003666 
FIXED, 
 000388 FIXED IN SHORTAGE AREA  

 
 
 

IBM Italia S.p.A.
Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI)
Cap. Soc. euro 384.506.359,00
C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153
Società soggetta all?attività di direzione e coordinamento di 
International Business Machines Corporation

(Salvo che sia diversamente indicato sopra / Unless stated otherwise 
above)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2010-10-27 Thread Bernard Coeytaux
There is a modify command for ANTMAIN which handles cache for DFDSS 
ConcurrentCopy to limit the storage used regarding the aux storage available.
Search with keywoard CC in the sms booksheleves.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2010-10-27 Thread Mike Schwab
http://publib.boulder.ibm.com/infocenter/zos/v1r10/index.jsp?topic=/com.ibm.zos.r10.antg000/sdm.htm
Suggests it is part of eXtended Remote Copy (XRC).  You might look at
I/O rates, a cable might have been cut and I/O stacked up on your
primary.  Do you route your connections via different routes.  A drive
failure might be causing a raid rebuild of the failed disk and slowing
writes.

On Wed, Oct 27, 2010 at 5:52 PM, Ted MacNEIL  wrote:
>>Users (or jobs) ANTAS001, ANTAS003, ANTAS004, ANTAS002 was using a
> large amount of memory at the time the message was generated.
>>Review to see what programs they were running.
>
> These are part of z/OS.
> Along with ANTMAIN.
> I forget exactly what they do, but I believe they have something to do with 
> supportin the IOS.
>
> -
> I'm a SuperHero with neither powers, nor motivation!
> Kimota!
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2010-10-27 Thread Ted MacNEIL
>Users (or jobs) ANTAS001, ANTAS003, ANTAS004, ANTAS002 was using a
large amount of memory at the time the message was generated.
>Review to see what programs they were running.

These are part of z/OS.
Along with ANTMAIN.
I forget exactly what they do, but I believe they have something to do with 
supportin the IOS.

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2010-10-27 Thread Ed Finnell
 
In a message dated 10/27/2010 1:49:12 P.M. Central Daylight Time,  
mike.a.sch...@gmail.com writes:

large amount of memory at the time the message was generated.   Review
to see what programs they were running.

>>
pV=nRT ? Gas law. My guess would be too many Requests, pipe/path  is 
clogged, receiver is bogged down with multiple requests. Tuning  opportunity, 
maybe service...open a  PMR 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2010-10-27 Thread Mike Schwab
On Wed, Oct 27, 2010 at 1:08 PM, Sharon Lopez  wrote:
> Has anyone seen this on your SDM (SYSTEM DATA MOVER) lpars?
>
> IRA400E 04,PAGEABLE STORAGE SHORTAGE
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2m9a0/17.29?ACTION=MATCHES&REQUEST=IRA400E&TYPE=FUZZY&SHELF=EZ2MZ920.bks&DT=20090604031249&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
04
Pageable frames between 16 megabytes and 2 gigabytes shortage
(Less than 2GB of real storage frames can be swapped out if needed.)

> *IRA404I ANTAS001 ASID 0131 OWNS 386726 PAGES, 326911
> FIXED,
>  158567 FIXED IN SHORTAGE AREA
> *IRA404I ANTAS003 ASID 0140 OWNS 388012 PAGES, 311695
> FIXED,
>  114506 FIXED IN SHORTAGE AREA
> *IRA404I ANTAS004 ASID 013E OWNS 382314 PAGES, 340669
> FIXED,
>  114061 FIXED IN SHORTAGE AREA
> *IRA404I ANTAS002 ASID 0024 OWNS 387917 PAGES, 340053
> FIXED,
>  002642 FIXED IN SHORTAGE AREA
> *IRA404I *MASTER* ASID 0001 OWNS 006377 PAGES, 003666
> FIXED,
>  000388 FIXED IN SHORTAGE AREA
>
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2m9a0/17.33?ACTION=MATCHES&REQUEST=IRA400E&TYPE=FUZZY&SHELF=EZ2MZ920.bks&DT=20090604031249&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

Users (or jobs) ANTAS001, ANTAS003, ANTAS004, ANTAS002 was using a
large amount of memory at the time the message was generated.  Review
to see what programs they were running.

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


IRA400E

2010-10-27 Thread Sharon Lopez
Has anyone seen this on your SDM (SYSTEM DATA MOVER) lpars?

IRA400E 04,PAGEABLE STORAGE SHORTAGE   
*IRA404I ANTAS001 ASID 0131 OWNS 386726 PAGES, 326911 
FIXED,
 158567 FIXED IN SHORTAGE AREA  
*IRA404I ANTAS003 ASID 0140 OWNS 388012 PAGES, 311695 
FIXED,
 114506 FIXED IN SHORTAGE AREA  
*IRA404I ANTAS004 ASID 013E OWNS 382314 PAGES, 340669 
FIXED,
 114061 FIXED IN SHORTAGE AREA  
*IRA404I ANTAS002 ASID 0024 OWNS 387917 PAGES, 340053 
FIXED,
 002642 FIXED IN SHORTAGE AREA  
*IRA404I *MASTER* ASID 0001 OWNS 006377 PAGES, 003666 
FIXED,
 000388 FIXED IN SHORTAGE AREA  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-12 Thread Steve Comstock

Richard Pinion wrote:

Wait a minute, I thought the State of Colorado doesn't have mainframes anymore!



No. The new CIO of the Colorado Revenue Department
was just quoted as saying "No one uses mainframes
anymore". They do, but this was his way of saying
he was amazed to find it out.

Kind regards,

-Steve Comstock

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-12 Thread Richard Pinion
Wait a minute, I thought the State of Colorado doesn't have mainframes anymore!

>>> [EMAIL PROTECTED] 4/12/2006 12:24:35 PM >>>
I had the same problem at this site a month ago.  My Low and OK
thresholds for frame stealing were already set at 4000,4500.  I doubted
that adding a few hundred more to the OK threshold would make a
difference.
What I found was that all of the batch jobs using up memory are running
SyncSort's bettergener and each was getting 4mb of fixed storage.  I
checked SyncSort mincore and it was setup for 4mb.  Mincore was reduced
to 320K and the problem has gone away.   So far I have not seen any
repercussions from reducing mincore for SyncSort.

Leif Rundberget
MVS, VM, Linux Operating Systems Support
Mainframe Network Administrator
State of Colorado
Department of Personnel & Administration (DPA)
Division of Information Technologies (DoIT)
690 Kipling Street,  Room 2060
Lakewood,  CO  80215-5844
Phone:  (303) 239-4357

E-mail correspondence to and from this address may be subject to the Colorado 
Public Records law. It may be subject to monitoring
 and disclosed to third parties, including law enforcement personnel by an 
authorized state official.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-12 Thread Leif Rundberget

I had the same problem at this site a month ago.  My Low and OK
thresholds for frame stealing were already set at 4000,4500.  I doubted
that adding a few hundred more to the OK threshold would make a
difference.
What I found was that all of the batch jobs using up memory are running
SyncSort's bettergener and each was getting 4mb of fixed storage.  I
checked SyncSort mincore and it was setup for 4mb.  Mincore was reduced
to 320K and the problem has gone away.   So far I have not seen any
repercussions from reducing mincore for SyncSort.

Leif Rundberget
MVS, VM, Linux Operating Systems Support
Mainframe Network Administrator
State of Colorado
Department of Personnel & Administration (DPA)
Division of Information Technologies (DoIT)
690 Kipling Street,  Room 2060
Lakewood,  CO  80215-5844
Phone:  (303) 239-4357

E-mail correspondence to and from this address may be subject to the Colorado 
Public Records law. It may be subject to monitoring
and disclosed to third parties, including law enforcement personnel by an 
authorized state official.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-11 Thread J Ellis
Hmm, lost my reply somehow. Anyway, check out your ieaopt/mccafcth setings.
I had to increase mine on a ~2.5gb system to avoid depleted afc and
pageable storage shortages. system would get low and something like a sort
would hit and system couldn't keep up. check out the mxg site or ibmlink
for more details. I ended up setting mine to (4000,5000), eventually added
another 2gb.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-11 Thread J Ellis
On Sat, 8 Apr 2006 08:27:11 +1000, Shane <[EMAIL PROTECTED]> wrote:

>On Fri, 2006-04-07 at 13:09 -0400, Knutson, Sam wrote:
>> We are talking about a shortage of PAGEABLE storage not paged storage.
>> Nothing Mark can do with his PAGE data sets is going to help.   Every
>> time we have been bitten by this it was a SORT product being too
>> aggressive in using FIXED frames.
>
>C'mon Sam, ease up on Steve - he ambles away from his comfortable chair
>and trout fishing to help out and you beat up on him !!!
>IRA200, IRA400 Phhhttt !!!
>
>Anyway, to the point. Hard to monitor in advance for this sort of thing,
>need to use the evidence you have to amend your processing.
>Messages tell you who was swapped - check the SADump you took prior to
>IPL to see what was actually happening at the time.
>Maybe you need to control region sizes allowed, maybe sort parms, maybe
>job schedules.
>
>Shane ...
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

Have you adjusted your ieaopt/mccafcth ? look on the mxg site or IBM link
for more detailed discussion. I ended up changing a ~2.5gb real system to a
higher value to keep the afc from bottoming out serveral times a day.
eventually added another 2gb real.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-07 Thread Steve Samson
Sorry folks. I must have just gotten up from a nap when I read the 
original message.


Shane, no trout fishing here, just bridge and taxes.

Cheers,

Steve

Knutson, Sam wrote:

We are talking about a shortage of PAGEABLE storage not paged storage.
Nothing Mark can do with his PAGE data sets is going to help.   Every
time we have been bitten by this it was a SORT product being too
aggressive in using FIXED frames.

Best Regards, 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-07 Thread Shane
On Fri, 2006-04-07 at 13:09 -0400, Knutson, Sam wrote:
> We are talking about a shortage of PAGEABLE storage not paged storage.
> Nothing Mark can do with his PAGE data sets is going to help.   Every
> time we have been bitten by this it was a SORT product being too
> aggressive in using FIXED frames.

C'mon Sam, ease up on Steve - he ambles away from his comfortable chair
and trout fishing to help out and you beat up on him !!!
IRA200, IRA400 Phhhttt !!!

Anyway, to the point. Hard to monitor in advance for this sort of thing,
need to use the evidence you have to amend your processing.
Messages tell you who was swapped - check the SADump you took prior to
IPL to see what was actually happening at the time.
Maybe you need to control region sizes allowed, maybe sort parms, maybe
job schedules.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-07 Thread Knutson, Sam
We are talking about a shortage of PAGEABLE storage not paged storage.
Nothing Mark can do with his PAGE data sets is going to help.   Every
time we have been bitten by this it was a SORT product being too
aggressive in using FIXED frames.

Best Regards, 

Sam Knutson, GEICO 
Performance and Availability Management 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574 

Don't hit the keys so hard, it hurts.

IRA400E return-code,PAGEABLE STORAGE SHORTAGE

 

Explanation:  The system detected a shortage of pageable central storage

frames.

 

In the message text:

 

return-code A code indicating the most severe shortage detected. The

  higher the return code, the more severe the shortage. The

  possible values for return-code are as follows:

 

  04Pageable frames between 16 megabytes and 2 gigabytes

shortage

 

  03Pageable frames below 16 megabytes shortage

 

  02Pageable frames in real storage shortage

 

  01Pageable to auxiliary (PTA) frames (DREF + fixed

pages) in processor storage.

 

System Action:  The system rejects LOGON, MOUNT, and START commands. and

keeps initiators selecting new jobs from running until the shortage is

relieved. The system swaps out the current in-storage address space with

the greatest number of fixed frames. The address space remains swapped
out
until the shortage is relieved.

 

The system writes message IRA403E to identify the heavy fixed page user.

 

System Programmer Response:  Examine users of V=R storage and other jobs

that have heavy page fix requirements for possible looping or for

extraordinary page fix needs. Correct any errors.

 

Source: System resources manager (SRM)

 

Detecting Module:  IRARMST2   
   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Steve Samson
Sent: Friday, April 07, 2006 12:53 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IRA400E

Mark,

Unless you had a uniquely ill-behaved program gobbling paging space, the
cause is that you don't have enough paging space. The thresholds for
these events are at high levels of page space utilization, far above the
30% utilization guideline for best performance.

Assuming you've eliminated a pathological cause, you should increase
significantly your paging configuration by PAGEADDing one or two large
page data sets. As a standby measure, you should always have another
page data set in reserve, to be PAGEADDed upon receiving the IRA400E
message.

Please follow up on this problem.

Good luck!

Steve Samson

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-07 Thread Pommier, Rex R.
We had the same situation a week ago with 1 difference.  I have a spare
page dataset on my system and when this happened, I was able to
dynamically activate the dataset and had enough time to get into SDSF DA
screen and discover that I had a SAS (actually my monthly MXG rollup)
job eating up all my AUX storage.  I was able to keep an eye on the
system by giving it the extra pagespace and watch the SAS job go to
completion.  I hasten to add that the SAS/MXG job was working as it was
supposed to, but the huge run pointed out a different problem with SMF
that I am fixing.

I know this doesn't directly answer your monitoring question, but if you
have the disk space, you might want to put an extra page dataset in your
back pocket just in case...

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Steely
Sent: Friday, April 07, 2006 11:04 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: IRA400E


Several day ago we received the following messages:
 
IRA400E 04,PAGEABLE STORAGE SHORTAGE 
IRA403E PXXX SWAPPED TO RECLAIM PROCESSOR STORAGE; 001759 PAGES
000117 FIXED etc...
 
Then we received:
 
IRA401E 04,CRITICAL PAGEABLE STORAGE SHORTAGE
IRA403E IOAOSASF SWAPPED TO RECLAIM PROCESSOR STORAGE; 002057 PAGES
57 FIXED   
etc..
 
The system locked up and we had to IPL.
 
We are z/OS V1R4 and we have RMF and CA-SYSVIEW. What can we do to
prevent this from happening again. Are there reports we can run or an
alert we can  set-up if an address space goes wild and starts eating up
storage. Any help would be appreciated. If you have an example of a
report we could execute to help determine which task are using an
excessive amount of storage would be helpful. 
 
Thank You 


--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-07 Thread Steve Samson

Mark,

Unless you had a uniquely ill-behaved program gobbling paging space, the 
cause is that you don't have enough paging space. The thresholds for 
these events are at high levels of page space utilization, far above the 
30% utilization guideline for best performance.


Assuming you've eliminated a pathological cause, you should increase 
significantly your paging configuration by PAGEADDing one or two large 
page data sets. As a standby measure, you should always have another 
page data set in reserve, to be PAGEADDed upon receiving the IRA400E 
message.


Please follow up on this problem.

Good luck!

Steve Samson

Mark Steely wrote:

Several day ago we received the following messages:
 
IRA400E 04,PAGEABLE STORAGE SHORTAGE 
IRA403E PXXX SWAPPED TO RECLAIM PROCESSOR STORAGE; 001759 PAGES

000117 FIXED
etc...
 
Then we received:
 
IRA401E 04,CRITICAL PAGEABLE STORAGE SHORTAGE

IRA403E IOAOSASF SWAPPED TO RECLAIM PROCESSOR STORAGE; 002057 PAGES
57 FIXED   
etc..
 
The system locked up and we had to IPL.
 
We are z/OS V1R4 and we have RMF and CA-SYSVIEW. What can we do to

prevent this from happening again. Are there reports we can run or an
alert we can  set-up if an address space goes wild and starts eating up
storage. Any help would be appreciated. If you have an example of a
report we could execute to help determine which task are using an
excessive amount of storage would be helpful. 
 
Thank You 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IRA400E

2006-04-07 Thread Knutson, Sam
Hi Mark,

What was running at the time?  SORT products seem be recurring offenders
in this type of problem.

What do the RMF Monitor III Storage reports show for the intervals
leading up to the problem?
In RMF III Opt 3 RESOURCE, then 7 STORF Storage usage by frames would be
a good starting point i.e. 

  RMF V1R5   Storage Frames  Line 1
of 696 
Command ===>  Scroll
===> CSR  
 

Samples: 120 System: BSYS  Date: 04/07/06  Time: 12.20.00  Range:
120   Sec
 

   Service  -- Frame Occup. --  - Active Frames - AUX   PGIN
ES
Jobname  C ClassCr  TOTAL   ACTV  IDLE  WSET  FIXED   DIV SLOTS RATE
RATE  
 

DB2UDBM1 S ONLUSR348K   348K 0  348K   2398 0 00

DB34DBM1 S ONLUSR284K   284K 0  284K   1915 0 00

DB2ADBM1 S ONLUSR249K   249K 0  249K   1683 0 00

DB2TDBM1 S ONLUSR244K   244K 0  244K   1608 0 00


Automated alerting is good even at the time this is detected.  We have
some exceptions in TMONMVS but we also page the performance and MVS
teams anytime IRA400E, IRA401E, and IRA402I are issued. 

Best Regards, 

Sam Knutson, GEICO 
Performance and Availability Management 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574 

"Think big, act bold, start simple, grow fast..." 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Steely
Sent: Friday, April 07, 2006 12:04 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: IRA400E

Several day ago we received the following messages:
 
IRA400E 04,PAGEABLE STORAGE SHORTAGE
IRA403E PXXX SWAPPED TO RECLAIM PROCESSOR STORAGE; 001759 PAGES
000117 FIXED
etc...
 
Then we received:
 
IRA401E 04,CRITICAL PAGEABLE STORAGE SHORTAGE IRA403E IOAOSASF SWAPPED
TO RECLAIM PROCESSOR STORAGE; 002057 PAGES
57 FIXED   
etc..
 
The system locked up and we had to IPL.
 
We are z/OS V1R4 and we have RMF and CA-SYSVIEW. What can we do to
prevent this from happening again. Are there reports we can run or an
alert we can  set-up if an address space goes wild and starts eating up
storage. Any help would be appreciated. If you have an example of a
report we could execute to help determine which task are using an
excessive amount of storage would be helpful. 
 
Thank You   

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


IRA400E

2006-04-07 Thread Mark Steely
Several day ago we received the following messages:
 
IRA400E 04,PAGEABLE STORAGE SHORTAGE 
IRA403E PXXX SWAPPED TO RECLAIM PROCESSOR STORAGE; 001759 PAGES
000117 FIXED
etc...
 
Then we received:
 
IRA401E 04,CRITICAL PAGEABLE STORAGE SHORTAGE
IRA403E IOAOSASF SWAPPED TO RECLAIM PROCESSOR STORAGE; 002057 PAGES
57 FIXED   
etc..
 
The system locked up and we had to IPL.
 
We are z/OS V1R4 and we have RMF and CA-SYSVIEW. What can we do to
prevent this from happening again. Are there reports we can run or an
alert we can  set-up if an address space goes wild and starts eating up
storage. Any help would be appreciated. If you have an example of a
report we could execute to help determine which task are using an
excessive amount of storage would be helpful. 
 
Thank You 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html