RE : RE : Detecting directory changes.
Doing whatever F11X$POSIX_FASTRDSEQNOS does. This is one of two things - it either enqueues a lock and dequeues the lock (...) , or it directly accesses the memory structures used by the lock manager The routine actually enqueues/dequeues a lock, and does not access directly the lock manager data structures. That's true is not so FAST, but I assume it does this because it does not want too be too much dependant of the internal data structures, which are regularly changing when VMS version changes. I tend to prefer notification via AST over polling. It is more efficient and should be faster I do too, but may be not in this case, because 1. doing this may interfer with internal VMS behaviour, and slow down the entire system (imagine you have a big lot of SMBD processes), 2. you may end with a huge number of locks (one per directory/per SMBD process) 3. using blocking ASTs in kernel mode can be highly dangerous, because image exit does NOT dequeue those locks, so you must be absolutely sure that there is no kernel blocking AST left when you exit, unless you'll crash when trying to execute a blocking AST routine that is no more in memory. (about rewriting the F11X$ routine in C) Since this could work on a VAX, but the routine doesn't exist there, then it might be useful if you want it to work equally well on a VAX. That's true, and would make it a little less undocumented/unsupported, because it would only depend on the resource names used by the XQP, and not on the actual presence of the F11X$ routine. I'll do it as soon as I have a little time. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : RE : Detecting directory changes.
Doing whatever F11X$POSIX_FASTRDSEQNOS does. This is one of two things - it either enqueues a lock and dequeues the lock (...) , or it directly accesses the memory structures used by the lock manager The routine actually enqueues/dequeues a lock, and does not access directly the lock manager data structures. That's true is not so FAST, but I assume it does this because it does not want too be too much dependant of the internal data structures, which are regularly changing when VMS version changes. Interesting. In that case, it is probably not actually any faster than doing it yourself. I tend to prefer notification via AST over polling. It is more efficient and should be faster I do too, but may be not in this case, because 1. doing this may interfer with internal VMS behaviour, and slow down the entire system (imagine you have a big lot of SMBD processes), I can't immagine that this would be much of a problem. You would have a few more locks in existance at any time is all. The tradeoff would be a little more memory for the lock manager and possibly slightly longer lists in the hash nodes that take a little more time to check for the lock manager, when it hits the slightly more frequent nodes with more than one entry. 2. you may end with a huge number of locks (one per directory/per SMBD process) How many different directories does you code maintain a cache for at a time for one process? It seems to me that it should maintain only a few - the most recently accessed directory and some number of previous directories, where some number could be a fixed value, controllable via the SAMBA.CONF file or a logical name, or might depend on how much memory each is using (i.e. you could limit it by memory use instead of by a specific number of directories). As I recall, Windows looks into each subdirectory when a directory is first accessed just looking for desktop.ini files, I think - I don't recall it wanting a full directory listing of each. Are individual files cached? Are the directories that a file is in cached when a specific file is looked for, or only for full directory listings? (Yeah, I know - I could look at the source, which would answer all of these questions.) I don't think the number of locks is likely to be a problem. Even on a small and fairly lightly used system there are usually thousands of locks. With 1000 SMBD processes each caching up to a maximum of 100 directories it might be a problem (which should be solved, mostly, from a simple autogen to adjust the relevant parameters to account for the additional lock usage). With 10 SMBD processes each caching up to 10 directories it wouldn't be a problem. 3. using blocking ASTs in kernel mode can be highly dangerous, because image exit does NOT dequeue those locks, so you must be absolutely sure that there is no kernel blocking AST left when you exit, unless you'll crash when trying to execute a blocking AST routine that is no more in memory. This is a concern. The code that does this should be absolutely clean and there should be an exit handler that knows how to clean the process' locks up. This is probably the strongest argument against doing it. Whether or not it is strong enough to stop you from doing it is another question. (about rewriting the F11X$ routine in C) Since this could work on a VAX, but the routine doesn't exist there, then it might be useful if you want it to work equally well on a VAX. That's true, and would make it a little less undocumented/unsupported, because it would only depend on the resource names used by the XQP, and not on the actual presence of the F11X$ routine. I'll do it as soon as I have a little time. Just be carefull. --- Carl Perkins Computer Systems Manager Geochemical Environmental Research Group Texas AM University [EMAIL PROTECTED] PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Detecting directory changes
To answer the question about Pathworks using the internal routine. I do not know. I do not have access to the Pathworks source as I am not on that team. I work closer to the actual hardware. Since Pathworks and Advanced server support both VAX and ALPHA, there is a good chance that it does not. Older Pathworks versions did not use a routine like that because part of the Microsoft Windows SMB specification allows programs to request a notification when a directory changes, and while I am not familiar with the latest release of Advanced Server, the earlier ones did not have it. This causes some Microsoft Windows programs not to work with Pathworks / Advanced Server. And I suspect that if just resurecting a POSIX routine was all that was needed to implement it, they would have done in on VAX also. SAMBA also has this same deficiency, unless they have found a way around it in the 3.x branch. The file system is scheduled for a major overhaul. I can not give details, but any program that makes any assumptions about undocumented internal structures such as names of locks may break. You do want to be able to support disks that are larger than a Terabyte, or files that are that big don't you? Parts of the retired POSIX product were used as a basis of the DII COE effort, and the DII COE routines that are used for UNIX portability are being merged into the base OpenVMS product. As this is happening, the POSIX modules may be removed or stop working. Or they may continue to be used. This is being decided by the teams involved. We just recently went through an issue on comp.os.vms with the CSWING freeware application that was and still is making invalid assumptions about how the file system operates or will operate in the future. Some early programmer apparently got this mis-information from reading the source listings, or from trial and error. Now I have put in requests for features to the file system, like a 64 bit ino_t type, storing at file close the apparent UNIX size of a record oriented file for stat to return, storing the UTC time in addition to local time so that stat will run faster. I have also requested support for alternate filenames, to help support ODS-2/ODS-5/ODS-? and 8.3 file lookups for applications like Pathworks Advanced Server and SAMBA. But when it comes time to look at funding and time allocation. Customer requested enhancements get priority over internal requests when all other things are equal. The use of the internal POSIX routine may work in the short term, but it should not be considered a permanent solution. -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Detecting directory changes
In message [EMAIL PROTECTED], John E. Malmberg [EMAIL PROTECTED] writes: The file system is scheduled for a major overhaul. I can not give details, but any program that makes any assumptions about undocumented internal structures such as names of locks may break. Yes, such a program may break in the future when someone eventually tries to run it under some future version of VMS. In the mean time, there are problems to be solved now where using undisclosed (they hopefully were documented somewhere by the developers) interfaces is the only practical solution. Such a program should isolate and abstract the fragile pieces as much possible. You do want to be able to support disks that are larger than a Terabyte, or files that are that big don't you? Parts of the retired POSIX product were used as a basis of the DII COE effort, and the DII COE routines that are used for UNIX portability are being merged into the base OpenVMS product. As this is happening, the POSIX modules may be removed or stop working. Or they may continue to be used. This is being decided by the teams involved. We just recently went through an issue on comp.os.vms with the CSWING freeware application that was and still is making invalid assumptions about how the file system operates or will operate in the future. Some early programmer apparently got this mis-information from reading the source listings, or from trial and error. Now I have put in requests for features to the file system, like a 64 bit ino_t type, storing at file close the apparent UNIX size of a record oriented file for stat to return, storing the UTC time in addition to local time so that stat will run faster. I have also requested support for alternate filenames, to help support ODS-2/ODS-5/ODS-? and 8.3 file lookups for applications like Pathworks Advanced Server and SAMBA. But when it comes time to look at funding and time allocation. Customer requested enhancements get priority over internal requests when all other things are equal. The use of the internal POSIX routine may work in the short term, but it should not be considered a permanent solution. -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Detecting directory changes
[Please ignore my previous post, sent by accident before I finished it..] In message [EMAIL PROTECTED], John E. Malmberg [EMAIL PROTECTED] writes: The file system is scheduled for a major overhaul. I can not give details, but any program that makes any assumptions about undocumented internal structures such as names of locks may break. Yes, such a program may break in the future when someone eventually tries to run it under some future version of VMS. In the mean time, there are problems to be solved now where using undisclosed (they hopefully were documented somewhere by the developers) interfaces is the only practical solution. Such a program should isolate and abstract the fragile pieces as much possible. Now I have put in requests for features to the file system, like a 64 bit ino_t type, storing at file close the apparent UNIX size of a record oriented file for stat to return, storing the UTC time in addition to local time so that stat will run faster. I have also requested support for alternate filenames, to help support ODS-2/ODS-5/ODS-? and 8.3 file lookups for applications like Pathworks Advanced Server and SAMBA. Obviously, the first step is making a file header 8K instead of 512 bytes in size :-) For UTC times in the file headers, I think it would be more compatible with ODS-2/5 if you stored the timezone offsets to be applied to the existing local time timestamps. - David L. Jones | Phone:(614) 292-6929 Ohio State University| Internet: 140 W. 19th St. Rm. 231a | [EMAIL PROTECTED] Columbus, OH 43210 | [EMAIL PROTECTED] Disclaimer: I'm looking for marbles all day long. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Detecting directory changes.
Without knowing what is using the internal routine, I do not know if it will remain, will be removed, or if changes to RMS will leave it totally or partially non-functional. Actually, this internal routine uses a feature of the XQP, not of RMS, but it's a detail. It may work for now, but as it is an internal routine, it is unsupported, and may break with out notice, even from the installation of an ECO kit. Well, this is hardly what happened in the past, however. As Dave Jones pointed out, this internal routine is dated 1993 in the sources, and uses an XQP feature (using the VMS lock manager in a certain way) that seems to be present since the very beginning of the XQP itself (middle of the 80s, if I remember correctly), precisely for managing the validation of the directory XQP cache in a cluster environment. In my opinion, the probability of a sudden break out for this particular feature sounds low. Note that my old method of looking at the lock value block of the XQP volume lock used another XQP feature that is hardly more documented or supported... Caching directory and file (stat) information enhances Samba/VMS performances very much, that's a fact. May be that the price to pay is to take the risk of using some undocumented/unsupported VMS feature. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Detecting directory changes.
If another way of doing it is desired, perhaps the following could be considered. The general description of the method is to use the lock manager in a way that is compatible with how RMS uses it. What you'd do is to take out a lock in PR (protected read) mode on the RMS resource that represents the directory file. These resources have names that are built using a known pattern (4 character prefix of RMS$, 6 byte FID, 16 character devlockname). So after you read the directory data into your cache you enqueue a PR mode lock to the resource and close the file, at which time this lock should be granted (possible refinement - the lock could initially be requested in NL (null) mode with LCK$M_EXPEDITE specified, then a conversion to PR mode enqueued; this may have some advantages). You specify a blocking AST with the lock. The PR mode lock will not block any read-only access to the file, as they should PR (or maybe CR) mode locks. Any open allowing writes to the file should trigger your blocking AST as these will involve a PW (protected write) or EX (exclusive) mode lock which will be blocked by this lock. In the blocking AST you enqueue a conversion of lock to NL mode and set a flag for the cache indicating that it is invald. The next time the cache is needed the program checks the validity flag and finds that it is not valid so the cache is refreshed from disk and the lock converted back to PR mode. (Note that the resources used by the RMS locks all have a minimum of executive mode access and are all system locks. This makes enqueueing them just a bit more complicated.) The advantage is that you wouldn't need to poll the sequence number via F11X$POSIX_FASTRDSEQNOS every time you want to read from the cache, possibly giving some slight (possibly trivial) increase in performance. (Instead of polling for the value, you get notified via the blocking AST.) The disadvantage is, I think, that you had best be very carefull when messing around with RMS or you could have an adverse effect on the system as a whole. It is also possible that you will be invalidating the cache more often than is really necessary since other accesses to the directory file for reading it may not always be done in a read-only type of way (defaults for opening files in C, for example, is no sharing which presumably causes an EX mode lock to be used which would trigger the blocking AST and invalidate the cache). You should note that the Frontport library already does this sort of thing with RMS locks, thus Samba V2.0.6 is also already doing this sort of thing (and it works OK). Frontport's useage of this is, as I recall, somewhat simpler - I think it only enqueues locks to RMS resources to find out who is blocking you, and those test locks are immediately dequeued. This is part of its increase to fcntl() functionality regarding locks. It's a possibility to consider, anyway. --- Carl PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE: Detecting directory changes
How does Pathworks do this? Since HP/Compaq will probably maintain Pathworks as a layered product, the Pathworks method will continue to be supported internally (unless there is a major change in Pathworks itself). Mike Ober. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Detecting directory changes.
That's actually a way to consider, but I am not too much confident, because the problem is to know when directory contents are changed. You are talking here of RMS locks, and changes in the directories are not made by RMS, but by the XQP. I mean that there is no calls to RMS $OPEN service when changing the directory contents, so there is probably no RMS$xxx resource either to be AST blocked for that purpose. I keep forgeting that even though the $RENAME service is part of RMS, it won't take out RMS locks (at least, I'm pretty sure it doesn't). OK, I have done some research. It turns out that the XQP uses serialization locks with names with a prefix of F11B$s followed by 4 bytes of binary data that are 2 bytes of FID file number and 2 bytes of RVN/NMX data (the only example I have found doesn't use the NMX data, but it is from 1994), essentially it is the FID with the middle two bytes of file sequence number removed. This is a child lock on a volume allocation lock - a lock taken out on a resource with a prefix of F11B$v followed by 12 bytes of volume name (space filled). So instead of blocking ASTs via a (probably never used) RMS resource, you could do it on the F11B$s serialization resource. According to the only mention of this on the Ask the Wizard pages, this is used by various software, including 3rd party softwre, for doing this sort of thing. I found an old (1994) program using this (it doesn't use the NMX byte to get the full range of file numbers, instead using only the RVN byte, so it will not always work as advertised on a more modern system - it will tend to operate on the wrong file if the desired file uses the NMX bits to extend its file number past the 16 bit limit). This program was for doing something a lot like SAMBA need - it was intended to replace the scanning of the contents of a directory to see if anything had changed with a way of being notified when it changed. See: http://www.eight-cubed.com/watchdir.zip which has a parent document of: http://www.eight-cubed.com/downloads.html The lock's resoure name's format is also mentioned in a few other places such as http:// www.geocities.com/keithparris/decus_presentations/ s2002_dist_lock_mgr_perf.ppt which includes this text in an example: 'F11B$vAPP2' 202020202020202032505041762442313146 Files-11 Volume Allocation lock for volume APP2 'F11B$sH...' 0148732442313146 Files-11 File Serialization lock for file [328,*,0] on volume APP2 The a lock on the former resouce would be the parent of the lock on the latter resource. (The parent lock evidently just needs to be in NL mode.) Figuring out some of this would be easier for someone with the VMS File Systems Internals book. Unfortunately that has not been updated since 1990 and would therefore be missing some information (like the NMX bits in the FID, probably). --- Carl PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Detecting directory changes.
Gents, From your discussion on this topic, it sounds like there are 2 things that can be most useful at this point: 1) Use the unsupported F11X$POSIX_FASTRDSEQNOS API in the coding of Samba on VMS for now. 2) Someone with an OpenVMS support contract put in a request for a supported API to provide the desired alert on directory changes. John has indicated that this is a prime time for such a suggestion. --Bryan From: SMTP%[EMAIL PROTECTED] COLLOT Jean-Yves 13-MAR-2003 12:26:56.76 To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subj: RE : Detecting directory changes. So instead of blocking ASTs via a (probably never used) RMS resource, you could do it on the F11B$s serialization resource That's exactly that resource that F11X$POSIX_FASTRDSEQNOS uses. The question is : is it really useful to re-write in C a routine that is already available in the system, even if it's an undocumented one ? PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Detecting directory changes.
So instead of blocking ASTs via a (probably never used) RMS resource, you could do it on the F11B$s serialization resource That's exactly that resource that F11X$POSIX_FASTRDSEQNOS uses. The question is : is it really useful to re-write in C a routine that is already available in the system, even if it's an undocumented one ? Since this could work on a VAX, but the routine doesn't exist there, then it might be useful if you want it to work equally well on a VAX. It also switches polling the lock value block using that routine every time you want to read from the cache to something that is not polling that resource. It is going from: Doing whatever F11X$POSIX_FASTRDSEQNOS does. This is one of two things - it either enqueues a lock and dequeues the lock in a lock mode such that it gets a copy of the current lock value block, or it directly accesses the memory structures used by the lock manager to locate and read the lock value block. Since it is called FASTRDSEQNOS and direct access would probably be faster, I assume that this is what it does (probably in kernel mode). to: Checking a local variable. This variable is set by the blocking AST to indicate that the cache is invalid. This uses blocking ASTs and pays no attention to the sequence number in the lock value block. I tend to prefer notification via AST over polling. It is more efficient and should be faster: walking the lock manager's data structures (in kernel mode, I expect) to get the data in the lock value block and comparing it to the saved value vs. checking a local variable to see if it has been changed from TRUE to FALSE (or whatever) by an AST. You do still have to worry about version compatability. I would guess that this should at least work on any version of VMS that uses the XQP, but maybe not. A concern is how the other, system controlled, locks behave. If they have possible modes that indicate read or write access, then this should work well (e.g. they could use PR mode locks when reading and PW or EX mode locks when writing). If they don't (e.g. they just get set to EX mode even for a read access), then it won't work so well - it would probably require switching to using the lock value block. If that is the case, then it is not so usefull except maybe just using it to get the contents of the lock value block on a VAX (assuming that it sets this, but just not provide the F11X$POSIX_FASTRDSEQNOS routine to read it), which just requries taking out the lock and converting it back and forth between modes to get the data stored in the lock value block every time you need it. If the VAX flavor of VMS doesn't set this value block, then it wouldn't be useful on the VAX for that and would probably be slower than F11X$POSIX_FASTRDSEQNOS on the Alpha (and thus not useful there either). So the usefullness depends on the behavior of VMS's use of these locks and also whether or not the VAX version uses the lock value block to store sequence number information. --- Carl PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : RE : Detecting directory changes.
(about F11X$POSIX_FASTRDSEQNOS) : I am trying to find out how stable that internal routine is. I am trying to see if a supported interface can be developed to either give notification on change, or a way to detect changes in the directory. As did Dave Jones (thanks again to him), I looked into the source of this internal VMS routine, and it looks OK to me. As I said in a previous message, it is not supported on VAX (VMS 7.1, which is the only version I have access) : it returns a SYSYEM-E-UNSUPPORTED status. I used Dave's example for testing and I am very satisfied with it, so I now use it very successfully for directory cache validity checking in Samba-Vms (for the VAX version, I keep the 30 seconds validity time-out). PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Detecting directory changes.
'Dave Jones' [EMAIL PROTECTED], wrote: I just joined this list, I've been playing with samba to the past few weeks. Welcome. For those that may not be familiar with Dave Jones, He is the maintainer and I think the main author of the OSU Threading Web server. In the archives there was discussion of the difficulty of reliably invalidating the stat cache when directory updates don't change it's allocation. While poking around the VMS source listings for a better solution, I came across a system routine that looks made to order for this problem. If you open the directory file, the function F11X$POSIX_FASTRDSEQNOS can be used to quickly fetch the header and data sequence numbers stored in the access lock's value block. I am trying to find out how stable that internal routine is. I am trying to see if a supported interface can be developed to either give notification on change, or a way to detect changes in the directory. As I do not work with either the C RTL or the filesystem area, it may take some time before I get a chance to run this down. -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Detecting directory changes.
That's just great. Does not seem to work on VAX platforms, however.
I'll include that in the new release.
Thanks a lot
JY Collot
-Message d'origine-
De : Dave Jones [mailto:[EMAIL PROTECTED]
Envoyé : lundi 3 mars 2003 07:57
À : [EMAIL PROTECTED]
Objet : Detecting directory changes.
I just joined this list, I've been playing with samba to the past few weeks.
In the archives there was discussion of the difficulty of reliably
invalidating the stat cache when directory updates don't change it's
allocation. While poking around the VMS source listings for a better
solution, I came across a system routine that looks made to order for this
problem. If you open the directory file, the function
F11X$POSIX_FASTRDSEQNOS
can be used to quickly fetch the header and data sequence numbers stored
in the access lock's value block. Any change to the contents of the
directory increments the data sequence, even if the header sequence
(file allocation, protection, etc) remains unchanged.
Below is a program that demonstrates the function. I've tested the program
under Alpha VMS 7.2-1 and 7.3-1, the routine appears to have been introduced
circa 1993.
--
/*
* Test for existence of f11x$posix_fastreadseqnos. This function returns
* the sequence numbers held in the serialization lock for an open
* directory, allowing you to quickly test for modification:
*
*hdrseqIncremented when header data changed (e.g. file
* grows or shrinks).
*
*dataseq Incremented when file data changes (e.g. file renamed).
*
* Privileges:
*Caller must have sysprv and cmkrnl privilege.
*
* Linking:
*Link the the /sysexe qualifier (sys$system:sys.stb on vax) to resolve
*the F11X$POSIX_FASTRDSEQNOS reference.
*
* Author: David Jones
* Date:3-MAR-2003
*
*/
#include stdio.h
#include stdlib.h
#include string.h
#include stat.h
#include fibdef.h
#include ssdef.h
#include starlet.h
#include descrip.h
#include iodef.h
struct seqno_st {
long hdrseq;/* header data sequnece */
long dataseq; /* file data sequence */
};
/*
* This function is part of the operating system image, link using
* the /sysexe[/selective_search] qualifer.
*/
int F11X$POSIX_FASTRDSEQNOS ( short chan, struct seqno_st *seqno );
int main (int argc, char **argv)
{
int status;
struct seqno_st seqno;
short chan;
struct stat info;
static $DESCRIPTOR(devnam_dx,);
struct { int length; struct fibdef *fib; } fib_desc;
struct fibdef fib;
struct { unsigned short status, count; long devdepend; } iosb;
char line[80];
/*
* Mislinking can cause system crash! do sanity check.
*/
if ( !F11X$POSIX_FASTRDSEQNOS ) {
printf ( Program improperly built, must link /sysexe\n );
return SS$_ABORT;
}
/*
* Stat the directory file named on the command line in order to
* get device name and file id.
*/
if ( argc 2 ) {
printf ( usage: fast_seqno filename\n );
return 1;
}
status = stat ( argv[1], info );
if ( status != 0 ) {
printf ( Failed to stat file '%s'\n, argv[1] );
return 1;
}
/*
* Assign channel and access file with speical fib$m_seqno that forces
* XQP to keep an access lock on the file.
*/
devnam_dx.dsc$a_pointer = info.st_dev;
devnam_dx.dsc$w_length = strlen ( devnam_dx.dsc$a_pointer );
status = SYS$ASSIGN ( devnam_dx, chan, 0, 0, 0 );
if ( (status1) == 0 ) {
printf ( Assign to '%s' failed: %d\n, info.st_dev, status );
return status;
}
fib.fib$l_acctl = FIB$M_SEQNO | FIB$M_NORECORD | FIB$M_NOLOCK;
fib.fib$w_fid[0] = info.st_ino[0];
fib.fib$w_fid[1] = info.st_ino[1];
fib.fib$w_fid[2] = info.st_ino[2];
fib.fib$w_did[0] = fib.fib$w_did[1] = fib.fib$w_did[2] = 0;
fib_desc.length = 10; /* minimal FIB */
fib_desc.fib = fib;
status = SYS$QIOW ( 0, chan, IO$_ACCESS|IO$M_ACCESS, iosb,
0, 0,
fib_desc, 0, 0, 0, 0, 0 );
if ( (status1) == 1 ) status = iosb.status;
if ( (status1) == 0 ) {
printf ( Error in access, status: %d, iosb: %d %d %x\n, status,
iosb.status, iosb.count, iosb.devdepend );
return status;
}
/*
* Now enter loop where we fetch sequence numbers every time returnis
* it.
*/
printf ( Each time you hit return, the current sequence numbers
will\n);
printf ( fetched and displayed. hit ctrl-Z to exit\n );
seqno.hdrseq = 0;
seqno.dataseq = 0;
while ( fgets ( line, 79, stdin ) ) {
/*
* XQP function must be called from kernel mode (probably
* need pages locked as well).
*/
struct {
long count;
long channel;
struct seqno_st *seqno;
} arglist;
