*line   1: Unknown output type = 
>*line   1: UNKNOWN DIRECTIVE G


kbd:style3.lay
$G
16


                  27(APM operating system etc. debate)


!<RDW:

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.

Item 2: The 'bug' program is increasingly being used fro discussion (as
well as non-bugs but that's another story).

Item 3: Shortly the APM OS will be 'frozen' & sole developement will be
towards developing 1 above.

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.

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.

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.

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.

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.

2) If this works the moving towards the encorporation with the UNIX news
service.



                                 1



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.

Suggested newsboxes

Newletter, OS, VMS, General, Flame (non defamatory), CS1 (babysitting),
UNIX (?), EMAS (??), Jargon, Humerous (for the cookie file stuff c)
                                                                 _

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 ......

!<USEFUL:

Some capital suggestions.

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.

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

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

David A Kerr

!<GDMR:

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


                                 2



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.

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.)

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.

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....

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).

I would suggest that only system-call emulation is sensible.  That way
we can make the kernel support other more sanitary things as well.

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.

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.....?!

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....

!<RDW:

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....)

!<ANON:

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


                                 3



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.

!<GDMR:

Qsarts Don't get qsarts.  Get Fred to design something which works
reliably.  The qsart hardware is not to be trusted.

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.

















































                                 4





Program stopped