IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

String concatenation with spaces inbetween


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
MARK OWEN

New User


Joined: 26 Jan 2010
Posts: 2
Location: Somerset,NJ

PostPosted: Tue Jan 26, 2010 4:33 am
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Jan 26, 2010 4:44 am
Reply with quote

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
View user's profile Send private message
tomehta

New User


Joined: 18 Aug 2008
Posts: 98
Location: India

PostPosted: Tue Jan 26, 2010 1:51 pm
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Tue Jan 26, 2010 3:02 pm
Reply with quote

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
View user's profile Send private message
tomehta

New User


Joined: 18 Aug 2008
Posts: 98
Location: India

PostPosted: Tue Jan 26, 2010 4:20 pm
Reply with quote

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
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table

PostPosted: Tue Jan 26, 2010 4:32 pm
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Jan 26, 2010 4:48 pm
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Tue Jan 26, 2010 5:11 pm
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Tue Jan 26, 2010 5:44 pm
Reply with quote

Bill O'Boyle,

I again apologize for miss-spelling your name.
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table

PostPosted: Tue Jan 26, 2010 5:55 pm
Reply with quote

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
View user's profile Send private message
tomehta

New User


Joined: 18 Aug 2008
Posts: 98
Location: India

PostPosted: Tue Jan 26, 2010 5:59 pm
Reply with quote

Thanks All, its really informative.

Regards
Back to top
View user's profile Send private message
MARK OWEN

New User


Joined: 26 Jan 2010
Posts: 2
Location: Somerset,NJ

PostPosted: Thu Jan 28, 2010 7:52 pm
Reply with quote

Thanks Everyone icon_smile.gif
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

PostPosted: Thu Jan 28, 2010 8:53 pm
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 2
No new posts PARSE Syntax for not fix length word ... JCL & VSAM 7
No new posts Sortjoin and Search for a String and ... DFSORT/ICETOOL 1
No new posts leading spaces can be removed in trai... DFSORT/ICETOOL 1
No new posts file manager is doing string conversion IBM Tools 3
Search our Forums:

Back to Top