Thanx everyone for your input ...
Here is how I explained things to our CIO:
I have carefully researched the idea of configuring our iSeries servers
using direct attached clients (Telnet for example) so that in the event
that the primary server unexpectedly stopped functioning (crashed) all
processing would automatically be transferred over to the secondary system
without the end user ever knowing anything happened.
This technology just does not exist. It may exist in a load balanced web
environments, but not in server environments like we use for CIS and most
likely even SAP.
An example that was shared with me during my research was... Let's say you
directly attached to Windows Server A, you open up a CMD window and type
DIR C: and hit enter.
<CMD window picture showing a DIR C: command>
While doing this, Server A crashes. I can't think of any scenario where
this window would remain open and the DIR C: command would automatically
continue running on Server B? This CMD window is unique to the server it
was opened on.
This is similar to having a Telnet Session connected to the iSeries. Let's
say it is connected to our Production iSeries server. An Interactive Job
has been started that defines how this session interacts with the server.
There are pieces of this job residing in RAM. Temporary job structures such
at Open Data Paths, memory pool allocation, etc. all being maintained by
the Operating System on the Production server.
These are not just database connections. These are job support functions
that define a job to the server before it ever accesses the database. This
"job" is unique to this server.
Now our Production iSeries server crashes. What are our options?
In our case, we are mirroring a set of disk attached to the Production
Server called an Independent Auxiliary Storage Pool (iASP). Another copy
of this storage pool is being maintained in "near real time" to another
server, our DR iSeries. These two servers are clustered together so if one
"disappears" a process could be started. This process is currently manual
but it could be automated through cluster commands. The process prepares
the copy of the iASP so it becomes the Primary copy and is made available
on the DR iSeries Server and an IP interface card is varied on with the
same IP address.
This is GREAT! We don't have to restore anything!
BUT ... It does take 20 - 45 minutes to attach the iASP and the direct
attached client jobs (TELNET) would have to be recreated on the DR Server.
In other words the user would have to sign in again. Also, any jobs
running in background (batch jobs) would have to be restarted too because
like interactive jobs, the OS maintains these job structures in RAM too.
We are journaling our data files and using commitment control so any
transaction that didn't finish prior to the crash will be backed out in
order to guarantee the integrity of the data. A minuscule amount of data
may need to be reentered too because the mirroring of data is being done
asynchronously due to the distance our DR location is from our source
system. Also any interrupted batch jobs will need to be restarted... but
this is so much better than having to wait while we reboot a system after a
crash or recover a whole system from tape at a DR site (which use to take
What we have configured is the best that is available today.
Reply or Forwarded mail from: Kenneth E Graap
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Sent: Thursday, December 18, 2014 4:05 AM
To: Midrange Systems Technical Discussion
Subject: Re: Hot Swap iSeries applications
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives