Rob brings up a salient point. ALL of your applications should be
journaled, regardless of if you use them for commit control or not. It aids
in speedier recovery from an abnormal termination, it aids in SWA, and if
set up properly with system managed journals, does not require significant
administrative work to manage them. In a PowerHA environment it's essential
to ensure properly managed HA clusters. (the same is true for the journal
based replication packages)
Another way to get past most of the complexity is BRMS. BRMS manages most
of the issues with respect to SWA nicely. The small investment in BRMS will
pay for itself in administration time, and recoverability in very short
order.
Another reason to use journals is to mitigate the need for getting
checkpoints across multiple libraries at one time. Granted referential
integrity might not be perfect without a multiple library checkpoint but
using journaling by application rather than library boundary goes a long way
to making that technique acceptable.
Very few of my customers have environments were the near restricted state
(however short) to achieve a synchronization point is required, rather by
using BRMS and good use of journaling you can achieve 98% of what you what
without the shutdown pain.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Wednesday, April 08, 2015 2:23 PM
To: Midrange Systems Technical Discussion
Subject: Re: save while active v7r1 - *IBM and also SAV
Jim,
I think you are a somewhat regular attendee of COMMON. That might be a good
place to really bone up.
Some search terms are: ragged save while active.
I think that might be the title of a redbook by Larry Youngren
With little to no journalling you may catch some grief.
Stream files are very picky and snicker at save while active.
Until we did the Mimix thing and started backing up from that we were doing
a crappy save while active. No checkpoint processing. No journalling.
Didn't care if order header was in sync with order line, etc
SAVACT(*SYSDFN). The goal being: You can back up, just don't disrupt the
users from getting into the data. I argued against it but had to bide my
time until Mimix. Only took a few years...
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: Jim Franz <franz9000@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 04/08/2015 03:05 PM
Subject: save while active v7r1 - *IBM and also SAV
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
We've been doing SWA for years (since mid 5.4), but also ending almost to
restricted state before starting SWA, and when checkpoint achieved,
starting subsystems.
Would now like to do as little (if any) shutdown before starting SWA.
The native "user" libraries usually not the issue (other than *IBM libs
with *SYSDFN option).
The IFS and IBM products have been the issue.
No journaling (a couple files maybe)
No commitment control.
Web client with C# updates to native files. (the http server for this is
not Power i) - and this would be the only really active updating app
active
at this time - and updates are minimal at this time period.
IBM Content Manager 5.3 (millions of images in Virtual Optical) - and we
are planning on still ending the Storage Manager subsystems - they just
don't share well...
Save is to tape library.
From ending subsystems, getting to checkpoint, started subsystems is 1.5
hrs.
(still no budget for mirroring or other technologies).
I've seen many posts of http server logs being an issue, and perhaps
performance tool jobs.
It is an option to end HTTP servers till checkpoint.
There are 20 years of posts on SWA, so where are we now?
Jim Franz
As an Amazon Associate we earn from qualifying purchases.