MF Cobol File Locks,ATomic File Close/Delt 
Author Message
 MF Cobol File Locks,ATomic File Close/Delt

Quote:

> I'm doing development work for multiple Unix platforms with MicroFocus
> Cobol.
> I'd appreciate it if anyone has an idea to either 1) make MF Cobol locks
> honored by non-Cobol applications,

That would be very difficult - the non-COBOL program would have to know and
reproduce exactly the method we use for file/record locking.
There is a reason we don't physically lock the portion of the file containing
the logically locked record - COBOL semantics say that using certain syntax
(I forget exactly what just now) you should still be allowed to read a locked
record, but recieve a "locked record" status to go with it.

Quote:
> 2) make MF Cobol do an atomic file close and delete that will allow the
> other application to recreate the file (?).

Have you tried deleting the file before closing it ?? Unix will still keep
the original file open for any COBOL programs using it, but it will have no
directory entry, so when your non-cobol process creates a new file with
that name, it will be allocated a different inode and you will have two
files, only one of which (the new one) is visible. As soon as the COBOL
processes die (or the files are closed), Unix will handle the removal of the
original file from the inode table. This is standard Unix behaviour - I don't
know about AS/400 though.

COBOL syntax only ? Hmmm - DELETE FILE "filename" might just check that the
file doesn't have a COBOL exclusive lock :(

How about: CALL "system" Using "rm -f filename" & x"00"

I know it's not quite what you mean, but that's still COBOL syntax :)

I'm not neccessarily condoning you use this without testing it carefully. It
depends just what this file is for etc, but you're potentially talking about
losing data even now :

COBOL opens file ....
non-COBOL opens file ....
COBOL deletes file ....
COBOL closes file ....

Anything written to the file by the non-COBOL program is still lost in this
case, because the file goes away the moment the non-COBOL program closes it.
This is a suggestion based on what you have asked for. You must take full
responsibility for any loss incurred due to your decision to use this
technique.

Cheers, Kev.

--


These views are strictly my own.
I doubt very much that anyone else would want them.



Tue, 28 Jul 1998 03:00:00 GMT  
 MF Cobol File Locks,ATomic File Close/Delt

Quote:

>> 2) make MF Cobol do an atomic file close and delete that will allow
the
>> other application to recreate the file (?).

>Have you tried deleting the file before closing it ?? Unix will still
keep
>the original file open for any COBOL programs using it, but it will have
no
>directory entry, so when your non-cobol process creates a new file with
>that name, it will be allocated a different inode and you will have two
>files, only one of which (the new one) is visible. As soon as the COBOL
>processes die (or the files are closed), Unix will handle the removal of
the
>original file from the inode table. This is standard Unix behaviour - I
don't
>know about AS/400 though.

Thanks for the reply Kevin.  I did try deleting the file while it was
still open - the delete did not take place.  I'll have to retest that
though, because as I think of it, I was not closing the file after the
delete.

Quote:

>COBOL syntax only ? Hmmm - DELETE FILE "filename" might just check that
the
>file doesn't have a COBOL exclusive lock :(

That's what the MF manual says also...

Quote:

>How about: CALL "system" Using "rm -f filename" & x"00"

>I know it's not quite what you mean, but that's still COBOL syntax :)

>COBOL opens file ....
>non-COBOL opens file ....
>COBOL deletes file ....
>COBOL closes file ....

>Anything written to the file by the non-COBOL program is still lost in
this
>case, because the file goes away the moment the non-COBOL program closes

it.

I got some additional information about Unix file management...when Unix
receives a file delete request, it prevents any new access to the file,
and waits until all current processes accessing the file are complete,
then deletes it.  So it looks like I'll have to go another route.  (Oh
for the good old days of IBM MVS JCL ---> DISP=(OLD,DELETE,KEEP))....



Wed, 29 Jul 1998 03:00:00 GMT  
 MF Cobol File Locks,ATomic File Close/Delt

Quote:

> I got some additional information about Unix file management...when Unix
> receives a file delete request, it prevents any new access to the file,
> and waits until all current processes accessing the file are complete,
> then deletes it.

I think that's what I was trying to say. The way Unix "prevents any new
access" is to remove the directory entry for the file - therefore noone can
reference the file any more. It is still possible for another process to create
a new file with the same name while the old file is still open in at least one
other process.

FYI, this is often used when temporary work files are required - create a
work file and immediately delete it. Now you have an open fd to a file that
(a) can't be seen in directory listings or opened by any other process and (b)
automagically goes away when you close it/terminate the process.

Kev.
--


These views are strictly my own.
I doubt very much that anyone else would want them.



Fri, 31 Jul 1998 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. MF Cobol File-locks on NFS

2. MS/MF COBOL : Load Failure (170) on file \COBOL\BINR\ADIS

3. MF file-locking

4. MF Solaris: how to clear a file lock?

5. MF Cobol ".FDD" Files

6. Data file creating/editing using MF Personal COBOL

7. Converting Files with COMP-6 to MF COBOL

8. Writing and reading device files in MF Cobol.

9. MF Cobol Data and Index file structure?

10. Question on MF - Cobol 3.1 Index files

11. MF Cobol 4.0 EXE file sizes

12. MF Cobol 4.0 EXE file size

 

 
Powered by phpBB® Forum Software