Cobol - Non-Cobol person getting error code

Author

Non-Cobol person getting error code

Monica J. Braverman

2004-11-20, 3:55 pm

I was sent an exe of a cobol program to unpack a datafile. First of
all, do I need any cobol compiler, run-time, etc to run this type of
exe? Second, I get an error message of "FILE STATUS 39 on
<UNOPENED-FILE>. Error detected at offset 004F in segment 00 of
program DBEPRT1.

I am running this at the command prompt of a PC running Windows XP
professional. Is this type of error message specific to the program
or is there an issue with XP running in DOS mode?

Thanks.

Lorne Sunley

2004-11-20, 3:55 pm

On Sat, 20 Nov 2004 15:28:19 UTC, monica@datashark.net (Monica J.
Braverman) wrote:

> I was sent an exe of a cobol program to unpack a datafile. First of
> all, do I need any cobol compiler, run-time, etc to run this type of
> exe? Second, I get an error message of "FILE STATUS 39 on
> <UNOPENED-FILE>. Error detected at offset 004F in segment 00 of
> program DBEPRT1.
>
> I am running this at the command prompt of a PC running Windows XP
> professional. Is this type of error message specific to the program
> or is there an issue with XP running in DOS mode?
>
> Thanks.

That error code usually indicates a mismatch between the file
definition used by the program and the actual file definition stored
in the data file. It is normally caused by different record lengths or
by different index definitions in an ISAM type data file.

Contact the person who the supplied the program.

--
Lorne Sunley

JerryMouse

2004-11-20, 3:55 pm

Monica J. Braverman wrote:
> I was sent an exe of a cobol program to unpack a datafile. First of
> all, do I need any cobol compiler, run-time, etc to run this type of
> exe? Second, I get an error message of "FILE STATUS 39 on
> <UNOPENED-FILE>. Error detected at offset 004F in segment 00 of
> program DBEPRT1.
>
> I am running this at the command prompt of a PC running Windows XP
> professional. Is this type of error message specific to the program
> or is there an issue with XP running in DOS mode?
>
> Thanks.

You don't need a compiler. You MAY need a run-time module, depending on the
particular COBOL compiler used. Inasmuch as the program actually started
execution, the latter is unlikely.

The de-code of "FILE STATUS 39" is "Conflict between fixed and defined file
attributes" is that, in attempting to open the file, the program decided the
internal attributes of the file do not match what was expected.

Note this is "internal attributes," not data. Several file types in COBOL
contain file-processing information in addition to data, for example record
lengths, links to other records, block sizes, etc.

It's like opening your door to a blind date. You are expecting certain
characteristics (6'2", 190#, blond, chisled-features, dimpled chin, perfect
teeth, smelling faintly of soap) and are greeted by an armadillo.

Bottom line, the file you're attempting to process doesn't match the
program's expectations. This is NOT, most likely, the result of incompatible
operating systems, or anything to do with COBOL per se.

Lueko Willms

2004-11-20, 3:55 pm

.. On 20.11.04
wrote monica@datashark.net (Monica J. Braverman)
on /COMP/LANG/COBOL
in d70cd025.0411200728.6fa7614e@posting.google.com
about Non-Cobol person getting error code

MJB> I was sent an exe of a cobol program to unpack a datafile. First of
MJB> all, do I need any cobol compiler, run-time, etc to run this type of
MJB> exe?

When you got an EXE, you certainly do not need a compiler. Maybe
you need some supporting DLLs or other form of runtime. But since the
program was sent to you this way, I guess the sender did include
everything you need; and this opinion is confirmed by the fact that
you got a sensible message from the program about a COBOL file status.

MJB> Second, I get an error message of "FILE STATUS 39 on
MJB> <UNOPENED-FILE>. Error detected at offset 004F in segment 00 of
MJB> program DBEPRT1.

The COBOL filestatus consists of two characters which are normally
numbers, the first indicating a major file status, and the second, the
minor status, with additional information.

Major file status = 3 means that there is an unrecoverable error,
or "Permanent Error" as the COBOL standard says. Minor Status = 9 then
means that there is an "file attribute conflict between specification
in program and the actual file". The message seems to indicate that a
file was actually not yet opened.

Did you get instructions on how to specify the files to be use?
Maybe the program does not find the file name where it looks for it.

Or the file you try to process is of a different format then the
program is expecting.

MJB> I am running this at the command prompt of a PC running Windows XP
MJB> professional. Is this type of error message specific to the program
MJB> or is there an issue with XP running in DOS mode?

As said before, File Status '39' appears to be a standard COBOL
file status, not an issue of running in DOS mode. BUT, of cource,
since several COBOL-Compiler did and do exist for DOS and Windows O/
Ses, it may be that the program does require some resources not
available unter Windows XP, but I don't think that this is the problem
in your case.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Man kann wirklich nicht wissen ob man nicht jetzt im Tollhaus sitzt. -G.C.Lichtenberg

