Article View: demon.ip.developers
Article #416Proposed changes to SNews to permit operation over a LAN
From: Brian {Hamilton Kelly}
Date: Tue, 09 Sep 1997 00:00
Date: Tue, 09 Sep 1997 00:00
90 lines
5992 bytes
5992 bytes
I've recently LANned together my SO's computer and mine. She runs WfWG3.11,
whilst I have OS/2 Warp 4 on my machine. At present, we're only running
NETBIOS/NETBEUI on the LAN, although I will be adding TCP/IP later (when I
get my ISDN connection, InJoy [for NAT], etc).
Anyway, in the interim, she'd like to be able to read netnews at the same
time as myself (I collect news using KA9Q/2, but otherwise use the DOS
components of DIS, rather than the OS/2 specific ports of SNews, Unbatch,
etc). Of course, this raises a few snags, and I'm proposing to make some
changes to SNews (and any other programs that might suffer "collateral
damage") to accommodate this usage.
1) At present, SNEWS.EXE uses the SNEWS environment variable to locate the
directory which contains ACTIVE, SUSPEND, SNEWS.RC and [user].NRC. By
setting this environment variable on her computer to use a network "drive",
it's possible to run SNews, read articles, update the .NRC file, etc.
However, I cannot simultaneously use SNews on the Warp machine, because
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.
I propose to make SNEWS.EXE take an optional command-line argument, being
the "username": if provided, SNEWS.EXE will pass this parameter when it
calls load_stuff(), causing the latter to read the specific .RC file for
her, which would be configured ONLY for use by remote access. The *actual*
username would be determined in the usual way from the content of this file
(from the "userid" .RC field), which would mean that that USER's .NRC file
would record the articles read by her, regardless of whether she did that
locally on the Warp machine, or from her machine across the network.
2) Having read in the [SNEWS].RC file with load_stuff, SNews locks the
HISTORY.SNW file and that particular user's .NRC file. Now I have no
worries about the latter, which is obviously a necessary precaution; but the
locking of HISTORY.SNW, achieved by creating a HISTORY.LCK file, would
prevent parallel operation, despite the newsbase (and history) being
accessed purely in a read-only fashion. I presume that HISTORY.LCK is
created to prevent any cock-up through trying simultaneously to run EXPIRE,
UNBATCH, etc., and this precaution is also necessary. Therefore I propose
to read back the content of the HISTORY.LCK file to see if it was created by
"SNews" (luckily, it already writes the name of the relevant component into
the lock file), and if so, to permit multiple readers. I'm proposing to add
an additional selflock() function to LOCKING.C which will permit this: only
SNews would use this entry (since obviously one doesn't want two copies of
EXPIRE or whatever running).
3) When KA9Q itself is running to collect new news, it too creates a
HISTORY.LCK file. However, this is actually to protect against multiple
accesses to the NNTP HISTORY file, and not to HISTORY.SNW: the latter is
only affected by UNBATCH, EXPIRE, etc. There is no reason, so far as I can
see, why one shouldn't be collecting a new batch of news from Demon's
servers, whilst simultaneously reading the OLD contents of the local
newsbase. Therefore I propose changing the name of the lock file for
SNews's HISTORY.SNW file to be SNWSHIST.LCK --- this would obviously require
alteration of all the support programs in the SNews suite to suit.
Can any of the SNews experts (Malcolm, JW, Niel, etc) see any problems with
any of the above changes?
One final problem, which I think lies more with my ignorance of NETBIOS
and/or WfWG. My girlfriend's computer has a local printer on its LPT1, and
accesses my LaserJet over the network (and imagines it's on LPT2, which
doesn't really exist). If she presses "o" to print an article, it gets sent
to the local PRN, which is LPT1, and prints on the (expensive) colour
printer. Even if LPT2 is set as the default printer (which works fine for
all Windoze applications), SNews, being a DOS application, always uses LPT1.
I also tried using "s" to "save" to LPT2, but SNews reported that it
couldn't open it, presumably because the "device" only exists so far as WfWG
is concerned.
Do I need to set up LPT2 as a network printer at the DOS level, before
entering WfWG (I realize that this question might be better asked on a
comp.os.* newsgroup)? Even if it were, SNews appears to open/write
explicitly to PRN (indeed, the OS/2 version has a special operation to open
PRN as stdprn, since the latter "standard" stream is not provided in the
OS/2 version of Borland's run-time library). How, at the DOS level, can one
reassign PRN to use LPT2? (I can't see how to do it; I'd forgotten quite
how primitive DOS is:-) Perhaps an additional optional entry in the .RC
file could accommodate such flexibilities?
I forgot to set a Reply-To address in this posting: if you prefer to e-mail
me, please do so on my home machine <bhk@dsl.co.uk>
--
Brian {Hamilton Kelly} TeX@rmcs.cranfield.ac.uk
Smail: School of Engineering & Applied Science, Royal Military College
of Science, Shrivenham, SWINDON SN6 8LA, U.K.
Phone: Swindon (01793) 785252 (UK), +44-1793-785252 (International)
Technical Details
Message-ID:
<1997Sep9.162238.977@rmcs.cranfield.ac.uk>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10bb05,a93027b270d46968,start
X-Google-Attributes: gid10bb05,public
From: tex@rmcs.cranfield.ac.uk (Brian {Hamilton Kelly})
Subject: Proposed changes to SNews to permit operation over a LAN
Date: 1997/09/09
Message-ID: <1997Sep9.162238.977@rmcs.cranfield.ac.uk>
X-Deja-AN: 271087249
Organization: Royal Military College of Science, Cranfield University
Newsgroups: demon.ip.developers