I'm watching COBOL tutorials, they use the "erase" statement to clean the screen and it doesn't work for me. The compiler indicates "syntax error, unexpected ERASE"
The code is:
DISPLAY "1.- CALC, 2.- CLOSE" ERASE.
It is my mistake?
I am using opencobol on ubuntu
Sorry about my English, it's not my native language
As noted by #user207421 ERASE is not a statement, it is a clause for the DISPLAY statement, and it even is standardized - but (standard-wise) it needs a specification what you want to erase:
ERASE [END] [OF] LINE
[END] [OF] SCREEN
EOL
EOS
The syntax you have shown is actually the very non-standard, outdated Microsoft-COBOL DISPLAY statement with ERASE phrase.
If you still use open-cobol then the package is heavily outdated, there should be a new gnucobol package available in Ubuntu (otherwise you could build from source). Using GnuCOBOL 2.2 you get a nicer error message:
error: syntax error, unexpected ., expecting LINE or SCREEN
And then you can decide if you want the old ms-cobol variant (that's supported in GnuCOBOL, but only with the pos-specifier) or the standard variant (ERASE EOS would be the compatible version and is supported by many compilers).
Related
I am trying to compile a simple program using COBOL and the gnuCOBOL cobc compiler. However, I cannot seem to get any sort of output for my program, error or otherwise. So I wrote a barebones "Hello World" program, and even that doesn't output as expected:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO-WORLD.
AUTHOR. Myself
PROCEDURE DIVISION.
DISPLAY "HELLO WORLD".
STOP RUN.
I am trying to copile this by running cobc -x hello_world.cob, which generates an executable, but the executable produces no output when run. What am I missing?
GNUCOBOL version 2.2.0
Your code starts at position 12 (or so it seems). GNUCOBOL expects it to start at position 8. You may either alter your code, or use the '-free' compiler flag.
The issue is rooted in the AUTHOR paragraph, but only in combination with the rest...
The AUTHOR paragraph is one of the comment paragraphs.
With fixed-form reference-format (which is where they commonly are found) those end whenever the next code starts in area a - and because the code is indented to column 12 there is no match and the complete rest of the program is skipped as "comment".
Note that this is identical with other compilers, too (I've checked with Micro Focus and ACUCOBOL).
Removing the comment line therefore "fixes" the issue, as well as the "real fix" that moves either all or all (COBOL2002+) or all but the statements (older reference-format) to column 8.
With free-form reference-format there is no "area a" and those comment-paragraphs therefore end with the start of the next line (which is the reason that compiling with --free "fixes" this issue as well).
Note: the comment paragraphs were removed with COBOL 2002, and because of the "special area-a handling" they are obsolete with GnuCOBOL (and only worked if "used correctly, as far as COBOL2002+ is concerned its support is an extension). With COBOL 85, where the comment paragraphs were already obsolete, the program would not compile because it enforces area a.
You can see this when compiling with the dialect and warning options:
$ cobc -xj hi.cob # compiles and runs, nothing happens
$ cobc -xj hi.cob -Wall
hi.cob:3: warning: AUTHOR is obsolete in GnuCOBOL [-Wobsolete]
$ cobc -xj hi.cob -std=cobol85 -Wall
hi.cob:3: warning: AUTHOR is obsolete in COBOL 85 [-Wobsolete]
hi.cob:1: error: 'IDENTIFICATION DIVISION' should start in Area A
$ cobc -xj hi.cob -std=cobol2002
hi.cob:3: error: AUTHOR does not conform to COBOL 2002
Note: area a enforcement depending on dialects is a GnuCOBOL 3.2 feature, this was not available back when the original question was asked.
Remove the line containing AUTHOR. Myself and it should work.
I am preparing overall knowledge on building a Forth interpreter and want to disassemble some of the generic Forth code words such as +, -, *, etc.
My Gforth (I currently have version 0.7.3, installed on Ubuntu Linux) will allow me to disassemble colon definitions that I make with the command see, as well as the single code word .. But when I try it with other code words, see + or see /, I get an error that says, Code +, and then I'm not able to type in my terminal anymore, even when I press control-c.
I should be able to decompile/disassemble the code words, as shown by the Gforth manual: https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Decompilation-Tutorial.html
Has anyone else had this issue, and do you know how to fix it?
Reverting to the old ptrace method did it for me.
First, from the command line as user root run:
echo 0 >/proc/sys/kernel/yama/ptrace_scope
After which see should disassemble whatever it can't decompile. Command line example (need not be root):
gforth -e "see + bye"
Output:
Code +
0x000055a9bf6dad66 <gforth_engine+2454>: mov %r14,0x21abf3(%rip) # 0x55a9bf8f5960 <saved_ip>
0x000055a9bf6dad6d <gforth_engine+2461>: lea 0x8(%r13),%rax
0x000055a9bf6dad71 <gforth_engine+2465>: mov 0x0(%r13),%rdx
0x000055a9bf6dad75 <gforth_engine+2469>: add $0x8,%r14
0x000055a9bf6dad79 <gforth_engine+2473>: add %rdx,(%rax)
0x000055a9bf6dad7c <gforth_engine+2476>: mov %rax,%r13
0x000055a9bf6dad7f <gforth_engine+2479>: mov -0x8(%r14),%rcx
0x000055a9bf6dad83 <gforth_engine+2483>: jmpq *%rcx
end-code
Credit: Anton Ertl
Most versions of SEE that I've seen are meant only for decompiling colon definitions. + and / and other arithmetic operations are usually written in assembly code and SEE doesn't know what to do with them. That's why you were getting the CODE error message: they're written in code, not Forth. There are several Forth implementations I've seen that have built in assemblers, but I don't think I've ever seen a dis-assembler. Your best bet for seeing the inner workings of + or / or other such words might be to use DUMP or another such word to get a list of the bytes in the word and either disassemble the word by hand or feed the data into an external disassembler. Or see if you can find the source code for your implementation or a similar one.
SEE is a word that has not a tightly controlled behaviour. It is a kind of best effort to show the code of a word X if invoked as
SEE X
It behaves slightly different according how difficult it is to do this. If you defined the word yourself in the session, you're pretty much guaranteed to get your code back. If it is a built in word, especially if it is a very elementary word like + , it is harder. It may look nothing much like the original definition, because of optimisation or compilation into machine code.
Specifically for gforth, if it gets hard gforth invokes the standard tools that are present on the system to analyse object files. So it may be necessary to install gdb and/or investigate how gforth tries to connect to it. For the concrete example of Ubuntu and gforth 0.7.3 Lutz Mueller gives a recipee.
.
I think SEE does it's job as designed.
There are words in FORTH defined in machine code (often called as primitives) and also there is a possibility to define machine code via assembler by the user ie.:
: MYCODE assembler memonics ;CODE
So the output of SEE shows not Code error, but that (ie.) + word was defined as machine code and one can see the disassembled mnenonics on the right of it's output.
I am running Ubuntu and trying to learn COBOL. I have dabbled in a few online tutorials but have had inconsistent results with certain programs.
I prefer to use vim in a bash shell; leading me to OpenCOBOL (cobc)
Is there a decent tutorial that will teach me the basics? I have been working through this one.
http://www2.southeastern.edu/Academics/Faculty/kyang/Cmps401/P2Cobol/Resources/Teach%20Yourself%20Cobol%20In%2021%20Days%20%282nd%20Ed%29.pdf
My issue is that when running some of the example source code, the compiler returns an error when trying to use a "*". It says it is expecting an end of file.
Here is my source code:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO-WORLD.
ENVIRONMENT DIVISION.
*comment here
DATA DIVISION.
PROCEDURE DIVISION.
DISPLAY 'HELLO WORLD!'.
STOP RUN.
Here is the command I am running:
cobc -x -free -o helloworld helloworld.cbl
Here is the error returned
helloworld.cbl:4: Error: syntax error, unexpected '*', expecting "end of file"
If you are using only the '*' comment, you need to use fixed form Cobol.
That means all of your division headers would start in "Area A", from columns 8-12, and your Display and Stop Run statements would start in "Area B", from column 12 - 72.
Or you could change the comment to a free form one, using '*>' and then it should work.
One of the best online COBOL learning resources is by Michael Coughlan, University of Limerick. http://www.csis.ul.ie/cobol/
Most, if not all the samples will work with GnuCOBOL, if you change the compiler directives to standard.
$ SET SOURCEFORMAT"FREE"
becomes
>>SOURCE FORMAT IS FREE
and change all the * column one comment markers to *>. If you like Vim, then those comment fixes are pretty easy
%s/^\*/\*>/gc
With those simple changes, the samples should compile clean with cobc. Michael has written one of the best beginner through advanced tutorials available on the net. Umm, that's a personal opinion.
I'm trying to make a very simple COBOL program. I've gotten my directory, configurations, etc. all set up, but when I go to compile it I get this error:
sampleCOBOL.cbl: In paragraph 'Main-Paragraph' :
sampleCOBOL.cbl:9: Error: syntax error, unexpected "end of file"
("sampleCOBOL.cbl" is my file name)
This is what my file contains:
Identification Division.
Program-ID. sampleCOBOL.
Data Division.
Procedure Division.
Main-Paragraph.
Display "Hello World!"
Stop Run.
I know that the error is occurring on Line#9 ("Stop Run."). However, why?
There is support for GNU COBOL (formerly OpenCOBOL) at SourgeForge.
From there, here is answer for the same error message: https://sourceforge.net/p/open-cobol/discussion/109660/thread/cdfe04a5/#0996
You can have you COBOL program obey the traditional fixed-column starts/ends, our you can put this, >>SOURCE FORMAT IS FREE in line one, column 12 of your program. You can then code without reference to column numbers.
If using column numbers, columns 1-6 are not used for code, column seven is for the comment, debugging, or new-page marker, or, rarely, continuing a literal which cannot fit on the previous line.
Code then either starts in columns 8-11 (aka "area a") or columnn 12-71 ("area b").
You do not need a full-stop/period in the PROCEDURE DIVISION except to end the PROCEDURE DIVISION header, before a paragraph/SECTION name and before the end of the program. In the distant past, you used to need lots of full-stops/periods, but not needed for many years (although many still code them).
Seeing your comment on the other answer and NealB's comment on your question, if you scroll down the linked-to discussion:
I have used Notepad++ for a lot of my own coding. You can set the EOL
to use UNIX instead of windows or UTF encoding. This will also resolve
EOF issues. Also, you will need to ensure you set "Use Spaces" when
tabbing. cobc has an issue when tabs are used from windows editors.
Putting that together, you are using Windows, tabs, and a version of OpenCOBOL which doesn't like tabs in source. You have two things to do directly to get it working, and you may want to get the latest version of GNU COBOL when it is convenient for you.
I suggest you go here, http://sourceforge.net/p/open-cobol/discussion/2526793/. Join, if you don't have a SourceForge account, or login if you do, and post in Help getting started. There are people there using Windows (which I don't) who should be able to help. The reason for login/join is that otherwise you will wait hours for your question to be "moderated" first, and you'll appear as Annonymous.
Figured out what was wrong. I had an extra line in between "Identification Division" and "Program-ID."
I have no idea how I missed that.
Boy, do I feel stupid.
The I of IDENTIFICATION must be at the column 8 ( 7 spaces before ).
---- sampleCOBOL.cob -------------------------
* Sample COBOL program
IDENTIFICATION DIVISION.
PROGRAM-ID. sampleCOBOL.
PROCEDURE DIVISION.
DISPLAY "Hello World!".
STOP RUN.
----------------------------------------
I faced the same problem recently when I just started learning COBOL. The point is each line should end with CRLF. You can refer here to see how you can achieve this.
Here is my minimal LaTeX document:
\documentclass{article}
\usepackage[polutonikogreek,english]{babel}
\newcommand{\Gk}[1]{\selectlanguage{polutonikogreek}#1\selectlanguage{english}}
\usepackage{ledmac}
\newcommand{\cn}[1]{\Afootnote{#1}}
\usepackage{ledpar}
\begin{document}
\beginnumbering
\pstart
\edtext{apostle}{\cn{\Gk{apostoloc}}}
\pend
\endnumbering
\end{document}
Executing latex test.tex produces the following error:
...
Section 1 (./test.1)
! Missing control sequence inserted.
<inserted text>
\inaccessible
l.15 \pend
?
Some notes:
The DVI produced looks fine despite the error.
Commenting out the \usepackage{ledpar} fixes the problem.
Not using the \Gk command also solves the problem. (But sort of defeats the purpose of having a footnote.)
What's going on here and how do I get around the error message?
According to the FAQ:
Sometimes LaTeX saves data it will reread later. These data are often the argument of some command; they are the so-called moving arguments. (‘Moving’ because data are moved around.) Candidates are all arguments that may go into table of contents, list of figures, etc.; namely, data that are written to an auxiliary file and read in later. Other places are those data that might appear in head- or footlines. Section headings and figure captions are the most prominent examples; there’s a complete list in Lamport’s book (see TeX-related books).
What’s going on really, behind the scenes? The commands in moving arguments are normally expanded to their internal structure during the process of saving. Sometimes this expansion results in invalid TeX code, which shows either during expansion or when the code is processed again. Protecting a command, using “\protect\cmd” tells LaTeX to save \cmd as \cmd, without expanding it at all.
So the \Gk command gets expanded too early in the process of TeXing the file and results in illegal code. The simplest solution is to declare the command robust:
\usepackage{makerobust}
\DeclareRobustCommand{\Gk}[1]{\selectlanguage{polutonikogreek}#1\selectlanguage{english}}
As to why using the ledpar package produces the error, I'm less certain. In order to facilitate notes in both the left and right side of parallel text, the ledpar package needs to redefine virtually every command provided by the ledmac package. Although I have not found the offending difference, one or more of the redefinitions must cause fragile commands to be expanded prematurely.