Donald Tees

2004-11-20, 8:55 pm

Donald Tees

2004-11-20, 8:55 pm

Lueko Willms

2004-11-20, 8:55 pm

.. On 20.11.04
wrote donald_tees@sympatico.ca (Donald Tees)
on /COMP/LANG/COBOL
in JwNnd.57948$Ho4.1950981@news20.bellglobal.com
about Re: Non-Cobol person getting error code

DT> Sorry aboput that last message ... error 29 is not found.

Major status 2 indicates an "invalid key" condition which is
considered to be a recovarable error

File not found should be indicated by 35:
3 = Permanent Error,
5 = file not present on OPEN INPUT
(in COBOL-2002 also for OPEN I-O and OPEN EXTEND

for minor status 9 to occur, if the compiler is correctly
implemented, the file would have to be present, but a conflict between
the file description in the program and the actual file detected.

I could imagine that 39 occurs e.g. when a file is specified as
ORGANISATION INDEXED, and the COBOL file system expects a separate
index file, but doesnt find one.

Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

A. Der Mann hat viele Kinder. B. Ja, aber ich glaube, von den meisten hat er bloß die Korrektur besorgt. -G.C.Lichtenberg

James J. Gavan

2004-11-21, 3:55 am

Lueko Willms wrote:

> I could imagine that 39 occurs e.g. when a file is specified as
>ORGANISATION INDEXED, and the COBOL file system expects a separate
>index file, but doesnt find one.
>
>
I now use SQL with DB Tables, but a practical example, and not very
often. I have my ISAM and other files as separate file classes - they
can be specified with (a) vannila FD entry 'Record size from 'a' to 'b'
depending upon 'c'", or (b) you use a copyfile in the Business Program
(Problem Domain) and the file class.

So, for say about a year, you use the new program with a record size of
100 chars total., putting a lot of data into it. Then you do some system
re-design *forgetting* what previously was the case, add a field, and
you set the copyfie record size to 105.

Now access the file and you get the '39'. I don't even memorize the
file-status codes, I just let the FileError class display the message :-

*>------- error tables
01 E1A.
05 pic x(19) value "Successful BUT :". *> 0
05 pic x(19) value "At end of file :". *> 1
05 pic x(19) value "Invalid key :". *> 2
05 pic x(19) value "Permanent Error:". *> 3
05 etc...
01 E1B redefines E1A.
05 ErrorText1 occurs 7 times pic x(19).

01 E2A.
05 pic x(34) value "00No further information ".
05 etc...
05 pic x(34) value "30I-O error/Data check parity err.".
05 pic x(34) value "34Boundary violation ".
05 pic x(34) value "35Open IO/INPUT/EXTEND non-optionl".
05 pic x(34) value "37Open with incorrect Open mode ".
05 pic x(34) value "38Open on file previously LOCKED ".
05 pic x(34) value "39Conflict between file & program ".
05 etc...
01 E2B redefines E2A.
05 E2 occurs 25 times.
10 ErrorText2-Number pic 9(02).
10 ErrorText2-Descrip pic x(32).

Plus separate tables to handle '9' as the first character, using the M/F
extensions to get a message for the second character :-

01 E9A.
05 pic x(35) value "000No further information ".
05 pic x(35) value "001Lack of buffer space/memory ".
05 pic x(35) value "002File not opened when accessed ".
05 pic x(35) value "003Serial mode error ".
05 pic x(35) value "004Illegal file name ".
05 etc...
01 E9B redefines E9A.
05 E9 occurs 94 times.
10 ErrTable9-Number pic 9(03).
10 ErrTable9-Descrip pic x(32).

Yes above could use SEARCH instead of PERFORM varying...., but I no
longer use it, so why bother to fine-tune.

Jimmy

Lueko Willms

2004-11-21, 8:55 am

.. Am 21.11.04
schrieb jjgavan@shaw.ca (James J. Gavan)
bei /COMP/LANG/COBOL
in nqUnd.291854$%k.25173@pd7tw2no
ueber Re: Non-Cobol person getting error code

JJG> I don't even memorize the file-status codes, I just let the
JJG> FileError class display the message :-

Well that sounds object-oriented. I neither do have a COBOL
compiler which is able to do that nor have I learned to use it.

I have written a COPY-Element for the file status:
whis has to be used with
COPY REPLACING == FILESTAT == by == Your-sensible-name ==

With a TYPEDEF available, I would use it once as such. Anyway, it
has to be referenced with qualification, like in
IF has-reached-at-end OF Your-sensible-name

010 01 FILESTAT .
020*> FILESTAT sollte beim COPY durch passenden Namen REPLACEd werden
030 88 File-Status-OK VALUE '00'.
040 02 Major PIC X.
050 88 is-Successful-completed VALUE '0'.
060 88 has-reached-at-end VALUE '1'.
070 88 has-invalid-key VALUE '2'.
080 88 has-permanent-error VALUE '3'.
090 88 has-logical-error VALUE '4'.
100 88 has-record-lock-problem VALUE '5'.
*> ab Standard 2002 und X/Open
110 88 has-file-lock-problem VALUE '6'.
*> ab Standard 2002 und X/Open
120 88 has-implementor-defined-condition VALUE '9'.
130 02 Minor PIC X.
140 88 has-no-further-information VALUE '0'.
150 88 it-just-didnt-work VALUE '1'.
160 88 has-duplicate-key-error VALUE '2'.
170 88 has-record-not-available VALUE '3'.
180 88 has-boundary-violation VALUE '4'.
190 88 is-not-present-file-or-recdesc VALUE '5'.
200 88 has-sequence-error VALUE '6'.
210 88 has-some-incompatability VALUE '7', '8', '9'.
220

and a COPY element to be PERFORMed by a ON FILE-ERROR in
DECLARATIVES, but whic has the values according to X/Open
resp. COBOL-2002 only worked in for the major file status:

010* This procedure requires the presence of
010* two items in the DATA DIVISION
011* which should look like this:
012* 01 FILE-STATUS-EXPLAINED.
013* 02 Major PIC X.
014* 02 Minor PIC X.
015*
016* 77 FILE-NAME-EXPLAINED PIC X(12).
017*
018* one has to MOVE the actual file status and the file name to these
019* fields, or rename the names in this COPY element.
020*
021 EXPLAIN-FILE-STATUS SECTION.
022 ANFANG.
030 DISPLAY 'Status ' FILE-STATUS-EXPLAINED ' on ' FILE-NAME-EXPLAINED ': ' WITH NO ADVANCING
040 EVALUATE Major OF FILE-STATUS-EXPLAINED
050 WHEN '0'
060 DISPLAY 'successful completion'
070 EVALUATE Minor OF FILE-STATUS-EXPLAINED
080 WHEN '0'
090 DISPLAY 'No further information'
100 WHEN '2'
110 DISPLAY 'duplicate key detected on READ or created on WRITE'
120 WHEN '4'
130 DISPLAY 'but length of record read does not correspond to fixed file attributes of ' FILE-NAME-EXPLAINED
140 WHEN '5'
150 DISPLAY 'but optional file is not (yet) present at OPEN time'
160 WHEN '7'
170 DISPLAY 'but referenced file is on a non-reel/unit medium'
180 WHEN OTHER
190 DISPLAY 'Unknown minor status'
200 END-EVALUATE
210 WHEN '1'
220 DISPLAY 'AT END condition with unsuccessful completion'
230 EVALUATE Minor OF FILE-STATUS-EXPLAINED
240 WHEN '0'
250 DISPLAY 'No further information'
260 WHEN '4'
270 DISPLAY 'seq READ on relative file, but more digits in rec number than described in file attributes'
280 WHEN '5'
290 DISPLAY 'but optional file is not (yet) present at READ time'
300 WHEN '6'
310 DISPLAY 'after AT END was already reached by a previous READ'
320 WHEN OTHER
330 DISPLAY 'Unknown minor status'
340 END-EVALUATE
350 WHEN '2'
360 DISPLAY 'Invalid Key condition with unsuccessful completion'
370 EVALUATE Minor OF FILE-STATUS-EXPLAINED
380 WHEN '0'
390 DISPLAY 'No further information'
400 WHEN '1'
410 DISPLAY 'sequence error for sequentially accessed indexed file'
420 WHEN '2'
430 DISPLAY 'WRITE would create a DUPLICATE KEY'
440 WHEN '3'
450 DISPLAY 'tried to randomly access a non-existent record'
460 WHEN '4'
470 DISPLAY 'boundary violation: tried to WRITE beyond physical limits or with larger rec no than possible'
480 WHEN '5'
490 DISPLAY 'optional file not present at START or READ'
500 WHEN OTHER
510 DISPLAY 'Unknown minor status'
520 END-EVALUATE
530 WHEN '3'
540 DISPLAY 'Permanent Error condition with unsuccessful completion'
550 EVALUATE Minor OF FILE-STATUS-EXPLAINED
560 WHEN '0'
570 DISPLAY 'No further information'
580 WHEN '4'
590 DISPLAY 'boundary violation. Attempt to write beyond limits of file (disc full?)'
600 WHEN '5'
610 DISPLAY 'file not present on OPEN INPUT'
620 WHEN '6'
630 DISPLAY 'mismatch of files on one reel'
640 WHEN '7'
650 DISPLAY 'OPEN I/O on a file which is not on mass storage'
660 WHEN '8'
670 DISPLAY 'file was previously CLOSEd with LOCK - OPEN failed'
680 WHEN '9'
690 DISPLAY 'file attribute conflict between specification in program and actual file'
700 WHEN OTHER
710 DISPLAY 'Unknown minor status'
720 END-EVALUATE
730 WHEN '4'
740 DISPLAY 'Logic Error condition with unsuccessful completion'
750 EVALUATE Minor OF FILE-STATUS-EXPLAINED
760 WHEN '0'
770 DISPLAY 'No further information'
780 WHEN '1'
790 DISPLAY 'can''t OPEN a file which is already OPEN'
800 WHEN '2'
810 DISPLAY 'can''t CLOSE a file which is not OPEN'
820 WHEN '3'
830 DISPLAY 'a REWRITE or DELETE IN seq mode was tried without prior successful READ'
840 WHEN '4'
850 DISPLAY 'boundary violation: record-size mismatch on WRITE or REWRITE, or beyond page limits'
860 WHEN '6'
870 DISPLAY 'no next record after unsuccessful START or READ w/o AT END'
880 WHEN '7'
890 DISPLAY 'READ on a file not OPENed in READ or I/O mode'
900 WHEN '8'
910 DISPLAY 'WRITE on a file not OPENed in WRITE or EXTEND mode'
920 WHEN '9'
930 DISPLAY 'REWRITE on a file not OPENed in I/O mode'
940 WHEN OTHER
950 DISPLAY 'Unknown minor status'
960 END-EVALUATE
961 WHEN '5'
962 DISPLAY 'Record Lock problem'
963 WHEN '6'
964 DISPLAY 'File Lock problem'
970 WHEN '9'
980 DISPLAY 'Implementor-defined condition with unsuccessful completion'
990 WHEN OTHER
001 DISPLAY 'Unknown File Status '
010 END-EVALUATE
020 .

And, of course, it might be nice to have those texts in an array
so that they might easily be displayed in various languages.

Anybody may feel free to use these two copy elements.

Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)

