🚀 go-pugleaf

Brian {Hamilton Kelly} (tex@rmcs.cranfield.ac.uk) wrote:
> SNews *always* uses SNEWS.RC.  Moreover, since her "version" of SNEWS.RC
> would also be used by her if she was reading news on *my* machine, certain
> paths therein are not correct when referenced remotely (e.g. the directory
> for queueing outgoing "posts" to mail2news), although this can be fixed with
> a separate version of "her" SNEWS.RC file.

You could also get round it by using subst (IIRC). So on the machine holding
the news, say on C: you'd have a

SUBST N: C:

all .RC entries would refer to N: rather than C:

on the remote machine either use SUBST again or just mount the "server" as N:

Of course having seperate user specific .RC files and some of the other
changes you've mentioned are more flexible...

-- 
<URL:http://www.pierrot.co.uk/>                                     Team AMIGA
A raccoon tangled with a 23,000 volt line today. The results
blacked out 1400 homes and, of course, one raccoon.  - Steel City News

How about trying cppnews instead. It has proven multi-user 
capabilities, and is SNEWS compatible.

See ftp://ftp.demon.co.uk/pub/trumphurst/cppnews

-- 
Nikki Locke, Trumphurst Ltd.      PC & Unix consultancy & programming
nikki@trmphrst.demon.co.uk            http://www.trmphrst.demon.co.uk

Sorry about long delay following up.

On 9 Sep, in article
     <1997Sep9.162238.977@rmcs.cranfield.ac.uk>
     tex@rmcs.cranfield.ac.uk "Brian {Hamilton Kelly}" wrote:

BK> I've recently LANned together my SO's computer and mine.  She runs WfWG3.11,
BK> whilst I have OS/2 Warp 4 on my machine.  At present,
..
BK> she'd like to be able to read netnews at the same
BK> time as myself (I collect news using KA9Q/2, but otherwise use the DOS
BK> components of DIS, rather than the OS/2 specific ports of SNews, Unbatch,
BK> etc).  Of course, this raises a few snags, and I'm proposing to make some
BK> changes to SNews (and any other programs that might suffer "collateral
BK> damage") to accommodate this usage.
BK> 
BK> 1) At present, SNEWS.EXE uses the SNEWS environment variable to locate the
BK> directory which contains ACTIVE, SUSPEND, SNEWS.RC and [user].NRC.  By
BK> setting this environment variable on her computer to use a network "drive",
BK> it's possible to run SNews, read articles, update the .NRC file, etc. 
BK> However, I cannot simultaneously use SNews on the Warp machine, because
BK> SNews *always* uses SNEWS.RC.  Moreover, since her "version" of SNEWS.RC
BK> would also be used by her if she was reading news on *my* machine, certain
BK> paths therein are not correct when referenced remotely (e.g. the directory
BK> for queueing outgoing "posts" to mail2news), although this can be fixed with
BK> a separate version of "her" SNEWS.RC file.
BK> 
BK> I propose to make SNEWS.EXE take an optional command-line argument, being
BK> the "username": if provided, SNEWS.EXE will pass this parameter when it
BK> calls load_stuff(), causing the latter to read the specific .RC file for
BK> her, which would be configured ONLY for use by remote access.  The *actual*
BK> username would be determined in the usual way from the content of this file
BK> (from the "userid" .RC field), which would mean that that USER's .NRC file
BK> would record the articles read by her, regardless of whether she did that
BK> locally on the Warp machine, or from her machine across the network.

Sounds reasonable to me, and backward compatible.  Might be best
to do it preceding the username with some option (e.g. -u) so as
to leave the door open for other options later (or perhaps Snews
already accepts options; I don't recall).

BK> 2) Having read in the [SNEWS].RC file with load_stuff, SNews locks the
BK> HISTORY.SNW file and that particular user's .NRC file.  Now I have no
BK> worries about the latter, which is obviously a necessary precaution; but the
BK> locking of HISTORY.SNW, achieved by creating a HISTORY.LCK file, would
BK> prevent parallel operation, despite the newsbase (and history) being
BK> accessed purely in a read-only fashion.  I presume that HISTORY.LCK is
BK> created to prevent any cock-up through trying simultaneously to run EXPIRE,
BK> UNBATCH, etc., and this precaution is also necessary.  Therefore I propose
BK> to read back the content of the HISTORY.LCK file to see if it was created by
BK> "SNews" (luckily, it already writes the name of the relevant component into
BK> the lock file), and if so, to permit multiple readers.  I'm proposing to add
BK> an additional selflock() function to LOCKING.C which will permit this: only
BK> SNews would use this entry (since obviously one doesn't want two copies of
BK> EXPIRE or whatever running).

