View previous topic :: View next topic
|
Author |
Message |
MARK OWEN
New User
Joined: 26 Jan 2010 Posts: 2 Location: Somerset,NJ
|
|
|
|
HI I have the following problem at work today ..
I have a string with multiple spaces inbetween and I have to concatenate another sting at the end of string 1
String 1 = ' <ABC> <CDEFGH> <IGK>'
String 2 = '</BKEEP>
However lenght of string 1 is too large 2200 bytes.
So when i try String delimited by SIZE I get unwanted spaces after the data . I cant use delimited by space too..since there are spaces in the data
Is there a way I could simply concatenate these strings as
'<ABC> <CDEFGH> <IGK> </BKEEP>'
Thanks for helping !!! |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Use FUNCTION REVERSE to reverse string 1, find the first non-blank using reference modification, reverse back string 1, calculate the position of the last character, and use reference modification to move string 2 to the right spot in string 1. |
|
Back to top |
|
|
tomehta
New User
Joined: 18 Aug 2008 Posts: 98 Location: India
|
|
|
|
Hi Mark,
just a illustration of what Robert told.
Code: |
MOVE FUNCTION REVERSE(WS-STMT-DATA)
TO WS-STMT-DATA-REV
INSPECT WS-STMT-DATA-REV TALLYING WS-SPACE-CNT
FOR LEADING SPACES
COMPUTE WS-STMT-DATA-ACTUAL-LEN =
LENGTH OF WS-STMT-DATA - WS-SPACE-CNT
MOVE WS-STMT-DATA(1:WS-STMT-DATA-ACTUAL-LEN) TO WS-STMT-DATA-ACTUAL
|
Do the same processing for the second string, and then
String them.
Hope this helps |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
or without using the unnecessary second 2200 byte area.
Code: |
MOVE ZERO TO WS-STRING-1-SPACE-CNT
WS-STRING-2-SPACE-CNT
INSPECT FUNCTION REVERSE(STRING-1)
TALLYING WS-STRING-1-SPACE-CNT FOR LEADING SPACES
INSPECT FUNCTION REVERSE(STRING-2)
TALLYING WS-STRING-2-SPACE-CNT FOR LEADING SPACES
COMPUTE WS-LEN-DATA-STRING-1 =
FUNCTION LENGTH OF STRING-1 - WS-STRING-1-SPACE-CNT
END-COMPUTE
COMPUTE WS-LEN-DATA-STRING-2 =
FUNCTION LENGTH OF STRING-2 - WS-STRING-2-SPACE-CNT
END-COMPUTE
MOVE STRING-2(1:WS-LEN-DATA-STRING-2)
TO STRING-1(WS-LEN-DATA-STRING-1 + 1:WS-LEN-DATA-STRING-2)
|
actually, you could have omitted the two computes and made them part of the reference modification, but I leave that to you. |
|
Back to top |
|
|
tomehta
New User
Joined: 18 Aug 2008 Posts: 98 Location: India
|
|
|
|
Hi Dick,
I have a question regarding performance of INSPECT, COMPUTE, STRING, MOVE (reference modification),
What is the decreasing order of performance for these verbs in cobol.
i know most of the times the performance tuning lies with database tuning. but say there is a pure cobol program and it need to be tuned for performance. (perhaps INSPECTING 1 MB Strings !!)
Regards |
|
Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007 Posts: 2146 Location: At my coffee table
|
|
|
|
tomehta wrote: |
I have a question regarding performance of INSPECT, COMPUTE, STRING, MOVE (reference modification) |
MOVE (reference modification): If the reference modification is hard coded, it is instantaneous, if variables, still damn quick.
COMPUTE: baring some strange wording, damn quick.
INSPECT: Probably somewhere between a TRT and an IF with reference modification, pretty damn quick.
STRING: A sweries of optimized IFs with rf and MOVEs with rf, pretty damn quick. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
What is the decreasing order of performance for these verbs in cobol. |
I have to ask why it matters to you. Unless your program has a loop running tens (or hundreds) of millions of times, performance should not be a concern -- unless you've got some really, really, really, really bad code. I've tested and consistently hit 10 million COBOL statements per second of CPU time, and I'm not running on a z10 which will be faster. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
tomehta,
you have asked an honest question; I'll give you an honest answer.
what CICS_Guy said is true.
with todays machine speeds and sophisticated/optimized compilers,
without the use of a performance analyzer,
you are mostly peeing-up-a-rope.
read the literature.
avoid subscripts.
absolute indexing is fastest (e.g. internal-cobol-table-item-variable(1))
indexing is next (e.g. internal-cobol-table-item-variable(index))
subscripting is slowest.
reference modification varies within the limits of the the above mentioned indexing variations compounded with the complexity of the expressions used.
the only objection I have to reference modification is that it is based on 'on the fly data defintion', as apposed to data definitions in working-storage and usage of indexing. but used properly, and well documented in the code, it is acceptable and used by me. But I have worked at many shops that outlaw reference modification.
tune the instructions in loops.
If something is only done once, try to use the best instruction for the purpose.
again read the literature and follow hints from people like Bill O'Boyle who have indepth understanding of the assembler generated by the cobol instructions.
remove COMPUTE from you list of 'bad performing instructions'.
STRING and UNSTRING are instructions that maybe slower than 'extremely well written code, written for the exact situation at hand',
but both instructions have a variety of traps (error exits) that facilitate easy to follow code.
INSPECT is universally know as slow.
But, sometimes an INSPECT CONVERTING/REPLACING/TALLYING is perfect for the situation, easy to follow (as opposed to a dizzying perform with ref-mod), easy to modify, and does not require a high level of experience on the part of the next programmer to follow.
you have to balance performance with ease of maintenance and readability.
and if you want to write assembler, write assembler and don't be silly in a COBOL program and try to impress the ignorant masses. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
Bill O'Boyle,
I again apologize for miss-spelling your name. |
|
Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007 Posts: 2146 Location: At my coffee table
|
|
|
|
dbzTHEdinosauer wrote: |
you have asked an honest question; I'll give you an honest answer.
what CICS_Guy said is true. |
I first learned FORTRAN, and then 1130 Assembler and saw a one for one relationship between the compiled code and the 'artfully scripted' assembled code.
Advancing to 'real' main frames, COBOL was easy but its performance against good Assembler code 'sucked'.
And, finally, optimization happened and any test I ran against my 'artfully scripted' COBOL or Assembler code versus the various newer verbs turned out to be pretty much a draw.
There are some things that should be avoided, things like using a display variable as a subscript, but trust the available verbs as good. |
|
Back to top |
|
|
tomehta
New User
Joined: 18 Aug 2008 Posts: 98 Location: India
|
|
|
|
Thanks All, its really informative.
Regards |
|
Back to top |
|
|
MARK OWEN
New User
Joined: 26 Jan 2010 Posts: 2 Location: Somerset,NJ
|
|
|
|
Thanks Everyone |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
Take heed to what CICS Guy, Robert, and Dick have said. If it's performance you're seeking, look at I/O, not which COBOL verbs to use. That's where 95% of your elapsed time is being spent. |
|
Back to top |
|
|
|