James J. Gavan

2004-11-21, 8:55 pm

Lueko Willms wrote:

>. Am 21.11.04
> schrieb jjgavan@shaw.ca (James J. Gavan)
> bei /COMP/LANG/COBOL
> in nqUnd.291854$%k.25173@pd7tw2no
> ueber Re: Non-Cobol person getting error code
>
>JJG> I don't even memorize the file-status codes, I just let the
>JJG> FileError class display the message :-
>
> Well that sounds object-oriented. I neither do have a COBOL
>compiler which is able to do that nor have I learned to use it.
>
>
Yes it is OO "coded" but the design idea is not confined to OO. What's
to stop you CALLing a separate general purpose program FILERRORS passing
the file name and the file-status code. The FileErrors class/program
can then do an informative error display. I don't , but could
accommodate Richard and his oft quoted phrase "Only check for the first
status character". :-)

Looking at your code below, I asked myself the question - has he got
this code repeated in *every* program. Looks like the answer is 'Yes'
because you have locked yourself in to the DECLARATIVES SECTION
approach. I can't give you numbers but there are a fair number here who
reject the Declaratives approach. This is my approach against a generic
ISAM template, and there are others, (in procedural/traditional format) :-

*>--------------------------------------------------------------
Method-id. "readNext".
*>--------------------------------------------------------------
Linkage section.
01 lnk-ReturnValues.
copy "\copylib\sqlResult.cpy" replacing ==(tag)== by ==05 lnk==.

