× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Scott,

Yes I certainly did try that option. It did not at all act like ALCOBJ does to truly protect the file from another process getting to it. I was writing a licensing system so it was rather crucial that we be able to create objects that could not be 'messed with' in any way shape or form by another process.

Thanks,

Genyphyr Novak




----- Original Message ----
From: "c400-l-request@xxxxxxxxxxxx" <c400-l-request@xxxxxxxxxxxx>
To: c400-l@xxxxxxxxxxxx
Sent: Tuesday, February 3, 2009 7:00:02 PM
Subject: C400-L Digest, Vol 7, Issue 4

Send C400-L mailing list submissions to
c400-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/c400-l
or, via email, send a message with subject or body 'help' to
c400-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
c400-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of C400-L digest..."


Today's Topics:

1. Re: C/C++ File Locking (Genyphyr Novak)
2. Re: C/C++ File Locking (Scott Klement)


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

message: 1
date: Mon, 2 Feb 2009 14:56:46 -0800 (PST)
from: Genyphyr Novak <genyphyr1@xxxxxxxxx>
subject: Re: [C400-L] C/C++ File Locking

Hi,

As far as the IFS use goes, I opened a call log with IBM support on this at end of last year. I could not find a way to exclusively lock an IFS file to prevent OTHER processes from accessing it or destroying it. I believe if everyone is 'playing nice' and all using the same way to access the file and checking results of open() it is different - but if you want it locked exclusively because you are not sure how someone else might access it, that seems to not work. I was creating a file and tried to open it with some locking in the open( ) ... I tested this ... but I could even delete it from another job while mine first one was 'locking' it and I wanted to prevent exactly this sort of thing from happening. The support center was unable to give me an API or function call to truly lock it from other processes in the same way that ALCOBJ protects 'normal' native iSeries non-IFS objects. I ended up changing to use non-IFS objects on the system. I guess it
depends on the purpose of your code.

Thanks,

Genyphyr Novak




On Mon, Feb 2, 2009 at 11:32 AM, Elvis Budimlic
<ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
If IFS stream file, check out open() function's O_SHARE_NONE flag.
If native (library) file system, check out ALCOBJ command.

Hth, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: [C400-L] C/C++ File Locking

I am new to the iSeries but not C/C++. I am porting a program that runs
on multiple platforms. This program may have several instances running
concurrently but each program shares on data file. My issue is what
function do I use to lock the file so that other apps can not read/write
this file while it is being locked by another process. On windows I
used CreateFile() and on UNIX I used Flock(). I am looking for
something similar or that will at least produce the same results. I
have attempted modifying the share permissions in the CL but this locks
the file for the entire run of the program and not only when this file
is open.


Thanks,

Edgar Gillock
ed_gillock@xxxxxx





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

message: 2
date: Mon, 02 Feb 2009 17:25:51 -0600
from: Scott Klement <c400-l@xxxxxxxxxxxxxxxx>
subject: Re: [C400-L] C/C++ File Locking

Hello,

As far as the IFS use goes, I opened a call log with IBM support on
this at end of last year. I could not find a way to exclusively lock
an IFS file to prevent OTHER processes from accessing it or
destroying it.

That's what O_SHARE_NONE does. Have you tried it? It works for me...


I believe if everyone is 'playing nice' and all using the same way to
access the file and checking results of open() it is different - but
if you want it locked exclusively because you are not sure how
someone else might access it, that seems to not work.

Assuming that you're using a file system that supports it, O_SHARE_NONE
does exactly that. No other process can open() the file when you have
it opened with O_SHARE_NONE. Anyone trying to open it will fail, and
errno will be EBUSY


creating a file and tried to open it with some locking in the open( )
... I tested this ... but I could even delete it from another job
while mine first one was 'locking' it and I wanted to prevent exactly
this sort of thing from happening.

O_SHARE_NONE only blocks others from opening the file. I don't think it
blocks others from unlinking it. I don't know why this matters, though?
What difference does it make if they unlink it while you have it open,
or whether they wait until the instant you close it? Either way, it's
deleted the second you close it.

Again, it's going to depend on the file system. But in the file systems
that we typically think of as "IFS file systems" (such as the root and
/QOpenSys ones) files aren't actually deleted when you unlink them.

You understand that, right? If a user runs the RMVLNK or DEL or ERASE
CL command against an object in / or /QopenSys, it will remove the
filename from the directory, but it won't actually delete the file's
data unless no jobs have the file open. (Plus, there can be no other
hard-links to the file, but that probably goes without saying.)

So if you have a file open, it can be unlinked, but you can continue to
use it without problems... the file isn't actually deleted (i.e. the
data sectors it occupies aren't marked as "unused") until you close it.


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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.