|
James, I used to use /copy a lot, even wrote a utility to allow nested copies, located source, and proper line type placement. Since I started using RPGIV, I have found that wherever I used /copy in RPGIII, a sub-procedure in a service program would work even better. We use an I/O server that calls file specific modules contained in service programs for all I/O. There are lots of advantages. David Morris >>> "James W. Kilgore" <qappdsn@ibm.net> 06/17/99 10:21AM >>> Bruce, This is exactly what we do. Only the routine is in a /COPY member. There are a couple more lines than in your example. Like we set a return code so the caller does not rely on an indicator. I made mention to SAA in regard to different thread, but back in 1987 when it was introduced we adopted a couple of it's concepts such as function isolation. This pretty much forced us into heavy /COPY usage. Well forced is a strong word. We chose that over cut/paste 'cause we're lazy. It has provided great benefits when a major overhaul has to be performed. If the CHAIN operation code changes, we have a single /COPY member per file to change then compile away. Now that we are moving towards ILE, we are still sitting on the fence as to whether this should be in a service program or not. Regardless of how we exercise record retrieval, the request would stay isolated in the /COPY. It could just as well contain a CALLP instead of a CHAIN. Any thoughts on using a service program for disk operations? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the RPG/400 Discussion Mailing List! To submit a new * * message, send your mail to "RPG400-L@midrange.com". To unsubscribe * * from this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe RPG400-L' in the body of your message. Questions should * * be directed to the list owner / operator: david@midrange.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.