sccrs_seek_monthly Starting execution of SK060000 transformation on 20140716...
WARNING - Implicit CLOSE of WFINPUT2-FILE ("SK060WFINPUT2")
WARNING - Implicit CLOSE of WFINPUT-FILE ("SK060WFINPUT")
sccrs_seek_monthly PROBLEMS - Refer to /tmp/sccrs_seek_monthly_ERROR_LOG_12280 for details
sccrs_seek_monthly Sending notification...
Temp file referred to above in nohup.out looks as follows:
s032:/usr/DATA/ETL/reports> cat sccrs_seek_monthly.sysout
Error Opening File: SK060100
File Status Return Code FILE-STATUS-KEY-1: 9 FILE-STATUS-KEY-2: 049 <<<<<<<<<<<<<<<<< MEANING????
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
SK060000 ABENDED WITH A RETURN-CODE OF 91
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These code snips can't compile. It has FILE-STATUS-KEY-2 defined twice.
But aside from that, what this code shows is a technique common to Micro Focus. Whenever they get a "9x" file status code, the x is a 1 byte binary number. That way they can have up to 255 different "9x" error codes. Look in their manual for the list.
GNU COBOL doesn't have any binary numbers in the file status codes. So this code isn't useful for this compiler.
Convert the x into a display number to print it. The DISPLAY statement in the code did the conversion automatically, but I wouldn't count on it on all compilers.
In this case it converted to a number 049. Looking up that number in the ASCII table shows that it is character "1".
So the file status code in question is "91". We can see that as the last display from S999-ABEND.
All "9x" codes are vendor defined. To determine what this means, you must look in the manual for the vendor. If this Micro Focus, you must look in their book. The GNU COBOL manual can't help with that.
But if this is being run with GNU COBOL, the GNU COBOL manual shows "91" as meaning "File not available."
Again, if this is not being run with GNU COBOL, then "91" might mean something completely different.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you can see all FILE-STATUS codes in the Doc.: GNU COBOL 2.0 Programmer’s Guide.
But your re-definition does not match with the Document:
"The FILE STATUS or SORT STATUS clause (they are both equivalent and only one or the other, if any, should be specified) is used to specify the name of a PIC 9(2) data item into which an I/O status code will be saved after every I/O verb that is executed against the file. This does not actually allocate the data item – you still need to allocate the item yourself somewhere in the DATA DIVISION."
It must be also PIC 9(2), and then you can use for example this code to get a message:
:::cobolfreeENVIRONMENTDIVISION.INPUT-OUTPUTSECTION.FILE-CONTROL.SELECTCOB-FILEASSIGNTOWS-COB-FILE-NAMESTATUSISWS-COB-FILE-STATUSORGANIZATIONISLINESEQUENTIAL.DATADIVISION.FILESECTION.FDCOB-FILE.01COB-LINEPICX(4096).WORKING-STORAGESECTION.*>file-status01WS-FILE-STATUS.02WS-COB-FILE-STATUSPIC9(02).88V-COB-FILE-OKVALUE00.88V-COB-FILE-EOFVALUE10.*>file-statusmessage01WS-FS-MESSAGE.02FILLERPICX(13)VALUE"Status Code: ".02WS-FS-CODEPIC9(2).02FILLERPICX(11)VALUE", Meaning: ".02WS-FS-MSG-TXTPICX(25).PROCEDUREDIVISION.DECLARATIVES.*>---------------------------------------------------------------------- COB-FILE-ERROR SECTION.*>---------------------------------------------------------------------- USE AFTER STANDARD ERROR PROCEDURE ON COB-FILE.IFNOTV-COB-FILE-EOFOFWS-COB-FILE-STATUSTHENMOVEWS-COB-FILE-STATUSTOWS-FS-CODEOFWS-FS-MESSAGEPERFORMEVAL-FILE-STATUSDISPLAYWS-FS-MESSAGEEND-IFEXITSECTION.COB-FILE-ERROR-EX.EXIT.*>---------------------------------------------------------------------- EVAL-FILE-STATUS SECTION.*>---------------------------------------------------------------------- EVALUATE WS-FS-CODE OF WS-FS-MESSAGEWHEN00MOVE"SUCCESS "TOWS-FS-MSG-TXTWHEN02MOVE"SUCCESS DUPLICATE "TOWS-FS-MSG-TXTWHEN04MOVE"SUCCESS INCOMPLETE "TOWS-FS-MSG-TXTWHEN05MOVE"SUCCESS OPTIONAL "TOWS-FS-MSG-TXTWHEN07MOVE"SUCCESS NO UNIT "TOWS-FS-MSG-TXTWHEN10MOVE"END OF FILE "TOWS-FS-MSG-TXTWHEN14MOVE"OUT OF KEY RANGE "TOWS-FS-MSG-TXTWHEN21MOVE"KEY INVALID "TOWS-FS-MSG-TXTWHEN22MOVE"KEY EXISTS "TOWS-FS-MSG-TXTWHEN23MOVE"KEY NOT EXISTS "TOWS-FS-MSG-TXTWHEN30MOVE"PERMANENT ERROR "TOWS-FS-MSG-TXTWHEN31MOVE"INCONSISTENT FILENAME "TOWS-FS-MSG-TXTWHEN34MOVE"BOUNDARY VIOLATION "TOWS-FS-MSG-TXTWHEN35MOVE"FILE NOT FOUND "TOWS-FS-MSG-TXTWHEN37MOVE"PERMISSION DENIED "TOWS-FS-MSG-TXTWHEN38MOVE"CLOSED WITH LOCK "TOWS-FS-MSG-TXTWHEN39MOVE"CONFLICT ATTRIBUTE "TOWS-FS-MSG-TXTWHEN41MOVE"ALREADY OPEN "TOWS-FS-MSG-TXTWHEN42MOVE"NOT OPEN "TOWS-FS-MSG-TXTWHEN43MOVE"READ NOT DONE "TOWS-FS-MSG-TXTWHEN44MOVE"RECORD OVERFLOW "TOWS-FS-MSG-TXTWHEN46MOVE"READ ERROR "TOWS-FS-MSG-TXTWHEN47MOVE"INPUT DENIED "TOWS-FS-MSG-TXTWHEN48MOVE"OUTPUT DENIED "TOWS-FS-MSG-TXTWHEN49MOVE"I/O DENIED "TOWS-FS-MSG-TXTWHEN51MOVE"RECORD LOCKED "TOWS-FS-MSG-TXTWHEN52MOVE"END-OF-PAGE "TOWS-FS-MSG-TXTWHEN57MOVE"I/O LINAGE "TOWS-FS-MSG-TXTWHEN61MOVE"FILE SHARING FAILURE "TOWS-FS-MSG-TXTWHEN91MOVE"FILE NOT AVAILABLE "TOWS-FS-MSG-TXTEND-EVALUATE.EVAL-FILE-STATUS-EX.EXIT.ENDDECLARATIVES.
László
Last edit: Simon Sobisch 2014-07-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But, 91 isn't FILE NOT AVAILABLE, it's FEATURE NOT AVAILABLE. Compile time options and choice of ISAM engine can trigger this. Just in case you ever actually see that status and need to start digging in.
If a custom EXTFH doesn't support delete, then DELETE FILE can return a 91, for instance. (EXTFH being one of the ./configure --with-index-extfh=... advanced compiler build options. There are other custom configurations that can trip a 91.)
Cheers,
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I'm Tony the programmer...
I've modified the code just slightly to make it easier to understand what is going on. No functionality changed and results are the same.
File control looks as follows:
::cobol
* ISAM File Of County Data (060T)
*********
SELECT SK060100-FILE
FILE STATUS IS FILE-STATUS
##GNU# ASSIGN TO "SK060100"
ORGANIZATION IS INDEXED
ACCESS MODE IS SEQUENTIAL
RECORD KEY IS COUNTY-NUMBER
OF SK060100-REC.
Working storage looks as follows:
You'll notice the last line is commented out which was included in the original post & I changed FILE-STATUS from X(02) to 9(02).
And I made some small changes to the displays that where causing confusion among the various people looking at this.
Following is the code that opens an ISAM file for output that is generating the error. This is being run with GNU COBOL (we are trying to convert our system from MicroFocus COBOL) and I understand the KEY-1 & KEY-2 fields are not useful at this time but are just leftover from running MF.
::cobolOPENOUTPUTSK060100-FILE.IFNOTFILE-STATUS-OKDISPLAY'Error Opening File: SK060100'IFFILE-STATUS-KEY-1EQUALS'9'DISPLAY'File Status Return Code 'DISPLAY'FILE-STATUS : 'FILE-STATUS' 'DISPLAY'FILE-STATUS-KEY-1: 'FILE-STATUS-KEY-1' 'DISPLAY'FILE-STATUS-KEY-2: 'FILE-STATUS-KEY-2ELSEDISPLAY'File Status Return Code: 'FILE-STATUSEND-IFMOVEFILE-STATUSTOWFABEND-CODEPERFORMS999-ABENDEND-IF.
And finally this is what the modified displays look like.
The temporary fix for 1.1 is likely to change config.h, these two must be set in your case
::c/* Use Berkeley DB library new features */#defineUSE_DB411/* Compile with the Berkeley DB library */#defineWITH_DB3
and do make && make check && make check again.
Can you please recheck with 2.0 from svn (adding --prefix=whereeveryouwantto)? Even if this means you have to recompile the COBOL sources too, if there is the need for a bugfix it will likely be placed in 2.0.
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I look in config.h, it appears that the option "--with-db=/usr/local/BerkeleyDB.4.7" did not really work on the configure statement. I mean, this is what I am seeing:
/ Use Berkeley DB library new features /
/ #undef USE_DB41 /
/ Compile with the Berkeley DB library /
/ #undef WITH_DB /
So, perhaps the issue I had with errors related to BerkeleyDB.4.7 vs SUNWbdb (BerkeleyDB-Base 4.2.52 also installed) was not really resolved when I tried that. I never noticed a problem when I ran the checks.
In any event, will your workaround resolve this? If I remember correctly, there was an issue with not being able to find Berkeley DB 4.7 during the configure or make.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If this doesn't work (see summary at end of configure) you could try to change the config.h entries as mentioned above and try a make afterwards (you either can compile it or not).
In any case make check should work fine, with no skipped tests (only ISAM related tests are skipped in 1.1 if no ISAM is configured).
If this doesn't work try 2.0-branch (with the configure line above), the configure+make scripts were changed a lot (make check in 2.0-branch will currently skip report-writer tests).
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Same results both ways. Back to my original error from a month ago. The configure tries to find the version and is unable to do so. Bug? Does not like BerkeleyDB version 4.7
So, I guess I need to run it the way it works, then edit the config.h, correct gurus?
root@scc032: ./configure CXXFLAGS=-I/usr/local/BerkeleyDB.4.7/include LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib --without-libiconv-prefix
checking for a BSD-compatible install... ./install-sh -c
checking whether build environment is sane... yes
(snip)
checking for Berkeley DB db.h version >= 4.1 ... yes (4.7)
configure: error: Include file db.h implies version >=4.1 but no library found
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are new to OpenCobol/GNU Cobol but experienced with COBOL. We don't know whether to stay with COBOL 1.1 or move to COBOL 2.0. Our usage is strictly batch processing of files. We are a Data Warehouse using COBOL to perform the extract and transform tasks of Extract, Transform and Load (ETL). There is no transactional or interactive or visual aspect to our usage.
With all the caveats about not being a "stable release" should we consider using COBOL 2.0 considering it is the now the more supported and patched version?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It has been stable for me over the last 2-3 years with very few bugs
seen but there again I just put my some 100+ programs through it and if
they work I am happy.
I have used many of the functions that are in v2 but not some of the
more weird one's.
Would I recommend it : Yes at least try it and run a test batch flow
through but not sure you will notice much in speed throughput but it is
a lot cleaner.
My current one and has been for all of this year is v2.1 with report
writer under Linux X64.
Vincent
On 23/07/14 13:13, Tony Partin wrote:
We are new to OpenCobol/GNU Cobol but experienced with COBOL. We don't
know whether to stay with COBOL 1.1 or move to COBOL 2.0. Our usage is
strictly batch processing of files. We are a Data Warehouse using
COBOL to perform the extract and transform tasks of Extract, Transform
and Load (ETL). There is no transactional or interactive or visual
aspect to our usage.
With all the caveats about not being a "stable release" should we
consider using COBOL 2.0 considering it is the now the more supported
and patched version?
Hi Team,
In the output below, what is the error being referenced by the FILE-STATUS-KEY-2 of "049"?
Thanks,
Susanne
Creating lookup table...
sccrs_seek_monthly Cleaning file /tmp/sccrs_seek_monthly_LOOKUP_TBL_SQL_12280.out.ascii...
sccrs_seek_monthly Starting execution of SK060000 transformation on 20140716...
WARNING - Implicit CLOSE of WFINPUT2-FILE ("SK060WFINPUT2")
WARNING - Implicit CLOSE of WFINPUT-FILE ("SK060WFINPUT")
sccrs_seek_monthly PROBLEMS - Refer to /tmp/sccrs_seek_monthly_ERROR_LOG_12280 for details
sccrs_seek_monthly Sending notification...
Temp file referred to above in nohup.out looks as follows:
s032:/usr/DATA/ETL/reports> cat sccrs_seek_monthly.sysout
Error Opening File: SK060100
File Status Return Code FILE-STATUS-KEY-1: 9 FILE-STATUS-KEY-2: 049 <<<<<<<<<<<<<<<<< MEANING????
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
SK060000 ABENDED WITH A RETURN-CODE OF 91
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Depends on how you've got file-status-key-1 and file-status-key-2. Posting this necessary information will help to get the answer.
Simon
I have a login now.
Here is what I posted earlier for the moderator...
My customer, Tony, Cobol programmer, responded...
Here is the code that I think they are looking for:
We are using Berkeley DB, V4.7, but this can change if needed.
Regards,
Susanne, OS Admin
Last edit: Simon Sobisch 2014-07-21
These code snips can't compile. It has FILE-STATUS-KEY-2 defined twice.
But aside from that, what this code shows is a technique common to Micro Focus. Whenever they get a "9x" file status code, the x is a 1 byte binary number. That way they can have up to 255 different "9x" error codes. Look in their manual for the list.
GNU COBOL doesn't have any binary numbers in the file status codes. So this code isn't useful for this compiler.
Convert the x into a display number to print it. The DISPLAY statement in the code did the conversion automatically, but I wouldn't count on it on all compilers.
In this case it converted to a number 049. Looking up that number in the ASCII table shows that it is character "1".
So the file status code in question is "91". We can see that as the last display from S999-ABEND.
All "9x" codes are vendor defined. To determine what this means, you must look in the manual for the vendor. If this Micro Focus, you must look in their book. The GNU COBOL manual can't help with that.
But if this is being run with GNU COBOL, the GNU COBOL manual shows "91" as meaning "File not available."
Again, if this is not being run with GNU COBOL, then "91" might mean something completely different.
Hi,
you can see all FILE-STATUS codes in the Doc.: GNU COBOL 2.0 Programmer’s Guide.
But your re-definition does not match with the Document:
"The FILE STATUS or SORT STATUS clause (they are both equivalent and only one or the other, if any, should be specified) is used to specify the name of a PIC 9(2) data item into which an I/O status code will be saved after every I/O verb that is executed against the file. This does not actually allocate the data item – you still need to allocate the item yourself somewhere in the DATA DIVISION."
It must be also PIC 9(2), and then you can use for example this code to get a message:
László
Last edit: Simon Sobisch 2014-07-21
Nice, László
But, 91 isn't FILE NOT AVAILABLE, it's FEATURE NOT AVAILABLE. Compile time options and choice of ISAM engine can trigger this. Just in case you ever actually see that status and need to start digging in.
If a custom EXTFH doesn't support delete, then DELETE FILE can return a 91, for instance. (EXTFH being one of the ./configure --with-index-extfh=... advanced compiler build options. There are other custom configurations that can trip a 91.)
Cheers,
Brian
Hi Brian,
there is a table about it, in GNU COBOL 2.0 Programmers Guide, page 4-11. We have to change the message for 91 there.
László
I'll pester Gary.
Thanks, László.
Cheers,
Brian
Hi, I'm Tony the programmer...
I've modified the code just slightly to make it easier to understand what is going on. No functionality changed and results are the same.
File control looks as follows:
Working storage looks as follows:
You'll notice the last line is commented out which was included in the original post & I changed FILE-STATUS from X(02) to 9(02).
And I made some small changes to the displays that where causing confusion among the various people looking at this.
Following is the code that opens an ISAM file for output that is generating the error. This is being run with GNU COBOL (we are trying to convert our system from MicroFocus COBOL) and I understand the KEY-1 & KEY-2 fields are not useful at this time but are just leftover from running MF.
And finally this is what the modified displays look like.
Thanks for all the help!
Last edit: Simon Sobisch 2014-07-21
Also we are running GNU COBOL 1.1.
Please include the output from cobc --info (or cobc --version if the first command is not implemented).
Having a quick look at 1.1:
This should be only returned if you configured --without-db. But the output of cobc --info will shed some light on this.
Simon
Jumping in here, given that I did the install. I chose with-db, but specified that I wanted a particular version. Here it is:
Also,
Last edit: Simon Sobisch 2014-07-21
Looks valid.
The temporary fix for 1.1 is likely to change config.h, these two must be set in your case
and do make && make check && make check again.
Can you please recheck with 2.0 from svn (adding --prefix=whereeveryouwantto)? Even if this means you have to recompile the COBOL sources too, if there is the need for a bugfix it will likely be placed in 2.0.
Simon
When I look in config.h, it appears that the option "--with-db=/usr/local/BerkeleyDB.4.7" did not really work on the configure statement. I mean, this is what I am seeing:
/ Use Berkeley DB library new features /
/ #undef USE_DB41 /
/ Compile with the Berkeley DB library /
/ #undef WITH_DB /
So, perhaps the issue I had with errors related to BerkeleyDB.4.7 vs SUNWbdb (BerkeleyDB-Base 4.2.52 also installed) was not really resolved when I tried that. I never noticed a problem when I ran the checks.
In any event, will your workaround resolve this? If I remember correctly, there was an issue with not being able to find Berkeley DB 4.7 during the configure or make.
If I may make a comment with only seeing some of the posts:
Status code is pic 99 or if you have a need xx.
It is not split into binary.
However for a MF compiler that is valid but NOT GNU / Open Cobol.
Please see the programmers manual/guide.
Vince
Last edit: Simon Sobisch 2014-07-21
I'd try to reconfigure first:
If this doesn't work (see summary at end of configure) you could try to change the config.h entries as mentioned above and try a make afterwards (you either can compile it or not).
In any case make check should work fine, with no skipped tests (only ISAM related tests are skipped in 1.1 if no ISAM is configured).
If this doesn't work try 2.0-branch (with the configure line above), the configure+make scripts were changed a lot (make check in 2.0-branch will currently skip report-writer tests).
Simon
I am getting ready to run this now, but noticed that the configure statement above does not include "--with-db". Did you mean to say:
export LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.7/lib
./configure CXXFLAGS=-I/usr/local/BerkeleyDB.4.7/ \
include LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib \
--with-db --without-libiconv-prefix
There is (currently) no need to add --with-db as this is the standard option. I'd change the export to
Simon
Fixed typos in question above about with-db:
./configure CXXFLAGS=-I/usr/local/BerkeleyDB.4.7/include LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib --with-db --without-libiconv-prefix
Same results both ways. Back to my original error from a month ago. The configure tries to find the version and is unable to do so. Bug? Does not like BerkeleyDB version 4.7
So, I guess I need to run it the way it works, then edit the config.h, correct gurus?
root@scc032: ./configure CXXFLAGS=-I/usr/local/BerkeleyDB.4.7/include LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib --without-libiconv-prefix
checking for a BSD-compatible install... ./install-sh -c
checking whether build environment is sane... yes
(snip)
checking for Berkeley DB db.h version >= 4.1 ... yes (4.7)
configure: error: Include file db.h implies version >=4.1 but no library found
May have come up before but:
What DB47 libraries have you installed?
Have you installed : lib64db4.7 and lib64db4.7-devel
or if you only use 32 bit Linux same as above but without the '64' bit.
Vince
Last edit: Simon Sobisch 2014-07-22
As said before: GNU Cobol 2.0 will work - as it uses the extracted version number (in your case 4.7) for checking the correct library.
You can kind-of-fix 1.1 (both configure.ac [just in case you regenerate it] and configure)
configure should find the correct library afterwards.
Simon
We are new to OpenCobol/GNU Cobol but experienced with COBOL. We don't know whether to stay with COBOL 1.1 or move to COBOL 2.0. Our usage is strictly batch processing of files. We are a Data Warehouse using COBOL to perform the extract and transform tasks of Extract, Transform and Load (ETL). There is no transactional or interactive or visual aspect to our usage.
With all the caveats about not being a "stable release" should we consider using COBOL 2.0 considering it is the now the more supported and patched version?
It has been stable for me over the last 2-3 years with very few bugs
seen but there again I just put my some 100+ programs through it and if
they work I am happy.
I have used many of the functions that are in v2 but not some of the
more weird one's.
Would I recommend it : Yes at least try it and run a test batch flow
through but not sure you will notice much in speed throughput but it is
a lot cleaner.
My current one and has been for all of this year is v2.1 with report
writer under Linux X64.
Vincent
On 23/07/14 13:13, Tony Partin wrote: