IBM Mainframe Forum

Hello,

Anyone could help me to solve the below query.It's one of the interview question recently faced.

There are 4 files, file 1 has the value 234567, file 2 has the value 567 now we would need to compare file 1 and file 2 and write the results in file 3 and file 4.

condition is file 3 should have the matching values of file 1 and file 2 and file 4 should have the unmatched values. Please write the program to get the desired output.

output should be file 3 = 567 and file 4 = 234. Hope my question is c lear.

Anyone please help me with the logic.

Lavanya Arun wrote:Please write the program to get the desired output.

No.

As this is your first post here, let me simply point out that this a help forum, not a give me code forum. If you want our professional product, be prepared to pay our professional rates (on the close order of USD 1000/day).

Anyone please help me with the logic.

OK, that's a reasonable request.

IIRC, Mr. Scherrer has posted skeleton for a two-file match COBOL program in a forum sticky. Have you looked at that?

Mr. Scherrer has posted skeleton for a two-file match COBOL program in a forum sticky.

I think this is a different requirement. It is a "substring" thing. My favourite use for OCCURS DEPENDING ON. I'll try to post an outline later.

im sorry Akatsukami for asking to write the program but what i meant was the program logic. I've gone thru the post by Mr.Scherrer. As Billy said im looking for another string move logic please.

Thanks Billy could you please help me with that?

Firstly, for your interview question (there is a seperate forum for those) your interviewer may have been looking for knowledge of "reference modification", INSPECT, STRING or UNSTRING. You should look all of these up in a manual and become fully aware of them.

I hope your answer was something like "I don't know, but I'd start by looking for string manipulations in the manual".

Another way to do the is byte-at-a-time (using subscripts or indexes) and ending up with some long intricate coding.

This is yet another way.

To start, an example of picking out substrings. "Hard-coding" the values is not much practical use (as if you knew the positions and lengths beforehand you could define the data like that) it is just to show how the substring extract works with these data-structures.



With OCCURS DEPENDING ON (ODO) you can make data have different lengths. You might find ODO used for an array of items in a record on a variable-length file. You might find it used to define a table range for SEARCH ALL. Again, look it up in the manual, and get a complete understanding of it.

Here we have an array which is only one byte long. In fact, two such arrays, one after the other. There is no problem if one, or both, of the depending on values is zero. Cobol knows about that. So, the first array we can use for the displacement along the full string, and the second array for the length of the substring.

Once we have the substring ready, just MOVE it like you would any other field. You can move it to a "plain" data-name, or to even to a data-name of a specific length (here I have used REDEFINES to combine the effect of both). If you just want to move it to a variable-length field (without it being a redefines) just make sure you make the OCCURS equal to the maximum possible length, as without the redefines it will be the definition with the ODO which is telling Cobol how much storage to allocate. In our example, this would be



Paste the first code-block into appropriate places in a little "noddy" Cobol program. Compile and run.

If you have SSRANGE or SSR as a compile option, change it to NOSSRANGE or NOSSR. The program will still work either way, but I hate the idea of SSRANGE/SSR (look it up in the manual if you are unaware of it).

Now a bit more detail for the specific problem.

Let's imagine you have one input file containing a number of records, each record consisting of a "string" of letters/symbols/whatever.

Let's also imagine you have a second input file containing one record, consisting of the "string" you want to remove (if present) from the strings on the first file.

The original string minus the substring (if present) is to be written to a third file. The substring (if found) to be written to a fourth file (including a "blank" record for the not-founds). There may be more than one substring match, so there may be more records on the fourth file than on the first. The third file should contain the same number of records as the first, so, if the searched-for string matches the entire input, a blank record must be output on the third file.

This requirement may be longer than the interview question, but it is a bit more realistic.

The input files can be very simple fixed-length, PIC X(whatever).

The third file could contain a flag (for matched or not), the length of the remaining string (could be zero) and the remaing string (in a fixed-length field same length as the first file).

The fourth file could contain a flag (for matched or not), the displacement of the substring, the length of the substring, the original string searched for (for confirmation) and the substring itself (both these last in fixed-length fields the same size as the second file).

