Interesting.
I joined this list recently specifically because our company is considering
a migration off our mainframe platform (VSE), and I've spent the past
several months researching the pros and cons to determine which direction
we should proceed in.
Thank you for posting the link to that article. While it presents some
interesting considerations, I didn't find it had much relevance for us. It
seemed to be focused primarily on capacity comparisons, and in mainly on
migrating *to* the mainframe. I thought the capacity discussion was
somewhat simplistic and unrealistic. It discussed things in terms of # of
migratable apps that will run on each platform. I've been here 20 years
and we've never defined things in those terms. What's an app (as used in
the article)? A program? A group of related programs? We have either dozens
of apps, or thousands of apps, depending on how you count. There is so much
more involved in capacity planning on the mf than merely a 'number of
apps'.
And what's 'migratable'? Does that mean that it could run, as is, in the
same language, on a different platform? We're evaluating going to the
iSeries and there's not much we have on the mf would run 'as is'- it will
all need to be converted to a different language, as well as all the
process infrastructure having to be converted (JCL to CL, eliminate
'cardin' concept, etc etc). So, does that count as migratable in the terms
of the article? Or if we can convert a program or group of programs
automatically using tools or consulting companies (which we're looking at),
does that count as migratable?
Our focus isn't so much on capacity, it's on platform consolidation. We
already have a team working on the iSeries for one of our major
applications, so the thinking is that if we were all on the same box, we'd
save the hardware software costs of the other box. We also have a concern
of obsolescence- there is a fear among some that our mf environment is too
out of date.
So our primary consideration is conversion cost- what is it going to take
to get us there? The more that has to be rebuilt redesigned, as opposed
to merely 'converted', the more it will cost.
We also have to consider the hidden costs of how long it takes a programmer
to do xyz on the mf vs the I. I realize the iSeries will offer some
features that we don't have on the mainframe. But, I'm also learning that
we will give up quite a bit as well, in the areas of automation and
efficiency. Over the decades, we've built a lot of custom processes and
developed techniques that would all need to be rebuilt and redesigned. In
meetings with the iSeries guys I keep hearing well we don't/can't do
*that*, but we do this instead. However the 'this instead' alternatives on
the iSeries never seem quite as easy or efficient as what we've got on the
MF. We have 3 times the staff on the iseries that we have on the mainframe,
supporting roughly the same volume of data, programs, and processes.
Anyway, I'd be interested in hearing of anyone else who has gone thru this
sort of assessment or migration project (from mainframe to iseries), and
what you've learned.
Bill
Ed Gould
ps2...@yahoo.com
To
Sent by: IBM IBM-MAIN@bama.ua.edu
Mainframe cc
Discussion List
ibm-m...@bama.ua Fax to
.edu
Subject
Item on Cost savings on the MF
05/27/2009 08:31
PM
Please respond to
IBM Mainframe
Discussion List
ibm-m...@bama.ua
.edu
SHOULD YOU MOVE APPS ON OR OFF THE MAINFRAME TO CUT COSTS?
http://go.techtarget.com/r/7192091/6570353
Wayne Kernochan, Contributor
As IT seeks to cut costs in the face of declining
