MicroFocus Cobol/2 Version 2.4.17 Indexed Files 
Author Message
 MicroFocus Cobol/2 Version 2.4.17 Indexed Files

According to documentation I have on MF Cobol/2, the way to create an
indexed file called vendor.dat with the unique key vendor-number for
MS-DOS is the following:

        SELECT VENDOR-FILE
                ASSIGN TO "VENDOR.DAT"
                ORGANIZATION IS INDEXED
                RECORD KEY IS VENDOR-NUMBER
                ACCESS MODE IS DYNAMIC.

This seems to work fine except that MF will let me add two records
with the same key without generating an error message (I can see them
in the file using Debug). However, when I read the file, only the
first recorded added with the duplicate key seems to be accessible.
Can anyone shed some light on this??

Thanks,
Chuck



Fri, 20 Feb 1998 03:00:00 GMT  
 MicroFocus Cobol/2 Version 2.4.17 Indexed Files


Quote:
> According to documentation I have on MF Cobol/2, the way to create an
> indexed file called vendor.dat with the unique key vendor-number for
> MS-DOS is the following:

>         SELECT VENDOR-FILE
>                 ASSIGN TO "VENDOR.DAT"
>                 ORGANIZATION IS INDEXED
>                 RECORD KEY IS VENDOR-NUMBER
>                 ACCESS MODE IS DYNAMIC.

> This seems to work fine except that MF will let me add two records
> with the same key without generating an error message (I can see them
> in the file using Debug). However, when I read the file, only the
> first recorded added with the duplicate key seems to be accessible.
> Can anyone shed some light on this??

> Thanks,
> Chuck

Hi Chuck,

Just a couple of things to check to make sure that things are ok.

Firstly, use the animator (if you have it, or you debug util) and
just before the write, query the main key and look at each value
BEFORE the write.  Next, just after the write do a check on
FILE-STATUS and see what result you get.

If you do not check your file-status, then all will appear to be ok,
and will seem to have written the two records.

If File-status = "00"  on both record writes, then the primary key
must be different.

A noddy little test for this would be, (Assume your vendor-number is
something like PIC 9(6)).

Create another version of your program, but in the write section, do
something like:

        MOVE  123456            TO  VENDOR-NUMBER.
        WRITE  VENDOR-RECORD.
        DISPLAY  FILE-STATUS  AT  2401  WITH  HIGHLIGHT.
        ACCEPT  WS-INPUT  AT  2480  WITH  NO-ECHO.

        MOVE  123456            TO  VENDOR-NUMBER.
        WRITE  VENDOR-RECORD.
        DISPLAY  FILE-STATUS  AT  2420  WITH  HIGHLIGHT.
        ACCEPT  WS-INPUT  AT  2480  WITH  NO-ECHO.

(I remember the good old days before animators (see above code)).

If this still works, and it should not, the I will need more info,
but if you try this, I think you will either see that the file status
has changed from "00" to "22" on the second write of a duplicate key
or that the main key in some way has changed.

In my experience with Cobol/2, I have had these sorts of problem,
but have found I was doing something wrong somewhere, and I felt
a fool when I found out what it was.

Hang loose,

Dudeman.
--
------------------------------------------------------------

     In The Quiet Of The Night Let Out Candle Always Burn
     Let Us Never Lose The Lessons We Have Learned.
------------------------------------------------------------



Sat, 21 Feb 1998 03:00:00 GMT  
 MicroFocus Cobol/2 Version 2.4.17 Indexed Files
Quote:

>According to documentation I have on MF Cobol/2, the way to create an
>indexed file called vendor.dat with the unique key vendor-number for
>MS-DOS is the following:

>    SELECT VENDOR-FILE
>            ASSIGN TO "VENDOR.DAT"
>            ORGANIZATION IS INDEXED
>            RECORD KEY IS VENDOR-NUMBER
>            ACCESS MODE IS DYNAMIC.

>This seems to work fine except that MF will let me add two records
>with the same key without generating an error message (I can see them
>in the file using Debug). However, when I read the file, only the
>first recorded added with the duplicate key seems to be accessible.
>Can anyone shed some light on this??

>Thanks,
>Chuck