Ready?

BTW I wrote the previous code in WORDPAD, and it has no SYNTAX CHECK button, so if you get compile errors, fix them yourself please.

MOVE your string from record on the second file to W-FILE2-STRING
MOVE W-FILE2-DISPLACEMENT-OF-LAST-BYTE TO W-FILE2-SEARCH-BACKARDS-DISPLACEMENT

Use a "loop construct" of your choice to reduce the value of W-FILE2-SEARCH-BACKARDS-DISPLACEMENT by 1 until
W-FILE2-STRING-TEST-FOR-NON-BLANK is not equal to space. Note, when your input field contains no trailing blanks, the "loop construct" should not execute. Note also, that if the field is entirely blank (ie
W-FILE2-SEARCH-BACKARDS-DISPLACEMENT becomes minus 1) then you have an entirely blank field and you should stop looking.

The length of the string on the second file, W-FILE2-STRING-LENGTH, can then be calculated as
(W-FILE2-SEARCH-BACKARDS-DISPLACEMENT + 1). Note, this will give you zero if the field is entirely blank.

Then we've finished with the second file.

For each record on the first file, first do a similar thing to above (all in new fields).

Then

Set a match flag off

if the two strings are zero length, set the match flag on, write the appropriate fourth file record and avoid the code to the end of the loop below
otherwise
if either of the strings are zero length, avoid the code to the end of the loop below (and will default to a non-match).

Now the guts of the thing. Some more data first.



MOVE ZERO TO W-FILE1-SEARCH-DISPLACEMENT
Calculate W-FILE1-LAST-DISPLACEMENT-TO-CHECK as W-FILE1-LENGTH - W-FILE2-STRING-LENGTH.
MOVE W-FILE1-LENGTH TO W-FILE1-REMAINING-LENGTH

A loop construct, where W-FILE1-SEARCH-DISPLACEMENT is incremented as the last statement in the loop. The loop should not be entered when
W-FILE1-SEARCH-DISPLACEMENT is greater than W-FILE1-LAST-DISPLACEMENT-TO-CHECK.

inside the loop
if W-FILE2-STRING is equal to W-FILE1-SUBSTRING, set match flag, write appropriate record on fourth file
then calculate W-FILE1-SHUFFLE-LENGTH as W-FILE1-LENGTH - W-FILE1-SEARCH-DISPLACEMENT and W-FILE1-REMAINING-LENGTH as
W-FILE1-SHUFFLE-LENGTH - W-FILE2-STRING-LENGTH
then MOVE W-REMAINING-PART-OF-STRING TO W-SHUFFLE-OVER-SUBSTRING (which is longer, so will be padded with trailing spaces to blank out the end of the string that is the length of W-FILE2-STRING-LENGTH)
calculate W-FILE1-REMAINING-LENGTH as itself minus W-FILE2-STRING-LENGTH
otherwise calculate W-FILE1-REMAINING-LENGTH as itself minus 1 (the keeping-in-step of this is just for information and consistency, no effect on the logic)
end of the loop (remembering to increase W-FILE1-SEARCH-DISPLACEMENT as mentioned earlier)

test the match flag and write an appropriate record to the third file

When you've finished the first file's records, close everything that is still open and display the counts that you have been assiduously keeping.

That's about it.

WORDPAD again. Uncompiled, untested. Not even code, couldn't compile it. Haven't desk-checked it either.


This moves the "complexity" of the byte-by-byte approach from the procedural code to the data definition.

Once you've cracked it, you may find many uses for it. I've used similar types of data structures many times, although not usually from scratch over a long period of time.

Or do a call to a Rexx routine. Rexx has functions that can find one string in another. 3 or 4 lines of code and return to your clumsy COBOL program!

NicC wrote:Or do a call to a Rexx routine.

Now there's an interesting answer. Didn't know you can do that.

Do I compile the Rexx code? Does "interpret" still work?

or... look here for string matching algorithms
http://www-igm.univ-mlv.fr/~lecroq/string/