$g kbd:style3.lay
$a pageno=1
$16
$b2
$l$m
$27(APM operating system etc. debate)
$b2
!<RDW:
$b1
Well here we go.....
Item 1:
  It is the now stated policy of the APM sofetware developement team to
move towards an environment upon which UNIX may be run.
$b1
Item 2:
  The 'bug' program is increasingly being used fro discussion (as well
as non-bugs but that's another story).
$b1
Item 3:
  Shortly the APM OS will be 'frozen' & sole developement will be towards
developing 1 above.
$b1
I should like to propose a facility similar to the UNIX NETNEWS program to
be written and placed in the useful: directory.  This *must* be a temporary
measure to be supplanted by the standard unix facility.  Since this would 
occur well within my university 'lifetime' I am willing to write and support
the code.
$b1
Facilities:
  In the first instance a simple extension of the view / bug program
(to run off one filestore only).  Further developement should be towards a
growing level of compatibility with the UNIX product to make the final
transfer user invisible.
$b1
With the arrival of ISO L4 I personally (an this is my real interest in this)
would like to see the possibility  of subscription to the Usenet newnet.
This should obviously not be done by massive file transfers every night 
(with the attendant problem of duplication of 50 Mb of data) but by use of the
10Mhz ethernet (perhaps a logical device might be mounted somewhere VAX/UNIX
APM with all the new on it).  Note the advantage here that if all the code is
written in terms of high level modules (ISO L4 and Terminal mostly) it should
run as happily on VAX as on any APM thus the news program on vax could become
devolved into the general news scene.  (I am not well versed in how the UNIX
newsnet works but probably another group would be made new.EUCSD. with 
the newsletter as a subfield.
$b1
There is one point which this would bring up - the fact that use of news seems
to be inextricably bound up with sending mail - not just to your local news
service but also to the rest of the world.  Ad hoc solutions to this are simple
both on VAX and on the APM, but a well worked out solution *must* be the only 
way forward.  Any code in the APM NEWS program might be mocked up to have use
a %routine send mail(......) so that the immediate solution might be a hack
(perhaps block file transfer to UNIX and thence onwards) and as a proper
mail system comes in a better solution can be implemented.
$b1
To summerise I would like to see:
 1) in the first instance a centralised (ie on one machine) version of bug/help
brought out for intradepartmental discussion.
$b1 
 2) If this works the moving towards the encorporation with the UNIX news
service.
$b1
Although *all* this code need not be of any interest to CO's (since it should
be using CO supplied routines at the top level).  I feel that it should at least
have official approval not only so that duplication (viz in the departmental 
newsletter) can be avoided but also, and more importantly, so that it may be
brought to the attention of members of staff.  Members of staff both acacdemic
and otherwise are employed because of their greater experience and knowledge in
the field of computer science and thus their opinions are to be especially 
encouraged.  The counter to this is that without the staff the subjects would
probably become parochial and possibly deteriorate to how to fit go-faster
stripes to BBC micros.
$b1
Suggested newsboxes
$b1
Newletter, OS, VMS, General, Flame (non defamatory), CS1 (babysitting),
UNIX (?), EMAS (??), Jargon, Humerous (for the cookie file stuff %c)
$b1
POSTSCRIPT:
  Frank (C) and Richard (M) tell me that they are starting at this. Good luck to
them hope that they take notice of this and if they want a hand coding ......
$b1
!<USEFUL:
$b1
Some capital suggestions.
$b1
1) Just a quick comment on RDW's bit.
   I agree, and suggest that he (or others) get a start on the basis
   of a news system.
   One of the most important points mentioned was that it be run of
   one filestore (presumably Bravo), what would be a nice side kick
   is a couple of external routines to allow a program to establish
   a logical connection to any filestore, EFTP, USEFUL:USERS, and
   others all do this, but in a rather messy way. Can we have these
   externalized and put in INC:FS?.IMP or something.
   In fact why bother with all the messing about at this level and get
   the 'system' to do it for us, such that ALL file names can be
   specified as residing on a given filestore, eg %include "::B:INC:???.IMP"
   etc etc etc.