You should be getting a 2/2 status back from the 2nd WRITE. Just because you can see the 2nd record by
looking in the data file doen't mean the record is actually in the index. The record is actually
marked as a deleted record, due to the fact the Micro Focus filehandler 1st writes the record to the
data file, then updates the index. If the index update fails, the record written to the data file is
simply marked as deleted and added to the data free space list, so it can be reused.
As the program has no file status defined, the program should be bombing out with a runtime error,
unless you have a invalid key clause, in which case it's up to the program to handle the error
condition (this may explain why no error is being generated).

--------------------------------



Sat, 21 Feb 1998 03:00:00 GMT  
 MicroFocus Cobol/2 Version 2.4.17 Indexed Files

Quote:



>> According to documentation I have on MF Cobol/2, the way to create an
>> indexed file called vendor.dat with the unique key vendor-number for
>> MS-DOS is the following:

>>         SELECT VENDOR-FILE
>>                 ASSIGN TO "VENDOR.DAT"
>>                 ORGANIZATION IS INDEXED
>>                 RECORD KEY IS VENDOR-NUMBER
>>                 ACCESS MODE IS DYNAMIC.

>> This seems to work fine except that MF will let me add two records
>> with the same key without generating an error message (I can see them
>> in the file using Debug). However, when I read the file, only the
>> first recorded added with the duplicate key seems to be accessible.
>> Can anyone shed some light on this??

>> Thanks,
>> Chuck

>Hi Chuck,
>Just a couple of things to check to make sure that things are ok.
>Firstly, use the animator (if you have it, or you debug util) and
>just before the write, query the main key and look at each value
>BEFORE the write.  Next, just after the write do a check on
>FILE-STATUS and see what result you get.
>If you do not check your file-status, then all will appear to be ok,
>and will seem to have written the two records.
>If File-status = "00"  on both record writes, then the primary key
>must be different.
>A noddy little test for this would be, (Assume your vendor-number is
>something like PIC 9(6)).
>Create another version of your program, but in the write section, do
>something like:
>    MOVE  123456            TO  VENDOR-NUMBER.
>        WRITE  VENDOR-RECORD.
>    DISPLAY  FILE-STATUS  AT  2401  WITH  HIGHLIGHT.
>    ACCEPT  WS-INPUT  AT  2480  WITH  NO-ECHO.
>    MOVE  123456            TO  VENDOR-NUMBER.
>    WRITE  VENDOR-RECORD.
>    DISPLAY  FILE-STATUS  AT  2420  WITH  HIGHLIGHT.
>        ACCEPT  WS-INPUT  AT  2480  WITH  NO-ECHO.
>(I remember the good old days before animators (see above code)).
>If this still works, and it should not, the I will need more info,
>but if you try this, I think you will either see that the file status
>has changed from "00" to "22" on the second write of a duplicate key
>or that the main key in some way has changed.
>In my experience with Cobol/2, I have had these sorts of problem,
>but have found I was doing something wrong somewhere, and I felt
>a fool when I found out what it was.
>Hang loose,

Mark,

Thanks for the reply. I am new at this stuff so I sort of understand
what you are doing here. Apparently, the FILE-STATUS should show that
the second write is creating an error and not updating the index file
(which is consistant with what I am seeing when I print put the file
after adding several duplicate key records). I am not sure how to set
up the FILE-STATUS variable (I put it in WORKING-STORAGE but cannot
seem to get it to work) can you give me just a bit more detail?

Thanks,
Chuck



Sun, 22 Feb 1998 03:00:00 GMT  
 MicroFocus Cobol/2 Version 2.4.17 Indexed Files

Quote:


>>According to documentation I have on MF Cobol/2, the way to create an
>>indexed file called vendor.dat with the unique key vendor-number for
>>MS-DOS is the following:

>>        SELECT VENDOR-FILE
>>                ASSIGN TO "VENDOR.DAT"
>>                ORGANIZATION IS INDEXED
>>                RECORD KEY IS VENDOR-NUMBER
>>                ACCESS MODE IS DYNAMIC.

>>This seems to work fine except that MF will let me add two records
>>with the same key without generating an error message (I can see them
>>in the file using Debug). However, when I read the file, only the
>>first recorded added with the duplicate key seems to be accessible.
>>Can anyone shed some light on this??

>>Thanks,
>>Chuck

