JLW@PSULIAS.BITNET (Lance Wilkinson) (02/02/90)
After nearly a month of trying to figure out why NETSERV was
sending me NETDATA tables when all I can recieve is PUNCH, the
folks at BITNIC were able to explain & correct the problem.
Thanks to Andy Robinson and Mike Hrybyk at BITNIC; thanks also to
Berthold Pasch who provided an explanation as well. While it's
unfortunate that the files had always been sent in PUNCH format
and suddenly were sent in NETDATA because I'd never set :tformat
to PUNCH (never needed to do so -- if it ain't broke, don't fix
it), that's all water over the bridge. Mike Hrybyk also supplied
the January RSCS tables for me *AGAIN* in PUNCH format so I
wouldn't have to wait until March to see my correct version of
the GENROUTS generated tables.
Now, I can finally do what we were all asked to do when this
NETSERV-issued GENROUTS-generated table stuff was started --
compare the recieved tables with the traditional Chris
Thomas-supplied tables.
I find some significant changes. Maybe not significant to most
folks, but significant to me because in order for me to accept
the NETSERV-shipped tables I'm going to have to *STOP* working on
my current, mission-critical assignment and open up what has been
production software since May of 1987 and change it.
Furthermore, I will then have to ship this software to the few
(but still there *ARE* a few) sites which run my implementation
of a Homebrew BitNet interface. All before the March cutover
date for the NETSERV tables.
Here's a sample record from the January Chris Thomas' tables --
it turned out to be the 30th record in the file I got; after it
is the 1928th record from the GENROUTS table Mike Hrybyk supplied
to me, representing the same node. Anybody notice some
differences, besides the location within the file, which isn't
significant to me (thank goodness).
ROUTE ALCANKTN PSUVM Alcan Int. Ltd. KRDC, CA
ROUTE ALCANKTN PSUVM 7 CA Alcan Int. Ltd. KRDC
They seem minimal to most folks, I'm sure. But notice that the
GENROUTS generated table has ROUTE prefixed by a leading
character. It's a blank, thank goodness, but it still means that
my current *SIMPLE* parser for this file (counting from 1, use
the 8 characters starting at column 7 in the record for the
target node, and the 8 characters starting at column 16 in the
record for the via-node) has to be changed. I also see a new
field, which *I* have no use for, between the 'via' node (always
PSUVM for me, but not always for the nodes who use my software),
and the country got moved to before the node abbreviation.
Having written the software which automatically recieves this
file and updates my system external node routing file *WITHOUT
HUMAN INTERVENTION* more than 3 years ago, and then closed it up
for production never to have opened it again, I can't say how
significant the rearranging is going to be. It might take 20
minutes. It might take until next July.
Back when this was first announced, Jim Conklin assured me the
*ONLY* changes would be to the flowerbox of commentary prefixing
the file. Perhaps I'm subscribed in my :routtab tag for the wrong
format of RSCS routing tables? My entry reads
:routtab.RSCS (NETSERV,ROUTING@PSULIAS)
so I don't think I'm asking for anything out of the ordinary.
The implementation of these changes is going to require at least
few hours of my time writing and then debugging. It's then going
to take several days to properly distribute the software, which
is going to have to accept *BOTH* Chris Thomas format and the new
format, since some of my user sites are not prone to install
software *at a specific time* -- reasonably, they'd want to
install it as soon as possible meaning they may still be
recieving and using Chris' tables with the new software -- just
in case there's a bug that has to be fixed before the NETSERV
tables become the only source of tables.
Now being saddled with a significant assignment which is
mission-critical to my installation (BITNET is critical, but
*NOT* mission-critical), namely the porting of our entire shop
from Bull CP-6 to DEC VMS in a 6 month timeframe, I don't have
time to waste with experimentation. Can somebody supply me with
the exact specifics of WHAT GENROUTS is going to supply in each
line of the table? Preferably in an old COBOL-style record
description that *ANYBODY* can read (given the possibility its
shift was an arbitrary one), but if not in a BNF style I can
generate a simple parser for?
Can someone also assure me that this format *WILL NOT CHANGE*???
J.Lance Wilkinson <JLW@PSULIAS.BITNET>
Systems Design Specialist - Lead Penn State University
Library Computing Services (814) 865-1818Andrew.S.Hooper@QUEENSU.CA (02/03/90)
This is really getting a little tedious. Perhaps you should have read the
specifications for the the RSCS routing tables before writing your code.
Both GENROUTS and Chris Thomas' tables conform to the specifications.
To quote from the IBM RSCS manual SH24-5005:
"RSCS directory control statements must be in the following formats, with
one or more blanks as operand delimiters. All operands are positional from
left to right. ... Operands may be entered in columns 1 through 71. All
data entered to the right of column 71, and all data entered to the right
of the last possible operand are ignored. No continuation of RSCS directory
control statements is provided. RSCS ignores completely blank records and
records having an asterisk (*) in column 1, allowing these lines to be used
for comments and print formatting.
...
ROUTE locid linkid
locid is the one- to eight-character location identifier of the remote
location that is being defined for indirect communication.
linkid is the one- to eight-character link identifier of the link on which
transmissions destined for the remote location are to be made. This
link must have been defined by a preceding LINK statement.
-----
Andy Hooper Queen's Univ. Computing Services Bitnet: HOOPER@QUCDN
Kingston, Ontario, Canada Telephone: +1 613 545 2019