|
Don, No time, but I just had to say...: I'm **sure ;D** the install was tested the same way *I* test *MY OWN* code: a) compile the code b) run it a couple times c) hold my thumb at arms length d) close one eye and look at the results e) if results look *reasonable*, I stamp it "gold"... ROFLMAO... Man...! "Sometimes I jes KILLLL maself...!" ...Foghorn Leghorn (the cartoon character) In all seriousness: That IS pretty much how I test my code, but I *know* IBM does MUCH better than that. I give them credit for that. I think Al hit on the problem that faces ALL developers: it's exceedingly difficult to improve a product and provide new features without, at the same time, introducing instability into the software. There's no doubt IBM does MUCH better at testing than I do, but IMNSHO I believe I do much better at reacting to any problems which come up (which are generally few, because the systems I do are not near as complicated). The extremely broad range of the customer-base of the 400 (which keeps growing broader) provides increasing challenges, as Al said. My point is that IBM can turn that disadvantage into an advantage. All they need to do is allow that customer-base to become part of the team that's charged with solving these problems. Again, to me anyway, that's the value of the iNation. But this can be easily accomplished, whether or not it's done under the flag of the iNation. Helping find the install problems is **just one** of the many kinds of things that **this list can accomplish**. Just need a connection between this list, and the folks at IBM who are trouble-shooting these problems. The folks on this list obviously won't represent ALL the possible situations that could cause problems, but probably 80% of them can be trouble-shooted for 20% of the effort... Because that's what this list does... Me... Offhand, I don't see the disadvantages... jt | -----Original Message----- | From: midrange-l-admin@midrange.com | [mailto:midrange-l-admin@midrange.com]On Behalf Of Don | Sent: Saturday, December 15, 2001 2:36 PM | To: midrange-l@midrange.com | Subject: Re: V5R1 Lic Pgm install failures | | | | | ....if at all? | | | | On Sat, 15 Dec 2001 barsa@barsaconsulting.com wrote: | | > | > I have had similar experiences, and I just re-install them. | > | > To me the fact that a failure in a restricted state of any | licensed pgm is | > just an indication that the process was never tested well enough. | > | > Al | > | > Al Barsa, Jr. | > Barsa Consulting Group, LLC | > | > 400>390 | > | > 914-251-1234 | > 914-251-9406 fax | > | > http://www.barsaconsulting.com | > http://www.taatool.com | > | > | > | > | > | > | > Larry Bolhuis | > <lbolhuis@arbsol.co To: Midrange | Systems Mailing List <MIDRANGE-L@midrange.com> | > m> cc: | > Sent by: Subject: V5R1 | Lic Pgm install failures | > midrange-l-admin@mi | > drange.com | > | > | > 12/14/01 11:17 PM | > Please respond to | > midrange-l | > | > | > | > | > | > | > Greetings to the highly intelligent Midrange community. | > | > The last two V4R5 to V5R1 upgrades that I have done have each failed to | > install at least a dozen program products. I didn't keep the lists but | > in each case they were smattered all over from pieces of SS1 all the way | > to XE1. In each case history log messages indicated the products were | > not copied from the media. LICPGM Option 5-prepare for install- had | > successfully located these products. After failing during the initial | > install the use of option 11-install licensed programs for each of the | > failed programs successfully loads them no problem. | > | > Both of these upgrades were dual processor 820 machines with lots of | > memory and disk. | > | > Nothing in the archives, or on the iSeries pages. | > | > Thoughts? Similar experiences? I'm full of ****? | > | > Thanks, | > | > - Larry. | > | > _______________________________________________ | > 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. | > | > | > | > | > | > _______________________________________________ | > 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. | > | | _______________________________________________ | 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.