*> above started out as FileResult.cpy, then when I switched to DBMS I
merely added Level *>88's which covered SQL results, like 'No more
Rows'. 99% usage is SQL, but if I do want to *>do a quickie with COBOL
files - then the one copyfile applies to both.

05 lnk-record.
10 occurs 1 to MaxRecordSize
depending on ws-RecordSize pic x.

Procedure Division returning lnk-ReturnValues.

initialize lnk-ReturnValues
Read Data-File next record
At End
Set fileFinis to True
Not at End
Move Data-record (1:ws-RecordSize)
to lnk-record (1:ws-RecordSize)
End-Read

if ws-fileStatus = "00" or "10"
continue

else set FileError to true
invoke super "showFileError" using ws-ErrorParams
End-if

End Method "readNext".
*>--------------------------------------------------------------

There's no ambiguity - in fact I "double-check", (a) using At End/Not
at End and then follow with (b) checking the *specific* status-codes
that apply to an ISAM READ NEXT. If it's OO then I invoke the FileErrors
class; parallel situation for Procedural, CALLing the FileErrors program.

so that they might easily be displayed in various languages.[color=darkred]

I would suggest it's more than, "it might be nice", but highly desirable, as per following from my FileErrors class :-

*>--------------------------------------------------------------
Method-id. "showFileError".
*>--------------------------------------------------------------
Linkage section.
copy "\copylib\Linkerr.cpy" replacing ==(tag)== by ==Lnk==.
01 lnk-response pic x(4) comp-5.

Procedure Division using lnk-ErrorParams
returning lnk-response.

initialize ws-MessageParams
move lnk-FileName to ws-Filename
move lnk-filestatus to ws-filestatus
set TypeCritical to true
set OK to true
move "File Error" to MessageLabel
initialize MessageText