>You should be getting a 2/2 status back from the 2nd WRITE. Just because you can see the 2nd record by
>looking in the data file doen't mean the record is actually in the index. The record is actually
>marked as a deleted record, due to the fact the Micro Focus filehandler 1st writes the record to the
>data file, then updates the index. If the index update fails, the record written to the data file is
>simply marked as deleted and added to the data free space list, so it can be reused.
>As the program has no file status defined, the program should be bombing out with a runtime error,
>unless you have a invalid key clause, in which case it's up to the program to handle the error
>condition (this may explain why no error is being generated).
>--------------------------------


Thanks, Ray. That explains why when I print the data file, I only see
the first record in the printout. The second one does not exist in the
index file.

Chuck



Sun, 22 Feb 1998 03:00:00 GMT  
 MicroFocus Cobol/2 Version 2.4.17 Indexed Files
The most common error encountered in COBOL programs using the FILE STATUS
construct is the failure to check the value of the FILE STATUS data item
after each and every I/O verb.  OPEN, CLOSE, READ, WRITE, REWRITE all can
cause changes to the value.  Many hidden bugs and 3:00 AM failures result
from failing to comprehensively check for the desired values.

An extra caution in using the MF COBOL (and for that matter all 85
standard COBOLs).  The exact values of File Status codes in the 9x range
is Implementor Defined.  Thus a program checking for a file status 92
might get an entirely different 9x value when ported from a text book
author's machine to MF, etc.

A final caution (learned with much wasted time) MF COBOL optionally (based
on a compile time directive) can redefine the second position of FILE
STATUS values as a one byte binary number representing a MF error message
code, rather than the more expected 0 - 9 value.  This only appears to
occur on 9x series code, so I have taken to define the 2 position file
status code as separate items under a single  01 entry to allow easy
access to the gross (first digit) and fine (second digit) status
indications, and the ability to more closely inspect the second byte.



Sun, 22 Feb 1998 03:00:00 GMT  
 MicroFocus Cobol/2 Version 2.4.17 Indexed Files


Quote:



> Thanks for the reply. I am new at this stuff so I sort of understand
> what you are doing here. Apparently, the FILE-STATUS should show that
> the second write is creating an error and not updating the index file
> (which is consistant with what I am seeing when I print put the file
> after adding several duplicate key records). I am not sure how to set
> up the FILE-STATUS variable (I put it in WORKING-STORAGE but cannot
> seem to get it to work) can you give me just a bit more detail?

> Thanks,
> Chuck

No Problem, but being that you are a bit new to this, here are a couple
of pointers.

1) File status.

   File status is a piece of working storage which you can set up and
   have the file i-o return codes written to.  This is good practice
   as you must check the file-status after every file operation.  I
   have known programmers that have written very nice structured code
   but with no file-status check.  The argument is that if a program
   is very well structured then you may not need to check the file-
   status.  I diagree, what happens if the hard disk goes down whilst
   you are running your program, your program will have no idea, except
   when the run time comes screaming to it's knees.

   Anyway, in your VENDOR files SELECT section, add an extra line to
   this to read:

                FILE STATUS  IS  FILE-STATUS.

   This ensures that when you do any file i-o, the result will be placed
   into the ws called FILE-STATUS.

2) Define FILE-STATUS.

   In Your WS section, or in a copybook in the WS (recommended, as this
   piece of code can be used for all programs which file i-o), define
   the WS as:

                01  FILE-STATUS-CAPTURE.
                    03  FILE-STATUS.
                        05  FILE-STAT1          PIC X.
                        05  FILE-STAT2          PIC X.
                    03  BINARY-STATUS  REDEFINES  FILE-STATUS.
                        05  BINARY-STAT         PIC 9(4) COMP-4.

3) File I-O.

   Everytime you do any file operation (OPEN, CLOSE, READ, START) the
   FILE-STATUS will be set.  This will allow you to control how the
   file I-O is going.

   Example, you want to search a given file for all records with the
   name of DUDEMAN on them, and your file has an alternate key of
   VENDOR-NAME.

   So, you could:-

        INITIALIZE  VENDOR-RECORD.
        MOVE  "DUDEMAN"               TO  VENDOR-NAME.

        START  VENDOR-FILE  KEY  NOT  <  VENDOR-NAME.

   Now you can check the FILE-STATUS.

        EVALUATE  FILE-STATUS

                WHEN  "00"  (EVERY THING WENT OK)
                        GO TO NEXT-PROCESS
                WHEN  "02"  (OK, BUT DUPLICATE KEY)
                        GO TO NEXT-PROCESS
                WHEN  "10"  (END OF FILE)
                        GO TO NO-RECORDS-FOUND
                WHEN  "23"  (NO RECORDS FOUND MATCHING)
                        GO TO NO-RECORDS-FOUND
                WHEN  OTHER (SOME OTHER CODE)
                        GO TO ERROR-PROCESSING

        END-EVALUATE.

