Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Use OUTFIL OMIT=(...) or OUTFIL INCLUDE=(...). OUTFIL is processed after INREC.
If that doesn't answer your question, then please explain in more detail what you're trying to do with an example of the input records and the expected output.
Thank you, it exactly answers my question. But I realized it's more complicated. In fact I want to extract all lines containing "MOVE A TO B" in a COBOL PGM. Unfortunatly, some MOVE are on 2 lines and may be not subsequent
See the example below :
Code:
MOVE AAA TO BBBB
MOVE CCCC TO DDDDDDDDDD
MOVE EEEEEEE TO
FFFFFFF
MOVE GGGGGGGG
TO HHHHHH
MOVE IIIIIIIII
*
TO JJJJJJ
And I want, after PARSE :
Code:
MOVE AAA TO BBBB
MOVE CCCC TO DDDDDDDDDD
MOVE EEEEEEE TO FFFFFFF
MOVE GGGGGGGG TO HHHHHH
MOVE IIIIIIIII TO JJJJJJ
So, how to make the link between n lines performing the same MOVE ?
Thank you, it realizes exactly what I wanted in my example... but with a real COBOL program I've got some problem :
Result:
Code:
********************************* Top of Data ***************
IDENTIFICATION DIVISION. IF FIN-FIC-CALEND
MOVE SPACE TO IF FIN-FIC-ENTREE
MOVE SPACE TO IF FIN-FIC-DOSS
MOVE SPACE TO WS-CPT (05)
..........
MOVE RCB-DOSS-AFF-MAIT-NO-2 TO S-V14040-DOSS-AFF-MAIT-NO-2
MOVE RCB-DOSS-AFF-MAIT-CDT-2 TO CMEN IF RCB-ENG-DTDEB = ZE
MOVE WS-DATE-DB2-INIT TO ELSE
MOVE RCB-ENG-DTDEB TO CMEN IF RCB-ENG-DTFIN = ZE
MOVE WS-DATE-DB2-INIT TO ELSE
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
I gave you what you asked for. Now you're asking for a lot more.
I assumed from what you told me that you only had comment statements, blank statements, MOVE statements and at most one continuation line for a MOVE statement. But you appear to have all manner of statements beyond those. You would have to omit all but the type of lines you showed me originally for this to work.
will get you the correct output when the entire MOVE a TO b statement is on the same line. But it won't get you the MOVE statements split across lines. There's nothing special about the lines following the MOVE lines that would allow us to extract them without extracting other lines. If the continuation lines all had TO b we could do it, but they don't. There also seem to be instances of multiple continuation lines after a MOVE line. I don't know if you want to do something with those lines or not, but if you do that makes it even more complicated.
Maybe some method with grouping and SPLICE would do what you want, but I don't understand what you want sufficiently to say for sure.
I realize it's more complex than I thought. For example, I can see in the program to analyse such sequence like
Code:
MOVE WS-DATE-DB2-INIT TO S-V14040-DOSS-DOUV
S-V14040-DOSS-DCLOT
S-V14040-DOSS-DMODIF
S-V14040-DOSS-DPURGE
S-V14040-DOSS-DIV-DDEB
S-V14040-DOSS-DIV-DFIN
And we have to recognize what follows the "TO", e.g.
in
Code:
MOVE A TO B C PERFORM P
The result should be
Code:
MOVE A TO B
MOVE A TO C
instead of
Code:
MOVE A TO B
MOVE A TO C
MOVE A TO PERFORM
MOVE A TO P
The rule could be something like that :
check only lines whose column 7 doesn't contain '*' and after column 12 :
1- identify the statement ' MOVE '
2- extract word(s) before ' TO ', may be in next line(s) (even for ' TO ')
3- extract word(s) after ' TO ' and stop when a special words is found as statements PEFORM, MOVE, IF, CALL... (beginning of new statements which mean "end of the MOVE statement"), may be in next line(s) too.
in 3- the point '.' has to be excluded from the word
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
Just curious, Searchman, how would you describe the end product of what you are attempting?
Just a guess, but maybe a tool to "clean up" some source code (at least the moves). . .
In addition to the discoveries above there are others including very long literals, multiple MOVEs on one line, preserving indentation for readability, subscripting/indexing, reference modification, preservation of punctuation, and probably a few more.
How many applications/programs/modules need to be passed thru this process?
I don't think it depends on the number of programs. The need is to follow a few data from beginning of an application to the end of this (or other) application.
File1 => PGM1 => file2 => PGM2 => file3...
First, I want to associate data from COPY1 of file1 in PGM1 with corresponding data from COPY2 of file2 in PGM1 and then until file3 or more
So, I want to extract ALL "MOVE A TO B" in PGM1, PGM2...
CICS guy, what do you mean by "end product", the end of program ?
Note, as you said Dick, the statement might be complex in theory, but in general in this application the way to write COBOL is nearly the same (look at the file attached).
I think the rules I gave in my last post take almost every case.
Franck, The rules I described are independant of language COBOL except for the reserved words that are nothing but strings (consider a list of strings, e.g. PERFORM and IF with the possibility to extend this list)
The rules I described are independant of language COBOL
not completely true...
for other languages there are many grammar driven shortcuts
what You are trying to implement is some kind of parser,
and, no offense meant - Frank/Alissa, I am not convinced that
any sort product would be the right tool.
For many many languages there is an explicit statement terminator/separator
for cobol things are much more complicated,
sometimes there is an explicit terminator,
in the other cases the end of a statement/(the beginning of the new one)
is marked by a reserved word in the input stream
You are tring to implement a token driven parser,
as opposite to the normal grammar driven parsers
the logic for such a thing for the move statement could be
scan for the MOVE keyword
start to accumulate tokens until END-OF-STATEMENT(BEGINNING-OF-THE-NEW-ONE)
parse the saved string
for the sort approach
You should check for more or less 300 reserved words
I would go for a REXX approach ( many samples available )
for example the rexx parser of the SCLM component
available in ( check Your naming conventions )
"ISP.SISPSAMP(FLMLRCBL)"
could be a good starting point for the overall logic
When I said "independant of COBOL" I meant : "you don't have to know COBOL", but, of course, this algorithm wouldn't be correct for another language.
Now, at first approach, it seems to me a COBOL program can product the result. But, I'm careful, may be I'm wrong. But, I say again the "parser" is not to cover all possible cases, only programs of limited applications (where the way to code is similar)
Yes, you're right, UNSTRING can change data, I'll do a search for this statement. But in my applications I don't think there are used to move data from input file to output file.
