Posted: Wed Jun 02, 2004 1:02 pm Post subject: COBOL suprograms, and efficiency
Hi, all:
This is my first post, so be gentle.... (*grin*) I search the board, but could not find anything relating to this topic....
I assume it is normal that, when displaying a field like an SSN (e.g., going from a straight-numeric field like 123456789 to a display-oriented field like 123-45-6789), it is common to have an 11-byte alpha field redefined into components, with hyphens inserted in the appropriate places.
I know this isn't a whole lotta work, but it is more than a few lines of code:
Code:
MOVE SSN (1:3) TO DISP-SSN (1:3)
MOVE '-' TO DISP-SSN (4:1)
MOVE SSN (4:2) TO DISP-SSN (5:2)
MOVE '-' TO DISP-SSN (7:1)
MOVE SSN (7:3) TO DISP-SSN (8:3)
I thought I might create a suprogram to do it, e.g.,
Code:
MOVE SSN TO DISP-SSN
CALL 'XXLSSN01' USING DISP-SSN
and let the supgm do the moving. (I suppose I could use it for validation as well; of course, then I'd have to put in some error handling...)
What I'm wondering is: What kind of efficiency hit would I take externalizing something simple like this? Let's say I need to do it half a million times in the course of a batch job.
Is there a better way to do this, e.g., with COPY? I originally leaned away from COPY because I don't like having to re-compile multiple objects when the copybook changes. But for something this simple, I doubt that would happen.
I do like the REPLACING parm in the COPY statement, which gives a little more flexibility to objects using the copybook, e.g.,
Code:
COPY XXLSSN01 REPLACING ==:TAG:== BY ==DISP-SSN==
And this brings up another question: Is there a way to do more than one "REPLACING" in a copybook? In other words, can I do something like:
Code:
COPY XXLSSN01 REPLACING ==:I-SSN:== BY ==SSN==
==:O-SSN:== BY ==DISP-SSN==
This way, objects using the copy book could just substitute the field names bing used for the source-SSN and the display-SSN.
What do you all think? Any input would be appreciated.
Joined: 12 Jan 2004 Posts: 240 Topics: 48 Location: Maryland
Posted: Wed Jun 02, 2004 2:38 pm Post subject:
Greg, I guess COBOL does not allow that to avoid the confusion with the '-' (MINUS) sign .
IF you want to do it with one MOVE , how about trying this :
Define :
You can follow vini's idea along with an inspect statement to replace the spaces to hyphens('-')
01 SSN PIC 9(3)B9(2)B9(4).
MOVE 123456789 TO SSN
INSPECT SSN REPLACING ALL X'40' BY X'60'
Hope this helps...
Cheers
Kolusu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kolusu,
Yes, it does - thanks!
So, do I need to use the hex representation; i.e., could I just as easily use the following:
Code:
INSPECT SSN REPLACING ALL ' ' BY '-'
Also, I'm still curious if there is a way to do more than one "REPLACING" clause in a copybook? In other words, can I do something like:
Code:
COPY XXLSSN01 REPLACING ==:I-SSN:== BY ==SSN==
==:O-SSN:== BY ==DISP-SSN==
I suspect the answer is "no", but if so, I was wondering if anyone has devised an ingenious workaround to accomplish this.
Joined: 15 Dec 2002 Posts: 637 Topics: 43 Location: Bengaluru, INDIA
Posted: Thu Jun 03, 2004 3:46 pm Post subject:
IMO, COPY is for including copybooks; code written for WS or PROCEDURE DIVISION. It is a compiler-directive not a verb to handle strings. _________________ ALL opinions are welcome.
Debugging tip:
When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
-- Sherlock Holmes.
IMO, COPY is for including copybooks; code written for WS or PROCEDURE DIVISION. It is a compiler-directive not a verb to handle strings.
I think most would agree with that. My posted question about how to use multiple replacements in copybooks was not for string handling, but more for flexibility in other objects that would use the copybook.
It goes back to my original copybook-vs-subprogram question. If I have some relatively simple code (i.e., code just complicated enough that I don't want to duplicate it, but maybe not quite complicated enough to require a stand-alone compiled object, then I would probably use a PROCEDURE DIVISION copybook.
But doing so would require that all objects using the copycode to define and use the field names I defined in the copycode; this is not only less flexible, it may also cause field-uniqueness conflicts. I could work around this by using very long field names (probably prefixed by the copybook name), but this could be cumbersome and would also require objects to MOVE their variables to mine before executing the copybook code.
A better way may be to have the copybook use "symbolic variables" that each calling object could then provide in the COPY statement itself.
I wouldn't recommend this for more than, say, two or three fields (or field prefixes); anything more than that may get cumbersome to use. If the externlized procedure requires more than just a few fields, it is probably better suited to be a stand-alone compiled object.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum