Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ACUCOBOL Coding Of Copy Statements 1

Status
Not open for further replies.

klophockey

Programmer
May 25, 2016
41
0
0
US
I am trying to compile an ACUCOBOL program which has copybooks instead of hard coding the information for File-Control, File Section and Working Storage.

It seems that the syntax I have coded in the program is wrong. However, I look at documentation that says I have coded it right.

I could use some input from some experts on how I should code a copybook to where the compiler will accept the syntax.

Below is an example of how I have things coded.

PROGRAM-ID. MYPGM.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
copy "SELECTS.sl".



DATA DIVISION.
FILE SECTION.
copy "FILEDESC.fd".



WORKING-STORAGE SECTION.
copy "WRKSTG.wrk".



PROCEDURE DIVISION.
MAIN.

DISPLAY 'Begin MYPGM Cobol Program'.

DISPLAY 'End CTUTIL2 Cobol Program'.

Goback.
 
post the complete error you are getting - most of the times it is a compile directive that is wrong or the copybooks can't be found on the directory where the compiler is looking for them.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Thank you very much for your response.

I am perplexed because I think I have the syntax correct AND the copybooks are in the same folder as the Cobol program.

Do you know of a something or some kind of switch in ACUCobol compiler that tells it where the copybooks are located? Just wondering if that is my problem.

Here are the error messages. Also, here is how things are coded in my program (this one being simplified for example sake)

MYPGM.cbl, line 4: Missing COPY file: 'slfiles.cpy'
MYPGM.cbl, line 10: Missing COPY file: 'fdfiles.cpy'
MYPGM.cbl, line 15: Missing COPY file: 'WrkStg.cpy'



PROGRAM-ID. MYPGM.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
copy "slfiles.cpy".

DATA DIVISION.
FILE SECTION.
copy "fdfiles.cpy".

WORKING-STORAGE SECTION.
copy "WrkStg.cpy".

PROCEDURE DIVISION.
DISPLAY 'Hello World'.
Goback.
 
I wonder if the PATH is set correctly. That is, is the compiler finding the file? To check this idea, I would hard-code the path, and/or move the copybooks into the directory where you are doing the compilation. While I am not familiar with AcuCOBOL, I have worked in Microfocus COBOL, and there is a specific parameter for the path to the copybooks.

==================================
advanced cognitive capabilities and other marketing buzzwords explained with sarcastic simplicity


 
Which operating system?

Tom Morrison
Consultant
 
2 possible things
1 - OS is case sensitive and the copybook names are not the exact case as they are on the filesystem.
2 - COPYPATH env variable is not set or is set and is not pointing to the correct folders

options for reading copybooks are
1 - current directory (where the ccbl is executed)
2 - locations defined on COPYPATH
3 - hardcoded location on source. e.g. copy "c:\myfolder\mycopybookname"

and it helps reading the manual

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Thank you for the responses.

You all nailed it absolutely correctly. Once I fixed the path for the copybooks it found them as it should.

Rookie mistake!! Thanks for your patience as I have worked with ACUCobol previously and it seems to have some quirks that are different from MFCobol


MAY I ASK ONE MORE QUESTION THAT I CANNOT SEEM TO FIND INFORMATION about......

Below I will show you a short piece of code. The compiler kicks out a message that says 'number too large' for the X(2000) line of code. I have changed the dataname to a very short name and I have changed the X(2000) to X(2) and I still get the error.

There are no other errors that kick out of the compile

Could you please tell me what I am missing

CTUTIL1.cbl, line 10: number too large


FD ACUFL1A.
01 ACUFIL1A-REC.
05 ACU1A-KEY Pic 9(9).
05 ACU1A-TEXT-DATA Pic X(58).
05 ACU1A-ALPHA Pic X(10).
05 ACU1A-ALPHANUMERIC Pic X(20).
05 ACU1A-NUMERIC Pic 9(5).
05 ACU1A-SPACES Pic X(2966).
05 ACU1A-ZEROS Pic 9(31).
05 ACU1A-ZEROS-IN-SPACES Pic X(2000).
 
as that is just a snippet of the code I would say the error is on the 9(31) not on the x(2000).
Note that although the max numeric size is 31, compile options may reduce this size for compatibility with other commpilers.

there is an compile option that will give you the full listing including all items that are included on the compile and the exact error below or above the line in error.

possibly the following options on top of those you have
-e error.lst -Lf -Lo listing.lst
where
-e - error file output
-Lf - full listing
-Lo - output listing file

if you can't find the issue post here the full compile command line and the output of both error.lst and listing.lst after you change the command line to include the options above and we may be able to help further.


Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Frederico Fonseca - You have been very kind to share your knowledge with me. Thank you very much.

You have provided GREAT INSIGHT into the issue I was encountering.

Just as a quick test, I reduced the size of the 9(31) to 9(10) and the compile did not fail.
I greatly appreciate the compiler option information as it will help me to know the maximum size that I can use in my program.

Interesting to note that ISCobol and MFCobol compilers will allow the 9(31) but the ACUCobol compiler will not. It may just be an installation limitation and not truly the ACUCobol compiler, also.

Again, thank you for taking time to point me in the right direction and generously share your expertise.
 
Acucobol depending on the version and compiler options will allow pic 9(31) according to the manual

Acucobol is really the best of all COBOL Compilers. If we ignore all the add-ons the other vendors have this one has a huge number of better options from a development point of view and almost all portable to all OS's the runtime runs on. and I have worked with allmost all vendors over the last 30 years.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top