|
You're just trying to stir up trouble.. or maybe business? <GRIN> -----Original Message----- From: Walden H. Leverich [mailto:WaldenL@TechSoftInc.com] Sent: Friday, December 28, 2001 5:34 PM To: 'midrange-advisory-request@midrange.com' Subject: Web enablement options (previously private) All, Nathan and I have traded a couple off-list e-mails concerning web enablement options based on the shoot-out on his site mentioned in a prior midrange-l post. With his prior permission I'm bringing this thread back to midrange-l since we think it may be of interest to other midrange-l'ers. Nathan, I'm not very familiar with Net.Data so I can't comment on the comparison, but AFAIK there is no "cache" per-se in IIS so ASP pages would always be read into memory. Of course, there is the underlying disk cache so it's actually unlikely that you'd have a physical read if it was a frequently accessed page. As far as what I use ASP for, that depends on your point of view. I could either say "quite a bit" or "as little as possible." Let me explain... I have no problem reading data from tables on the AS/400 in ASP via ADO and SQL statements (select xxx from yyy where zzz) However, I draw the line at any serious business logic or any updates (add/change/delete) of any kind. In all those cases we call stored procedures on the AS/400 that are actually just RPG programs. These stored procedures are called from the ASP. My ASP programmers are responsible for simple select queries and more importantly, making the site look pretty. They needn't concern themselves with the details of the business logic or the cross-file updates necessary to allocate a rubber-widget from inventory in warehouse 1 for order 2. On the flip side, my AS/400 programmers must concern themselves with these business-critical operations, but they could care less if the customer name was in red or green, bold or underlined, in Arial or Times New Roman. All those decisions are important, but not to the AS/400 programmer. There is a severe line between programmers and web designers and it's rare that someone can cross over that line. -Walden ------------ Walden H Leverich III President Tech Software (516)627-3800 x11 WaldenL@TechSoftInc.com http://www.TechSoftInc.com -----Original Message----- From: Nathan M. Andelin [mailto:nandelin@relational-data.com] Sent: Friday, December 28, 2001 15:59 To: Walden H. Leverich Subject: Re: OS/400 *SAVF - Boats For Sale Table From: "Walden H. Leverich" <WaldenL@TechSoftInc.com> > As far as your questions go I've attached the only code involved (it's > all ASP, nothing on the AS/400). Walden, There's a striking similarity between your ASP file, and the 1st version of my Net.Data macro. It used SQL to populate a result set. I later changed it to call an RPG program for performance reasons. It was an attempt to make the Net.Data version look as good as possible. For simple requests like a report, a scripting solution (like Net.Data and ASP) is ideal. In contrast, my Relational-Web product is designed for robust, highly-interactive applications. Applications with significant scope. I've never worked with ASP, but the performance of Net.Data degrades terribly when macros are not in cache. Net.Data's internal cache is limited. In complex applications macros get swapped in and out memory regularly. CPU utilization goes up dramatically. Response time suffers. What do you use ASP for? Thanks, Nathan M. Andelin www.relational-data.com _______________________________________________ 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.