I strongly suggest that you also write a common error routine and make
this a copybook, so that you can copy it into all programs which use
file i-o.

Hope this has helped, (P.S. The Binary-Status field will allow you to
decode extended file-status codes ie, 141, 042, 013 etc).

Hang loose,

Mark.  

--
------------------------------------------------------------

     In The Quiet Of The Night Let Out Candle Always Burn
     Let Us Never Lose The Lessons We Have Learned.
------------------------------------------------------------



Sun, 22 Feb 1998 03:00:00 GMT  
 MicroFocus Cobol/2 Version 2.4.17 Indexed Files

Quote:


>1) File status.
>   File status is a piece of working storage which you can set up and
>    .....................................................
>   have the file i-o return codes written to.  This is good practice
>   into the ws called FILE-STATUS.
>2) Define FILE-STATUS.
>3) File I-O.

>     In The Quiet Of The Night Let Out Candle Always Burn
>     Let Us Never Lose The Lessons We Have Learned.
>------------------------------------------------------------

Mark,

Thanks a million!! That really helps me a lot. I have tried to find
some basic schools here in Ga. to help me get started with Cobol but
they just do not seem to exist. So, I am reading the book and trying
things out. I appreciate you taking the time to be so detailed about
this.

Chuck



Wed, 04 Mar 1998 03:00:00 GMT  
 MicroFocus Cobol/2 Version 2.4.17 Indexed Files


Quote:


> >1) File status.

> >   File status is a piece of working storage which you can set up and
> >    .....................................................
> >   have the file i-o return codes written to.  This is good practice
> >   into the ws called FILE-STATUS.

> >2) Define FILE-STATUS.

> >3) File I-O.


> >     In The Quiet Of The Night Let Out Candle Always Burn
> >     Let Us Never Lose The Lessons We Have Learned.
> >------------------------------------------------------------

> Mark,

> Thanks a million!! That really helps me a lot. I have tried to find
> some basic schools here in Ga. to help me get started with Cobol but
> they just do not seem to exist. So, I am reading the book and trying
> things out. I appreciate you taking the time to be so detailed about
> this.

> Chuck

Hi,

No problem Chuck, I know when I first started to learn
Cobol, I found it pretty hard going for the first 6
months or so, and after then things started to fall
into place and everything came together.

I was also lucky that I was working with a guy who knew
Cobol, so I could ask questions.

Anyway, no problem for the info, if you need anything
else to do with MF Cobol, then post another article
and if I cant help, I'm sure someone esle will know
the solution.

Hang Loose and happy programming!

Mark W.
--
------------------------------------------------------------

     In The Quiet Of The Night Let Out Candle Always Burn
     Let Us Never Lose The Lessons We Have Learned.
------------------------------------------------------------



Wed, 04 Mar 1998 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Microfocus COBOL index file structure

2. Microfocus COBOL version 3.1 versus UNIX File listing.

3. Help with Microfocus personal cobol and Microfocus Level II cobol

4. Worbench Microfocus Problem file indexed access random

5. CONVERT INDEXED FILES FROM ICOBOL TO MICROFOCUS

6. Microfocus Cobol for Linux - buy or swap with SCO OS5 version

7. Microfocus Cobol for Linux - buy or swap with SCO OS5 version

8. Microfocus Cobol for Linux - buy or swap with SCO OS5 version

9. Recherche COBOL MICROFOCUS d'occas version 4 32 bits

10. MICROFOCUS COBOL WORKBENCH VERSION 3.1 TO 4.0

11. indexed file format and data files- for cobol compilers

12. ASCII File (written with Microfocus) content and IBM Cobol Set for AIX

 

 
Powered by phpBB® Forum Software