You haven't discussed unlocking.  I imagine you would need to add a
2nd field to the lock file, a count of lockers.  Last one out deletes
the file.  I assume your file server respects access rights so that
you can use something like _fsopen() to avoid simultaneous update
of the lock file?

You also need to consider shelling out of Snews.  I don't run multiple
users, but as a single user, I'm really REALLY grateful for that
lock file.  I have a nasty habit of shelling out of Snews, doing
whatever, taking 3 phone calls, making a coffee, then saying "Hey,
I'd better go read the news!" and typing "Snews" at the command
prompt.  Thank God the lock file prevents self-mutilation.

BK> 3) When KA9Q itself is running to collect new news, it too creates a
BK> HISTORY.LCK file.  However, this is actually to protect against multiple
BK> accesses to the NNTP HISTORY file, and not to HISTORY.SNW: the latter is
BK> only affected by UNBATCH, EXPIRE, etc.  There is no reason, so far as I can
BK> see, why one shouldn't be collecting a new batch of news from Demon's
BK> servers, whilst simultaneously reading the OLD contents of the local

I agree.

BK> newsbase.  Therefore I propose changing the name of the lock file for
BK> SNews's HISTORY.SNW file to be SNWSHIST.LCK --- this would obviously require
BK> alteration of all the support programs in the SNews suite to suit.

Either that or change K9aq and Unbatch's lock file name.  So many
different ka9q's around, probably less desirable.

But either such solution has serious repercussions, given that there
are existing users, and no matter how hard you try, stopping users
upgrading piecemeal is an impossible goal.

Perhaps looking for snewshist.lck AND history.lck and making some
conservative assumptions <waves hands vaguely>, even asking the
user for comfirmation if things look bad?

If that kind of scheme results in frequent irritating prompts for
the user, I'd suggest allowing them to be suppressed if a suitable
new param is added to the .rc file.  That way each user has to be
aware of the potential danger of not fully upgrading.

If you can solve all the above, and if there are other people
wanting this along with the mods I've done, I'd be open to
integrating the two.  If you want my sources, Brian, I'd be glad
to email them -- they're not secret, I've just been too lazy
to put them on a web page lately, since most people just seem
to want the binary.  I'd also upgrade mail2snz.

..
BK> One final problem, which I think lies more with my ignorance of NETBIOS
BK> and/or WfWG.  My girlfriend's computer has a local printer on its LPT1, and
BK> accesses my LaserJet over the network (and imagines it's on LPT2, which
BK> doesn't really exist).  If she presses "o" to print an article, it gets sent
BK> to the local PRN, which is LPT1, and prints on the (expensive) colour
BK> printer.  Even if LPT2 is set as the default printer (which works fine for
[rest of networked printers query: snip]

Well, I reckon Snews printing facilities are Completely Rotten And Putrid.
(Supply your own acronym).  I'd rip them out and use the space for
something useful, except I know there's always at least one user on
Alpha Centauri who would scream about it.

I can see the point in writing an article to a file, but why would
anyone want to print the whole text of an article, with no margins,
no headers, no page numbers, no choice of font, no ...  And even if
more space were wasted adding those features, who uses paper anyhow?
You can't "grep" paper.  You can't "sort" paper (at practical speed).
A whole filing cabinet full of it fits onto a CD-ROM.  About the
only thing paper is good for is writing letters to friends who don't
have an email address.

So get a new set of friends.

:-)

--
John Washington

In article <874755439snz@wash.demon.co.uk>, John Washington
<john$@wash.demon.co.uk> writes
>BK> newsbase.  Therefore I propose changing the name of the lock file for
>BK> SNews's HISTORY.SNW file to be SNWSHIST.LCK --- this would obviously require
>BK> alteration of all the support programs in the SNews suite to suit.
>
>Either that or change K9aq and Unbatch's lock file name.  So many
>different ka9q's around, probably less desirable.
>
>But either such solution has serious repercussions, given that there
>are existing users, and no matter how hard you try, stopping users
>upgrading piecemeal is an impossible goal.

Since it's snews thats changing, it should be the snwshist.lck file that
gets added (ie no changes to KA9Q). It isn't unreasonable to expect
unbatch/expire/etc to be upgraded along with snews. Put all the files in
the same .zip, and include the reasoning in the docs. Anyone who still
gets it wrong deserves all they get :-)

-- 
Mark Rogers (Software Engineer)       -o-      mark@controlware.demon.co.uk
2M_ControlWare, Yaxley, Peterborough, ENGLAND.