|
> Let's not forget that the "sub-programs" which > perform acceptably today for occasional interactive > use are often the buggers that chew up our > day-end window when called repeatedly in large batch runs! > > My point is that a good programmer should be looking > forward a little ways at anticipated uses, and not > just at the immediate problem at hand. Excellent points John! By way of agreement, I once worked on an application that progressed exactly as you describe. What ran well for a few dozen records at a time (load a subfile page) became a morass when run over several thousand A/R transactions in batch. We ended up having to share access paths, not set LR on when returning from the sub-programs and carefully minimise file I/O (passing entire records as parameters instead of adding an F-spec and CHAINing.) This was on S/38, so there was no easy way around the problem unless we converted the sub-programs to /COPY members. The name collisions alone would have spelt doom to that attempt. --buck
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.