Evaluate true
when ws-fileStatus = "RS"
invoke self "recordSizeError"
when other
invoke self "errorCode1"

Evaluate ws-FileStatus1
when "9" invoke self "extendedCodes"
when other invoke self "ansiCodes"
End-evaluate

invoke self "getErrorString"

End-evaluate

invoke ErrorMessage "showMessage"
using lnk-Parent, ws-MessageParams
returning lnk-response

End Method "showFileError".
*>--------------------------------------------------------------
Method-id. "ansiCodes".
*>--------------------------------------------------------------
Local-Storage section.
01 n pic x(4) comp-5.

Procedure Division.
initialize ErrorType2
perform with test after
varying n from 1 by 1 until n = 25 or ErrorType2 not = spaces

if ws-FileStatus-ansi85 = ErrorText2-Number (n)
move ErrorText2-Number (n) to ErrorNumber
move ErrorText2-Descrip (n) to ErrorType2
End-if
End-perform
End Method "ansiCodes".
*>---------------------------------------------------------------

If you look at the method above "ansiCodes" - you will recall that I did say it made sense to do a SEARCH, rather than a PERFORM.

Now my SQL Tables are separate classes, but they parallel the above, either you get an OK condition, "No more rows" or other = Error. Again CALL/INVOKE a separate SQLERRORS Class/Program.

As I recall, the originator of this thread was a young lady asking for
help. Her message said she was getting a status "39" - none of us
thought to comment, "What a lousy program you have been provided. It
didn't even bother to tell you what File-Status "39" meant !

