Perhaps you could give us a sample of what you expected to be the output.
You said:
I can understand the FF at the begining of the first line.
However, the last output line puts REC 4 at the SAME LINE as record 3!
Also, is there a way to stop the FF and let the compiler automatically leaves the remaining lines black given a PAGE-SIZE?
Maybe if you put 'write fd-print-rec AFTER 1' for the rec 4 line then it might work - it did for me.
To stop the FF - don't put AFTER PAGE.
and let the compiler automatically leaves the remaining lines black given a PAGE-SIZE?
3. This line is somewhat incomprehensible.
I presume you meant - 'blank' and where are you giving a PAGE-SIZE. ?? - A4 A5 - Foolscap ??
I'm not trying to be hard on you but the result you got was precisely what you told the compiler to produce. - Give us a correct sample you want & we'll tell you how to get it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for taking the question, I will further explain what I want to say or do...
Point A
I expected the lines:
MOVE "REC 4" TO FD-PRINT-REC
WRITE FD-PRINT-REC
to cause the "REC 4" to print on a new physical line not on the same line as the previous one where "AFTER ADVANCING" was used. [edit]
I would be very surprised if this behavior is ANSI COBOL or ENTERPRISE COBOL.
Point B
As for page size, I am well aware that specifications such as A-4 is not possible.
I was implicitly referring to the logical page size in LINAGE clause had it ben specified.
My overall objective is:
*I want to write a report that can be printed from the PC or from the mainframe or viewed as file without using MS-Word or another tool and want it to look the same. *
This requires that no control characters be part of the line. However, this implies that AFTER ADVANCING PAGE is not to be used (or possibly any AFTER ADVANCING) since it generates the "FF" (by default).
My other option is to manually code the advancing to a new page by filling the current page with N blank lines after the last written line (assuming no footer).
Any suggestions will be much appreciated.
Thanks.
Last edit: Emmad 2021-11-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because you've said - WRITE FD-PRINT-REC AFTER 3
the 0D0A were written 'before' the data (3 times) - this left the 'print head' at that position - so the next piece of data REC 4 was written straight after - somewhat logical.
Actually look at the output as hex & you'll see what I mean.
Once you've started with the after advancing bizzo - you're effectively hooked.
I haven't written a report file in donkeys years but either you use the correct report function (which I've never used) OR you describe the whole page in w-s & write to specific lines as required - OR you use a line counter. That's the way I'd have done it.
The last one will give you a format that can be viewed in word or text editor - the one using w-s will require you to dump w-s line by line to the output file and then blank the whole lot out again - but that again should give you a word/editor type file & both methods should work fine to dump to a printer as well.
Others may be able to show how to use the built in report generator part of Cobol - but I doubt that will give a word/editable file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
kind of funny answer since the report writer is there to - guess - write formatted reports.
printing 'FF' for form feed is simply wrong it should be ASCII 12.
Since the first post mentioned word I assume Windows. So Line feed should be CRLF and it seems to be that according to the output.
the
MOVE "REC 3 AFTER 3" TO FD-PRINT-REC
WRITE FD-PRINT-REC AFTER 3
does NOT exactly what it is supposed to do, print 3 blank lines and then the record it just print 2 blank lines
shouldn't
MOVE "REC 4" TO FD-PRINT-REC
WRITE FD-PRINT-REC
do a implicit
MOVE "REC 4" TO FD-PRINT-REC
WRITE FD-PRINT-REC AFTER 1 ?
hmm - that would be also wrong, because in that case there should be ONE blank line in between REC3 and REC4.
it is even worse - shouldn't each write of a line always end with a Line feed? So that line 4 is automatically on a new line AND ends with a new line also?
even the compiler itself does not like the last line of a source NOT be terminated by a line feed so a line sequential file as output should put a line feed on the end of every record?
something is wrong here,
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, thanks for your thoughts. I get different representation of the first byte in the line 2 depending on the editor used, for example, see the image below.
AFTER 1 should push the line down 1 line, write the record out, then position the logical print head on the next line at either the first column (On IBM I guess it would use 2nd column shine the first is reserved for line control character known as ASA). Picture:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IF you DON'T say AFTER then the data IS followed by a CRLF - REC1 & REC 4
BUT IF you DO say AFTER then the data IS NOT followed by a CRLF - REC2 after page
REC3 after 3.
IF you understand that then there are 3 CRLF's between REC2 & REC3.
SO the data output reflects what is requested - perfectly.
I have attached the specific statements from the Programmers Guide regarding Line advancing - perhaps this should have been specified to get YOUR required results.
LINE ADVANCING
These are files with an internal structure similar to that of a line sequential file.
These files are defined (without an explicit ORGANIZATION specification) using the
LINE ADVANCING clause on their SELECT statement (see [SELECT], page 95).
When this kind of file is written to by a GnuCOBOL program, an end-of-record
delimiter sequence will be automatically added to each data record as it is written
to the file. A WRITE to this type of file will be done as if an AFTER ADVANCING 1
LINE clause were specified on the WRITE, if no ADVANCING clause is coded.
Like line sequential files, these files should not be defined to contain any exact binary
data fields because the contents of those fields could inadvertently have the end-of-
record sequence as part of their values — this would confuse the runtime system
when reading the file, and it would interpret that value as an actual end-of-record
sequence.
Last edit: David Wall 2021-11-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your explanation, almost all is agreed upon, however, the main issue I am having is why was the first WRIET followed by CRLF and the one for REC 3 was not followed by CRLF? That is, if the AFTER ADVANCING 1 is implicit when no ADVANCING is specified, REC 4 should appear on a separate line not appended to REC 3.
Please refer to: Google Books -Page 19
Last edit: Emmad 2021-11-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
REC 3 AFTER 3 -
There are 3 CRLF's before the RED 3 SO there are NO CRLF's AFTER the REC3 is written. IF you use the LINE ADVANCING clause on the SELECT statement then there WILL be a CRLF AFTER the REC3 line. - simples..
The guide specifically says: A WRITE to this type of file will be done as if an AFTER ADVANCING 1
LINE clause were specified on the WRITE.
You're not using 'this type of file' are you ?? -
specify the LINE ADVANCING and all will be well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
Thank you for your help in advance. I got this result from the code below using GNU COBOL 3.2 on Windows 10.
I can understand the FF at the beginning of the first line.
However, the last output line puts REC 4 at the SAME LINE as record 3!
EDIT
I discovered that if I write:
MOVE "REC 4" TO FD-PRINT-REC WRITE FD-PRINT-REC AFTER 1Then the text "REC 4" appears on a separate line as it was supposed to be.
This pages says that if AFTER ADVANCING is ommitted, that compiler assumes AFTER ADVANCING 1:
https://bs2manuals.ts.fujitsu.com/psCOBOL2000V16en/cobol2000-user-guide-13779/processing-of-cataloged-files-cobol-compiler-user-guide-81/sequential-file-organization-cobol-compiler-user-guide-87/creating-print-files-cobol-compiler-user-guide-93
Do you think a ticket needs to be opened for this?
END EDIT
Also, is there a way to stop the FF and let the compiler automatically leaves the remaining lines black given a PAGE-SIZE?
Last edit: Emmad 2021-11-14
Perhaps you could give us a sample of what you expected to be the output.
You said:
I can understand the FF at the begining of the first line.
However, the last output line puts REC 4 at the SAME LINE as record 3!
Also, is there a way to stop the FF and let the compiler automatically leaves the remaining lines black given a PAGE-SIZE?
and let the compiler automatically leaves the remaining lines black given a PAGE-SIZE?
3. This line is somewhat incomprehensible.
I presume you meant - 'blank' and where are you giving a PAGE-SIZE. ?? - A4 A5 - Foolscap ??
I'm not trying to be hard on you but the result you got was precisely what you told the compiler to produce. - Give us a correct sample you want & we'll tell you how to get it.
Thank you for taking the question, I will further explain what I want to say or do...
Point A
I expected the lines:
to cause the "REC 4" to print on a new physical line not on the same line as the previous one where "AFTER ADVANCING" was used.
[edit]
I would be very surprised if this behavior is ANSI COBOL or ENTERPRISE COBOL.
Point B
As for page size, I am well aware that specifications such as A-4 is not possible.
I was implicitly referring to the logical page size in LINAGE clause had it ben specified.
My overall objective is:
*I want to write a report that can be printed from the PC or from the mainframe or viewed as file without using MS-Word or another tool and want it to look the same. *
This requires that no control characters be part of the line. However, this implies that AFTER ADVANCING PAGE is not to be used (or possibly any AFTER ADVANCING) since it generates the "FF" (by default).
My other option is to manually code the advancing to a new page by filling the current page with N blank lines after the last written line (assuming no footer).
Any suggestions will be much appreciated.
Thanks.
Last edit: Emmad 2021-11-14
Because you've said - WRITE FD-PRINT-REC AFTER 3
the 0D0A were written 'before' the data (3 times) - this left the 'print head' at that position - so the next piece of data REC 4 was written straight after - somewhat logical.
Actually look at the output as hex & you'll see what I mean.
Once you've started with the after advancing bizzo - you're effectively hooked.
I haven't written a report file in donkeys years but either you use the correct report function (which I've never used) OR you describe the whole page in w-s & write to specific lines as required - OR you use a line counter. That's the way I'd have done it.
The last one will give you a format that can be viewed in word or text editor - the one using w-s will require you to dump w-s line by line to the output file and then blank the whole lot out again - but that again should give you a word/editor type file & both methods should work fine to dump to a printer as well.
Others may be able to show how to use the built in report generator part of Cobol - but I doubt that will give a word/editable file.
Thank you for your suggestions.
kind of funny answer since the report writer is there to - guess - write formatted reports.
printing 'FF' for form feed is simply wrong it should be ASCII 12.
Since the first post mentioned word I assume Windows. So Line feed should be CRLF and it seems to be that according to the output.
the
MOVE "REC 3 AFTER 3" TO FD-PRINT-REC
WRITE FD-PRINT-REC AFTER 3
does NOT exactly what it is supposed to do, print 3 blank lines and then the record it just print 2 blank lines
shouldn't
MOVE "REC 4" TO FD-PRINT-REC
WRITE FD-PRINT-REC
do a implicit
MOVE "REC 4" TO FD-PRINT-REC
WRITE FD-PRINT-REC AFTER 1 ?
it is even worse - shouldn't each write of a line always end with a Line feed? So that line 4 is automatically on a new line AND ends with a new line also?
even the compiler itself does not like the last line of a source NOT be terminated by a line feed so a line sequential file as output should put a line feed on the end of every record?
something is wrong here,
Mike
Hi, thanks for your thoughts. I get different representation of the first byte in the line 2 depending on the editor used, for example, see the image below.
AFTER 1 should push the line down 1 line, write the record out, then position the logical print head on the next line at either the first column (On IBM I guess it would use 2nd column shine the first is reserved for line control character known as ASA).
Picture:
IF you look at the hex of the output - it does exactly what it says it will.
REC 1 (CRLF)
(FF)REC 2-AFTER PAGE
(CRLF)(CRLF)(CRLF)
REC 3 AFTER 3
REC 4(CRLF)
IF you DON'T say AFTER then the data IS followed by a CRLF - REC1 & REC 4
BUT IF you DO say AFTER then the data IS NOT followed by a CRLF - REC2 after page
REC3 after 3.
IF you understand that then there are 3 CRLF's between REC2 & REC3.
SO the data output reflects what is requested - perfectly.
I have attached the specific statements from the Programmers Guide regarding Line advancing - perhaps this should have been specified to get YOUR required results.
LINE ADVANCING
These are files with an internal structure similar to that of a line sequential file.
These files are defined (without an explicit ORGANIZATION specification) using the
LINE ADVANCING clause on their SELECT statement (see [SELECT], page 95).
When this kind of file is written to by a GnuCOBOL program, an end-of-record
delimiter sequence will be automatically added to each data record as it is written
to the file. A WRITE to this type of file will be done as if an AFTER ADVANCING 1
LINE clause were specified on the WRITE, if no ADVANCING clause is coded.
Like line sequential files, these files should not be defined to contain any exact binary
data fields because the contents of those fields could inadvertently have the end-of-
record sequence as part of their values — this would confuse the runtime system
when reading the file, and it would interpret that value as an actual end-of-record
sequence.
Last edit: David Wall 2021-11-14
Thank you for your explanation, almost all is agreed upon, however, the main issue I am having is why was the first WRIET followed by CRLF and the one for REC 3 was not followed by CRLF? That is, if the AFTER ADVANCING 1 is implicit when no ADVANCING is specified, REC 4 should appear on a separate line not appended to REC 3.
Please refer to: Google Books -Page 19
Last edit: Emmad 2021-11-14
REC 3 AFTER 3 -
There are 3 CRLF's before the RED 3 SO there are NO CRLF's AFTER the REC3 is written.
IF you use the LINE ADVANCING clause on the SELECT statement then there WILL be a CRLF AFTER the REC3 line. - simples..
The guide specifically says:
A WRITE to this type of file will be done as if an AFTER ADVANCING 1
LINE clause were specified on the WRITE.
You're not using 'this type of file' are you ?? -
specify the LINE ADVANCING and all will be well.
I did it for you - see attached source code & output file - all is good.
I do appreciate your effort to provide help - Thank you very much.
Emmad - we're all here to help each other - that's the way we learn. :) Dave..
Lovely, Cheers :)