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.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.