Jimmy
[color=darkred]
> I have written a COPY-Element for the file status:
>whis has to be used with
> COPY REPLACING == FILESTAT == by == Your-sensible-name ==
>
> With a TYPEDEF available, I would use it once as such. Anyway, it
>has to be referenced with qualification, like in
> IF has-reached-at-end OF Your-sensible-name
>
>
>010 01 FILESTAT .
>020*> FILESTAT sollte beim COPY durch passenden Namen REPLACEd werden
>030 88 File-Status-OK VALUE '00'.
>040 02 Major PIC X.
>050 88 is-Successful-completed VALUE '0'.
>060 88 has-reached-at-end VALUE '1'.
>070 88 has-invalid-key VALUE '2'.
>080 88 has-permanent-error VALUE '3'.
>090 88 has-logical-error VALUE '4'.
>100 88 has-record-lock-problem VALUE '5'.
> *> ab Standard 2002 und X/Open
>110 88 has-file-lock-problem VALUE '6'.
> *> ab Standard 2002 und X/Open
>120 88 has-implementor-defined-condition VALUE '9'.
>130 02 Minor PIC X.
>140 88 has-no-further-information VALUE '0'.
>150 88 it-just-didnt-work VALUE '1'.
>160 88 has-duplicate-key-error VALUE '2'.
>170 88 has-record-not-available VALUE '3'.
>180 88 has-boundary-violation VALUE '4'.
>190 88 is-not-present-file-or-recdesc VALUE '5'.
>200 88 has-sequence-error VALUE '6'.
>210 88 has-some-incompatability VALUE '7', '8', '9'.
>220
>
>
> and a COPY element to be PERFORMed by a ON FILE-ERROR in
>DECLARATIVES, but whic has the values according to X/Open
>resp. COBOL-2002 only worked in for the major file status:
>
>
>010* This procedure requires the presence of
>010* two items in the DATA DIVISION
>011* which should look like this:
>012* 01 FILE-STATUS-EXPLAINED.
>013* 02 Major PIC X.
>014* 02 Minor PIC X.
>015*
>016* 77 FILE-NAME-EXPLAINED PIC X(12).
>017*
>018* one has to MOVE the actual file status and the file name to these
>019* fields, or rename the names in this COPY element.
>020*
>021 EXPLAIN-FILE-STATUS SECTION.
>022 ANFANG.
>030 DISPLAY 'Status ' FILE-STATUS-EXPLAINED ' on ' FILE-NAME-EXPLAINED ': ' WITH NO ADVANCING
>040 EVALUATE Major OF FILE-STATUS-EXPLAINED
>050 WHEN '0'
>060 DISPLAY 'successful completion'
>070 EVALUATE Minor OF FILE-STATUS-EXPLAINED
>080 WHEN '0'
>090 DISPLAY 'No further information'
>100 WHEN '2'
>110 DISPLAY 'duplicate key detected on READ or created on WRITE'
>120 WHEN '4'
>130 DISPLAY 'but length of record read does not correspond to fixed file attributes of ' FILE-NAME-EXPLAINED
>140 WHEN '5'
>150 DISPLAY 'but optional file is not (yet) present at OPEN time'
>160 WHEN '7'
>170 DISPLAY 'but referenced file is on a non-reel/unit medium'
>180 WHEN OTHER
>190 DISPLAY 'Unknown minor status'
>200 END-EVALUATE
>210 WHEN '1'
>220 DISPLAY 'AT END condition with unsuccessful completion'
>230 EVALUATE Minor OF FILE-STATUS-EXPLAINED
>240 WHEN '0'
>250 DISPLAY 'No further information'
>260 WHEN '4'
>270 DISPLAY 'seq READ on relative file, but more digits in rec number than described in file attributes'
>280 WHEN '5'
>290 DISPLAY 'but optional file is not (yet) present at READ time'
>300 WHEN '6'
>310 DISPLAY 'after AT END was already reached by a previous READ'
>320 WHEN OTHER
>330 DISPLAY 'Unknown minor status'
>340 END-EVALUATE
>350 WHEN '2'
>360 DISPLAY 'Invalid Key condition with unsuccessful completion'
>370 EVALUATE Minor OF FILE-STATUS-EXPLAINED
>380 WHEN '0'
>390 DISPLAY 'No further information'
>400 WHEN '1'
>410 DISPLAY 'sequence error for sequentially accessed indexed file'
>420 WHEN '2'
>430 DISPLAY 'WRITE would create a DUPLICATE KEY'
>440 WHEN '3'
>450 DISPLAY 'tried to randomly access a non-existent record'
>460 WHEN '4'
>470 DISPLAY 'boundary violation: tried to WRITE beyond physical limits or with larger rec no than possible'
>480 WHEN '5'
>490 DISPLAY 'optional file not present at START or READ'
>500 WHEN OTHER
>510 DISPLAY 'Unknown minor status'
>520 END-EVALUATE
>530 WHEN '3'
>540 DISPLAY 'Permanent Error condition with unsuccessful completion'
>550 EVALUATE Minor OF FILE-STATUS-EXPLAINED
>560 WHEN '0'
>570 DISPLAY 'No further information'
>580 WHEN '4'
>590 DISPLAY 'boundary violation. Attempt to write beyond limits of file (disc full?)'
>600 WHEN '5'
>610 DISPLAY 'file not present on OPEN INPUT'
>620 WHEN '6'
>630 DISPLAY 'mismatch of files on one reel'
>640 WHEN '7'
>650 DISPLAY 'OPEN I/O on a file which is not on mass storage'
>660 WHEN '8'
>670 DISPLAY 'file was previously CLOSEd with LOCK - OPEN failed'
>680 WHEN '9'
>690 DISPLAY 'file attribute conflict between specification in program and actual file'
>700 WHEN OTHER
>710 DISPLAY 'Unknown minor status'
>720 END-EVALUATE
>730 WHEN '4'
>740 DISPLAY 'Logic Error condition with unsuccessful completion'
>750 EVALUATE Minor OF FILE-STATUS-EXPLAINED
>760 WHEN '0'
>770 DISPLAY 'No further information'
>780 WHEN '1'
>790 DISPLAY 'can''t OPEN a file which is already OPEN'
>800 WHEN '2'
>810 DISPLAY 'can''t CLOSE a file which is not OPEN'
>820 WHEN '3'
>830 DISPLAY 'a REWRITE or DELETE IN seq mode was tried without prior successful READ'
>840 WHEN '4'
>850 DISPLAY 'boundary violation: record-size mismatch on WRITE or REWRITE, or beyond page limits'
>860 WHEN '6'
>870 DISPLAY 'no next record after unsuccessful START or READ w/o AT END'
>880 WHEN '7'
>890 DISPLAY 'READ on a file not OPENed in READ or I/O mode'
>900 WHEN '8'
>910 DISPLAY 'WRITE on a file not OPENed in WRITE or EXTEND mode'
>920 WHEN '9'
>930 DISPLAY 'REWRITE on a file not OPENed in I/O mode'
>940 WHEN OTHER
>950 DISPLAY 'Unknown minor status'
>960 END-EVALUATE
>961 WHEN '5'
>962 DISPLAY 'Record Lock problem'
>963 WHEN '6'
>964 DISPLAY 'File Lock problem'
>970 WHEN '9'
>980 DISPLAY 'Implementor-defined condition with unsuccessful completion'
>990 WHEN OTHER
>001 DISPLAY 'Unknown File Status '
>010 END-EVALUATE
>020 .
>
> And, of course, it might be nice to have those texts in an array
>so that they might easily be displayed in various languages.
>
> Anybody may feel free to use these two copy elements.
>
>
>
>
>Yours,
>Lüko Willms http://www.mlwerke.de
>/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
>"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
>Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)
>
>

Lueko Willms

2004-11-22, 8:55 pm

.. On 22.11.04
wrote jjgavan@shaw.ca (James J. Gavan)
on /COMP/LANG/COBOL
in d9aod.293074$Pl.199594@pd7tw1no
about Re: Non-Cobol person getting error code

JJG> Looking at your code below, I asked myself the question - has he got
JJG> this code repeated in *every* program. Looks like the answer is
JJG> 'Yes'

