Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

String of variables depending upon length

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Shriram Jogdand

New User


Joined: 14 Oct 2008
Posts: 65
Location: Pune

PostPosted: Tue May 31, 2011 4:19 pm    Post subject: String of variables depending upon length
Reply with quote

Hi,

I want to string 2 vaiables which are declared as X(30). I want to srting them depending upon length variables which will be dynamically calculated. I tried below but not working since it is asking for DELIMITED BY parameter. Now can you tell me which parameter I need to give in DELIMITED clause?

STRING Ws-Var1(1:WS-DATA-LENGTH-1)
Ws-Var2(1:WS-DATA-LENGTH-2)
INTO Ws-var3
Back to top
View user's profile Send private message

dbzTHEdinosauer

Global Moderator


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

PostPosted: Tue May 31, 2011 4:24 pm    Post subject:
Reply with quote

duh, how about BY SIZE?

suprisingly this info is found in the manual
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue May 31, 2011 6:02 pm    Post subject: Re: String of variables
Reply with quote

Shriram Jogdand wrote:
Hi,

I want to string 2 vaiables which are declared as X(30). I want to srting them depending upon length variables which will be dynamically calculated. I tried below but not working since it is asking for DELIMITED BY parameter. Now can you tell me which parameter I need to give in DELIMITED clause?

STRING Ws-Var1(1:WS-DATA-LENGTH-1)
Ws-Var2(1:WS-DATA-LENGTH-2)
INTO Ws-var3


Instead of trying to use reference modification in the STRING, why not just use the reference modification?

Ws-Var1 to Ws-var3
Ws-Var2 to Ws-var3 starting from ( ws-data-length-1 + 1 ) (length irrelevant, Cobol will just move what there is anyway, trailing blanks are blanks whether moved or padded).

I know the above is not Cobol code, but there's no such thing as a free lunch.

Can't see a need for the length of the 2nd field.

Doing this way, I'd comment it:
* Concatenating two "strings" seperated by one space.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue May 31, 2011 6:25 pm    Post subject: Reply to: String of variables
Reply with quote

Of course, I don't know if you have trailing blanks. If you do, you don't need to calculate the 2nd length for the STRING. If you don't, then you'd need the 2nd length for the reference modification move.

As Dick says, check out STRING in the manual. While you are at it, look at UNSTRING as well, so you get to know what that can do. Heck, toss in INSPECT also. You might be able to get your field length(s) easily with that.
Back to top
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Wed Jun 01, 2011 10:58 am    Post subject: Re: String of variables
Reply with quote

1) do you have access to manuals.
2) do you have access to quick reference(on mainframe)

option 2 is quicker and easier way of getting all the info 1 needs for day-to-day work.

The string statement you have pasted in the original query has a syntax error. Manuals/QW would have helped you rectify this. Once you have the statement in a TESTable state you can do a quick 2-3 tests to verify the functionality of certain keywords yourself. This way one tends to remember things for long.

About your query:
I am assuming that you have to remove trailing blanks with one blank(between the 2 fields).

For a couple of 30 byte long alphanumeric fields, using STRING is not the efficient way fo doing it. Specially if your program is a batch program supposed to process thousands of records one after the other with this logic in place.

You could use an inline perform(with reference modification on the first field) in reverse direction to find the first non-space character in the first field and then attach the second field at that point(dont worry about the length of the second string).
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


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

PostPosted: Wed Jun 01, 2011 11:46 am    Post subject:
Reply with quote

Quote:
For a couple of 30 byte long alphanumeric fields, using STRING is not the efficient way fo doing it. Specially if your program is a batch program supposed to process thousands of records one after the other with this logic in place.

You could use an inline perform(with reference modification on the first field) in reverse direction to find the first non-space character in the first field and then attach the second field at that point(dont worry about the length of the second string).


Have to take issue with a few points.

1. with todays cpu power, you need to approach millions of records before you can measure an appreciable difference in time.

2. with todays new compilers, the STRING and UNSTRING (as well as INSPECT) are no longer the cpu hogs they once were.

3. compare the code generated between
a routine with reference modification
and
the same routine with well thoughtout data layout and using INDEXED by.
you will find less code is generated by one byte moves with INDEX than with reference modification - especially if offset and length are variables.
Though, again, todays processor speeds make the difference of execution negligable until you reach the multimillion repetition mark.

