|
Hi Bill, Given the nature of user commands, I can't say I'd worry about it. CL programs are rarely optimized for performance. I see these types of job utilities or maintenance routines as being more of a convenience than as an integral part of an application. I'd hardly expect any command processing program to behave like a component of an application, leaving its files and resources open for the next call, and I'm not sure I'd trust one that did.... <G> Eric DeLong Sally Beauty Company MIS-Project Manager (BSG) 940-898-7863 or ext. 1863 > -----Original Message----- > From: bill.reger@convergys.com [mailto:bill.reger@convergys.com] > Sent: Tuesday, July 02, 2002 1:44 PM > To: Midrange-L@midrange.com > Subject: Writing Commands given an ILE World > > > I have always really liked having user-written commands to do > utility-type > functions. The ability to run them from a command line and also from > within a CL program was always very handy and understandable. > Especially > since AS/400 programmers use the OS/400 commands all the time. > > However I am finding that commands are becoming a bit limited > as one writes > more and more ILE functions. Because a command always runs a CPP (the > operative word being the last "P" for Program), you are getting the > performance issues inherent in CALLing programs rather than using a > subprocedure (or a module) as you would if the command was a > subprocedure > instead. And since most commands are designed and written > for one-pass > use, they (usually) open and close their files every time they're run. > > All of this seems to be a performance penalty when a command > is used over > and over. Any comments or opinions? > > Bill
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.