Well, actually I had just coded it for one of those test or
demonstration programs which I wrote for this forum. As I explained
before, it nearly a decade that I do not use COBOL for production
programs, I only take a fresh look now.

It is to be used as a COPY-element; of course, it could also be
realized as a subprogram to be CALLed. Most of the possibilities would
never be used, only those pertaining to unrecoverable errors, those
with major status = '3' and '4'. But writing it helped me to regain
knowledge of all those possible file status values.

JJG> because you have locked yourself in to the DECLARATIVES
JJG> SECTION approach.

Yes, that's the place for event handling in a COBOL program.

JJG> I can't give you numbers but there are a fair number here who
JJG> reject the Declaratives approach.

Might well be, and I would guess, they are against it because the
procedures there are just triggered by EVENTS and not by some GOTO or
other very manual control of the program.

I didn't use DECLARATIVES back then when I had to write COBOL
programs as an employee, but after 7 years of event programming using
forms on Windows, I got accustomed to it. The program has to be able
to react to any event, and should not try to put external events under
control of a sequential program flow.

At the beginning it frightened me, to have a module with a number
of procedures in there, but not BEGIN and no END, only procedures
which would be called either bei a form, triggered by some event, like
entering the form, leaving it, entering or leaving a filed, a double-
click with the mouse, are maybe also called directly be the user from
the menu. I was used to COBOL programs which had ONE entry (the first
executable statement in the PROCEDURE DIVISION), and ONE exit (or
multiple exits, if coded badly), and then I had to deal with those
modules having neither start nor end, only the procedures had those...

My view is that the normal program flow in a COBOL program should
take care of _expected_ results and stati of the data being processed,
and leave _unrecoverable_ errors to the contingency processing via
DECLARATIVES. Major error stati 3 (Permanent Error) and 4 (Logical
Error) should not occur in the program, and can't be recovered, so
that the only remedy can be to terminate the program.

JJG> This is my approach against a generic ISAM template, and there
JJG> are others, (in procedural/traditional format) :-

Thank you for the insight in your work. Unfortunately, my COBOL
compiler can't handle objects oriented statements.

I for my part don't think that it is wise to duplicate what the
compiler does in a self-written program, putting an additional layer
between the actual application and the system.

When my program does a READ, the further processing is determined
by the success reflected in the value of the file status, which is
taken care of in the program structure, and unrecoverable errors are
treated by the contingency processing in the EVENT processing part
called DECLARATIVES in a COBOL program.

I do NOT use the AT END and similar phrases with the READ
statements, since all that information is in the file status, and
those phrases to not allow to specify a combined condition. E.g., if I
would want to read only a slice of an indexed file, I would specify a
PERFORM loop with the combined conditional expression "UNTIL has-
reached-end-of-file OR key-item > upper-limit" or similar. So, adding
an additional layer is nothing but an encumbrance.

Sure, it might make sense to write dedicated procedures for each
table or relation in a database, but -- as I mentioned to Robert
Wagner some time ago -- if switching from simple files to database
does not affect the structure of the application, then the design of
that application seesm questionable to me.

Besides, the screen handling according to X/Open and COBOL-2002 is
missing those event handlers; there should be more USE FOR phrases
like

USE AFTER OPENING OF SCREEN <some-screen-name>
USE AFTER ENTERING FIELD <some-field-name>
*> which is called GetFocus in e.g. Javascript
USE AFTER DOUBLE-CLICK ON <some-screen-element>
*> which could be a button or an entry-field

and so on.

A screen-handling program in COBOL would have a very large
DECLARATIVES section, and a relatively short rest of the program.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Man stattete ihm sehr heißen, schon etwas verbrannten Dank ab. -G.C.Lichtenberg

Howard Brazee

2004-11-22, 8:55 pm

On computers that I have worked on, this error has nothing to do with CoBOL, but
is given by the OS - except that you may have to look at the CoBOL source code
to determine why it is expecting a file that has different attributes than what
it sees.

Richard

2004-11-22, 8:55 pm

l.willms@jpberlin.de (Lueko Willms) wrote

> And, of course, it might be nice to have those texts in an array
> so that they might easily be displayed in various languages.

I have the file status texts in my 'decode file', a collection of
small data items indexed by a 'field name' and value. This file is
mainly used for validation items, for example it may have records:

SEX M Male
SEX F Female
SEX O Other

or whatever the client decides is appropriate for that field.

For File status, I have, for example:

FILESTAT 00 Successful operation
FILESTAT 02 Allowable Duplicate key
...
FILESTAT 22 Record with that key already exists.
FILESTAT 23 Record is missing from the file
FILESTAT ....
FILESTAT 9001 Insufficient buffer space
...

These may be changed by the client or redone in a different language
without changing the program. As this file is always open by a
control module that is loaded first in any system there shouldn't be a
problem accessing the codes, except perhaps if there has been a disk
fail.

