Re: South Dakota migrates off mainframe; chaos ensues

2008-07-11 Thread Matthew Stitt
This reminds me of the Oklahoma Payroll debacle of the mid-1990's.  The
primary problem there was the new non-mf system contractors never checked
the payroll data being sent to the Treasurer for check printing had the
correct formats and data.  The state finally went back to the mainframe
system.  I don't think they ever tried that stunt again.

On Thu, 10 Jul 2008 11:10:25 EDT, Ed Finnell [EMAIL PROTECTED] wrote:


In a message dated 7/10/2008 9:54:58 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:

where somebody might say, gee, why not spend $c  $a+$b to develop  the
software on the new platform? This question needs to be answered  in
management speak and not techie speak. And the only reason that  I
can think of would be risk avoidance. But is risk avoidance  worth
the cost ($a+$b-$c)? We've done similar things here and been told  go
ahead despite the risk. Sometimes it has worked fine, other times  we
were left with a mess.



Isn't this a contract issue? Maybe ought to  flush out on John Anderson's
ISVCOSTs list. One of our bright VM'ers has been  doing clean-up from a shaky
conversion of one of S.D.'s neighbors for over  three years at IBM contract
rate.
Loves it except for the sub-zero  winters.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Re: South Dakota migrates off mainframe; chaos ensues

2008-07-10 Thread Pommier, Rex R.
Pat,

I absolutely agree with your first statement below.  I'm not sure I
agree with the second half.  My point was that there would most likely
have been much less programming effort if they had decided to just make
the required changes to the application to fulfill the law changes,
leaving the application where it was, since they had a non-negotiable
deadline.  Then once the system was working, they could have had a
second effort to migrate the system to the alternate platform, giving
them the ability to fall back if they had problems of the magnitude they
are having.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick O'Keefe
Sent: Wednesday, July 09, 2008 3:27 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: South Dakota migrates off mainframe; chaos ensues


... decided to use this law change as the reason to migrate the 
application off the mainframe.  So, they had no fall-back ability in 
case of problems -
...

To be fair, this problem had less to do with off the mainframe 
than onto a new application and no fallback.  If the same 
project managers were involved, the migration would probably
have gone no better if it had been to another application on the 
mainframe.

Pat O'Keefe  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Re: South Dakota migrates off mainframe; chaos ensues

2008-07-10 Thread McKown, John
 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R.
 Sent: Thursday, July 10, 2008 9:43 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: South Dakota migrates off mainframe; chaos ensues
 
 Pat,
 
 I absolutely agree with your first statement below.  I'm not sure I
 agree with the second half.  My point was that there would most likely
 have been much less programming effort if they had decided to 
 just make
 the required changes to the application to fulfill the law changes,
 leaving the application where it was, since they had a non-negotiable
 deadline.  Then once the system was working, they could have had a
 second effort to migrate the system to the alternate platform, giving
 them the ability to fall back if they had problems of the 
 magnitude they
 are having.  
 
 Rex

Though I agree with you, from a higher management viewpoint, it would
sound something like: Lets spend $a dollars to upgrade the existing
software for this new function. Once it is complete and working, we will
spend $b more dollars to convert it to another platform. I can see
where somebody might say, gee, why not spend $c  $a+$b to develop the
software on the new platform? This question needs to be answered in
management speak and not techie speak. And the only reason that I
can think of would be risk avoidance. But is risk avoidance worth
the cost ($a+$b-$c)? We've done similar things here and been told go
ahead despite the risk. Sometimes it has worked fine, other times we
were left with a mess.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Re: South Dakota migrates off mainframe; chaos ensues

2008-07-10 Thread Ed Finnell
 
In a message dated 7/10/2008 9:54:58 A.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

where somebody might say, gee, why not spend $c  $a+$b to develop  the
software on the new platform? This question needs to be answered  in
management speak and not techie speak. And the only reason that  I
can think of would be risk avoidance. But is risk avoidance  worth
the cost ($a+$b-$c)? We've done similar things here and been told  go
ahead despite the risk. Sometimes it has worked fine, other times  we
were left with a mess.



Isn't this a contract issue? Maybe ought to  flush out on John Anderson's 
ISVCOSTs list. One of our bright VM'ers has been  doing clean-up from a shaky 
conversion of one of S.D.'s neighbors for over  three years at IBM contract 
rate. 
Loves it except for the sub-zero  winters.







**Get the scoop on last night's hottest shows and the live music 
scene in your area - Check out TourTracker.com!  
(http://www.tourtracker.com?NCID=aolmus0005000112)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Re: South Dakota migrates off mainframe; chaos ensues

2008-07-09 Thread McKown, John
 -Original Message-
 From: The IBM z/VM Operating System 
 [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
 Sent: Wednesday, July 09, 2008 11:17 AM
 To: [EMAIL PROTECTED]
 Subject: South Dakota migrates off mainframe; chaos ensues
 
 From this week's TechTarget magazine(watch for line wrap here)
 
 
 http://www.mail2web.com/cgi-bin/redir.asp?lid=0newsite=http:/
 /go.techtarget
 .com/r/3997279/567145
 
 DJ

Tinyurl to that site.

http://preview.tinyurl.com/6o4oqe

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Re: South Dakota migrates off mainframe; chaos ensues

2008-07-09 Thread Pommier, Rex R.
Hi John,

Interesting way for my home state to get in the media!!  Unfortunately
the state made a slight mistake in this implementation.  The
legislature decided to change the way license plates are handled when a
vehicle gets sold.  They switched from the plates going with the vehicle
to the plates staying with the seller.  There was a hard implementation
date to get this change made.  Unfortunately they apparently decided to
use this law change as the reason to migrate the application off the
mainframe.  So, they had no fall-back ability in case of problems -
which apparently are myriad.  One of my co-workers said he heard the
application needs to be cycled multiple times a day - either to keep it
from crashing or because of crashes.

Rex



 Subject: South Dakota migrates off mainframe; chaos ensues
 
 From this week's TechTarget magazine(watch for line wrap here)
 
 
 http://www.mail2web.com/cgi-bin/redir.asp?lid=0newsite=http:/
 /go.techtarget
 .com/r/3997279/567145
 
 DJ

Tinyurl to that site.

http://preview.tinyurl.com/6o4oqe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Re: South Dakota migrates off mainframe; chaos ensues

2008-07-09 Thread Patrick O'Keefe
On Wed, 9 Jul 2008 13:02:16 -0500, Pommier, Rex R. 
[EMAIL PROTECTED] wrote:

...They switched from the plates going with the vehicle
to the plates staying with the seller.  ...

Way off topic, but I've had some cars with the bolts so rusted I'd
never get the plates off.   I guess I'd have to keep the car forever
if I were from South Dakota.

... decided to use this law change as the reason to migrate the 
application off the mainframe.  So, they had no fall-back ability in 
case of problems -
...

To be fair, this problem had less to do with off the mainframe 
than onto a new application and no fallback.  If the same 
project managers were involved, the migration would probably
have gone no better if it had been to another application on the 
mainframe.

Pat O'Keefe  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html