RE: Crashed system

Hi Chris

Once upon a time (pre-RAID) storing the journal receivers in a separate ASP
- isolating the storage for them - could be used as part of a recovery
strategy. With no RAID and the disk technology in use there were some pretty
compelling reasons for doing this.

In the event that an individual disk failed (think good old 3370's or better
yet 9332/600's), only the ASP where that disk resided was compromised. Thus
you had a situation where either the journal receivers were intact in a
secondary ASP and you could recover and apply all your transactions up to
when the system went down, OR your journal receivers were toast but your
data libraries were intact and you could continue working after the system
was recovered (some messing about required, of course).

The recovery involved doing a RCLSTG if I remember rightly but it was a
pretty effective way to recover right up to the last transaction IF you had
isolated the receivers in a second ASP. In fact I think at one stage
receivers were the only objects you COULD put in an ASP.

Regards
Evan Harris

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Chris Bipes
Sent: Saturday, 17 January 2009 10:43 a.m.
To: Midrange Systems Technical Discussion
Subject: RE: Crashed system

This will not fix the problem of QTEMP filling up the system ASP as that
is were QTEMP is created. I do not know how you can tell the system to
use ASP X for QTEMP. There are only a handful of reasons to create
secondary ASP's, Journal Receiver and Save File. Then it is only for
performance reasons, not to isolate storage. You also have to remember
that the ASP will overflow to the System ASP automatically. This does
not solve the problem with a run away job writing to QTEMP.




Chris Bipes
Director of Information Services
CrossCheck, Inc.