James J. Gavan

2004-11-23, 3:55 am

Lueko Willms wrote:

>JJG> because you have locked yourself in to the DECLARATIVES
>JJG> SECTION approach.
>
> Yes, that's the place for event handling in a COBOL program.
>
>
>
Don't want to digress to Exception Handling, (haven't written it yet),
but you stumped me originally using 'event' in that context. Guess
that's having the good old 'Windows' blinkers on and thinking of events
as being something primarily coming from focusing on GUIs. (Not
Declaratives as such, but I do recall Pete using the word 'event' in a
similar context - but its meaningfulness at the time passed me by).

However COBOL 2002 certainly supports your contention in terms of OS
'System Events', and the way they currently capture such events, (not
actual coding, but something like) :-

ON EXCEPTION
RAISE EC-FILE-DUPLICATE-KEY

Spurious example but it ties into DECLARATIVES. Did write asking
somebody who might be able to illustrate. He eventually acknowledged my
message with the reply, ":Sorry I've been retired for some years now, so
I haven't kept up with the latest COBOL standards". Pity - keeping the
grey cells active with challenges helps to alleviate the possibility of
becoming a geriatric space-cadet :-)

>JJG> I can't give you numbers but there are a fair number here who
>JJG> reject the Declaratives approach.
>
> Might well be, and I would guess, they are against it because the
>procedures there are just triggered by EVENTS and not by some GOTO or
>other very manual control of the program.
>
> I didn't use DECLARATIVES back then when I had to write COBOL
>programs as an employee, but after 7 years of event programming using
>forms on Windows, I got accustomed to it. The program has to be able
>to react to any event, and should not try to put external events under
>control of a sequential program flow.
>
>
>
Above initially puzzled me - but I see below you do make specific
reference to Windows events - using API GUI features, albeit through an
intermediary GUI tool, whatever that may have been.
I don't want to comment further on what you've written because I will
only find myself getting repetitive when I try to illustrate what I
consider to be my Exception Handling problem - so bear with me.

> At the beginning it frightened me, to have a module with a number
>of procedures in there, but not BEGIN and no END, only procedures
>which would be called either bei a form, triggered by some event, like
>entering the form, leaving it, entering or leaving a filed, a double-
>click with the mouse, are maybe also called directly be the user from
>the menu. I was used to COBOL programs which had ONE entry (the first
>executable statement in the PROCEDURE DIVISION), and ONE exit (or
>multiple exits, if coded badly), and then I had to deal with those
>modules having neither start nor end, only the procedures had those...
>
> My view is that the normal program flow in a COBOL program should
>take care of _expected_ results and stati of the data being processed,
>and leave _unrecoverable_ errors to the contingency processing via
>DECLARATIVES. Major error stati 3 (Permanent Error) and 4 (Logical
>Error) should not occur in the program, and can't be recovered, so
>that the only remedy can be to terminate the program.
>
>
>
Agree basically with above - but not the total case - and taking your
very last statement,

"so that the only remedy can be to terminate the program.",

see my comments when I address Exception Handling.

>JJG> This is my approach against a generic ISAM template, and there
>JJG> are others, (in procedural/traditional format) :-
>
> Thank you for the insight in your work. Unfortunately, my COBOL
>compiler can't handle objects oriented statements.
>
> I for my part don't think that it is wise to duplicate what the
>compiler does in a self-written program, putting an additional layer
>between the actual application and the system.
>
>
You are no doubt well versed in other OO languages, and I think I'm
correct in saying that COBOL is the only language with an in-built file
system (????). Given its own -in-house syntax, COBOL can be manipulated.
I tend to use the word 'concepts' when relating to OO COBOL, but perhaps
more accurately it should be 'OO problem solving design', and follow
that up with
'conventional' COBOL syntax, but assisted by an OO approach.

I struck lucky; although cobolreport.com no longer appears to be
accessible, using a google search on 'Gene Webb' I got the following
link, (which is a part of cobolreport.com) :-
..
http://objectz.com/oocobol/tutorial/

Follow the link through ----> 'Samples"------> "Byte Stream File class",
which is Gene's example on COBOL file handling in OO. It includes
everything but the kitchen sink. Very comprehensive, if somewhat complex
looking, plus he wraps the whole thing in Rational Rose, which tends to
put you off, particularly if you have no knowledge of what Rational Rose
is doing.. Don't get side-winded by the overall concept and look at what
his individual methods are doing. Quite a while since I looked at it,
but from memory it is an overall COBOL file handler. I went for a
simpler approach, (well at least in my opinion), producing a general
purpose class for each of the following ISAM, ISAM with One Alternate
Key, Relative, Sequential and Line Sequential - which allows me to
segregate access successs/failure by file type.

Let's call it quits on file handling and allow me to write my thing on
Exception Handling - 'cos I want to pick you brain, amongst others.

Jimmy

Sponsored Links