|
----- Original Message ----- From: "Scott Mildenberger" <Smildenber@Washcorp.com> > Steve, > > The complexity can be removed by encapsulating the functionality into > procedures/modules. Only the person who writes this piece has to worry > about the complexity, for all the other programmers it can be simpler. > > Scott Mildenberger > Hi Scott, An example from work today. I was told to find out "how is the outq assigned to the debit packing slip" First stop to find out was the print pgm. I scan the code and find no OVRPRTF code. Next I look at the backround processor cl which calls the print pgm. It has an override, but it gets the override value from the *Lda. A search of the cl pgm shows the *Lda being loaded with data from the data queue which feeds the bp. Now I have to find the interactive pgms with send the "print debit packing slip" msg to the dtaq. I find that those pgms load the *Lda with info from different sources. etc, etc. That is tough to encapsulate. If it was all pgm call based from start to finish, no BP, I could ask a user to run the print option, put them in StrSrvJob debug, and step the code to find out what I needed to know. Steve Richter
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.