I'm new to Fujitsu COBOL 3.0 software. I tried executing a simple program. The code and errors are as follows. Everything in program appears to be correct. Can anyone help me out? Any prestandards are to be followed in this software?
The sample cobol program is:
IDENTIFICATION DIVISION.
PROGRAM-ID. ShortestProgram.
PROCEDURE DIVISION.
DisplayPrompt.
DISPLAY "I did it".
STOP RUN.
--------------------------------------------------------------------------------------
** DIAGNOSTIC MESSAGE ** (NOPRGMID)
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 0: JMN1102I-S IDENTIFICATION DIVISION HEADER IS MISSING. HEADER ASSUMED TO BE CODED.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 1: JMN1019I-W INDICATOR AREA MUST CONTAIN '-','*','/','D',OR BLANK. A BLANK IS ASSUMED TO BE SPECIFIED.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 1: JMN1005I-W CHARACTER STRING 'DENTIFICATION' MUST START IN AREA B. ASSUMED TO START IN AREA B.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 1: JMN1356I-W INVALID WORD 'DENTIFICATION' IS SPECIFIED IN IDENTIFICATION DIVISION. IGNORED UNTIL NEXT PARAGRAPH OR DIVISION.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 2: JMN1019I-W INDICATOR AREA MUST CONTAIN '-','*','/','D',OR BLANK. A BLANK IS ASSUMED TO BE SPECIFIED.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 2: JMN1005I-W CHARACTER STRING 'ROGRAM-ID' MUST START IN AREA B. ASSUMED TO START IN AREA B.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 4: JMN1019I-W INDICATOR AREA MUST CONTAIN '-','*','/','D',OR BLANK. A BLANK IS ASSUMED TO BE SPECIFIED.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 4: JMN1005I-W CHARACTER STRING 'ROCEDURE' MUST START IN AREA B. ASSUMED TO START IN AREA B.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 6: JMN1004I-W RESERVED WORD 'DISPLAY' MUST START IN AREA B. ASSUMED TO START IN AREA B.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 7: JMN1104I-S PROGRAM-ID PARAGRAPH IS MISSING. PROGRAM-NAME GENERATED BY SYSTEM.
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB 7: JMN1004I-W RESERVED WORD 'STOP' MUST START IN AREA B. ASSUMED TO START IN AREA B.
STATISTICS: HIGHEST SEVERITY CODE=S, PROGRAM UNIT=1
The warnings (referring to area B) seem to suggest your code should by starting in the second column of each line. Which is why it's finding e.g. "DENTIFICATION" instead of "IDENTIFICATION".
I've never developed in COBOL but I vaguely remember that the first column has to be blank, or * for a comment: the warning messages seem to indicate that / - and D are valid values too.
UPDATE: Google suggests that COBOL compiler ignores the first 6 columns and that column 7 has a special significance (D for debugging, * for comment, ...). Though maybe the behaviour is compiler-specific. So I suspect your problem is that your code is starting in col 7 where it should be col 8.
Shift everything over 7 columns so that IDENTIFICATION DIVISION starts in column 8 and all subsequent lines began in column 8 or greater.
There's also a compiler switch (can't remember off the top of my head) that allows you to start in col 1
Taking a WAG (wild-ass guess) here. Haven't cobol'd since my last year of college.
Your error message says, at the bottom,
STATISTICS: HIGHEST SEVERITY CODE=S, PROGRAM UNIT=1
Okay, so I figure you have some warnings (possibly CODE=W), and one or more errors that are actually causing your program to fail.
So, scanning the error message, I see lots of W-s, and one line with an S:
C:\FSC\PCOBOL32\samples\SAMPLE6\SAMPLE7.COB
7: JMN1104I-S PROGRAM-ID PARAGRAPH IS
MISSING. PROGRAM-NAME GENERATED BY
SYSTEM.
So it seems you're missing your Program-ID paragraph. Looking at your program, I do see a n identification division, which has a program-id.
I can conclude four things from this:
1) Your identification division paragraph is malformed
2) As Neil said, you aren't running your snippet, but a sample that does not have an ID paragraph. Open sample7.cob and see
3) Some other issue is causing the error, but it is being hidden or misinterpreted as an ID paragraph error
Related
Hi I have written a COBOL program where I am using a file, but while defining file definition it is giving me error, please tell me what to do.
FILE-CONTROL.
SELECT CONTROL0-FILE
ASSIGN TO CONTR.
SELECT APCO-FILE
ASSIGN TO APCOOUT.
FD APCO-FILE.
I A "RECORDING MODE" OF "V" WAS ASSUMED FOR FILE "APCO-FILE". //ERR MSG
RECORDING MODE IS V
S "RECORDING" WAS INVALID. SCANNING WAS RESUMED AT THE NEXT AREA "A" //ERR MSG
ITEM, LEVEL-NUMBER, OR THE START OF THE //ERR MSG
RECORD CONTAINS 30 TO 300
BLOCK CONTAINS 6152 CHARACTERS
LABEL RECORDS STANDARD.
01 APCOIN-REC-1 PIC X(30).
01 APCOIN-REC PIC X(300).
The problem is the . after APCO-FILE, it ends the file definition
FD APCO-FILE.
RECORDING MODE IS V
RECORD CONTAINS 30 TO 300
BLOCK CONTAINS 6152 CHARACTERS
LABEL RECORDS STANDARD.
Change to
FD APCO-FILE
RECORDING MODE IS V
RECORD CONTAINS 30 TO 300
BLOCK CONTAINS 6152 CHARACTERS
LABEL RECORDS STANDARD.
I think you've been given the solution. I would like to ad some comment which may help you find errors yourself in the future.
The compiler reads what it thinks is a statement, and then verifies syntax, and if an error is found, writes error message(s). It then goes on with the next statment.
So firstly, the fact that there is an error message after FD APCO-FILE. indicates that the compiler considers the statement to be complete right at this point. Secondly, the fact that there is another error message after RECORDING MODE IS V tells you that the compiler thinks this is another statement, and it doesn't understand it, hence "RECORDING" was invalid ...
So the compiler thinks the part starting with RECORDING is a new statement, while you meant it to be a continuation of the FD statement. Think about what would cause the compiler and you to disagree, and you might soon see the "." after APCO-FILE which should not be there.
I am trying to print to a GT800 Zebra printer thru serial port.
I am using ZPL. I want to control the width which is fine in auto mode. To address that in the >^BC> command I am using Auto mode as no other size setting under ^BY works
Following is the code
^XA
^MMT
^PW831
^LL400
^LS0
^BY2,,76^FT225,141^BCN,76,Y,Y,N,A
^FD:RNIP29200082034^FS
^FO225,157^A#N,18,10,E:CAL002.FNT^FD26030-0892R^FS
^FO383,157^A#N,18,10,E:CAL002.FNT^FD08.01.20 12:00PM^FS
^FO225,187^A#N,18,10,E:CAL002.FNT^FDLAMP-DR RH^FS
^FO453,187^A#N,18,10,E:CAL002.FNT^FDXBA3^FS
^PQ1,0,0,Y
^XZ
There is a funny problem. If the ^BC mode = A then if three zeros come together gives issues for eg ABCD29200082034 it prints ABCD29200 and does not complete the barcode. But the other lines are getting printed. But if the data is ABCD29200182034 , there are no issues.
If BC mode = U then even if the code is ABCD29200182034 it prints 292001820347. Note 7 is added in the end.
I am clueless as to what is this issue. I remember facing this same issue in Honeywell printer too once.
Thanks
NOTE : I replaced the 000 with 111 and the problem persists.
ZPL Manual says the following
A= Automatic Mode :This analyzes the data sent and automatically determines the best packing method. The full ASCII character set can be used in the ^FD
statement — the printer determines when to shift subsets. A string of
four or more numeric digits causes an automatic shift to Subset C.
Note , it says a string of four or more numeric digits causes an automatic shift to subset C, but when the same string is 290010 it has no issues. I am really lost
With this code, I get
16: Perform stmnt not terminated by end-perform
33: syntax error, unexpected end-perform
Why is it saying that I need an end-perform and also not need it?
identification division.
program-id. xxx.
* will accept and display a num until 0 is called then
* asks to go again
data division.
file section.
working-storage section.
01 num pic 9(4).
01 hold pic 9(4).
01 another pic x.
procedure division.
perform until another = 'N' (line 16)
Display "Another Session (Y/N)? "
with no advancing
if another = 'Y'
Display "Enter a 4-digit unsigned number (0 to stop): "
with no advancing
accept num
move num to hold
perform until num = 0
Display "Enter a 4-digit unsigned number (0 to stop): "
with no advancing
accept num
if num <> 0
move num to hold
end-perform.
display space
Display "The last number entered: "hold
End-perform. (Line 33)
stop run.
end-perform.
display space
Display "The last number entered: "hold
End-perform. (Line 33)
It's that full-stop/period (Line 30) which is the killer.
Although since the 1985 Standard COBOL is much more relaxed about full-stops/periods, a single one will bring all current scopes screaming to a halt. You could have nesting 50 levels deep, and one single full-stop/period would end them all, in one fell swoop.
My advice is to use the absolute minimum of full-stop/periods in the PROCEDURE DIVISION.
That is: one to terminate the PROCEDURE DIVISION header; one to terminate each paragraph/SECTION label; one to terminate a paragrpah/SECTION; one to terminate a program (for a program with no paragraphs/SECTIONS). Also, if you have PROCEDURE DIVISION COPY or REPLACE statements, you'll need full-stops/periods to terminate those.
Except for the termination of the labels I put each full-stop/period on a line of its own, never attached to any code. I can then move code around and insert code without worrying about whether I need to add/remove a full-stop/period.
As to why you need END-PERFORM, it is an "inline PERFORM". Syntactically, an inline PERFORM requires an END-PERFORM, but your use of the full-stop/period caused termination of the PERFORM scope before the END-PERFORM was located, so the error on line 16. Subsequently an END-PERFORM unconnected to a PERFORM was located, so the error on line 33.
It is important when putting error messages in your questions that you include the error message exactly as you see it. Copy/paste, don't re-trype, please. Include any message numbers, as well.
You absolutely can not mix the full stop "." scope terminator from Cobol-74 with the End-* scope terminators from Cobol-85.
The difference is that the full stop "." terminates ALL scopes.
The End-* terminates only the most recent scope, just like you might expect.
Putting a "." in the middle of code with End-* is kinda like dropping a nuclear bomb in the middle of it. As a rule, for compilers made in the last quarter century or so, a period should only occur in the procedure division at the end of a paragraph name, or at the end of a paragraph (and sections too, but those are useless in an age where segmentation and overlays are managed by the operating system). I like to use "EXIT." or "CONTINUE." just to highlight that I'm using one of the bad-nasty-best-avoided-periods in the procedure division.
I'm completely new to COBOL, and I'm wondering:
There seems to be no difference between
DISPLAY "foo"
and
DISPLAY "foo".
What does the dot at the end of a line actually do?
When should I use/avoid it?
The period ends the "sentence." It can have an effect on your logic. Consider...
IF A = B
PERFORM 100-DO
SET I-AM-DONE TO TRUE.
...and...
IF A = B
PERFORM 100-DO.
SET I-AM-DONE TO TRUE
The period ends the IF in both examples. In the first, the I-AM-DONE 88-level is set conditionally, in the second it is set unconditionally.
Many people prefer to use explicit scope terminators and use only a single period, often on a physical line by itself to make it stand out, to end a paragraph.
I'm typing this from memory, so if anyone has corrections, I'd appreciate it.
Cobol 1968 required the use of a period to end a division name, procedure division paragraph name, or procedure division paragraph. Each data division element ended with a period.
There were no explicit scope terminators in Cobol 68, like END-IF. A period was also used to end scope. Cobol 1974 brought about some changes that didn't have anything to do with periods.
Rather than try to remember the rules for periods, Cobol programmers tended to end every sentence in a Cobol program with a period.
With the introduction of scope terminators in Cobol 1985, Cobol coders could eliminate most of the periods within a procedure division paragraph. The only periods required in the procedure division of a Cobol 85 program are the to terminate the PROCEDURE DIVISION statement, to terminate code (if any) prior to first paragraph / section header, to terminate paragraph / section header, to terminate a paragraph / section and to terminate a program (if no paragraphs / sections).
Unfortunately, this freaked out the Cobol programmers that coded to the Cobol 68 and 74 standard. To this day, many Cobol shops enforce a coding rule about ending every procedure division sentence with a period.
Where to use!
There are 2 forms to use point.
You can use POINT after every VERB in a SECTION.
EXAMPLE:
0000-EXAMPLE SECTION.
MOVE 0 TO WK-I.
PERFORM UNTIL WK-I GREATER THAN 100
DISPLAY WK-I
ADD 1 TO WK-I
END-PERFORM.
DISPLAY WK-I.
IF WK-I EQUAL ZEROS
DISPLAY WK-I
END-IF.
0000-EXAMEPLE-END. EXIT.
Note that we are using point after every VERB, EXCEPT inside a PERFORM, IF, ETC...
Another form to use is: USING ONLY ONE POINT AT THE END OF SECTION, like here:
0000-EXAMPLE SECTION.
MOVE 0 TO WK-I
PERFORM UNTIL WK-I GREATER THAN 100
DISPLAY WK-I
ADD 1 TO WK-I
END-PERFORM
DISPLAY WK-I
IF WK-I EQUAL ZEROS
DISPLAY WK-I
END-IF
. <======== point here!!!!!!! only HERE!
0000-EXAMEPLE-END. EXIT.
BUT, we ALWAYS have after EXIT and SECTION.....
When it is my choice, I use full-stop/period only where necessary. However, local standards often dictate otherwise: so be it.
The problems caused by full-stops/periods are in the accidental making of something unconditional when code "with" is copied into code "without" whilst coder's brain is left safely in the carpark.
One extra thing to watch for is (hopefully) "old" programs which use NEXT SENTENCE in IBM Mainframe Cobol. "NEXT SENTENCE" means "after the next full-stop/period" which, in "sparse full-stop/period" code is the end of the paragraph/section. Accident waiting to happen. Get a spec-change to allow "NEXT SENTENCE" to be changed to "CONTINUE".
Just tested that in my cobol 85 program by removing all of the periods in procedures and it worked fine.
example:
PROCEDURE DIVISION.
MAIN-PROCESS.
READ DISK-IN
AT END
DISPLAY "NO RECORDS ON INPUT FILE"
STOP RUN
ADD 1 TO READ-COUNT.
PERFORM PROCESS-1 UNTIL END-OF-FILE.
WRITE-HEADER.
MOVE HEADER-INJ-1 TO HEADER-OUT-1
WRITE HEADER-OUT-1.
CLOSE-FILES.
CLOSE DISK-IN
CLOSE DISK-OUT
DISPLAY "READ: " READ-COUNT
DISPLAY "WRITTEN: " WRITE-COUNT
SORT SORT-FILE ON ASCENDING SER-S
USING DISK-OUT
GIVING DISK-OUT
STOP RUN.
I have some csv record which are variable in length , for example:
0005464560,45667759,ZAMTR,!To ACC 12345678,DR,79.85
0006786565,34567899,ZAMTR,!To ACC 26575443,DR,1000
I need to seperate each of these fields and I need the last field which should be a money.
However, as I read the file, and unstring the record into fields, I found that the last field contain junk value at the end of itself. The amount(money) field should be 8 characters, 5 digit at the front, 1 dot, 2 digit at the end. The values from the input could be any value such as 13.5, 1000 and 354.23 .
"FILE SECTION"
FD INPUT_FILE.
01 INPUT_REC PIC X(66).
"WORKING STORAGE SECTion"
01 WS_INPUT_REC PIC X(66).
01 WS_AMOUNT_NUM PIC 9(5).9(2).
01 WS_AMOUNT_TXT PIC X(8).
"MAIN SECTION"
UNSTRING INPUT_REC DELIMITED BY ","
INTO WS_ID_1, WS_ID_2, WS_CODE, WS_DESCRIPTION, WS_FLAG, WS_AMOUNT_TXT
MOVE WS_AMOUNT_TXT(1:8) TO WS_AMOUNT_NUM(1:8)
DISPLAY WS_AMOUNT_NUM
From the display, the value is rather normal: 345.23, 1000, just as what are, however, after I wrote the field into a file, here is what they become:
79.85^M^#^#
137.35^M^#
I have inspect the field WS_AMOUNT_NUM, which came from the field WS_AMOUNT_TXT, and found that ^# is a kind of LOW-VALUE. However, I cannot find what is ^M, it is not a space, not a high-value.
I am guessing, but it looks like you may be reading variable length records from a file into a fixed length
COBOL record. The junk
at the end of the COBOL record is giving you some grief. Hard to say how consistent that junk is going
to be from one read to the next (data beyond the bounds of actual input record length are technically
undefined). That junk ends up
being included in WS_AMOUNT_TXT after the UNSTRING
There are a number of ways to solve this problem. The suggestion I am giving you here may not
be optimal, but it is simple and should get the job done.
The last INTO field, WS_AMOUNT_TXT, in your UNSTRING statement is the one that receives all of the trailing
junk. That junk needs to be stripped off. Knowing that the only valid characters in the last field are
digits and the decimal character, you could clean it up as follows:
PERFORM VARYING WS_I FROM LENGTH OF WS_AMOUNT_TXT BY -1
UNTIL WS_I = ZERO
IF WS_AMOUNT_TXT(WS_I:1) IS NUMERIC OR
WS_AMOUNT_TXT(WS_I:1) = '.'
MOVE ZERO TO WS_I
ELSE
MOVE SPACE TO WS_AMOUNT_TXT(WS_I:1)
END-IF
END-PERFORM
The basic idea in the above code is to scan from the end of the last UNSTRING output field
to the beginning replacing anything that is not a valid digit or decimal point with a space.
Once a valid digit/decimal is found, exit the loop on the assumption that the rest will
be valid.
After cleanup use the intrinsic function NUMVAL as outlined in my answer to your
previous question
to convert WS_AMOUNT_TXT into a numeric data type.
One final piece of advice, MOVE SPACES TO INPUT_REC before each READ to blow away data left over
from a previous read that might be left in the buffer. This will protect you when reading a very "short"
record after a "long" one - otherwise you may trip over data left over from the previous read.
Hope this helps.
EDIT Just noticed this answer to your question about reading variable length files. Using a variable length input record is a better approach. Given the
actual input record length you can do something like:
UNSTRING INPUT_REC(1:REC_LEN) INTO...
Where REC_LEN is the variable specified after OCCURS DEPENDING ON for the INPUT_REC file FD. All the junk you are encountering occurs after the end of the record as defined by REC_LEN. Using reference modification as illustrated above trims it off before UNSTRING does its work to separate out the individual data fields.
EDIT 2:
Cannot use reference modification with UNSTRING. Darn... It is possible with some other COBOL dialects but not with OpenVMS COBOL. Try the following:
MOVE INPUT_REC(1:REC_LEN) TO WS_BUFFER
UNSTRING WS_BUFFER INTO...
Where WS_BUFFER is a working storage PIC X variable long enough to hold the longest input record. When you MOVE a short alpha-numeric field to a longer one, the destination field is left justified with spaces used to pad remaining space (ie. WS_BUFFER). Since leading and trailing spaces are acceptable to the NUMVAL fucnction you have exactly what you need.
I have a reason for pushing you in this direction. Any junk that ends up at the trailing end of a record buffer when reading a short record is undefined. There is a possibility that some of that junk just might end up being a digit or a decimal point. Should this occur, the cleanup routine I originally suggested would fail.
EDIT 3:
There are no ^# in the resulting WS_AMOUNT_TXT, but still there are a ^M
Looks like the file system is treating <CR> (that ^M thing) at the end of each record as data.
If the file you are reading came from a Windows platform and you are now
reading it on a UNIX platform that would explain the problem. Under Windows records
are terminated with <CR><LF> while on UNIX they are terminated with <LF> only. The
UNIX file system treats <CR> as if it were part of the record.
If this is the case, you can be pretty sure that there will be a single <CR> at the
end of every record read. There are a number of ways to deal with this:
Method 1: As you already noted, pre-edit the file using Notepad++ or some other
tool to remove the <CR> characters before processing through your COBOL program.
Personally I don't think this is the best way of going about it. I prefer to use a COBOL
only solution since it involves fewer processing steps.
Method 2: Trim the last character from each input record before processing it. The last
character should always be <CR>. Try the following if you
are reading records as variable length and have the actual input record length available.
SUBTRACT 1 FROM REC_LEN
MOVE INPUT_REC(1:REC_LEN) TO WS_BUFFER
UNSTRING WS_BUFFER INTO...
Method 3: Treat <CR> as a delimiter when UNSTRINGing as follows:
UNSTRING INPUT_REC DELIMITED BY "," OR x"0D"
INTO WS_ID_1, WS_ID_2, WS_CODE, WS_DESCRIPTION, WS_FLAG, WS_AMOUNT_TXT
Method 4: Condition the last receiving field from UNSTRING by replacing trailing
non digit/non decimal point characters with spaces. I outlined this solution a litte earlier in this
question. You could also explore the INSPECT statement using the REPLACING option (Format 2). This should be able to do pretty much the same thing - just replace all x"00" by SPACE and x"0D" by SPACE.
Where there is a will, there is a way. Any of the above solutions should work for you. Choose the one you are most comfortable with.
^M is a carriage return.
Would Google Refine be useful for rectifying this data?