$b1
2) As for next years capital expenditure.
   How about another 'network server'.
   Into this plug the coming MSF clock decoder (super accurate time),
   Teletext decoder (up to the minute cricket results and news),
   (both CS4 projects)
   A new hardware addon with
     6 (or so) RS-232 serial ports
     2 (or so) parallel ports (centronics?)
     etc
   Then into this we can plug printers, plotters, and anything else
   that comes to mind.
   Get some enthusiastic boffin to write the necessary control software
   queuing theory, etc etc, and the VAX-ETHER problems vanish overnight
   (hopefully)
   I don't see why VAX can't send its output to the ethernet, rather than
   APM users sending output to VAX, after all this is how it was in the
   old days
$b1
   Of course the above suggestion may become void with the arrival of the
   10Mbit/sec ether port... but won't it have to sit in a 'server' somewhere
$b1   
        David A Kerr
$b1
!<GDMR:
$b1
Ether
It is essential that the two subjects of an ether gateway and the place
to hang slow devices are kept separate.  The gateway is assumed to be
providing transparent connections between anywhere and everywhere in the
not-too-distant future.  The subject of slow devices should be restricted
to the best place on a uniform problem-free ether to hang various slow
devices.
$b1
As I have said, I think the plotters should be removed from VAX.  I don't
think the printer should be moved unless facilities are provided which
are up to the standard of VMS V4 (coming soon).  The filestores are
intended as purely passive nodes, so the printer shouldn't be hung
directly off one of them.  (The situation in the Tower is a hack.)
$b1
The printer used to be attached to the OLD interdata filestore (now
deceased).  It was moved to VAX because only 31 machines could send
files there.  This represented an infinite improvement in service for
a large fraction of the user population.  It was never attached to
the new filestores.  The hardware to do so is dubious and the software
is a quick hack job which is suitable only for a benign environment.
$b1
The ether gateway is intended to remove any reliability problems,
particularly at the VAX end.  Any arguments for moving the printers
because of unreliability are red herrings and should be resisted.
There may be other arguments for and against, but these should
be allowed to stand for themselves and not buried in irrelevancies.
You might as well argue that the laser printer shouldn't have been
connected as it was....
$b1
UNIX
There seems to be some sort of vague thought that the Fred-machine
system should be converted to run UNIX, or to support UNIX facilities
or to run a UNIX shell (whichever particular flavour you prefer --
there are three).
$b1
I would suggest that only system-call emulation is sensible.  That
way we can make the kernel support other more sanitary things
as well.
$b1
The filestore situation is rather similar.  People seem to want a
UNIX file system (whatever that is -- 4.1 or 4.2?).  People also
want other things which contradict this (eg versions).  It seems
to me that the best way forward is to do it from scratch ourselves
incorporating the good features of the systems we know about.
$b1
Why do we want to slavishly split our infinitives (sorry, slavishly
copy) ten-year-old technology when we have a chance to do it again
but very well this time.....?!
$b1
PS
I intent producing a draft filestore spec sometime.  Hierarchical
directories (UNIX-style) will be in, as will be versions, differential
files, audit trails, decent protection....
$b1
!<RDW:
$b1
Plotters
If vax V4 has such powers for queues why do we not spool our plotters ?
It is the logical thing to do - the spoller would, admitedly probably
have to be a batch job but I assume that V4 will have all the needful
(after all it has everything else....)
$b1
!<ANON:
$b1
Capital Submissions
JHB
GDMR's and DAK's comments are noted.  I have already a proposal for a 'slow
devices' machine which would remove the need for printing through the vax.
It would logically have QSART multi-RS232 boards on it and whatever else is
seen as necessary to drive the devices it would spool.  I am dead against
combining multiple functions in one machine - you get the worst of both
(all) components.   Teletext is interesting. Prestel even more so. Trouble is
Teletext is a bit limiting and Prestel implies a hefty recurrent bill.
$b1
!<GDMR:
$b1
Qsarts
Don't get qsarts.  Get Fred to design something which works reliably.
The qsart hardware is not to be trusted.
$b1
Spooled plotters
We don't spool our plotters because someone has to change the paper.  If
you have to stop and start the plot queue at the end of each sheet you
might as well just run the plotters interactively as at present.
$b1
$e