timl@maxwell.Concordia.CA ( TIM LAPIN ) (02/26/90)
An interesting thing happened to me on the way through my morning check: I found that after convert news_root:news.items news_root:items command, the command convert/recliam news_root:news.items **failed** due to: "File currently locked by another user". Note: NO other news related job was being run at the time (with the possible exception of someone using the package). Is there an inherent time delay in the first command that causes the second to get mixed up or will another user calling news cause the file to be locked? I need to find a way to insure that the file is free to be manipulated at that time. Would a 'set protection' command do the job? -- Tim Lapin Concordia University Tel: (514) 848-7639 INTERNET: timl@maxwell.concordia.ca BITNET: timl@vax2.concordia.ca
glassmann@ccavax.camb.com (02/27/90)
In article <1872@clyde.concordia.ca>, timl@maxwell.Concordia.CA ( TIM LAPIN ) writes: > > I found that after convert news_root:news.items news_root:items command, > the command convert/recliam news_root:news.items **failed** due to: > "File currently locked by another user". According to various RMS experts I've spoken to, CONVERT/RECLAIM is a waste of time, especially right after doing a CONVERT. CONVERT/RECLAIM makes sections of the file (buckets) available if all of the records in the buckets have been deleted. This is a pretty rare situation in general, and is impossible right after doing a CONVERT, which does not copy deleted records. > > Note: NO other news related job was being run at the time (with the > possible exception of someone using the package). Is there an inherent > time delay in the first command that causes the second to get mixed up > or will another user calling news cause the file to be locked? CONVERT needs exclusive access to the file. That means that any user running NEWS will cause it to fail. It would be nice if there was a way to kick users out of NEWS when you're ready to run CONVERT, and keep them out until you're done. -- Lenny Glassmann lenny@ccavax.camb.com ...uunet!ccavax!lenny
sloane@kuhub.cc.ukans.edu (Bob Sloane) (03/02/90)
In article <18477.25ea4d0e@ccavax.camb.com>, glassmann@ccavax.camb.com writes: > CONVERT needs exclusive access to the file. That means that any user running > NEWS will cause it to fail. It would be nice if there was a way to kick users > out of NEWS when you're ready to run CONVERT, and keep them out until you're > done. Funny you should ask. :-) Just this week I needed to move all of the NEWS file do another device, so I needed some way to lock people out of NEWS until the move was done. First, I modified NNTP_ACCESS.NEWS to contain just the line: no.nntp.access read post * Then I wrote a short FORTRAN program: STOP "News is unavailable for file reorgisation." END I compiled and linked the FORTRAN program and replaced the NEWS executable with this new program. Then I removed NEWS.EXE in INSTALL so that new users would get the message from the FORTRAN program. I killed off the currently running NEWSSKIM batch job. Since this was happening about midnight, I didn't need to kill off any NEWS users, but I would probably have used some sort of program to use $FORCEX to kill off NEWS as needed. After this, SHOW DEVICE/FILE on the old device where NEWS was kept showed that none of the files were busy. Then I started the BACKUP to copy NEWS to the new device. About 15 hours later, the copy finished, and I fixed everything up. Anyway, it is possible to kill off NEWS and keep users out using these methods. NNTP_ACCESS.NEWS will keep any nntp clients from accessing the server, and replacing NEWS.EXE will keep any new users out. For users currently using NEWS, you can stop their process, or (more friendly) you can $FORCEX them out of NEWS. While I had the files available, I used the following procedure to compress NEWS.ITEMS and NEWS.GROUPS. -- USmail: Bob Sloane, University of Kansas Computer Center, Lawrence, KS, 66045 E-mail: sloane@kuhub.cc.ukans.edu, sloane@ukanvax.bitnet, AT&T: (913)864-0444 $ ! N E W S P A C K . C O M $ ! $ ! Author: $ ! G Huston $ ! Computer Services Centre $ ! Australian National University $ ! Modified by: $ ! Bob Sloane University of Kansas Computing Services $ ! added code to optimize indexed files $ ! $ ! Version $ ! V5.3 05-May-1989 RRS $ ! V5.2 26-Apr-1988 GIH $ ! $ ! $ !********************************************************************** $ ! Start code $ ! $ on error then goto abort $ oldprv = f$setprv("SYSPRV") $ if .not. f$privilege("SYSPRV") then exit $ analyze/rms/fdl/output=news_root:newsgroups.fdl news_root:news.groups $ edit/fdl/analyze=news_root:newsgroups.fdl/nointer news_root:newsgroups.fdl $ convert/fdl=news_root:newsgroups - news_root:news.groups news_root:news.groups $ purge news_root:news.groups $ purge news_root:newsgroups.fdl $ analyze/rms/fdl/output=news_root:newsitems.fdl news_root:news.items $ edit/fdl/analyze=news_root:newsitems.fdl/nointer news_root:newsitems.fdl $ convert/fdl=news_root:newsitems.fdl - news_root:news.items news_root:news.items $ purge news_root:news.items $ purge news_root:newsitems.fdl $ abort: $ exit
NEWSMGR@pavo.concordia.ca (Tim Lapin Tel: (514) 848-7639 News Manager) (03/03/90)
In article <1872@clyde.concordia.ca>, timl@maxwell.Concordia.CA ( TIM LAPIN ) writes: > An interesting thing happened to me on the way through my morning check: > > I found that after convert news_root:news.items news_root:items command, > the command convert/recliam news_root:news.items **failed** due to: > "File currently locked by another user". > > I need to find a way to insure that the file is free to be manipulated at > that time. Would a 'set protection' command do the job? > -- > Tim Lapin Concordia University Tel: (514) 848-7639 > INTERNET: timl@maxwell.concordia.ca BITNET: timl@vax2.concordia.ca Hi once again, Well, after posting the above epistle, I gave the matter some more thought and short of kicking people off the system between certain times if they are running NEWS, I came up with two alternatives: Firstly, thanks to those who responded. 1) Set ACL lists for news.items to be limited to a minimum during the database management routines. 2) Re-define the 'news.exe' hook to a '.com' file which will decide on running news based on access priveledge and time of day. Naturally, both these methods share the weakness that if someone is ALREADY on NEWS before the changes come into effect, then they will neatly bypass the controls. However, one can set the changes to occur well before the invokation of the database routines and can set them back only after the routines have finished. In this way one reduces the chance of having someone on at the crucial time. If anyone else has a better idea I'd like to hear it. If anyone wants my workarounds just ask. If enough ask, I'll post the relevant files. -- Tim Lapin Concordia University Tel: (514) 848-7639 INTERNET: timl@maxwell.concordia.ca BITNET: timl@vax2.concordia.ca NEWSMGR: newsmgr@pavo.concordia.ca | ANU NEWS 5.8A VMS 5.1 VAX C 3.0