|
Hello,
midrange.com
* A [prototype] is actually a copy-book. I haven't
worked out how to define the prototype parameter as a reference to an
external data dictionary. Therefore, the field definition is whatever is
hard-coded in the parameter declaration. Is this correct, or is there
another way?
Paul Tuohy, and others, have explained how to use a reference to an externally defiend field in a /COPY member. That'll work -- however, in my experience, hard-coding the parameter lengths is a better idea.
Why? Let's look at an example:I have a file called CUSTMAS. It stores the customer's address in a 30A field. I write a service program to retrieve this address from the file. I create 500 programs that display the customer's address by calling a routine in my service program.
Then, 1 year later, I determine that 30A isn't long enough for an address. It'd be better to make it 40A. No problem, right? CUSTMAS is only used from one service program, so I can change the address field to 40A, and recompile only one object, right? Wrong. Because I used LIKE() for the prototypes, every program will break (without receiving any sort of "level check" or "signature violation error! They'll just corrupt memory!)
I can't simply recompile all of the programs because I don't know what that'll do. The 30A fields may be laid out on the screen in a manner that adding 10 characters will cause field overlaps. Or they may be going to a report where overprinting will occur. What a mess! I'll have to look at every single program individually, and I have to do that "all at once" because I have to change the file and upgrade the programs all at the same time or it'll break.
If I had hard-coded the length of the parameters on my prototype, then I could upgrade the file without affecting the callers of the service program. I could then add a new subprocedure to the service program that returns the longer address. All of the existing programs will still work, and new ones can use the longer field.
Now, after I've upgraded the file and service program, I can casually go through and update the 500 programs that call it. It's no longer a "time crunch" because the programs still work.
Does that make sense?Of course, another solution (although, it's somewhat more complicated) would've been to pass the address with options(*VARSIZE) and to pass the length as a separate parameter. That way, the service program could handle different sized address fields -- but, as I said, it's more complicated, and if I don't know the field is about to change, I probably wouldn't have done it that way.
* A program which requires the prototype needs to make
sure that the parameter passed to the procedure matches the attributes
declared in the prototype. If the prototype definition changes then it
seems extremely difficult to manage the amendment of all the programs
which use the prototype/procedure.
That's the reason you put a prototype in a /COPY member. The prototypes can then make sure that you're passing the correct values to the service program. Since you use the same prototypes everywhere, the attributes of the parms will always match.
Just something to think about.
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.
