|
View previous topic :: View next topic
|
| Author |
Message |
Shriram Jogdand
New User
Joined: 14 Oct 2008
Posts: 65
Location: Pune
|
|
|
|
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 |
|
 |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
duh, how about BY SIZE?
suprisingly this info is found in the manual |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| 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 |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| 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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
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 |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
| 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 |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
|
|
