|
Hi Jon, I looked at your email address, do you work in Italy these days? I think that it was 1993 when I did this architecture. My statement, "haven't upgraded to a RISC machine" is based on that date. I thought it was a mistake at the time but I couldn't convince the boss to change his mind and I was too low on the totem pole to push very hard. Please reconsider your first three comments in light of that fact. Jon, I apologize for not making that clear. We are in violent agreement. When I wrote the note, I was focused on the architecture considerations and I failed to consider that someone might interpret that bit using today's facts. I did confuse you and included information across several years of development. One of the guys who worked for me wrote a code generator in C that created file server programs (and the .h files) in C. It worked like a dream and the language was invisible to the application programmers but, at the time, the boss refused to accept the generator. He said something like, {the application managers won't accept the programs because they have no organic C programming skills}. In this case, the {} means "paraphrase". I tried to argue with the boss but that was a life-limiting move - that man was, and still is, VERY stubborn and one of the best red-faced shouters I have ever met. His track record on application and business decisions is awesome so he might have been right. At the time, winning wasn't a good gamble and might have been unpleasant. You may have noticed that I strongly supported the idea that the file server programs should be "re-gener-able" at will. Someone in the financials application groups decided that it was a good idea to put the cost center security logic into the file server program. In my opinion, it was a mess and still haunts. Because the application managers were thinking of putting other logic into the programs, it was important to them that they could maintain the programs. Coding them in C would have prevented that. At the time, I thought that was one of the advantages of coding them in C but ... oh well. Two years later, when they rearchitected and redesigned the entire suite, all the application groups had one or more C programmers all of whom would have seen the risk of putting business logic into the file server programs and this would have been a non-issue. At the time of this design and initial implementation, we could have chosen to use either ILE C or the OPM version. Timing again, sorry. I agree that customers should stay current on OS releases. I think that they should be forced up. I saw a note on the midrange list from someone who was at V3R7. Compared to V4R3 or V4R4, V3R7 is a very bad place to be. I think that the right approach is to withdraw support for releases more than a certain number of years old or more than a certain number of releases back. In my opinion and at this time, there is no justification for being on V4R1 or earlier. I think that V4R2 is not nearly as good as V4R3. Software rot is bad for everyone. I am leaving all of your comments on this note. Every one of your points is exactly right today. Richard Jackson mailto:richardjackson@richardjackson.net www.richardjacksonltd.com Voice: 1 (303) 808-8058 Fax: 1 (303) 663-4325 -----Original Message----- From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On Behalf Of Jon.Paris@hal.it Sent: Tuesday, July 04, 2000 12:25 PM To: RPG400-L@midrange.com Subject: RE: ILE Conversion >> Why write the file server in OPM RPG? Because most of your customers haven't upgraded to ILE machines and you don't want to force them to - its bad for business to force customers to do things. I have to take issue with a number of points arising from this and other comments in your note. First - you say they "Haven't upgraded to ILE machines" You mean they are running V2 releases? I'm not sure I'd want to keep such customers anyway. All V3 and later releases support ILE. Second - If you RPG IV in compatibility mode then its behaviour is almost identical to RPG/400 anyway. The benefits of RPG IV over RPG III are so overwhelming I can't believe that you have seriously looked at the language at all. Third - It is perfectly possible to write full ILE programs (making full use of subprocedures etc.) that can co-habit with OPM programs without an enormous amount of work. Fourth - who said the "old" programs had to share the new IO routines anyway? They can stay as-is and be converted as/when they get re-written. As to writing the thing in C - you're confusing me here. The only C compiler is an ILE one - you said earlier that you don't want to force your customers to use ILE - am I missing something here?. Anyway, all of the C I/O routines can be used directly from RPG IV with no need for a C compiler on the box (not a trivial expense at present) so for those occasions when more flexibility than supplied by RPG is required you can go that way. Besides - there is no need to produce a complete I/O system that can handle any file/any format/ any operation - simply routines that put in one place the operations required of a specific file/file set. Last - but by no means least - I think we _should_ force our customers to do things from time to time. Shouldn't we encourage them to upgrade to supported releases? One BP I know recently informed their customer base that they would have to move to a minimum V4R2 level to receive the new release. The customer's reaction (much to their surprise) was "Oh good - we thought we should move but were waiting for you to tell us we needed to!" IMHO if you allow your customers to "rot" as you appear willing to do, then they are easy targets for the NT "solution" advocates. What happens to your business then? +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.