|
From: "Walden H. Leverich" <WaldenL@TechSoftInc.com> > 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. My understanding is that ASPs are processed by a COM component that reads, parses, and interprets the VB script found in the page. That component supplies a runtime environment for the script. It is separate from IIS, but uses ISAPI to interface with IIS. I'd bet that COM component has some internal storage for cached pages, similar to Net.Data. > 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) That's a good use for scripting technologies, in my opinion too. > However, I draw the line at any serious business logic or any > updates (add/change/delete) of any kind. That's good too. For one thing, a lot of business logic mixed with HTML leads to code that's hard to follow, and maintain. > 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. That sounds interesting. How is it done? Other ASP programmers who I know like to create their own COM components for business logic. It's separate from the ASP, but is activated from the ASP, and runs under Windows. > 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... That's a good division of skills. > 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. Very good division of skills. For robust, highly-interactive applications, my preference is to give the business programmer a little more control. The HTML page doesn't call the RPG program. The RPG program writes the HTML page. A subtle difference that puts the business programmer in the driver seat. The HTML guru still designs the user interface, but passes it to the business programmer to implement. Nathan M. Andelin www.relational-data.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.