4. Probably most important:
STRING and UNSTRING (and INSPECT) require less code,
whereas reference modification requires the coder to actually understand what he is doing (clearly not the case here).
and, if the data definitions change in length,
the code in the perform routine with reference modification also must change.
not so with STRING, UNSTRING, INSPECT.

IMUO:
a last comment:
if you want to be an Assembler programmer,
program in assembler - people following your code expect the BS incountered.

but if you are coding in COBOL - use the commands available,
don't create little routines of assemblerise type COBOL.

Reference modification is/should be employed for rare instances when data-layout changes are difficult or overly complicated.

A COBOL program should be written so that one can look at the data layout and anticipate what going on,
and not have to get into the bowels of code to find the little gotchas'.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Wed Jun 01, 2011 2:52 pm    Post subject:
Reply with quote

nihalansari, your lack of COBOL skills shows in your post. Why do all this
Quote:
You could use an inline perform(with reference modification on the first field) in reverse direction to find the first non-space character in the first field and then attach the second field at that point(dont worry about the length of the second string).
when it would be much easier to just use FUNCTION REVERSE then INSPECT TALLYING LEADING SPACES? Same result in 2 COBOL statements (3 if you include the SUBTRACT statement).

Furthermore, STRING is a perfectly acceptable way to do the original task, anyway. Whoever told you that it (STRING) would not be efficient
Quote:
to process thousands of records
is extremely mistaken. Since z machines execute millions of COBOL statements per second of CPU time (I've tested this by the way), running mere thousands of records through a STRING statement versus some other method might cause the CPU time to jump by some fraction of a second -- but not more.

There is a Beginner's and Student's Forum that might be more suited to your level of COBOL skills.
Back to top
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Wed Jun 01, 2011 3:14 pm    Post subject:
Reply with quote

The reason why String, Unstring and Inspect are "called inefficient" is the underlying theory that they are ibm system routines which execute behind the scenes.

Reference modification is something that is not preferred in many shops but same is true for String, Unstring and likes. If I am working on a set of programs which were developed years ago and have been adhering to standards (like not use String etc.) then I will have to follow that in order to maintain uniformity in the code.

I have used String and Unstring in past as well reference modification(though least preferred) and cobol indexed tables. It depends what suits us for a particular scenario.

Advances in technology like processor speed, memory etc. have made these concepts less important.
Back to top
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Wed Jun 01, 2011 3:20 pm    Post subject:
Reply with quote

Robert Sample wrote:
There is a Beginner's and Student's Forum that might be more suited to your level of COBOL skills.


There's indeed this nice forum. I often go there and try to learn from whatever possible source. I will keep visiting it coz I know I am far from being perfect.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Jun 01, 2011 8:36 pm    Post subject: Reply to: String of variables
Reply with quote

Something's been nagging away at me about my response. Aha (I finally thought) seeing the word "String" in the title made me assume text data. Nothing else to support that. All the trailing and intervening spaces were guesses. Not so good.

STRING, UNSTRING and INSPECT are Cobol verbs, part of the "Cobol Standard". How they are implemented is up to how the compiler is written. In such cases don't worry about "theories" (often baseless rubbish, by which I mean nothing but hot-air to support them) but worry about practice. If they were blisteringly slow in IBM Cobol, they wouldb't get used by those with experience.

I have seen many cases of horrible things that people did, byte-by-byte, to move data around. There are many ways to remove the hide from furry family pets, but the piles of butchered carcases I've seen from these sort of techniques are much larger from than from botched attempts to use STRING, UNSTRING and INSPECT (I'm old enough to miss TRANSFORM, but INSPECT does all that and more). The manual, or the manual and some practice. To be open about the byte-by-bytes, the usual problem was using very short datanames (saves all that typing) and then getting them mixed up. AKA incompetence, I suppose.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts SQZ pipe delimited file with 1 column... Rick Silvers DFSORT/ICETOOL 2 Sun Nov 06, 2016 8:11 pm
No new posts Joinkeys operation when key1 and key2... Susanta DFSORT/ICETOOL 5 Wed Nov 02, 2016 5:35 pm
No new posts Protection Exception while move 0 to ... Kevin Vaz CICS 10 Tue Oct 18, 2016 4:19 pm
This topic is locked: you cannot edit posts or make replies. Checking wether a string starts from ... sundaram.naveen CLIST & REXX 9 Thu Oct 06, 2016 11:56 am
No new posts Format to pipe delimited with variabl... pshongal SYNCSORT 6 Wed Sep 14, 2016 2:48 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us