Let's assume the following scenario:
"Disastrous" power outage occured, no alternate power source is
available, only UPS battery. Time for battery discharge is approx. 20-30
minutes.
DASD is mirrored to remote site, system z/OS, DB2, CICS.
The goal is to keep *remote* copy as consistent as pos
I think the most important action--but not necessarily the first--is V XCF
OFF. That should stop ongoing I/O in as synchronized a manner as possible
across all applications.
$PJES2 will most certainly never complete, but it will prevent any new
tasks from starting. I would NOT do a TERM because yo
What effect would a "Quiesce" have? This is a clean, safe way to end
all I/O but what incomplete transactions will be lost?
Tom
On Tue, 2005-12-06 at 08:13 -0800, Skip Robinson wrote:
> I think the most important action--but not necessarily the first--is V XCF
> OFF. That should stop ongoing I/O
>$PJES2 will most certainly never complete, but it will prevent any new
>tasks from starting. I would NOT do a TERM because you lose all control
>at that point.
>From experience on education systems I'd say the $PJES2 isn't even
necessary. I've always seen JES2 stopping after the V XCF OFF befo
If you only have about 20 minutes of batteries left, do as orderly a
shutdown as possible. (Even our heavily loaded production system doesn't
take 20 minutes to come down.)
As pointed out before, get the major players down (IMS, DB2, CICS) - those
that have business critical transactions that may
>>From experience on education systems I'd say the $PJES2 isn't even
>>necessary.
>I would not subscribe to that. $PJES2 should always be done. If JES2
comes
>down is another matter.
I agree, doing the $PJES2 will not hurt.
>>This makes me belive JES2 is one of the (few?) products that listens
<-- snip -->
Let's assume the following scenario:
"Disastrous" power outage occured, no alternate power source is
available, only UPS battery. Time for battery discharge is approx. 20-30
minutes.
<-- snip -->
Why do you believe you have 20-30 minutes to do something? I would loo
In a message dated 12/7/2005 9:41:41 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Why do you believe you have 20-30 minutes to do something? I would look how
long can the weakest component stay available: switch or any other interface
on the path to devices and then to the mirror d
The reason I would do a $PJES2 is to prevent new work from starting. If you
know that the end of the world is imminent, the less still running the
better. Otherwise you could have all manner of tasks kicking off at a
really unfortunate time. Maybe a simple $P would be even better just to
turn off t
TISLER Zaromil wrote:
<-- snip -->
Let's assume the following scenario:
"Disastrous" power outage occured, no alternate power source is
available, only UPS battery. Time for battery discharge is approx. 20-30
minutes.
<-- snip -->
Why do you believe you have 20-30 minutes to
: How to quickly shut down system
TISLER Zaromil wrote:
> <-- snip -->
> Let's assume the following scenario:
> "Disastrous" power outage occured, no alternate power source is
> available, only UPS battery. Time for battery discharge is approx.
Pommier, Rex R. wrote:
To throw my $.02 in, do you have any non-critical equipment on the UPS
that could be powered down ahead of time (non-essential tape, printers,
etc) that could possibly extend the UPS uptime duration? I have lived
thru this scenario - lost street power and no generator. W
On Wed, 2005-12-07 at 20:54 +0100, R.S. wrote:
>
> Back to the question, what about DB2, which I'm most worried ?
> I'd like to "quiesce" all the system activity as much as possible, just
> to avoid long time for get the DR system ready. I don't want to spent
> hours to backout uncommited trans
R.S.,
For *SIMPLE* solution that is also *clean* I recommend issuing -STOP DB2
MODE(FORCE) command for each DB2 subsystem. (Command syntax changes based
on if you are data sharing or not.) For tasks not currently in DB2 it
will post an exit; for tasks in DB2 it will stop during next suspend or
The more I think about this, the more I think less is better.
Given the amount of time to fully understand the situation, find the
procedure (which has never been tested), get a management buy in to pull
the trigger, thoughtfully issue the correct commands in the correct
sequence (watching for an
Hal Merritt wrote:
The more I think about this, the more I think less is better.
Given the amount of time to fully understand the situation, find the
procedure (which has never been tested), get a management buy in to pull
the trigger, thoughtfully issue the correct commands in the correct
seq
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: How to quickly shut down system
...snip
That's why the procedure have to be *SIMPLE*. No checking, no decision,
no analysis.
However I'm still not sure, what's better - do something like STOP
DB2,MODE(FORCE) or do nothing.
--
Radoslaw Skorup
From: "Hal Merritt"
> I was once advised to cancel the IRLM address space. DB2 tends to
> abruptly drop in its tracks, but knows what to do to get back going
> again.
Never had it fail. Doesn't win popularity points with the DBAs though.
Likewise, we have our CICS regions in STCJOBS; C CICS* work
A.EDU
Subject: Re: How to quickly shut down system
I was once advised to cancel the IRLM address space. DB2 tends to abruptly drop
in its tracks, but knows what to do to get back
going again.
Hal
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Beha
19 matches
Mail list logo
