|
No, Scott, it's my rather extensive experience with business application development in Unix and OS/400. I was the Manager of Architecture at System Software Associates and responsible for the overall architecture of nearly two million lines of RPG code, 1/3 of which I designed and perhaps 10% of which I actually coded. In addition, I designed and oversaw the development of over 2 million lines of C code under OS/2 for our graphical client/server development - I wrote about 20% of that code. When SSA decided to move to Unix (to support the platform independence that Leif loves so much, and that ultimately killed the company) I was the lead architect for the project which implemented all the basic functions of OS/400 that weren't implemented in Unix, or at least weren't compatible with how the AS/400 worked, such as OVRxxxF, output queues, program calls, message files, program message queues, job descriptions and the like. We basically had to emulate each of the OS/400 system objects and the standard OS/400 commands such as SNDPGMMSG and SBMJOB. I was also involved with the conversion of native I/O to SQL. I spent a lot of time trying to get Sybase to work, as well as Oracle. Compared to DB2/400, both are incredible dogs, especially as file sizes reach the million-record mark. Neither can support the level of data-driven database navigation required for an enterprise-level business application. Today's BPCS is a bloated, careening mess, where what originally took 4,000 lines of RPG now takes some 44,000 lines of tool-generated SQLRPG. So, yes, I'm pretty anti-Unix and anti-SQL, but I've got a lot of very good experience behind me to back up my opinion. I have programmed my share of Unix, more than I care to, and while I love Unix (and awk and grep and yacc) for text processing (which is what web serving is all about, when you get down to it), it will never be an industrial-strength transaction-processing environment. In my opinion. Joe ---------- Original Message ---------------------------------- From: Scott Klement <klemscot@klements.com> Reply-To: MIDRANGE-L@midrange.com Date: Thu, 5 Apr 2001 10:16:44 -0500 (CDT) > Is this from your vast experience with FreeBSD, Joe? And is it that same experience where you decided that it runs "crap like Oracle" or is "SQL-based". Frankly, perhaps you should refrain from commenting on something that you've never even tried to do! On Thu, 5 Apr 2001, Joe Pluta wrote: > I'm not going to waste a lot of time on this, as it's all but pointless. I > did read your post. The parts where you say Unix can outperform the AS/400 > as a LAN server are correct, the points where you say you can write business > applications on it are not. FreeBSD has no integrated database, uses crap > like Oracle, and so will never work as a business logic server. > > That's all I want to say. Read whatever you want into it. FreeBSD can > never support a real enterprise-level business application and an AS/400 can > (and no, Yahoo is not a real business application, it's a web application - > different animal). You like FreeBSD? Great. Use it. Just don't compare > it to OS/400. They're different beasts. > > Joe > > +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-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.