|
This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] I think you have a valid point, I am not sure how many people actually do thorough testing on their test machines. Took me years to get them to stop putting new versions of payroll on the production machine, and then if it worked ok, put it on the development machine. Their mentality of the development machine was that it was just a place to compile code - not test. And if it did need a few weeks/months of testing, how do you put anything into production for the old system in that time period - duplicate more libraries? Workload may be harder to handle but duplicating programs and data is not. Before we upgraded our production box to handle Domino and Tivoli Storage Manager it was a 200GB machine. Our development machine is a 337GB machine. With testing, training and source, you need more disk. Rob Berendt -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Buck Calabro <Buck.Calabro@commsoft.net> Sent by: midrange-l-admin@midrange.com 08/27/2002 10:26 AM Please respond to midrange-l To: midrange-l@midrange.com cc: Fax to: Subject: Test environments (was: upgrade) >I think more people may take advantage >of test environments as this capability >[LPAR on partial processors] becomes more >widespread. I wonder how many people actually USE a test environment. All of our customers set one up (so they can test drive the new version of our software before putting it into production.) But they also don't run parallel for any length of time either. If OS upgrades work the same way (run a small subset of your business work on it), I wonder how many people actually find problems this way? I mean, if I think that V5R2 might have 'issues' with my application, workload, data or configuration, wouldn't I have to duplicate the application, workload, data and configuration in order to test them? --buck _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.