LETTERS - Issue 150, September 1992:

To ALL from W6GO:

Thanks for your messages and files included below.  My comments, if
any, are enclosed in <<< and >>> as shown below:

<<< This is a comment from W6GO >>>

73, Jay


**********************************************************************
	   * * * * C:\SYSOPS\LTRS\AD8J.LTR * * * * 
**********************************************************************
-
Hi Jan and Jay:

I have removed K8AZ from the .INC files as you have requested. 
As far as the date that I extract your data goes, I try to do it
around the 20th of the month when I can find enough time to
complete the task.  Since the Cluster is located at a remote site
I can't do it as easily as most of the other SYSOPS.  What used
to be a fairly simple task has become quite complicated.  This is
what I have to do each month:


TO GET YOUR DATA:

1.  I unload the OPERNAM.DAT file at the Cluster site from the
    360K drive and take it to work where I clean it up.
2.  I then return to the Cluster site and reload the OPERNAM.DAT file.
3.  My next step is to run GODISK to get your data on a 360K disk.
4.  I then return to work and copy this 360K disk onto a 1.44M disk for you.

TO LOAD YOUR DATA:

1.  I take the 1.44M disk you send me to work where I UNZIP it and copy
    GOQSL.ZIP to a 360K disk.
2.  I take the 360K disk to the Cluster site, UNZIP it, and run GONEW.  
    Just this one step takes 22 minutes on our slow XT.

With all the running around and disk copying, the process takes
me about 4 or 5 hours.  I try to arrange to do all this on a day
that my boss is gone so he doesn't find out what I'm doing.  

The bottom line is:  Please don't bug me about being a few days
early.  Considering the limitations I am working around, I'm
proud to say that I have never missed a month and the boss hasn't
figured out why my job performance drops off around the 20th of
each month.

Keep up the good work on your end, us grunts in the field
appreciate it.

73,  John, AD8J

<<<John, 

You are working too hard.  You should skip one trip and take a small 
hit on the OPERNAM.DAT statistics.  I only clean up my OPERNAM.DAT 
every few months, and that's all that is really needed. I suggest 
you do the following:

1.  Run GODISK to get data on a 360K disk.
2.  I then return to work and copy this 360K disk onto a 1.44M disk. 
    <Mail disk to W6GO>
    <Disk received from W6GO>
3.  Unzip 1.44M disk and copy  GOQSL.ZIP to a 360K disk.
4.  Take the 360K disk to the Cluster site, UNZIP it, and run GONEW.  
5.  Unload the OPERNAM.DAT file at the Cluster site from the
    360K drive and take it to work and clean it up.
6.  Go to the Cluster site and reload the OPERNAM.DAT file (if enough
    errors to justify).

The only disadvantage is that the OPERNAM.DAT will no doubt not be 
at 100% accuracy, because it has been left to its own devices for 
nearly a month.  Actually, most of the OPERNAM.DAT errors are found 
and corrected just by running K1EA's OP_SORT program.  You might give
that a try.

John, many thanks for your efforts.  The reason I "bitch" about data 
being "too early" is that we miss late-breaking data. 

73,  Jay

>>>>>
-
**********************************************************************
	   * * * * C:\SYSOPS\LTRS\GB7DXC.LTR * * * * 
**********************************************************************
-
HI Jay, Not much news this month.
I have enclosed a file !MOREINF.ZIP which contains QSL updates from
GB7WDX node (all from G3SWH!) some of which don't appear to have
made it up to GB7DXC. I thought you might as well have the info just
in case it is unique.
Cheers for now de John - G4PDQ.

<<< John.. Only one of those G3SWH incomplete files was current, and it
    made it into the database just fine.  I would appreciate it if you
    would keep an eye on your TEMP directory and see if you can determine
    what is happening.  Usually those strange files are due to forwarding
    timeouts that are repeated successfully later. >>>
-
**********************************************************************
	   * * * * C:\SYSOPS\LTRS\GB7YDX08.LTR * * * * 
**********************************************************************
-

 Hi Jay and Jan,                                                                                    31st August 1992
 
 First, thanks for the new OP.EXE utility which I have used for this month's
 submission.  I think John G4PDQ uses the SET/ALIAS within a USERCMD file to
 allow OZ7SM to change his callsign to G/OZ7SM.
 
 I have a lot of BPQ information this month which I hope will be of some use
 and might explain a few  anomolies.   John G8BPQ has rewritten COMMANDS.DOC
 with some new  information  about  the  switch.    I  have enclosed another
 file  called  BPQSTATS.DOC  which  attempts to explain what all the various
 commands and numbers mean within BPQ code.   Also, I have enclosed the very
 latest upgrade for BPQ code  to  4.05f.   Only one file, BPQCFG.EXE changes
 from 4.05e and the upgrade only inolves  overwriting  the  old  BPQCFG.EXE.
 There are a number of small bug fixes and improvements to the STATS package
 in version 4.05f.   The switch only  version  of BPQ 4.05f is also included
 and the file is SWITCH.EXE.

  Steve, G3VMW 

<<<Thank you!  I'll try to get this into BPQINFO before the October GODISK.>>>


		       Changes in BPQ 4.05f
		       ~~~~~~~~~~~~~~~~~~~~

 1) Several bugs fixed on TNC2 (PACLEN, AH=1F/AL=2, AH=8).   New Fn added to
    set PACLEN to recommended value from node.
 2) All numeric aliases were treated as port numbers.
 3) Reflected routes now get OBSCOUNT set, so they dont vanish too soon.
 4) ON-OFF keying for CWID (mainly for RUH/DataRadios)
 
 
 John G8BPQ and me have been testing a pair  of  the  new  Kantronics  D4-10
 70cms  data  radios  at 19200 baud with Data Engines and the new 9600/19200
 baud internal TNC.   It looks very  promising  and we are hoping to upgrade
 our backbone link to run at 19200 eventually.  Holidays have got in the way
 of much of the development work,  however, September is looking good at the
 moment.
 
 73 de Steve G3VMW
 SysOp GB7YDX, Wetherby, West Yorkshire
 
	-------------------------------------------------------------

 GB7BPQ  4-Aug-1992 2334Z The File
 
 G8BPQ NODE COMMANDS
 ~~~~~~~~~~~~~~~~~~~
 
 This  document  explains  the commands available within the Node section of
 the G8BPQ switch, and an explanation of the responses.
 
 First the result of inputting an invalid command:
 
 NOTTS:G8BPQ-3} Invalid command - Enter ? for command list
 
 Entering ? produces the following:
 
 NOTTS:G8BPQ-3} BBS CONNECT BYE INFO NODES PORTS ROUTES USERS
 
 Note that BBS is only present if the BBS support is enabled (BBS=1  in  the
 config file).  If you have defined your own applications, they will also be
 listed.
 
 
 The BBS (and your other application  names)  must  be entered in full - all
 other commands can be abbreviated to the first character of the command.
 
 
 Entering BBS (or your own application name) will connect you to  the  first
 free BBS (etc) port, or give an error message if none are available.
 
 
 The CONNECT command is used to connect you to another node,  or to a normal
 AX.25 user.   To connect to another node,  enter C NODECALL or C NODEALIAS.
 The  system  will  select  the 'best' radio port and neighbour to to use to
 reach the required node using its ROUTES and NODES lists.
 
 The format used to connect  to  another  normal user depends on whether you
 have more than one radio port.  The formats are:
 
		 (stuff in [] being optional)
 
      C CALL [via digi1 [digi2...]]If you only have one port
 
 
   C P CALL [via digi1 [digi2...]]         Where P is the port number,
   if you have more than 1.
 
 
 (You can use C 1 CALL if you only have  1  port  -  its  just  a  waste  of
 typing!)
 
 
 If  you miss out the port number where it is needed,  you will get an error
 message, listing the available ports.
 
 Normally you cannot override the automatic route selection when you connect
 to another node,  but you can  fool  the  system  into thinking a node is a
 normal station by connecting to the  alias,   and  adding  an  SSID.    For
 example,  if you want to connect to NOTTS:G8BPQ-3,  you can force a Level 2
 connect on a secified port by entering C P NOTTS-1
 
 It  is  also  possible  to  instruct  the  node  to remain connected to the
 currrent node,  when the connection  to  the  next one is closed.   This is
 achieved by adding an S (for STAY) after the connect command.  For example,
 if I type:
 
		    C GB7YDX S
 
  I get:
 
		    NOTTS:G8BPQ-3} Connected to GB7YDX
 
 If I then enter B, GB7YDX closes the connection, but instead of getting ***
 Disconnected, I get:
 
		    Returned to Node NOTTS:G8BPQ-3} 
 
 This is particularly useful if you are exploring a distant  set  of  nodes,
 and don't want to have to reconnect over the whole path again and again.
 

 The BYE commnad disconnects you from the switch.
 
 
 The INFO command sends your INFO text from the config file:
 
  NOTTS:G8BPQ-3} G8BPQ Packet Switch, Mapperley, Nottingham. IO92KX
  Commands are basically the same as NET/ROM, but to connect to another
  normal station (not another node), you must specify a port number before
  the callsign. Use PORTS command to list available ports. The BBS command
  connects you to the associated Mailbox.
 

 The  PORTS  command lists available ports.   The descriptions come directly
 from the configuration file,  and  should  give  at least the frequency and
 baud rate used.
 
  NOTTS:G8BPQ-3} Ports:
   1 144.650 MHz 1200 Baud (PC120)
   2 432.675 MHz 1200 Baud (DRSI)
   3 Experimental NET/ROM Link
 

 The NODES command lists all the other NETROM/THENET/BPQ Nodes known to your
 node:
 
 NOTTS:G8BPQ-3} Nodes:
 BBSTST:G8BPQ-1     DV7:G4RFG-1        LRG7:G0GDR-1       G4RFG-2
 LRGBBS:GB7LRG      AAABBS:GB7AAA      #LNX2:G4GOU-1      BM1:G7AXC-1
 BM2:G7AXC-2        BM7:G7AXC-7        DV2:G4RFG          DV6:G4RFG-3
 BOB432:G8HBE-3     NEC21:G8VPQ-2      FPV7:G4FPV-7       SY4:G3UQH-4
 WP4:G0KNR-4        LRG2:G0GDR-2       NEC22:G8VPQ-3      MM2:GB7MM-2
 TFONET:G8TFO-8     NEC90:G8VPQ-9      NH:G0HWC           RP2:GB3RP-2
 ADH2:G8ADH-2       SY7:GB7SY-7        HX2:GB7HX-2        WORC7:G8TIC-7
 WV2:G1RLI-2        TEWKS3:G6CMG-3     WB7:G4DVM-7        BOB650:G8HBE-2
 LED:GB7LED         SY8:G3UQH-8        VPQNET:G8VPQ-8     GH2:GB7GH-2
 SY2:G3UQH-2        FPV:G4FPV-2        AP2:GB7AP-2        LX2:GB7LX-2
 LX4:G6TNZ-1        LX7:GB7LX-7        RAYNET:GB7NRC      SF2:G8POT-2
 #NICK:GB7LRG-7     NEC72:G8VPQ-7      WORC2:G8TIC-2      PQ2:GB3PQ
 TEWKS4:G6CMG-4     BOB675:G8HBE-4     FPV71:G4FPV-8      TEWKS9:G6CMG-9
 TICNET:G8TIC-8     BRX:G4AKZ          SC4:G4AJJ-4        CD2:G6ANN-1
 TEWKS7:G6CMG-7     TCPIP:G4GOU        CHELT2:G4MEM-2     DROIT7:G8TFO-7
 DROIT2:G8TFO-2     MK6:G4WIM          MV2:G2AFD-2        SERVER:GB7AAA-9
 ERA24:G0DXX        WP1:GB7WP-1        WP2:GB7WP-2        WP7:GB7WP-7
 MK2:G4WIM-2        MK23:G4WIM-7       LNXBBS:GB7LNX-2    TVB:G6TVB
 #GATE0:G6CMG-5     #GATE1:G6CMG-6     WORC22:G8TIC-1     VPQ90:G8VPQ-10
 VPQ91:G8VPQ-11
 
 
 By entering N NODECALL (or N NODEALIAS),  you can list the routes that  the
 system will use to access that node:
 
	 N GB7YDX
 
 
  NOTTS:G8BPQ-3} Routes to: DXYORK:GB7YDX RTT=7 FR=17  B 2
  > 87 4 5 GB7YS
     0 4 7 G8BPQ-8
     0 4 6 G4FIS-2
 
 The bits after the callsign are only shown if some frames have been send to
 that node.  RTT stands for Round Trip Time, and is a rolling average of the
 time taken to get a response from that node (in seconds).  FR means Frames,
 the number of info frames sent to the node.   The B, if present,  indicates
 the target is a BPQ node,  and the number following the B is the number  of
 hops to the target.
 
 Up to 3 possible routes to the node are listed.  The first number displayed
 is the 'quality' -  the  relative  desirability  of using this route rather
 than another.   The second is the Obsolesance Count,  an indication of  how
 long  it  is  since  the system was last told about ( or successfully used)
 this route.  The number starts at a value set in the config file (typically
 5) and is decremented each time a 'NODES' broadcast is sent (typically evey
 hour).   The third number is the port.   A > indicates the currently active
 route.
 
 The Round Trip Times and frame  counts  for all nodes with a non-zero count
 can be displayed by entering N T
 
 
  N T
   NOTTS:G8BPQ-3} Nodes:
   G1FYS              RTT=22 FR=5  B 
   #LDS:G3WNR-3       RTT=17 FR=39  B 
   AP21:GB7AP-2       RTT=90 FR=866
   AYTON:G4HRM        RTT=76 FR=18  B 
   BADBBS:GB7BAD      RTT=40 FR=2576  B 2
   BEDS:G1ZPU         RTT=283 FR=1  B 4
   BFD41:G4GIR-4      RTT=31 FR=593
   BOSTON:G4LPL       RTT=28 FR=1606  B 2
   COV22:G3ZFR-3      RTT=29 FR=14
   DXYORK:GB7YDX      RTT=7 FR=17  B 
   HALFAX:G6KZJ       RTT=30 FR=306  B 2
   HF:G4JLB-8         RTT=32 FR=99  B 4
   LADY61:G7EQM-8     RTT=68 FR=1754  B 1
   NEC:G8VPQ          RTT=113 FR=127  B 
   NN22:G8AMG-2       RTT=30 FR=2047
   NN41:G8AMG-4       RTT=19 FR=250
   NN72:G8AMG-7       RTT=19 FR=301
   NOTBBS:GB7NOT      RTT=34 FR=5659  B 1
   OAK:G0LTN-1        RTT=76 FR=1309  B 3
   PBORO:G1ARV-8      RTT=26 FR=230  B 2
   RP:GB7RP           RTT=41 FR=1396  B 
   RUTBBS:GB7RUT      RTT=10 FR=10683  B 1
   RUTLND:G4FIS-2     RTT=7 FR=16468  B 1
   SHEF:GB7YS         RTT=15 FR=11547  B 1
   TLH2:G1TLH-2       RTT=36 FR=5245  B 
   WN:G7HPM           RTT=52 FR=2281  B 4
   XOWPMS:G1XOW-2     RTT=38 FR=58  B 
   YORK:G1FTA         RTT=37 FR=363  B 3
   YORKS:GB7YW        RTT=20 FR=117  B 
 
 
 
 The ROUTES command lists the stations which this node can hear. 
 
 NOTTS:G8BPQ-3} Routes:
		     
  4 GB7YS 0 0! 
  1 G4FIS-2 14 0! 
  3 G3SDC-8 35 0! 
> 6 G4FIS-2 150 58!  
  3 G0INA-1 90 0!  
  2 G8BPQ-5 250 0!
  4 G1EQT-8 50 0!  
> 4 G0INA-3 120 48!  
> 5 GB7YS 150 93! 
  3 G7JGX-3 25 0!  
> 4 G4IRX-3 50 9! 
  7 G8BPQ-8 250 105  
  4 G7EQM-8 10 1  
 
 
 
 The > indicates that there is an active link to the node.   The first number
 is the port.   The second  is  the  quality.    This may be derived from the
 'default quality' parameter in the PORTS section of the config file,  or may
 be specified explicitly in the ROUTES section.  A value of zero will prevent
 the route from being used,  and is normally used when you have a one-way  or
 marginal  path.   The third number is the number of NODES list entries which
 refer to this  route.    This  isn't  used  by  the  software  -  it is just
 information for the user.   The '!' indicates a 'locked route' - one entered
 in the CONFIG file,  or via SYSOPH.   Other entries come and go as this node
 hears NODES broadcasts.
 
 
 Additional information may be obtained by entering R R
 
  R R
  NOTTS:G8BPQ-3} Routes:
   4 GB7YS 0 0!  8  0  0%  0  0  18:52
   1 G4FIS-2 14 0!  0  0  *  0  0  00:00
   3 G3SDC-8 35 0!  0  0  *  0  0  00:00
 > 6 G4FIS-2 150 58!  57022  1333  2%  0  0  21:55  0
   3 G0INA-1 90 0!  0  0  *  0  0  00:00
   2 G8BPQ-5 250 0!  0  0  *  0  0  00:00
   4 G1EQT-8 50 0!  0  0  *  0  0  17:13
 > 4 G0INA-3 120 48!  19305  819  4%  0  0  21:40  0
 > 5 GB7YS 150 93!  27017  6229  23%  0  0  21:44  0
   3 G7JGX-3 25 0!  0  0  *  0  0  00:00
 > 4 G4IRX-3 50 9!  2025  42  2%  0  0  22:09  0
   7 G8BPQ-8 250 105  592  0  0%  0  0  22:02
   4 G7EQM-8 10 1  3077  219  7%  0  0  21:37
 
 
 The extra fields are:
 
   Info frames sent
   Info frames retransmitted
   Retry Rate - the ratio of the above 2, as a percentage
      (or * if both are zero)
   Non-standard maxframe (from Config file)
   Non-standard frack    (      ditto     )
   Time the last NODES broadcast was heard from this node.
 
   The last figure is only present if there is an active link.   It  is  the
   number of frames queued to be sent.  Up to 4.05e, this only counts frames
   queued above the link level - there may be up to another 8 queued at link
   level.  With version 4.05f and above it includes all frames queued.
 
 
 The retry rate gives a good indication of how well  the  link  is  running.
 Dedicated  links  should  normally  be well below 10%.   A shared link will
 normally have a higher rate,  but anything above say 25% is likely to cause
 significant delays.   Another indication of a poor link is a high number of
 frames queued - any nonzero value of  4.05e or below,  or above 8 for later
 versions which persists for more that a  minute  or  so  is  likely  to  be
 causing problems.
 

 The USERS command lists the stations currently using the node.
 
 
  NOTTS:G8BPQ-3} G8BPQ Network System V3.21 (95)
  Host6(NOTTS:G8BPQ-3)
  Host3(NOTTS:G8BPQ-3)              <-->  Circuit(LRG7:G0GDR-1 G8BPQ-1)
  Uplink(G9XXX)                     <~~>  Downlink(G9YYY)
 
 
 Host is an internal (Normally BBS Port)
 Circuit is a link from/to another node.
 Uplink is a connection from a normal Ax.25 station.
 Downlink is a connection to a normal user.
 
 The <--> indicates an active session. <~~> indicates a session being set up.
 
 The Number on the end of the header line is the number of free buffers.
 
  
 There are a few commands not given in the menu.    These  are  primarily  of
 interest  to  the  sysop,  (or for me to experiment with).   They are LINKS,
 STATS, L4T1, and PACLEN.
 
 
 The LINKS command lists the currently active AX.25 Sessions (Both user
 access and node-node links)
 
  NOTTS:G8BPQ-3} Links:
  G0GDR-1 G8BPQ-3 S=5 P=2 T=3 V=2
 
  S is the link state (see AX25 protocol spec, but the main ones are 
  2 (connecting) 4 (disconnecting) 5 (connected)).
  P is the port.
  T is the link type. 1=Uplink, 2=Downlink, 3=Node-Node link.
  V is the AX.25 Version (1 or 2).
 
 
 
 The STATS command displays a number of counters.
 
  S
  NOTTS:G8BPQ-3} 
  Time active (mins)               8786
  Timer Overruns                     48
  Buffers: Max/Cur/Min/Out          100       76       16        0
  Known Nodes                       144
  L4 Connects Sent/Rxed            1055     1732
  L4 Frames TX/RX/Resent/Reseq    73288    96544     1870       42
  L3 Frames Relayed               10148
 
  L2 Frames Digi-ed       0       0       0       0       0       0       0
  L2 Frames Heard    124393    1870   80601   82124   60600  167575    2650
  L2 Frames Rxed      11921       0    2909   66674   59032   94340    1447
  L2 Frames Sent      15955    1870    4690   69857   71328  107267    3284
  L2 Timeouts          4466       0     984    5437    7697    1154      58
  REJ Frames Rxed         7       0       2     460    1681     214       0
  RX out of Seq         269       0       3     951    1697     272       0
  Underrun/Poll T-O       0       0    5358     233       0       0       0
  RX Overruns             0       0   39814       0       0       0      63
  RX CRC Errors       42260       0       1       0    2324   27025       0
  FRMRs Sent              0       0       0      19       0       0       0
  FRMRs Received          0       0       0       0       0       0       0
  Frames abandoned        1       0       0       0       0       2       0
  Link Active %        9  6   0   0   0   0   0   0  14  21  50  82   0   0
 
 
 Most are fairly obvious, but a few need a bit of explanation.   There is one
 set of level 2 counters for each port.
 
 
 Time Active is the time since the system was loaded.
 
 The Buffer count Maximum,  Minimum and  Current should be obvious.   The Out
 figure is the number of times a request to allocate a buffer failed  because
 there were none available.
 
 The  L4 frames resent count is the number retransmitted because an ACK wasnt
 received within the L4 timeout  period.    The  Reseq count is the number of
 frames received out of sequence,  but subsequently used because the  missing
 frame(s) eventually arrived.
 
 Timer  Overruns  count the number of times the main code (which is initiated
 by the timer  interrupt)  is  still  running  when  the next timer interrupt
 occured.   If it increments very  rapidly  (several  times  a  minute),   it
 indicates  that  the  PC is too slow for the amount of data being processed.
 It is normal for an XT class  machine  running  a couple of BBS ports to get
 about one overrun per minute.  My 10MHz AT clone shows very few.
 
 
 A large number in the 'REJ received' field may indicate that  your  Maxframe
 is too high.   Similarly a large number in 'RX out of sequence' may indicate
 the the station taking to you has too large a maxframe.
 
 RX  Overruns  indicate  characters lost because the software didn't process
 the interrupts fast enough.   If you are running KISS ports,  and you get a
 lot (ie a significant  percentage  of  L2  frames heard),  try reducing the
 speed of the link from the PC to the TNC.   If you are using an  HDLC  card
 (DRSI or PC120),  particularly at high speed,  then there isnt much you can
 do  except  buy  a  faster machine.   (But I would like to hear from anyone
 having problems running at 9600 baud or  above  - I may be able to speed up
 the routines a bit).
 
 Underuns indicate a similar problem in responding to TX interrupts, but only
 apply to HDLC cards.   As you cant get a TX underrun on an async port,  this
 field is also used to count timeouts on a polled KISS system).
 
 Frames  abandoned  counts  the  number of frames discarded because they have
 been waiting to be sent (for DCD to clear) for more than 60 secs.   If a lot
 occur, then either your squelch is a bit dodgy, or the channel is VERY busy.
 Only used for HDLC cards.
 
 Link Active shows two values for each port.    The first is the % of time in
 the last minute that your station was transmitting, and the second the % the
 channel was active (sum of Transmitting and DCD active).    Only  maintained
 for  HDLC ports.   Note that of you are using SOFTDCD,  then the indicated %
 active may be an overestimate.
  
 The L4T1 command displays or sets  the  Level 4 timeout used for the current
 session.  It is primarily for me to experiment with.
 
 PACLEN sets or displays the PACLEN value used for messages generated by the
 node (eg command responses).  Again it is mainly for me to play with.
 

 John Wiseman, G8BPQ
 Revised 5/8/92
 

		G8BPQ Packet Switch - What the Numbers Mean!
		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
			    Steve Wilson, G3VMW
			    ~~~~~~~~~~~~~~~~~~~
 In the examples I have detailed  below,   I  have tried to explain what the
 various commands and facilities actually represent.  The examples are taken
 from two working BPQ Packet Switches;  SHEF:GB7YS which is a  six-port  BPQ
 Data Engine arrangement and YORKS:GB7YW which is a six-port PC-based system
 supporting the GB7YDX PacketCluster.   The live information was gathered on
 a terminal program called BPQTERM which has the facility  to  capture  text
 from 'on air' displays.
 
 Some of the information is taken  from  G8BPQ's  COMMAND.DOC  and  this  is
 highly recommended supplementary reading.

	  
 >Sun Aug 02 07:43 1992

 USERS

 SHEF:GB7YS} G8BPQ Network System V4.05 Beta-2 for Data Engine (117)
 Circuit(YORKS:GB7YW GB7YW)
 Circuit(DXYORK:GB7YDX GB7YDX)     <-->  Circuit(NMCLUS:GB7BPQ GB7YDX)

	------------------------------------------------------------

 There seems to be some confusion with the BPQ R R command and the following
 might explain some of the lesser known facilities.   Remember,  you can use
 just R R on its own,  which gives a listing of all the ports or R  R  (port
 number) to display the statistics for that particular port, e.g.  R R 1

R  R - Means ROUTE RETRIES and the information produced in the display is an
       indication of  how  'good'  a  particular  link  is performing.   The
       information is arranged as follows:

    A |   B     | C   | D  | E |   F    |   G   |  H  | J | K |   L   | M |
   ---|---------|-----|----|---|--------|-------|-----|---|---|-------|---|
  > 1 | G8BPQ-3 | 150 | 35 | ! | 664835 | 90992 | 13% | 0 | 0 | 06:41 | 0 |

The > sign at the side of the port number indicates that the link is in  use
with a L4 connection.  A L2 connection will not have the chevron indication. 

A) Port     The number allocated  to  that  port  in  BPQCFG.TXT;  Port 1 is
	    usually the first port which is declared but doesn't have to be,
	    and ports can be numbered within BPQCFG.TXT

B) Node     The neighbouring node which  links  to  the packet switch on the
	    port number which has been assigned.   In this case  PORT  1  is
	    used  to  link  to  G8BPQ-3  and a ROUTE QUALITY of 150 has been
	    assigned.   This is a dedicated link  on 23cms and we don't hear
	    anything  else  direct  on  that  port  because  of  directional
	    antennas.   However,  this is not  the  case  with  Port  5  and
	    although  a  link  has been locked in to BOSTON:  G4LPL,  with a
	    ROUTE QUALITY of 100,   the  4m  port  (70.3125 MHz) on the SHEF
	    packet switch also hears WIL80:G6WYT-4 on Port 5. The difference
	    is that G6WYT-8 is assigned the DEFAULT RQ of 10 and there is no
	    exclamation mark (!) to indicate that the route is LOCKED.   The
	    route to WIL80 from SHEF is pretty poor because the Pennines are
	    in the way and we are not keen  to  encourage  linking  on  that
	    route.    Any  node heard direct on a port will automatically be
	    assigned a RQ of 10.

C) RQ       ROUTE QUALITY and is the value which is assigned in  the  ROUTES
	    part  of  BPQCFG.TXT.    It  seems  that in the USA,  there is a
	    tendency to let the ROUTES list float,  i.e.   you do not assign
	    route qualities and prefer  to  work  with  Level 2 (Link Layer)
	    connects.  This is why the W6GO route list shows two routes with
	    default RQs of 10.   If you use  L2  connects  the  R  R  (route
	    retries)  listing  does  not  work!   It is only valid with true
	    L3/L4 connects.

D) Routes   This  figure  indicates the number of nodes which can be reached
	    via the link (in this case G8BPQ-3 has routes to 35 other packet
	    nodes).

E) Lock     A  locked  route  is one which is declared in the ROUTES list of
	    BPQCFG.TXT - the  exclamation  mark  indicates  that a route has
	    been locked at that route quality.

F) Frames   This is the number of outgoing packet frames on  this  port  but
	    ONLY  L3/L4  -  if  you  link  out at L2,  then there will be no
	    indication of the number of frames sent on the port.

G) Rejects  This  figure is the number of rejected frames,  i.e. those which
	    have  been  refused  because  of  CRC  errors, and  subsequently
	    retransmitted.   A high number of reject frames indicates a poor
	    link.   The same rules about L3/L4 frames apply as in the Frames
	    example above.   L2 connects don't  give an indication of reject
	    frames.  BEWARE!

H) %Retries This is the ratio of REJECT FRAMES divided by FRAMES SENT and is
	    an indication of how good a link is performing.    A  good  link
	    should  have  %Retry figures of less than 10% If you look at the
	    listing above,  you can  see  that  the  link to G8BPQ-3 is just
	    below  par, and  we  think  that  this  is  because  of  antenna
	    deficiencies.   The link is changing frequency to 70cms and will
	    run at 19200 baud.   These statistics gave us a good  indication
	    that we needed to improve things.

J) MAXFRME  This  slot indicates whether there is a non-standard MAXFRAME as
	    declared in the BPQCFG.TXT file, e.g. greater than 7.
	    
K) FRACK    As above,  but indicates  whether  non-standard  values of FRACK  
	    have been declared.

L) Bcast    This  is  the  time  that the packet switch heard the last NODES
	    broadcast from the station defined  in the ports list.   In this
	    example, SHEF last heard a nodes broadcast from NOTTS:G8BPQ-3 at
	    06:41 - this is a very useful indicator and if a nodes broadcast
	    gets missed it suggests a link problem.    It  also  provides  a
	    diagnostic  tool  to  provide  an  indication  of roughly when a
	    neighbouring packet switch might have ceased operating.

M) Queue    This is  an  indication  of  the  number  of  outstanding frames
	    waiting to be sent.  If you see a high number here (I've seen 75
	    on one local packet switch today!) you have REAL problems.   The
	    switch is stacking packets and there is a problem on  the  link.
	    If  the  number  indicated here is 0, then all is well and there
	    are no  stacked  packets  waiting  to  go  on  that port.   This
	    indication is only present if the link is actually in-use.    Up
	    to BPQ 4.05e,  only L3/L4 frames are counted and there may be up
	    to  another  8 queued at the L2 link layer.   With BPQ 4.05f and
	    above, the number represents all frames which are queued.


	------------------------------------------------------------

R R

SHEF:GB7YS} Routes:
> 1 G8BPQ-3 150 35!  664835  90992  13%  0  0  06:41  0
> 2 GB7YW 150 32!  505859  38598  7%  0  0  07:24  0
> 6 G0KAP 50 7!  3314  3622  109%  0  0  07:22  0
> 4 GB7RP 150 82!  684960  101188  14%  0  0  07:22  0
> 5 G4LPL 100 1!  45188  2934  6%  0  0  06:42  0
  5 G6WYT-8 10 1  30  25  83%  0  0  07:08
  6 G8BPQ-3 50 5!  459  152  33%  0  0  06:38
> 6 G6KZJ 80 10!  201553  17633  8%  0  0  07:12  0
  5 G4MCC-9 25 2!  61338  59105  96%  0  0  06:34
> 3 G3WNR-3 180 53!  255535  8052  3%  0  0  06:37  0
  4 G0INA-1 10 1  0  0  *  0  0  07:15


	------------------------------------------------------------

LINKS -  These are the links which are currently set up via SHEF and in many
	 cases,  they are L4 (straight-through  datagrams) which do not show
	 on the USERS display but will be indicated on a LINKS display,   or
	 at  least,   the neighbouring nodes to which a link has been set up
	 will be shown.

  SHEF:GB7YS} Links:                         
  GB7RP GB7YS S=5 P=4 T=3 V=2              
  G8BPQ-3 GB7YS S=5 P=1 T=3 V=2
  G3WNR-3 GB7YS S=5 P=3 T=3 V=2
  G0KAP GB7YS S=5 P=6 T=3 V=2
  GB7YW GB7YS S=5 P=2 T=3 V=2
  G6KZJ GB7YS S=5 P=6 T=3 V=2
  G4LPL GB7YS S=5 P=5 T=3 V=2
  
  S=2   Connecting        P is Port Number           T=1  Uplink
  S=4   Disconnecting     V is AX25 Version 1 or 2   T=2  Downlink
  S=5   Connected                                    T=3  Node-to-Node Link


	------------------------------------------------------------

 STATS   Here is a sample STATS display from a very busy packet switch.  You
	 can see from  the  information  that  SHEF  has been running 247203
	 minutes or 4120 hours (172 days) but there have been 17  WARMSTARTS
	 which  are  attributable to power disconnections or glitches.   The
	 important figures are L2 Frames Received  and L2 Frames Sent and in
	 an ideal situation,  these two should be as close to  the  same  as
	 possible.  It indicates the level of retries on that port.  The R R
	 command  gives  a  better  indication and provides a retry count in
	 percentage values.

SHEF:GB7YS} 
Time active (mins)             247203
Warm Restarts                      17
Buffers: Max/Cur/Min/Out          123      118       66        0
Known Nodes                       155
L4 Connects Sent/Rxed            4296     5337
L4 Frames TX/RX/Resent/Reseq   322369   546811     7337      147
L3 Frames Relayed             2475823

L2 Frames Digi-ed          0        0        0        0        0        0
L2 Frames Heard      1653856  1848969  1156432  4152887   716706  1775329
L2 Frames Received   1609878  1809414  1093515  1410445   415905   501643
L2 Frames Sent       1738988  1894114  1123543  1715561   585732   645569
L2 Timeouts           106761   122255    34032   187544   141926    62387
REJ Frames Received    19916     6377     3041    15968      517     3939
RX out of Sequence     43266    23386     2890    22817     1897     3250
Underruns/Poll Tout        0        0       37       37       31       42
RX Overruns                0        0        0        0        0        0
RX CRC Errors        1915970  1897340       15        0        0        0
FRMRs Sent                 1        1        4        5        1        3
FRMRs Received             2        1        0        0        0        0
Frames abandoned           1        1        0        0        0        0
Link Active %          8  14   21  30    0   0    0   0    0   0    0   0


 Time active     This is the amount  of  time  the  switch has run since the
		 software was last restarted or the PC was rebooted.

 Timer Overruns  This is a count of the number of times the main code (which
		 is initiated by timer interrupts) is still running when the
		 next timer interrupt occurred.  If timer overruns increment
		 very rapidly (several times per minute),  it indicates that
		 the PC is too slow  for  the  amount of data which is being
		 processed.   It is normal for an XT class machine running a
		 couple of BBS ports to get about one  overrun  per  minute.
		 An AT class machine will show very few timer overruns.
		 
 Buffers         The Buffer Max/Cur/Min/Out indication  is a dynamic display
		 of the number of buffers available (Cur)  and  the  maximum
		 and  minimum  number  of  buffers  available to the system.
		 Expect between 100 and  135  maximum  buffers on a PC-based
		 system,  depending on the configuration in use.   The 'Out'
		 figure is the number of  times  a  request  to  allocate  a
		 buffer failed because there were none available.

 Known Nodes     This  is  the  number of nodes in the NODES list and should
		 represent a list of distant  packet nodes which your switch
		 has a good chance of reaching.   The nodes list and  'Known
		 Nodes' can be reduced by increasing MINQUAL. 
		 
 L4 Connects     The  number  of  L4  connects  which have been made via the
		 switch in both directions. 
		 
 L4 Frames       The L4  frames  resent  count  is  the number retransmitted
		 because the ACK  wasn't  received  within  the  L4  timeout
		 period.    The Reseq count is the number of frames received
		 but out of  sequence,   but  subsequently  used because the
		 missing frame(s) eventually arrived.
		 
 REJ Frames      A  large  number in the 'REJ received' field  may  indicate
 RXed            that your MAXFRAME is too high.
		 
 RX out of Seq   Similarly,  a large number in  'RX  out  of  sequence'  may
		 indicate  that  the  station  you  are talking to has too a
		 large a MAXFRAME.
		 
 RX Overruns     Indicates  characters  lost  because  the  software  didn't
		 process the interrupts  fast  enough.    If you are running
		 KISS ports,  and you get a lot of RX  overruns,   i.e.    a
		 significant proportion of L2 frames heard, try reducing the
		 speed of the link from the PC to the TNC.  If you are using
		 an HDLC card such as the DRSI PC*PA or PC120,  particularly
		 at high speed, then there isn't much you can do, except buy
		 a  faster  machine.   (G8BPQ would like to hear from anyone
		 having problems running at 9600 baud or above, as he may be
		 able to speed up the routines a bit).
		 
 Underruns/      Indicates a similar problem to RX overruns,  but in respect
 Poll Timeouts   of the software responding to TX interrupts,  however, this
		 only applies to HDLC cards.  As you can't get a TX underrun
		 on an asynchronous port,  this  field is also used to count
		 timeouts on a polled KISS system.
		 
 Frames          Counts the number of frames  discarded  because  they  have
 Abandoned       been  waiting  to be sent (i.e.   waiting for DCD to clear)
		 for more than 60 seconds.  If a lot occur, then either your
		 squelch is not working right (open  squelch  and  SOFTDCD=1
		 gives  better  performance)  or  the  channel is VERY busy.
		 Only used for HDLC cards.
		 
 Link Active     Shows  two  values  for  each  port.    The  first  is  the
		 percentage of time that your station was transmitting,  and
		 the second is the percentage the channel was active (sum of
		 transmitting and DCD activity).    It is only maintained on
		 HDLC ports.   NOTE - If you are using  SOFTDCD,   then  the
		 indicated percentage may be an overestimate.
		  
	------------------------------------------------------------

N *   This  command  gives  a  listing  of  all  the network nodes which are
      reachable from this network node.    In  the  case of SHEF,  all these
      network nodes have a route quality better than 20.  The N * also lists
      all the 'hidden' nodes which begin with a # character,  e.g.    #CHELT
      which would not normally be listed with a NODES (N) command.

SHEF:GB7YS} Nodes:
G1BRB-2            #CHELT:G4PDQ       #LDS:G3WNR-3       #SCUN1:G0KAP-13    
7VALLY:G1DIL       AP21:GB7AP-2       AYINET:G7AYI-1     AYTON:G4HRM        
BADBBS:GB7BAD      BHMBBS:GB7BHM      BM21:G7AXC-2       BM90:G7AXC-10      
BM92:G7AXC-11      BMXBBS:GB7BMX      BNOR72:G6GUH-7     BOB20:G8HBE-2      
BOSTON:G4LPL       BSX:G0BSX-2        CATT:G3EKL         CD21:GB7CD-2       
CD40:GB7CD-4       CLEVE:G8EIA        CYMBBS:GB7CYM      DHM70:G0JEC-7      
DXCHEL:GB7DXC      DXPLEE:G0KVJ-4     DXYORK:GB7YDX      EDG21:G6JVS-2      
EDG22:G6JVS-3      EQTBBS:GB7EQT      FLG:G0FLG-1        FLGBBS:GB7FLG      
FYSBBS:GB7FYS      GLOS:GB7GH         HALFAX:G6KZJ       HELP:GB7TIC-1      
HTLPMS:G1HTL-2     HUDD:G1FYS         HULL21:G8UVQ-2     HULL42:G8UVQ-4     
HULL61:G8UVQ-6     HULL85:G8UVQ-7     IP0307:G8AMD-5     IP041B:GB7SDC-5    
IP1125:G8HBE-5     IRXPMS:G4IRX-1     KANT8:G8BPQ-8      LDSBBS:GB7LDS      
LEEDS:G3WNR        LEIC:G3SDC-8       LTNBBS:GB7LTN      LWBBBS:GB7LWB      
LX2:GB7LX-2        LX4:GB7LX-4        LX6:G4GOU-6        LX7:GB7LX-7        
MALV41:G6MSV-4     MAPPLY:G1HTL-1     MGKPMS:G8MGK-1     MK22:G8CCV-2       
MK42:G8CCV-4       MK72:G8CCV-7       MLVN21:GB7MH-2     MLVN41:GB7MH-4     
MLVN60:G4FPV-6     MLVN72:GB7MH-7     MLVN74:G4FPV-9     MLVN90:GB7MH-9     
MLVN91:G4FPV-7     MRU:G4MRU          MRUBBS:GB7MRU      NEC:G8VPQ          
NEMBBS:GB7NEM      NEWP41:GW4BLE-4    NMCLUS:GB7BPQ      NN:G8AMG-3         
NN22:G8AMG-2       NN41:G8AMG-4       NN72:G8AMG-7       NN74:G8AMG-10      
NN81:G8AMG-11      NN90:G8AMG-9       NOTBBS:GB7NOT      NOTT1:G0INA-1      
NOTT2:G0INA-3      NOTTS:G8BPQ-3      NWILTS:GB7NW       NWNOTT:G1XOW-1     
OAK:G0LTN-1        PE42:GB7PE-4       PE72:GB7PE-7       PLAINS:G4IRX-3     
PMBBBS:GB7PMB      PMBNET:GB7SY       REDDIT:G8MGK       RHB18:G7KEV-1      
RHB22:GB7YM-2      RHB41:GB7YM-4      RHB75:GB7YM-7      RP:GB7RP           
RUTBBS:GB7RUT      RUTLND:G4FIS-2     SAL21:GB7SW-2      SAL40:GB7SW-4      
SAL79:GB7SW-7      SAWLEY:G8XAN-1     SC21:GB7EY-2       SC41:GB7EY-11      
SC74:GB7EY-13      SC83:GB7EY-10      SC91:GB7EY-1       SC92:GB7EY-9       
SCUN:G0KAP         SDCBBS:GB7SDC      SSY:G1SSO          STRD21:GB7ST-2     
STRD41:GB7ST-4     STRD72:GB7ST-7     SUTBBS:GB7SUT      SUTT:G1EQT-8       
SUTTON:G8AMD       SWINDN:G8VRI       SYD21:G4MHV-2      SYD72:G4MHV-7      
SYP:G6TVA          SYPBBS:GB7SYP      TAME80:G4MCC-8     TAME90:G4MCC-9     
TCMBBS:GB7TCM      TICBBS:GB7TIC      TLH2:G1TLH-2       TLHBBS:GB7TLH      
UPTN/7:G8ADH       VPQ20:G8VPQ-1      VPQ90:G8VPQ-10     VPQNET:G8VPQ-8     
WAKE:G0COA         WIL80:G6WYT-8      WN:G7HPM           WORC:G8TIC-1       
WORCS:G8TIC        WP:GB7WP           WP70:G0KNR-7       WP91:G0KNR-1       
WRGBBS:GB7WRG      XANBBS:GB7XAN      XGN:G4XGN-9        XGN20:G4XGN-3      
XGN22:G4XGN-2      XGN90:GB7BD-7      XGN91:GB7BD-1      XGN92:G4XGN-10     
XGN94:GB7BD-8      XOWPMS:G1XOW-2     YORK:G1FTA         YORKS:GB7YW        

	------------------------------------------------------------

I

  SHEF:GB7YS} G8BPQ Packet Switch, Wharncliffe, North Sheffield: IO93fl
	 Kantronics Data Engine running BPQ code in EPROM
	      DX PacketCluster Link and Access Node
		      Sysop: G3VMW @ GB7LDS

 The INFORMATION field for the switch is reproduced above.

	------------------------------------------------------------

 The  following  displays  are  from  the  YORKS:GB7YW PC-based switch which
 supports GB7YDX:


>Sun Aug 2 07:47 1992

USERS

YORKS:GB7YW} G8BPQ Network System V4.05e (93)
Host31(DXYORK:GB7YDX)             <-->  Circuit(SHEF:GB7YS GB7YDX)
Circuit(#LDS:G3WNR-3 GB7MDX)      <-->  Host04(DXYORK:GB7YDX)
Host33(G3VMW)                                     
Circuit(CATT:G3EKL G8ESB)         <-->  Host02(DXYORK:GB7YDX)
Circuit(XGN94:GB7BD-8 G4TDI)      <-->  Downlink(G4TDI-15 G8AWN-8)
Circuit(#LDS:G3WNR-3 GB7DXC)      <-->  Host05(DXYORK:GB7YDX)
Circuit(LEEDS:G3WNR GB7LDS)       <-->  Circuit(CYMBBS:GB7CYM GB7LDS)
Uplink 2(G3TRV)                   <-->  Host06(DXYORK:GB7YDX)
Uplink 2(G0KKZ)                   <-->  Host03(DXYORK:GB7YDX)
Uplink 2(G4ZOY-15)                <-->  Host07(DXYORK:GB7YDX)
Circuit(XGN91:GB7BD-1 G7LKU)      <-->  Circuit(NOTTS:G8BPQ-3 G7LKU)
Uplink 1(G4FUO)                   <-->  Host09(DXYORK:GB7YDX)
Circuit(G4ATZ-5 G4ATZ-5)          <-->  Host08(DXYORK:GB7YDX)
Circuit(WP:GB7WP G0REK)           <-->  Host11(DXYORK:GB7YDX)

	------------------------------------------------------------

R R

YORKS:GB7YW} Routes:
  1 G3EKL 80 22!  54  0  0%  0  0  07:29
> 3 GB7YS 150 87!  4728  357  7%  0  0  07:46  0
> 4 G3WNR-3 150 69!  7999  245  3%  0  0  07:45  2
> 5 G1FTA 140 32!  1337  75  5%  0  0  07:34  0
  6 G3VMW 150 0!  0  0  *  0  0  00:00
  1 G6KZJ 10 1  0  0  *  0  0  07:18
> 1 G4ATZ 10 2  159  0  0%  0  0  07:42  0

	------------------------------------------------------------
 
 By entering N NODECALL (N NODEALIAS),  you can list the  routes  which  the
 system will use to access the remote node.

 N WP

	YORKS:GB7YW Routes to: WP:GB7WP RTT=16 FR=7597 B=3
	> 86 5 4 G3WNR-3
	  60 5 3 GB7YS
	  36 5 5 G1FTA

 Up to three possible routes to the remote  node  are  listed.    The  first
 number  displayed  is  the  'QUALITY' which is the relative desirability of
 using this route rather  than  another.    The second is the 'OBSOLESCENCE'
 count,  and indication of how long it is since the  system  was  last  told
 about (or successfully used) this route.   The number starts at a value set
 in the BPQCFG.TXT file (typically 5) and is decremented each time a 'NODES'
 broadcast  is  sent  (typically every hour) and refreshed by incoming nodes
 broadcasts from adajacent nodes.   The  third  number  is the 'PORT' on the
 switch and the > indicates that the route shown is currently active.

 
 N T    This gives the round-trip time to the node shown in the listing  and
	the  number  of  packet  frames which have been sent to that network
	node.   RTT or round-trip time  is  the  rolling average of the time
	taken to get a response from that node (in seconds) and a good  link
	should return RTTs of better than 10 seconds.   FR means Frames, i.e
	the  number of info frames sent to the node.   The 'B',  if present,
	signifies that the target  network  node  is  a BPQ switch,  and the
	number after the B is the number of link hops to the target node.
	
 

YORKS:GB7YW} Nodes:
G4ATZ-5            RTT=12 FR=9
#LDS:G3WNR-3       RTT=10 FR=5364  B
BOSTON:G4LPL       RTT=30 FR=279  B 
CATT:G3EKL         RTT=20 FR=272  B 2
CLEVE:G8EIA        RTT=23 FR=122  B 3
CYMBBS:GB7CYM      RTT=13 FR=49  B 1
DXPLEE:G0KVJ-4     RTT=26 FR=57
HALFAX:G6KZJ       RTT=25 FR=23  B 
KANT8:G8BPQ-8      RTT=5 FR=5  B 3
LDSBBS:GB7LDS      RTT=8 FR=48
LEEDS:G3WNR        RTT=9 FR=169  B
NOTTS:G8BPQ-3      RTT=23 FR=16  B 2
RP:GB7RP           RTT=9 FR=5  B 2
RUTLND:G4FIS-2     RTT=23 FR=54  B 3
SC21:GB7EY-2       RTT=21 FR=52
SCUN:G0KAP         RTT=161 FR=161  B 
SHEF:GB7YS         RTT=11 FR=2500  B 1
WAKE:G0COA         RTT=14 FR=172  B 
WP:GB7WP           RTT=16 FR=522  B 3
XGN22:G4XGN-2      RTT=27 FR=18
XGN94:GB7BD-8      RTT=16 FR=21
YORK:G1FTA         RTT=3 FR=8  B 1

	------------------------------------------------------------

INFO

YORKS:GB7YW} GB7YW Packet Switch, Bramham, Wetherby, West Yorkshire: IO93hv
	       DX PacketCluster Link and Access Node
		      SysOp: G3VMW @ GB7LDS

    The CLUSTER command connects you to the GB7YDX DX PacketCluster.

		       
-
**********************************************************************
	   * * * * C:\SYSOPS\LTRS\JA7RHJ.LTR * * * * 
**********************************************************************
-
Hi Jay,

I wanted to download the latest version PacketCluster software, but didn't.
I found a bug in the communication software I am now using.  The problem is
that Z-modem doesn't work properly.  I will try next time.

By the way, a friend of mine Kenny, AH0K wrote a small software with a full of
fun.  Very good for CT training to prepare for CW contest.  Original document
is written in Japanese, so I tried to translate.  Might be a poor translation.
Anyway, please try it.

Regards,

					  - BEAR -  Yasushi  Kumagai
						     JA7RHJ / AA6PU


<<<BEAR,
   The CT trainer is "gang busters" (Wonderful!).  It is posted on 
DX-BBS as CTMODOKI.ZIP.  Please let AH0K know how much his work is 
appreciated.
   73,  Jay
>>>
-
**********************************************************************
	   * * * * C:\SYSOPS\LTRS\KC8MK.LTR * * * * 
**********************************************************************
-
Dear Jay:

I hope that things are going well for you out there this summer. It has been
an unusual summer here, we have only had a couple of days over 90. As far
as I am concerned, it can stay this way.

I have a number of things I want to try and cover with you, in no particular
order:

1) UPDATE/QSLNEW   I have noticed for quite some time if you add a listing
   to QSLNEW, on the last line you send, if you put a CTRL/Z at the end
   of the line, instead of on a separate line, you do not get the data
   on that last line to appear in the update. Not a real big problem, but
   something that I have noticed.   It works fine if the CTRL/Z  (and of
   course /EX) is on a separate line.

<<<Yes, BIG PROBLEM.  I mentioned it in READ150 this month. >>>


2) G8BPQ    When a user disconnects, the user does not always get a disconnect
   frame from the cluster. The user receives the CUL message, and then
   nothing. He is no longer shown connected, but no disconnect is ever 
   sent. I have seen this problem several times, and my users have commented
   on it. It did it in 405b, and still does it in 405e.

<<<BPQ406 seems to fix this>>>

3) DXNODES DATABASE   Please pass along the following corrections to the DXNODES
   database as it relates to Ohio. I don't think he has been updated in quite
   some time about Ohio, and there have been some changes.
   
   Mansfield      KN8COQ   off the air since 10/91.
   Westerville    KC8MK    144.950* 145.590* 446.975* 445.500** 433.625**
   Erie           K3TUP    IS IN PENNSYLVANIA
   Findlay        N8ET     144.95
   Toledo         W8HHF    ?

<<<Too late to get into this months.  The best way to get DXNODES data to
   NV6Z is to send a message to him on DX-BBS.  I'll extract this and 
   send it to him, but unfortunately he has already uploaded the new file
   for this months distribution.>>>


I think I should be ready to try and upload to you via modem next month. I tried
your suggestion about loading the information as soon as I receive it, and then
going back again (I operate KC8MK remotely) for the GODISK info this month. I
didn't get any feedback from my users that they noticed anything different, so 
they are all either asleep or silent. I am never quite sure which.

<<Both?  (Hi)  73, Jay>>

73, Jim

-
**********************************************************************
	   * * * * C:\SYSOPS\LTRS\WA2TVE.LTR * * * * 
**********************************************************************
-
Jay, I think I may have goofed. I think all is ok with the files I 
am sending you but its possible that some files are not there. I will
make sure next time. Also as you can see my opernam.dat file
is growing very large. I have tried UNLOAD OPER OPER.ASC NOSORT and it 
runs out of memory. Can you suggest a way to clean it up? Maybe you have 
a few files you can send me with the next disk that will help.
THx Howie WA2TVE

<<<Howie, you might try OPSORT.  I'll experiment with your file after
   I get GOIDISK to bed for this month, and I'll put a note with your
   disk if I come up with anything more.>>>

-
**********************************************************************
	   Messages from DX-BBS GODISK Conference:
**********************************************************************
-
Date: 08-15-92 (22:29)              Number: 1066 of 1173
  To: ALL                           Refer#: NONE
From: W6GO                            Read: (N/A)
Subj: GATEWAY, VERY-LIMITED         Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

The "gateway" or "very-limited protocol" features used by SYSOPs who are
linking on HF is now included in PacketCluster.  It is in Version 5.4-21
and some previous.  AK1A has uploaded the description file and I have
posted it here on DX-BBS as GATEWAY.ZIP.
   73, Jay


Date: 08-16-92 (05:25)              Number: 1068 of 1173
  To: K5EJ                          Refer#: NONE
From: W6GO                            Read: 08-16-92 (19:10) HAS REPLIES
Subj: WD5B                          Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi EJ,
   I received an inquiry here from WD5B.  He is asking about getting the
QSL Manager data on his node, and I have responded to him.
   However, as he is shown as a remote node in your system, he should be
able to access the data on K5EJ and not need a redundant installation on
his node.  Of course, that assumes that your connection is a reasonable
one.
   Can you shed some light on this?
      73, Jay

Date: 08-16-92 (13:40)              Number: 1070 of 1173
  To: WA5PIE                        Refer#: 1054
From: AK1A                            Read: 08-29-92 (14:13)
Subj: HAMCALL UPDATE?               Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Rick, I'll put it on here as soon as I receive it from Buckmaster...
haven't heard from them yet.
73, Dick

Date: 08-16-92 (19:10)              Number: 1071 of 1173
  To: W6GO                          Refer#: 1068
From: K5EJ                            Read: 08-16-92 (20:27)
Subj: WD5B                          Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

yes..rich is about 100 miles south of me in conway..I have a good link
to him..i get with him on getting set as a remote node...tnx..E.J.

Date: 08-16-92 (20:30)              Number: 1072 of 1173
  To: AK1A                          Refer#: NONE
From: W6GO                            Read: 08-24-92 (18:54)
Subj: V6 ENHANCEMENT                Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Dick..
   As we have discussed, we need the ability to maintain the FILTERS
file.  An editor would be nice, a means to compare it with OPERNAM.DAT
and delete records which are older than a time you would specify, a way
to review exactly what the users have set as filter values, etc.
   At the minimum, we need the details on the file format so that
external editors/processors could be written.
   73,  Jay

Date: 08-17-92 (05:08)              Number: 1073 of 1173
  To: SYSOP                         Refer#: NONE
From: WA0PUJ                          Read: 08-17-92 (05:44) HAS REPLIES
Subj: COMMENT (1)                   Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay, I now have ProComm Plus up and working and it seems to work very
well, especailly, Z-Modem.   Hmmmmmmmm.....just like you said it would!
By the way, I have heard 14th hand or so that the ARRL is recommending
to the FCC to eliminate unattended operations.  I have absolutely NO
IDEA what is involved, but if that is indeed true, It will virtually
shut down PacketCluster operation as we know it, at least on the HF
links.  Maybe some new and better rules are in the works.  I hope we get
to comment on the NPRM! if that is the case.  Again, I have just heard
rumors, and likely they are distorted.  I have NOT seen ANYTHING in
print.
73, Glenn WA0PUJ

Date: 08-17-92 (06:39)              Number: 1075 of 1173
  To: WA0PUJ                        Refer#: 1073
From: W6GO                            Read: 08-20-92 (06:16)
Subj: COMMENT (1)                   Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Glenn,
   I've made your message public so others can participate in the
"thread" you raise.  Before I get to that, congrats on Procomm+.  I'm
pleased that you like it!
   On the HF packet.  As I understand it, and I may be incorrect, the
ONLY legal unattended HF packet is that run by the people identified in
the Special Temporary Authority negotiated some years ago by the ARRL
with the FCC.  As I understand it, the ARRL does not intend to attempt
to renew that STA, and has had second thoughts about HF packet in
general.  Some people contend that is because the ARRL feels it would
negatively impact their National Traffic System.
   If what I believe is actually true, most of the present unattended HF
packet is not legal because the stations involved are not listed in the
STA.  I don't understand how a rule change will shut down something that
is illegal in the first place.  Why should it stop?
   I'm going to attempt to get some more details including the list of
people authorized by the STA.  If I succeed, I'll post it here.
   73,  Jay

Date: 08-17-92 (09:41)              Number: 1076 of 1173
  To: AK1A                          Refer#: NONE
From: WP4K                            Read: 08-24-92 (18:54)
Subj: PC.LOG                        Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi, Dick hope all is Ok and that V6 is coming along fine, I'm leaving
thismsg here hoping there could be something you can do for me, you see
since V5.3xx, I have been having this weird problem, after an
undetermined amount of time the"sh/log" command will not work from the
console, after mentioning it to Jay, he suggested to clean the
records,created a newlog and that seem to work for quite some time. Then
when I upgraded to 5.4-19 it came back, bue now the users could not use
it neither, and when I went to check I couldn't either, not even ALt-L
will work. The only thing I noticed was thosefiles that grow on The PC
directory, which are named with numbers and none .XXX; this was strange
so I ran NDD, and it came back telling me that there were splitt data in
these files and I let get corrected, but this files keepshowing and with
time they keep growing,usually  I just erase them, and reboot the PC,
then the sh/log command will work ok for some time and then will stop
working. This can happen any time one hour after re-boot, 15 min. or 10
hrs. Then it will work again ans so on. Can you suggest something,is
getting to be a pain,you know. If you need more Inf, can call me at the
offiec at 809-721-3333 1100Zto2000Z, or leave a msg here I ll chkevery
morning...
Thanks, and keep it coming..........

Date: 08-17-92 (14:22)              Number: 1077 of 1173
  To: SYSOP                         Refer#: NONE
From: N6ND                            Read: 08-17-92 (15:40) HAS REPLIES
Subj: COMMENT (1)                   Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay, got a new Boca 14400 modem and so for, it seems to work OK.
It is set up on Com3, IRQ5 and does transfers at abt 1640 cps.  73

Date: 08-17-92 (15:40)              Number: 1078 of 1173
  To: N6ND                          Refer#: 1077
From: W6GO                            Read: 08-26-92 (20:23)
Subj: BOCA 14400 MODEM              Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Rick,
   That's great!  I wonder if they fixed some firmware problem or
perhaps your machine doesn't have the conflicts of the machines I tried
mine in before I sent it back.  I'm very pleased with my Lightning
14400, and it IS a half-card, not like BOCA that advertizes half-card
and it won't fit in a half-card slot!
   The price is sure great on the Boca you have, and if you get it
working, as you have, then you can't lose!
   73,  Jay

Date: 08-17-92 (17:14)              Number: 1080 of 1173
  To: VE3CDX                        Refer#: NONE
From: W6GO                            Read: 08-18-92 (05:22)
Subj: CLUSTER MAPS                  Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Barry,
   Those maps you uploaded are great.  They are on DX-BBS as
CLUSMAPS.ZIP, just as you uploaded them.  How can we keep them
up-to-date?  Are you maintaining a master set?  If so, are you
soliciting maps from other areas, perhaps even those not presently
linked via HF?  If you don't mind, I would prefer to run all maps that
might come in here to you and twist your arm to upload a new set each
month for distribution.
   If it makes sense, it would be easy to set up a system where you
could have your own conference here and receive uploads without my
intervention.  You would be SYSOP of the VE3CDX conference on DX-BBS.
   Lets discuss?  These maps are something EVERY SYSOP should have for
reference, along with the DXNODES database.  BTW, if you expected the
users to have access to the DXNODES database, you could probably leave
some data off the maps, perhaps making them a bit "less busy".
   Thanks for sharing these with us!
      73,  Jay

Date: 08-17-92 (20:38)              Number: 1081 of 1173
  To: W6GO                          Refer#: NONE
From: N5JKN                           Read: 08-18-92 (05:59) HAS REPLIES
Subj: HIGH SPEED CONNECT            Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay,
I was unable to get a high speed connect negoated by my modem this
time. I was able to force 2400 baud and then force 9600 baud, but
the modem was never able to negoate a high speed connect. This is the
first time that has happened. Have you made any changes? ie Modem,
telephone line, modem parms, etc.

73, Tom - N5JKN

Date: 08-18-92 (05:11)              Number: 1082 of 1173
  To: SYSOP                         Refer#: NONE
From: KN4HW                           Read: 08-18-92 (06:00)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay..  I had my call chged from KN4HW to AC4TN.  Please adjust your
records accordingly.  Tnx!  I will send you a note abt this GVC 14.4
modem on a later date, still putting it thru it's paces first..
tnx, 73.  Dave, TN

Date: 08-18-92 (05:35)              Number: 1083 of 1173
  To: SYSOP                         Refer#: NONE
From: VE3CDX                          Read: 08-18-92 (06:00)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay
Just afew things before I get here.
Firstly I'm sorry I had to depart the phone so fast yesterday
afternoon but the customs inspector was looking at me kind of funny
because I was sittting in the bay and talking on the phone..hi!
I spoke with Rich KI3V re TheNet and he is going to be in touch
with you. I will BETA test it here also.
I uploaded another file to you this time but forgot to join GODISK
first. Its called DX_CDX and is a rundown on the spots on my
cluster since the first of the year. Its mainly for your info but
if you think its of general interest then put it on the board.
Speaking of stats I find the USERSTATS very interesting and will
be making noises to the appropriate people..hi! I saw the note
last time and to be honest meant to look at them but then forgot.
Thats it for now I think. I have the file you asked me to get so
will read and act as required.
Thanks again Jay.
Cheers....Barry

Date: 08-18-92 (05:59)              Number: 1084 of 1173
  To: N5JKN                         Refer#: 1081
From: W6GO                            Read: 08-19-92 (12:23) HAS REPLIES
Subj: HIGH SPEED CONNECT            Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Tom,
   I received a phone call today which related a similar problem.  I
cycled the power to the Hayes Ultra 14400 modem and all seemed ok.  This
is the second time this has happened recently.  This is a new modem
Hayes sent me with the latest firmware.  I'm going to see if I can get
them to replace it.
   Please let me know if it seems normal the next time you connect.  If
not, please call me on the phone and I'll cycle it.  One more time will
be conclusive for me!
   73,  Jay

Date: 08-18-92 (17:03)              Number: 1085 of 1173
  To: W6GO                          Refer#: NONE
From: K4CEF                           Read: 08-18-92 (21:07) HAS REPLIES
Subj: CONNECTION                    Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay,
Saw another message on the board to you about someone having
some difficulty with negotiating a high speed connect in last
few days--I sometimes see that also--did last nite--tried calling
twice and could not get a 9600 connect negotiated in the time
before the carrier dropped--all seems OK today. Thanks for your
help in getting problems resolved that 5.4-23 fixed--seems like
it is working great here so far.
73, Bart

Date: 08-18-92 (21:07)              Number: 1087 of 1173
  To: K4CEF                         Refer#: 1085
From: W6GO                            Read: 08-20-92 (16:41)
Subj: CONNECTION                    Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Bart,
   Please let me know ASAP if you see that condition again.  I think you
had the problem when I cleared it by recycling the modem.  If there is
ANY more indication of a problem I will switch the modems again between
my work computer and the BBS.  Thanks for the info!
   73, Jay

Date: 08-19-92 (05:47)              Number: 1088 of 1173
  To: AK1A                          Refer#: NONE
From: W6GO                            Read: 08-24-92 (18:54)
Subj: V6 ENHANCEMENT                Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Dick,
  This is a two-part request dealing with the homenode flag in OPERNAM.DAT.

  1.  I would like the "homenode set" flag to appear next to the homenode
call in SH/ST.  If the flag is set, then add the  5 characters "(set)"
to the homenode call.

  2.  I would like a way to unset that flag, such as the syntax
SET/NOHOME_NODE/USER=usercall, allowing it to revert to the last connected
homenode.  This should propogate to all nodes.  The user would also be able to
remove the flag with SET/NO_HOME_NODE.

73, Jay

Date: 08-19-92 (12:23)              Number: 1089 of 1173
  To: W6GO                          Refer#: 1084
From: N5JKN                           Read: 08-19-92 (15:22) HAS REPLIES
Subj: HIGH SPEED CONNECT            Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay,
Everything was OK this time. Go a high speed connect with no problem.
Thanks.

Tom - N5JKN.

Date: 08-19-92 (14:01)              Number: 1090 of 1173
  To: W6GO                          Refer#: NONE
From: K1XX                            Read: 08-19-92 (15:25) HAS REPLIES
Subj: BPQ S/W...WHAT ELSE           Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay - a question for the multitudes....one of our Packetcluster nodes
is having problems getting 6 ports running with the bpq s/w.  He
currently has version 4.05e of G8BPQ and 5.4-21 of Packclus.  Is anyone
running more than 4 ports on G8BPQ?  The most any one of our nodes has
running is 4 ports.   Thanks  Charlie K1XX

Date: 08-19-92 (15:25)              Number: 1091 of 1173
  To: N5JKN                         Refer#: 1089
From: W6GO                            Read: 08-22-92 (12:16)
Subj: HIGH SPEED CONNECT            Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Yep!  Thats because I put in the "old" Hayes Ultra 14400 V1.0.  The V1.1
modem quit again yesterday and it is not going back into the BBS!  I'm
negotiating now with Hayes for a replacement.

Thanks for your patience!

73, Jay

Date: 08-19-92 (15:26)              Number: 1092 of 1173
  To: K1XX                          Refer#: 1090
From: W6GO                            Read: 08-20-92 (12:09)
Subj: BPQ S/W...WHAT ELSE           Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Well....
   As you can see from the CFG file in my system which is included in
BPQINFO, the W6GO node runs 6 ports, 5 of which are active.  How
aboutuploading his CFG file?  I'll be glad to review it.
   73, Jay

(No guarantees, you get what you pay for, hi!)

Date: 08-20-92 (05:28)              Number: 1095 of 1173
  To: SYSOP                         Refer#: NONE
From: WS7I                            Read: 08-20-92 (05:26) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay,

Trying out a Gateway 2000 14.4.  Works pretty good but very long time to
achieve connects.

73, Jay

Ws7i

Date: 08-20-92 (05:26)              Number: 1096 of 1173
  To: WS7I                          Refer#: 1095
From: W6GO                            Read: 08-24-92 (02:27)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

V.32bis negotiations take 30 seconds or so unless you set both modems up
to ONLY accept those speeds.  It's what price you pay for compatibility.

However, once you get going, they really get going!

73, Jay

Date: 08-20-92 (06:18)              Number: 1097 of 1173
  To: SYSOP                         Refer#: NONE
From: WA0PUJ                          Read: 08-20-92 (06:26) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Sorry I royally goofed up your process last month.  I was trying to get
on the 100% club, but only ended up in the 0% club!!!  I PROMISE to
follow directions EXACTLY.  39 lashes for me!
73, Glenn

Date: 08-20-92 (06:26)              Number: 1098 of 1173
  To: WA0PUJ                        Refer#: 1097
From: W6GO                            Read: 08-24-92 (02:05)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Apology accepted!  Last month was a frustrating one for problems, and
in re-reading my comment to you it seems (now) like I overreacted a bit.
 So, based on that, you can take back 6 of those 39 lashes you decreed.

73,  Jay

Date: 08-20-92 (15:15)              Number: 1099 of 1173
  To: AK1A                          Refer#: NONE
From: W6GO                            Read: 08-24-92 (18:54)
Subj: V6 ENHANCEMENT                Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Dick..
   How about a minor change to the SH/LOG lookup.  As it is now, if I do
a SH/LOG W6OA, it returns log entries for W6OA and W6OAT because it
finds the W6OA string in both callsigns.  I offer two solutions in order
of my preference.

1. Assume a space after a SH/LOG that has no recognizable qualifier,
i.e., a SH/LOG callsign.  In that way you would always be looking for
the specified callsign plus a space and you would only get the requested
callsign.  The downside is that if ANYBODY has created some
downstream process that depends on your implied wild card which follows
the callsign, that downstream process will now fail.  I suggest that
you accept a "*" as the last character of the callsign to switch it back
to its present condition, thus providing the present functionality but
requiring the * to signify that you stop the match before the implied
space would be added.

2.  (workable but not preferred) Accept a space as a valid character in
a lookup. The downside is that users would have to be told to append a
space to this lookup only, making it different than SH/ST callsign and
others.  Users assume that SH/LOG is a lookup rather than a search (even
though they may not know the difference,hi) and report the find of
several callsigns as a bug.

   73,  Jay


Date: 08-21-92 (02:18)              Number: 1101 of 1173
  To: W6GO                          Refer#: NONE
From: K4CEF                           Read: 08-21-92 (06:42)
Subj: COPY OF MESSAGE TO AK1A       Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Dick,

Looks like when we fix one thing on the Cluster, we break another.
Version 5.4-23 fixed a buncha good things, but SEND/COPY now no
longer works where the recipient is an embedded Distro list...I
have a list called NORTH where the primary call is KB4HU and then
an embedded distribution list that should be added to the bottom
of the message. SEND/COPY msgnr NORTH now sends it to the correct
primary call (KB4HU), but no distro list gets added. SEND NORTH
sends the message correctly...Can you take a look? This is a
feature we use all the time...
73, Bart

Date: 08-21-92 (12:33)              Number: 1102 of 1173
  To: W6GO                          Refer#: NONE
From: WB8ZRL                          Read: 08-21-92 (15:15)
Subj: ROUTE COMMAND COMMENTS        Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Some comments on the R R questions.  Using your example:

> 6 WA7G-1 10 1  5823  1313  22%  0  0  16:49  0
> 4 N6IXX-3 10 1  19  4  21%  0  0  16:31  0

The ">" shows that the route is in use for.

The "6" is the port number, and the call is the call of the node on
that port.

The "10" is the QUALITY of that route.

The "1" is the OBSOLENSCENCE, and if followed by an "!", it indicates
a LOCKED ROUTE.

The "5823"  is the number of packets (sent/received/both???) since
startup/or   R R Z.

The "1313" is the number of the packets deemed in error.

The "22%" is the percentage of those packets in errors.

The next two numbers are unknown and I have never seen them non-zero.

The "16:49" is the last time that WA7G-1 sent his node-list info.

The "0" is (I think) the number un packets queued to send.  It will
not be there if the route is not active (">").

I specifiy my two nodes in the BPQCFG.TXT file under ROUTES:.  I also
specifiy MAXROUTES=2 to limit the routes to exactly these two.

On another subject, I had some random problems with the SWITCH
randomly disconnecting an adjacent cluster node.  To fix, insure that
PacketCluster parameter PC50TIMER is less than BPQ parm IDLETIME.  It
seems the DEDHOST does not send the nulls every 11 minutes when the
connect is done from my computer (this is true for users as well as
other cluster nodes).  When the connect is initiated from the other
side, then the nulls get correctly sent.

  73  Tom  WB8ZRL

Date: 08-21-92 (18:04)              Number: 1103 of 1173
  To: ALL                           Refer#: NONE
From: W6GO                            Read: (N/A)
Subj: BPQ DISCONNECT PROBLEM        Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

RE: BPQ 405e, DEDHOSTs, PacketCluster.

   I have had reports of "slow disconnects".  That is, the user
types "B", PacketCluster says CUL, but a disconnect is never
received by the user and the connect stays up to the PacketCluster
node.  I've tried many times to recreate this problem but I've been
unable to cause it myself.  I finally trapped one, thanks to K6PBT,
and I would be interested in hearing from other SYSOPs who have
experienced the same problem or can shed light on the subject.

   I have a monitor log session saved which was captured by a
monitor TNC not connected to the node, and I have the console log
for the same period of time saved.  Here's the upshot of the
analysis:

   User types B, CUL packet is sent, but no disconnect frame.  The
node and the station continue exchanging polling frames forever at
an interval set by the T3 timer (in my case T3=300, so it is every
300 seconds, or 5 minutes).  The user does not appear on the BPQ
USER display.  The BPQ LINKS command, however, shows the link.  The
link display for the link is shown as "S=4 P=1 T=1 V=2".  The S=4
indicates the link is "disconnecting".  It is the only link in the
link display shown with a status of anything other than S=5, which
means "connected".

   I had the user turn off his radio.  The first time a polling
frame was not received back from the user, a disconnect frame was
sent.  Then, after retry-number of disconnect frames, the link
was dropped by BPQ.  Note the unusual: The polling frame was NOT
retried!  The first disconnect frame was sent 10 seconds after my
node sent the polling frame to the user that was not answered.  If a
user who is link status 5 goes away, the polling frame retries
retry-number of times before disconnecting the user.

   My conclusion is that BPQ has been told to disconnect this
connection, and BPQ receipts for that instruction by showing the S=4
in the links table.  But, for some unknown reason, BPQ doesn't
follow through with the disconnect.  It looks to me like a problem
in BPQ, but as I don't claim familiarity with the AX.25 link state
indicators,  I would appreciate comments from any and all,
especially our UK SYSOPs who can ring in BPQ himself.

   73, Jay

Date: 08-21-92 (23:59)              Number: 1104 of 1173
  To: AK1A                          Refer#: NONE
From: W6GO                            Read: 08-24-92 (18:54)
Subj: V6 ENHANCEMENTS               Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Dick..
   I found a file dated 2/20/92 which included these suggestions for V6.
They are repeated and amplified below:

1. Security and privilege levels - table driven on a user callsign
basis.

2. Scroll-back buffer in monitor window, ability to capture from
buffer and write all or part to a file.

3. Scroll-back buffer in SYSOP output window, ability to capture
from buffer and write all or part to a file.

4. Interface to PCBoard via Lantastic.  Allow dial-in to local node,
password access to actually connect (requires amateur license), allow
access to PCBoard from PacketCluster.

5. Multiple nodes via Lantastic.  Data exchanged via temporary files.

6. Database control, PRE/POST files::
There should be an imbedded command which can be included in a database
record which would disable the PRE file or the POST file (or use both to

disable both) for just the display of that record.  For example the
record
#INF is shown below:

#INF
@NOPRE
@NOPOS
This is a database which is used only for test purposes and
carries no useful information
&&

The @NOPRE disables the #PRE record or PRE file for THIS RECORD ONLY.
The @NOPOS disables the #POS record or POS file for THIS RECORD ONLY.


7. User output format imbedded commands:
There should be a host of commands which can be imbedded into any record
or file, like @more@ in the middle of the record would cause a pause in
display waiting for user input.  The PCBoard commands below would be a
very good starting point. Note that these commands should only work if
in UPPER CASE.  In that way, messages can be sent over PacketCluster
which discuss the commands without causing them to take effect.  Recap:
lower case does nothing, upper case causes the desired effect, in
anything displayed to a user, even a mail message.  Note that these are
described in lower case so that if they are implemented this file will
be displayed exactly as you see it.


@more@
------
Causes a "more?" prompt to be displayed to which the caller may type
"Y", "N", "NS" or simply press ENTER to continue.

Note that if @qoff@ is also used the "more?" prompt will be instead
turned into a "press enter to continue" prompt where the only option
is to press the enter key.


@pause@
-------
Causes a "more?" prompt to be displayed to which the caller may type
"Y", "N", "NS" or simply press ENTER to continue.  The @pause@
command differs from the @more@ command in that it uses a timer and
if the caller fails to type anything before the timer expires then
it will automatically continue as if the caller had pressed enter.

Requires SET/pause_timer nn (default 30 for 30 seconds) command to
modify the length of the timer.

Note that if @qoff@ is used the "more?" prompt will be instead turned
into a "press enter to continue" prompt where the only option is to
press the enter key or wait for the 10 seconds to expire.


@poff@
------
Turns "more?" prompts off.  This disables the normal "line counting"
which enables PacketCluster to pause the output after the user's
screen has filled up.  The entire file (up to a @pon@) is sent to
the user.


@pon@
-----
Turns the "more?" prompt back on.


@qoff@
------
Turns regular "more?" prompts into "press enter to continue"
prompts. The reason why might want to use this command is to force
the caller to go completely thru a file or a subsection of that
file.  For instance, if placed at the top of the BULLETIN file with
@qon@ after the first 30 lines in the file you could force the
caller to read the top 30 lines after which he would get the normal
"more?" prompt to which he could answer "N" and stop the display.


@qon@
-----
cancels @qoff@


@wait@
------
Causes a "press enter to continue" prompt to be displayed to which
the caller's only response is to press the enter key to continue the
display.


73, Jay

Date: 08-22-92 (13:55)              Number: 1105 of 1173
  To: SYSOP                         Refer#: NONE
From: N6VB                            Read: 08-22-92 (15:20) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Is there an updated WPXLOC.RAW file out there that has the latest
prefix updates i.e.  9A  ? The latest one I see is April.
Also....what is the name of the file that has the list of all
available files for download ?  I know I read that somewhere but
failed to write it down.

Also....do you have any more of those $20 state machines for
the DRSI boards ?

Thanks! 73   Scott N6VB

Date: 08-22-92 (16:40)              Number: 1108 of 1173
  To: KC4LWI                        Refer#: 1107
From: W6GO                            Read: 08-23-92 (18:55) HAS REPLIES
Subj: BPQ LOCKUP PROBLEM            Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi John..
  I've moved your message to the GODISK conference so as not to "more
befuddle" the non-PacketCluster SYSOPS, hi.
  You have both BBS and NODE set to 0.  That means you don't accept
connects, period.
  You might like to refer to my BPQCFG.TXT which is included in
GO-BPQ2.TXT.  You will see BBS=1, NODE=0.  This is because I don't want
users accessing my station as a switch, only as a "BBS" (PacketCluster).
  I don't have any idea exactly what is SUPPOSED to happen if you set
both of these parms to 0, because there isn't an application I can
think of that would set them that way.  Pethaps you have identified
that for us!
  I didn't look any farther in the CFG file once I noted this condition.
  Please leave this message active with the original message, so that
others won't comment on the same item.
  73, Jay

Date: 08-23-92 (18:55)              Number: 1109 of 1173
  To: W6GO                          Refer#: 1108
From: KC4LWI                          Read: 08-24-92 (03:38)
Subj: BPQ LOCKUP PROBLEM            Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

   I looked at the Real BPQCFG.TXT and the BBS was set to 1... Guessed
I messed that one up somehow... As long as the problem exists I will
leave these messages so that it keeps a good thread of what is going on.
73's - John

Date: 08-24-92 (10:38)              Number: 1110 of 1173
  To: ALL                           Refer#: NONE
From: WP4K                            Read: (N/A)
Subj: HARD DISCONNECT (BPQ)         Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

HELLO EVERYONE, WE ARE EXPERIENCING AN ANNOYING AMOUNT OF HARD
DISCONNECT OF USERS AT RANDOM TIMES,3'5'10 MINUTES. WE ARE USING
XT/10MHZ/BPQ405E/PCV5.4-21..... THERE IS A NODE/BBS OPERATION AND THE
USAGE ISMODERATE/SLIGHT. STILL EVEN IS THERE IS ONE USER IT ALSO GETS
HARD DISCONNECT. WE ARE PLANING ON UPGRADE DE HARDWARE BUT WILL LIKE TO
CLEAN THE ACT AS MUCH AS POSSIBLE, I'M INTERESTED ON SEEN SOME TIMING
CFG. SINCE I BELIEVE THE REASON IS THERE.
ALSO, CAN SOME ONE EXPLAIN TO ME(I CAN'T FIGURE IT OUT) WHY IS'T THAT
EVEN WHEN YOU SET-UP ON BPQCFG.TXT FOR YOUR TXD, ON PORTS, IF YOU GO TO
*SYSOP AND CHECK YOUR PORTS TXD#, IT ALLWAYS IS ON 1 AFTER A REBOOT, I
ALLWAYS GET IT TO MATCH PORT, BUT THEREARE SOME TIMES I'M NOT HERE?
ANY COMMENTS.

Date: 08-24-92 (11:45)              Number: 1111 of 1173
  To: W6GO                          Refer#: NONE
From: WB8ZRL                          Read: 08-25-92 (05:01) HAS REPLIES
Subj: R R CORRECTION                Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay - I sent you a msg last week attempting to explain the R R
display. I had an error in there.  The fourth number, a "1" in your
example, was in error.  Instead of "Obsolesence", it should be as
follows:


The "1" is the number of nodes reached through WA7G-1, and if
followed by an "!", it indicates a LOCKED ROUTE.  (A value of "1"
seems to indicate that WA7G-1 is the 'end of the line'.)

Sorry for the mistake.    73/dx  tom

Date: 08-24-92 (16:25)              Number: 1112 of 1173
  To: W6GO                          Refer#: NONE
From: K1XX                            Read: 08-25-92 (05:01)
Subj: BPQ, AGAIN                    Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay - another bpq question.  I'm currently using 4.05e and am having
a problem with stations going into the "disconnecting" state.  Once in
this state, I can not get them out of the links table without a complete
computer reset.  I thought setting T3 > 0 would cycle a timer by those
stations caught in this state and delete them from the links table.  The
only other clue might be the fact that the station is using V1 protocol.
Do you or others have any thoughts?  Thanks  Charlie K1XX

Date: 08-24-92 (16:37)              Number: 1113 of 1173
  To: W6GO                          Refer#: NONE
From: K1XX                            Read: 08-25-92 (04:56)
Subj: BPQ                           Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay I just read message 1103 after entering my new one conerning the
problem with disconnecting stations.  The station that has this
problem the most frequently reports the same symptom of not receiving a
disconnect message.  I'll try to trap the data and see what I can come
up with.  Charlie

Date: 08-25-92 (05:01)              Number: 1114 of 1173
  To: WB8ZRL                        Refer#: 1111
From: W6GO                            Read: 08-28-92 (12:07)
Subj: R R CORRECTION                Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Thank you!  Now, why doesn't it work in BPQ 405E?
   73, Jay

Date: 08-26-92 (20:36)              Number: 1115 of 1173
  To: W6GO                          Refer#: NONE
From: N6ND                            Read: 08-27-92 (03:34) HAS REPLIES
Subj: HOMENODE LISTING              Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay, quick note abt the Homenode Listing for San Diego.  N6ND is
located at Pt. Loma and serves central San Diego and points south to
TJ.  KD6HRO is located at my home in Ramona, (my son's call) and is
a Limited Cluster used to link ND and K6JYO.  N6CDA is also a Limited
Cluster that is on occasionally but is served by KD6XM as far as the
GO list is concerned.  73...Rick

Date: 08-27-92 (03:34)              Number: 1116 of 1173
  To: N6ND                          Refer#: 1115
From: W6GO                            Read: 09-01-92 (21:24)
Subj: HOMENODE LISTING              Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Thanks, Rick,  I'll puzzle that out when I process the September data.
Hopefully I'll get it right!  This homenode business is somewhat like
nailing jelly to a tree, hi!
   73, Jay

Date: 08-27-92 (13:07)              Number: 1117 of 1173
  To: W6GO                          Refer#: NONE
From: N8HTT                           Read: 08-28-92 (06:53) HAS REPLIES
Subj: FILES                         Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay,
Just wanted to let you know of a problem I had with the files you mailed
on the disk..They involved the contest.zip and dealer.zip.
When the unzip process was about over, my printer started up and did a
print screen, then the computer locked up. Onl;y did it on theoe two
giles...
TNX FOR SAMPLE DX-BBS   HELPED A LOT... YES I am SHOUTING IT>
73 ED

Date: 08-27-92 (22:50)              Number: 1119 of 1173
  To: SYSOP                         Refer#: NONE
From: KJ9D                            Read: 08-28-92 (07:16) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay, Is there a GODISK file for me to download?  Someone in our club
was supposed to have paid for it back at Dayton.  I just was told this
the other day.  "hey, how cme we dont have the golist?"  Anyway, I could
not find it to download, however I may be missing something.  Will try
again tonite after 0500z.
73-Joe/KJ9D

Date: 08-28-92 (06:53)              Number: 1120 of 1173
  To: N8HTT                         Refer#: 1117
From: W6GO                            Read: 09-01-92 (10:22)
Subj: FILES                         Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Ed..
  Sorry about the disk.  Several people reported one or two files zapped
this month.  Guess the postoffice was running a vacuum or a floor
polisher again next to the mail bags.  Hope you were able to download
replacements ok.
  73, Jay

Date: 08-28-92 (07:16)              Number: 1121 of 1173
  To: KJ9D                          Refer#: 1119
From: W6GO                            Read: 08-29-92 (03:12)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Joe,
   Nice to hear from you again. Yes, your subscription is paid through
Issue 157, as you should be able to see on the mailing label.
   The last time you uploaded data was October, 1991. You are completely
out of date with QSLOLD and most of the command/batch files.
   Please review all of the bulletins (download BULLALL.ZIP), especially
Bulletin 3. Please review READNEW.ZIP and INQUIRY.ZIP. MONTHLY.ZIP has
also changed.  Please upload a copy of your OPERNAM.DAT file to meet the
upload schedule in bulletin 7 and I will reinstate you as a GOQSL SYSOP.
   You should download a new copy of QSLOLD.ZIP in preparation for the
GOQSL file which will be prepared for you based on your OPERNAM.DAT.
   You should also catch up on the READnnn.ZIP and LTRSnnn.ZIP files
that you have missed, so that you will understand the changes that have
taken place while you were inactive, and so that you will understand
why you must meet the schedule in the future.
   73, Jay

Date: 08-30-92 (19:46)              Number: 1122 of 1173
  To: SYSOP                         Refer#: NONE
From: KE9I                            Read: 08-30-92 (21:07)
Subj: COMMENT (1)                   Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay,
I will be leaving on my honeymoon/dx pedition tomorrow 8/31
I will be on from V2 Aug 31-Sept 5
and VP2V from 9/5 to 9/10 and VP2E from 9/10 to 9/17, I will be active
on all bands modes cw/ssb and some rtty. Just got married yesterday and
looking forward to the honeymoon/dx pedition. Will let you know how it
went later in the month ! 73 Jerry KE9I

Date: 08-31-92 (02:04)              Number: 1123 of 1173
  To: ALL                           Refer#: NONE
From: K6LLK                           Read: (N/A)
Subj: BPQ405E                       Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay,

Just thought I would pass along to you and the others I have been
really impressed with BPQ405E software.

I recently had 40 users connected to my node via BPQ and had no
problems at all even after several DX announcements in a row. I noticed
no one being dropped as I have in previous versions. This is indeed
very promising!
			    73 John K6LLK

Date: 08-31-92 (12:40)              Number: 1124 of 1173
  To: SYSOP                         Refer#: NONE
From: K1EA                            Read: 08-31-92 (15:31)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay, I think the "six port" problem is solved for now, though I don't
understand why.  The two significant differences between your setup and
mine were the fact that you used separate interrupts and that you run
two copies of DEDHOST (and two tncs within PacketCluster).
The separate IRQ's had no effect on my problem, but adding a second
copy of DEDHOST and TNC2 to sysop.dat seems to fix it...
I won't know if it's fixed until it has stayed up a week, but all
indications are go, and here's why.
Before the fix PacketCluster would try to reboot (read in messages
headers) right after booting about 2 out of three times. The rest of the
time it would last from 10 minutes to 3 days before doing the same thing
and crashing. I booted four times in a row with no trouble this morning
after adding the second copy of DEDHOST.
- Ken

Date: 09-01-92 (00:31)              Number: 1125 of 1173
  To: W6GO                          Refer#: NONE
From: WJ8R                            Read: 09-01-92 (01:19) HAS REPLIES
Subj: JULY ETC...                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay...
Sorry that I forgot to forward the July data on time. In fact by the
time I realized it... it was too late.... Lots of other things on my
feeble mind last month..... Job changes and illness of my father just
to name a couple....

W8HHF in Toledo Ohio is not getting his GO stuff thru me. He determined
it to be a better and more reliable path... Could you make the changes
needed for your records please ?

Thanks again for the great job the both of you do.

73     Tom   WJ8R

Date: 09-01-92 (01:19)              Number: 1126 of 1173
  To: WJ8R                          Refer#: 1125
From: W6GO                            Read: NO
Subj: JULY ETC...                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Tom,
   Sorry to hear about your fathers illness.  I hope all is ok now.  You
will need to correct your INC files to delete W8HHF.  Otherwise, he
shows up on both yours and K8NLD, and I then have to make a manual
choice, which I will do this month.  Thanks for confirming that he is
not getting the data through you.
   73,  Jay

Date: 09-01-92 (10:27)              Number: 1127 of 1173
  To: W6GO                          Refer#: NONE
From: N8HTT                           Read: 09-01-92 (14:49)
Subj: FILES                         Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay, I had a major failure here while trying to add an additional hard
drive. I lost my opernam.dat, dx.dat and a bunch of files in \packclus.
Sent what I had.
73 Ed

Date: 09-01-92 (11:37)              Number: 1128 of 1173
  To: SYSOP                         Refer#: NONE
From: W4AXO                           Read: 09-01-92 (14:49)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

GUESS I'M SNAKE BIT...TRIED TO UPLOAD THE GOLIST UPDATES FOR AUG.
THIS IS FIRST TIME I'VE HAD A PROBLEM UPLOADING.
Will try again.. thanks.  de Jim

Date: 09-01-92 (13:52)              Number: 1129 of 1173
  To: SYSOP                         Refer#: NONE
From: W6PQS                           Read: 09-01-92 (14:50)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay, started to send you the info about using DCD with KPC-2, KAM,
etc. but discovered I did not know exact price of latest upgrade v 5.0
so will fix it and send it along in a day or so... 73

Date: 09-02-92 (09:49)              Number: 1130 of 1173
  To: ALL                           Refer#: NONE
From: WP4K                            Read: (N/A)
Subj: BPQ DISCONNECTS               Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hello, everyone just wanted to check if anyone outhere is still having
the"hard disconnect" problems, since is been unusual that no one has
posted anything regarding this problem. My only findings have been that
after asking some users to verify their connections using all available
call-alias(4 in total to my case), what I found was that the only time
it happen was when they connected to the cluster call( WP4K), if they
used the node call, it will not do it, and also as long as they were
doing something in the cluster, they will not get disconnected.
I also try going back to DRSI/TNCTSR drivers, and the condition was
still there, if they connected and did nothing they will get
retried-out, and/or hard disconnect. I'm in the process of verifying the
tnc tones,level's, deviation etc at the cluster. As soon as I do that,
I'll post the results. In the mean time has any one try anything
different and what were the results.????

Date: 09-02-92 (23:15)              Number: 1131 of 1173
  To: W6GO                          Refer#: NONE
From: KK4JF                           Read: 09-02-92 (23:22) HAS REPLIES
Subj: BUL11.TXT                     Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay, I noticed thatyou have specified time frames for uploading and
downloading for the godisk process.  In the bul11.txt file it shows when
the upload times begin, but not when they end.  Do you think that you
could add that for the next download in bul11.txt.  Maybe I just missed
it in there.  CUL

Date: 09-02-92 (23:22)              Number: 1132 of 1173
  To: KK4JF                         Refer#: 1131
From: W6GO                            Read: 09-07-92 (17:58)
Subj: BUL11.TXT                     Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

I'm a bit confused.  The first column in bulletin 11 is "Upload cutoff".
 Do you want me to repeat that column again?
   73, Jay

Date: 09-03-92 (15:00)              Number: 1133 of 1173
  To: AK1A                          Refer#: NONE
From: AA4DO                           Read: 09-10-92 (13:24) HAS REPLIES
Subj: V6 SUGGESTION                 Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

How abt a feature for v6 that allows one to define "areas" that can be
used by announce packets and msgs.  Similar to dist lists, but use nodes
instead of individual stations.  For example, we could define area TN to
be all the nodes in Tennessee, MIDTN as all nodes in middle Tennessee,
etc.  This would simplify needing to send a message or announcement that
is localized in nature and would also cut down on ANN/FULL packets from
users that don't know what nodes cover the area they need to get info
to.
Tnx.  Gary

Date: 09-04-92 (06:00)              Number: 1134 of 1173
  To: SYSOP                         Refer#: NONE
From: KJ9D                            Read: 09-04-92 (06:11) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay,
I uploaded my opernam.dat file to you.  When will the GODISK be
available for me to download?  I'll be starting from scratch so I'll
need full instructions as to how its setup.
Thanks
Joe/KJ9D

Date: 09-04-92 (06:11)              Number: 1135 of 1173
  To: KJ9D                          Refer#: 1134
From: W6GO                            Read: 09-05-92 (06:26)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

-> Jay,
-> I uploaded my opernam.dat file to you.  When will the GODISK be
-> available for me to download?  I'll be starting from scratch so I'll
-> need full instructions as to how its setup.
-> Thanks
-> Joe/KJ9D
Joe,
    I can't find KJ9D.ZIP anywhere on DX-BBS. What directory did you
upload it to?  I will need that file before I can process anything for
you.   If I get your file here by the cutoff date (see Bulletin 11),
I'll be able to include it in this months' process.
    For instructions, just review READNEW.ZIP and MONTHLY.ZIP, as I
suggested in my last message.  READNEW provides references to other
instruction files before it gives you instructions on how to prepare and
upload the OPERNAM.DAT file (as KJ9D.ZIP).
    73,  Jay

Date: 09-05-92 (02:29)              Number: 1136 of 1173
  To: VE3CDX                        Refer#: NONE
From: KI3V                            Read: 09-07-92 (05:10)
Subj: THENET PLUS CODE              Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Barry,    I am still waiting for the new code from Bill......Just
wanted to let u know I havent forgot.......73  Rich  KI3V

Date: 09-05-92 (06:38)              Number: 1137 of 1173
  To: SYSOP                         Refer#: NONE
From: KJ9D                            Read: 09-05-92 (23:14) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay,
I think I screwed up (typical) and uploaded the file to you last evening
titled OPERNAM.ZIP not KJ9D.ZIP.  I did upload KJ9D.ZIP tonight all ok.
I'll reveiw all your .zip bulls and get on track.
I ordered a 14,4000 modem this past week, should have it tuesday or so,
guess that will save a lot of downloading time eh? Currently at 2400.
Thanks,
73-Joe/KJ9D

Date: 09-05-92 (23:14)              Number: 1138 of 1173
  To: KJ9D                          Refer#: 1137
From: W6GO                            Read: 09-07-92 (04:10)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

-> Jay,
-> I think I screwed up (typical) and uploaded the file to you last
-> evening titled OPERNAM.ZIP not KJ9D.ZIP.  I did upload KJ9D.ZIP
-> tonight all ok. I'll reveiw all your .zip bulls and get on track.
-> I ordered a 14,4000 modem this past week, should have it tuesday or
-> so, guess that will save a lot of downloading time eh? Currently at
-> 2400. Thanks,
-> 73-Joe/KJ9D

Hi Joe:
  KJ9D.ZIP received ok, with your OPERNAM.DAT file.  Thanks for your
interest.  There have been several changes since you became inactive, so
it is really appropriate for you to start over.  I think you will find
everything you need in the files I mentioned.  Don't forget to also
download QSLOLD.ZIP when you are ready to install GOQSL.
  Congrats on the high-speed modem.  You will be pleasantly suprised at
how well it works.  I suggest Porcomm+ V2 as a communications program as
it has ZModem built-in.  Be sure to use 38400 baud as the speed that
your communications program talks to your modem.   The modems themselves
will negotiate the line speed, and you handicap the throughput if you
open the port to the modem at only the 14400 line speed.
   73,  Jay

Date: 09-06-92 (05:28)              Number: 1139 of 1173
  To: AK1A                          Refer#: NONE
From: W6GO                            Read: 09-10-92 (13:25)
Subj: V6 ENHANCEMENT REQUEST        Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Dick,
   As you know, we have a Users Group that helps to support our cluster.
We have a database called UG which is really a roster database.  What we
would like to be able to do is send a conditional logon message based
upon the presence or absence of a callsign in the database.  One way to
implement this would be as follows:

SET/LOGON/TRUE UG.FUL UG.YES
SET/LOGON/FALSE UG.FUL UG.NO

This says if the callsign is found as a record in UG.FUL, display the
file UG.YES as a final logon message.

The second line displays UG.NO to people not in the database.

I don't see how you could efficiently do this on a database lookup
unless it was local.  You would need another modifier in PC44 which
would then get back the file for display to the user, I guess.

Another spiffy enhancement to this would be the ability to display a
record from the database as the logon message rather than a separate
file, perhaps with a # indicator in the command line.

73, Jay

Date: 09-07-92 (19:01)              Number: 1140 of 1173
  To: SYSOP                         Refer#: NONE
From: VE3CDX                          Read: 09-08-92 (05:35) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay.
I uploaded my info this morning for issue 150 but I think I may
have miss labled it as VE3CDX09 when it should have been 10.
The info gathered anyway is from the last 40 days. Sorry for the
confusion. Hope it doesn't cause your system any problems.
Cheers..Barry

Date: 09-08-92 (04:32)              Number: 1141 of 1173
  To: SYSOP                         Refer#: NONE
From: AC4TN                           Read: 09-08-92 (05:33)
Subj: COMMENT (1)                   Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay.. I read the article on the $25net pgm, so I gave them a call,
orderred the software, installed it and all I can say is WOW!  What a
time-saver! It sure has made life much easier xfering files between
computers and it doesn't slow the cluster computer down one little bit.
Sure appreciate your suggestions, they sure have helped me out in
keeping the cluster up and running smooth.  Several other articles abt
maintence, ect have made the node here run as smooth as silk.  I have
the node do a shutdown on monday morning, does a complete tape backup,
compresses the drive, reboots and it's back in business (takes abt 21
min on an 6mhz AT) while i'm still in bed.  All I have to do is swap the
tape out weekly!  I'm still trying to write a batch file that will start
my coffee in the morn..  Keep up the good work with suggestions, ect for
they have sure made life as a cluster sysop much less tedious.. 73,
Dave, AC4TN

Date: 09-08-92 (05:35)              Number: 1142 of 1173
  To: VE3CDX                        Refer#: 1140
From: W6GO                            Read: 09-12-92 (04:38)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

No Problem, the naming convention is really up to you, and almost
anything works as long as it doesn't duplicate an existing filename.
73, Jay

Date: 09-08-92 (11:52)              Number: 1143 of 1173
  To: SYSOP                         Refer#: NONE
From: N5JKN                           Read: 09-08-92 (16:41)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay,
I had a problem and lost my oper.dat file and dx records,
so I uploaded what I have.

Tom - N5JKN.

Date: 09-09-92 (00:27)              Number: 1144 of 1173
  To: ALL                           Refer#: NONE
From: W6GO                            Read: (N/A)
Subj: BPQ DISCONNECT PROBLEMS       Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

FYI: PacketCluster SYSOPs and for relay to G8BPQ:

More on the "failure to complete disconnect" problem.  These
conditions were discovered as a result of a phone call from KC8MK,
during which I looked at my tables here.  BTW, my BPQ stats reports
34521 minutes uptime, or almost 24 days.

I have two invalid entries in my LINKS table in G8BPQ.  These are to
AX25 V1 users, AH2AK and AA6KZ, who disconnected several days ago.
The entries are S=4 P=1 T=1 V=1.  There seems to be no way to
eliminate these entries.  My T3 timer is set to 300, but as I
understand AX25 L1 V1, the links will never be tested because they
are V1, so they never go away.  I can connect to the node with a new
callsign, using either V1 or V2, and disconnect gracefully (or a
hard disconnect) and the entry goes out of the LINKS table.  It
appears that these entries "got stuck" somehow, now preventing these
users from connecting again (they are told "W6GO Busy") without
adopting an SSID other than zero.   This seems to track with the
K1XX problem reported here in an earlier message.

Also, I have an "Uplink" entry in the BPQ Users table for a station
that disconnected several days ago, WA6SAZ.  There is no LINKS entry
for this station. There seems to be no way to eliminate this entry.
When he connects now, both entries stay in the USERS table.  The new
entry shows a Host connect to W6GO, but the old entry stays there,
on another line, with no connection on the right side of the USERS
table display.  This causes no trouble to that user, but certainly
is incorrect.

I do not know the mechanism which has placed these "stuck" entries
into the USERS and LINKS tables, and I do not know any way to
eliminate them without rebooting the BPQ switch.  Fortunately most users
are aware of the problem and know to change their call to SSID -1 when
they get "W6GO Busy" indication.

Other SYSOPs report situations where people don't receive a
disconnect from the node after they send a Bye command, and
ultimately do a hard disconnect to be released.  I haven't been able
to recreate such a condition, even though it has been reported to me
on my node (see my previous message which reviewed the nodes failure to
disconnect, continuing to poll.  However, the V1 connects described
above certainly could have started in the same way as the "failure to
complete disconnect" problem.

I did a BPQdump which is on DX-BBS as GO-DUMP.ZIP should any of you
UK SYSOPs like to pull it for G8BPQ's review.  It is not in the
directory but may be downloaded nonetheless.  It is 36,152 bytes
long.

73,  Jay

Date: 09-09-92 (02:54)              Number: 1145 of 1173
  To: ALL                           Refer#: NONE
From: W6GO                            Read: (N/A)
Subj: UPLOAD/FILEAREA/OVERWRITE     Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

From   : W6GO
To     : W6GO
Date   :  5-Sep-1992
Time   : 0004Z
Subject: More on UPLOAD/FILEAREA
Size   : 1827

Well!  I learned something today about PacketCluster.

As a user, if you do UPLOAD/FILEAREA filename, for example W6JZU does
UPLOAD/BULLETIN UGNEWS.022, this will allow you to upload a file which
is propagated to all the nodes in the cluster.  If that file already
exists, it won't allow the user to upload the new file.  So, if the
file does exist....

Then you do UPLOAD/FILEAREA/OVERWRITE and it accepts the upload and
sends it to the other nodes.  HOWEVER...  to prevent malicious
overwrites by a user, it does not delete the file.  Instead, it renames
it with a random extension on the filename, like UGNEWS.123.  This is
the way it is designed to work.  The manual certainly isn't clear on
this point!

So...   If somebody uploads a file and then wants to overwrite it, he
needs to tell the NODEs so they can delete the old file.  For instance,
had we known how this works, we should have instructed Smitty to do
the UPLOAD/FILEAREA/OVERWRITE and then asked him to send a message to
the nodes like..

"There is a file in your bulletin area that must be deleted.  It will be
a file which starts with the filename UGNEWS.  There should be two files
present, UGNEWS.021 and UGNEWS.022.  Please delete any other file which
starts with UGNEWS."

What would probably be better would be for Smitty to just send a new
file with a completely new file name.  Then, Smitty could ask a SYSOP to
remotely delete the incorrect files on the other nodes or he could send
a message to NODES asking them to delete the incorrect files.  The
second alternative could be a poor one, as some SYSOPs don't check their
mail for days.

At any rate, I learned something, and I agree that there is NOT a bug.
The way it is is really better, preventing malicious deletions as AK1A
suggested.

73, Jay

cc:W6JZU

Sent to distribution list NODES
*>*>*>K6AYA K6AYA N6IXX
*>*>*>K6LLK K6LLK W6OAT W6OTC N6ST KJ6NN
*>*>*>W6OAT W6OAT W6RGG
*>*>*>KI3V KI3V AA7EN
*>*>*>W6OTC W6OTC WA9WYB

Date: 09-09-92 (13:28)              Number: 1146 of 1173
  To: SYSOP                         Refer#: NONE
From: K1XX                            Read: 09-09-92 (19:40) HAS REPLIES
Subj: BPQ INCOMPLETE DISCONNECT     Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay - I uploaded trace.zip this morning.  This file contains 3
different trace files and tests I did with K1HJC to show the disconnect
problem.  I'll call back in a day or so to see if you have any
questions.  73s Charlie K1XX

Date: 09-09-92 (15:46)              Number: 1147 of 1173
  To: SYSOP                         Refer#: NONE
From: K1XX                            Read: 09-09-92 (19:36)
Subj: BPQ RETRIES MISSING           Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay one other commment.  I really miss having the number of retries
available for each user.  I find it a valuable piece of information as
I try to trouble shoot the reason for user disconnects.
Thanks Charlie K1XX

Date: 09-09-92 (19:36)              Number: 1148 of 1173
  To: K1XX                          Refer#: 1147
From: W6GO                            Read: 09-10-92 (12:34)
Subj: RETRIES MISSING IN BPQ        Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

I agree!  The problem is described in the BPQITEMS.TXT file in
BPQINFO.ZIP.  It looks like DEDHOST will have to be replaced to get that
functionality.
   73, Jay

Date: 09-09-92 (19:40)              Number: 1149 of 1173
  To: K1XX                          Refer#: 1146
From: W6GO                            Read: 09-13-92 (04:56) HAS REPLIES
Subj: BPQ INCOMPLETE DISCONNECT     Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Charlie..
   You found it!  Please see TRACES.ZIP for both your file and mine.
I'm asking Dick to take a look at them.
   73, Jay

Date: 09-10-92 (12:41)              Number: 1151 of 1173
  To: SYSOP                         Refer#: NONE
From: K1XX                            Read: 09-10-92 (16:09)
Subj: BPQ DISCONNECT                Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Well Jay, things just keep getting stranger and stranger!  I've had a
number of strange problems come up over the last few days: explained
mass disconnects by 4-6 users, incomplete directory listings going to
users, the trace_monitor file receiving incomplete data.  So, last
nite, I reverted back to version 5.4-02 from 5.4-21.  I'm using bpq
4.05e.  K1HJC and I then tried to duplicate the spot/bye problem and
could not do it.  I'm going to stay in this configuration for a while to
see if things stabilize.  I also suspect a possible problem between
QEMM & DRDOS 6.0.  My date, randomly, has not been changing.  I've seen
the same problem on 2 different 386s, but never on my old XT.
Maybe someday it'll all work out.   73s Charlie K1XX

Date: 09-10-92 (21:51)              Number: 1153 of 1173
  To: W6GO                          Refer#: NONE
From: K4CEF                           Read: 09-11-92 (08:28) HAS REPLIES
Subj: NEW USE FOR OP.EXE            Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay,
Here's something you might find handy sometime: We operate on limited
protocol over here with 26 nodes--we are always seeing announces from
some user to another station saying SET YOUR HOMENODE--either because
the recipient is a brand new user who hasn't set his HOMENODE or
because the sender's node wasn't connected when he did etc etc...
I used your OP.EXE program to make an ASCII file from OPERNAM that
has homenodes in it for all the users in the file, and then with an
editor edited out all but my own users. A little more with the editor
and I can turn the "K4CEF" at the front of each line into a
SET/HOME/USER= prior to the callsign, and then eliminate the other
quotes and the date.

The bottom line is that I end up with a file full of
SET/HOME/USER=XXXXX K4CEF
lines that I can put into a CMD file. In fact, I put pieces of it,
each with 10 calls, into 10 command files so as not to clog the
network--then at the appropriate time when a large number of nodes
are connected, I just execute one or more of 'em (@CAL1) and keep
all the nodes apprised of my users--this is a real convenience when
the number of nodes in your limited protocol network keeps growing.
Thanks for OP.EXE--a real timesaver! Where do I send my royalty check?
73, Bart

Sample file:
set/home/user=K4CEF K4CEF
set/home/user=KB8DB K4CEF
set/home/user=AK0M K4CEF
set/home/user=K4ADK K4CEF
set/home/user=KA2DRH K4CEF
set/home/user=K4IKR K4CEF
set/home/user=AA4AR K4CEF
set/home/user=WB4VKW K4CEF
set/home/user=N4HIX K4CEF
set/home/user=WB4RFZ K4CEF

Date: 09-11-92 (03:23)              Number: 1154 of 1173
  To: W6GO                          Refer#: NONE
From: NV6Z                            Read: 09-11-92 (08:27)
Subj: DXNODES VER 4.5               Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Hi Jay,
Finally found time to do some updating to DXNODES.  The file I just
uploaded (DXNODE45.ZIP) is the latest and includes data from the CLUSTER
Maps you refered me to.  Thanks for the help.

Hi to Jan

73 Ron

Date: 09-11-92 (08:28)              Number: 1155 of 1173
  To: K4CEF                         Refer#: 1153
From: W6GO                            Read: 09-11-92 (17:12)
Subj: NEW USE FOR OP.EXE            Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Wow!  Gee...  At $5 per user.......

Date: 09-13-92 (04:13)              Number: 1156 of 1173
  To: AK1A                          Refer#: NONE
From: W6GO                            Read: 09-15-92 (03:18)
Subj: V6 SUGGESTION                 Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

How about a local only high water mark?  Maybe display only with SH/CL?
   73, Jay

Date: 09-13-92 (05:23)              Number: 1158 of 1173
  To: ALL                           Refer#: 1149
From: W6GO                            Read: HAS REPLIES
Subj: BPQ INCOMPLETE DISCONNECT     Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

More on this strange problem.  I was running Version 5.4-24, and I had
been up for 18 days.  BPQ (and the two DEDHOSTS) had been up for 28
days, according to the BPQ stats display.

Charlie, K1XX, found exactly how to cause the condition.  I feel that
when this condition occurs, it is not usually due to a user doing
exactly what is detailed below.  However, this DOES cause the condition,
so at least now we can research it.

Here's how to demonstrate the problem:
--------------------------------------
From a user, make DX announcement and immediately type B.  The DX
announcement goes out.  PacketCluster console monitor shows the CUL line
going out.  The user gets disconnected from PacketCluster but remains
connected to the BPQ switch.  User must do a hard disconnect to get away
from BPQ.  Even though T3 timer in BPQ is set to 300, the connection
never goes down.  The connection is NOT in the BPQ USERS display,
but is in the BPQ LINKS display, shows S=4, disconnecting.  But NEVER
disconnects.  If the user happens to be running AX25L2V1, he must use a
different SSID to reconnect, as the S=4 entry NEVER goes out of the
LINKS table.  You can turn on TRACE_MONITOR to confirm that the
disconnect is never sent to the user.

However, if the same user does a WX/F followed by a B, he is
successfully disconnected!

I believe the basic problem is in the BPQ software, as the entry never
goes out of the LINKS table but it should.  However, as WX/F works ok, I
asked AK1A to look at the trace data and see if perhaps DX could be
changed to be the same as WX/F, as a workaround.  He assured me that it
already was, and that perhaps the DX packet structure or content being
different from the WX packet could be the answer, affecting DEDHOST or
BPQ in some way.  Perhaps the fact that the DX packets are longer than
the WX packets I tried has something to do with the difference.  We
concluded that it could also be a timing problem in giving DEDHOST the
disconnect too fast after a DX announcement, and that this was
something we could test. So, Dick made me a special version of
PacketCluster for test purposes. It includes a parameter SET/BYETIME n
where n is a time in seconds that user BYEs are delayed before
processing.

I installed the new version, SET/BYETIME to 10.  WORKED PERFECTLY!  To
prove the problem was gone, I set BYETIME to 0 (same as before, no
delay) and that also worked perfectly!  So, I installed 5.4-24 again
and tried it. It, too, worked perfectly!  Maybe PacketCluster must be
up for a long time before the "problem" will happen.  I've installed
the test version again with BYETIME set to 5.  I'll watch it.

If you are having this problem (demonstrate as described above), try
SHUTDOWN/QUIET and restart to see if that fixes the problem (for a
while).  Please let me know if you are able to run the test and your
results.  Please also include the version number and the time it was
running before the shutdown/quiet, and any other specifics on your node
you think might be useful.  For this to be a useful test, you must not
restart DEDHOST or BPQ.  Just SHUTDOWN/QUIET, start PACKCLUS again and
recover your users and nodes.

To our UK friends:  Can you see that John, BPQ, is made aware of this
problem?  The fact that there are entries in the LINKS (and USERS, too)
tables that don't go away and that we cannot clear is disconcerting.  I
have two AX25L2V1 users that have not been able to connect with SSID-0
for weeks, as they are stuck in my LINKS table.  I have one user shown
in the USER table as UPLINK1(WA6SAZ) with no host connection (my node is
'BBS' only) and he is not in the LINKS table.  If he connects again,
another entry in the USERS table shows his connect to the Host.  I
believe that the BPQ software should provide some means for the SYSOP
to fix the tables, like we can do with PacketCluster.  These phantom
entries have been in the BPQ tables for WEEKS.

73, Jay

PS... I wonder when BPQ will review the VALIDCALLS problem and others
in the BPQITEMS list again?    The BPQ software runs great and has many
advantages over the TNCTSRs (PC/TNC by WA8DED).  However, some of these
items are disconcerting.

Date: 09-14-92 (22:44)              Number: 1159 of 1173
  To: ALL                           Refer#: 1158
From: W6GO                            Read: HAS REPLIES
Subj: BPQ INCOMPLETE DISCONNECT     Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Results of the special version (V5.4-27) tests at W6GO:

I installed V5.4-27 and SET/BYETIME to 5.  Using K1XX's spot/bye test,
there was no problem.  I tried it again after 24 hours, and the problem
was back!  I tried making a long announcement followed by bye, and that
worked perfectly.  Then another spot/bye, and it worked perfectly.  I
then set BYETIME to 7.

After another 18 hours, I tried spot/bye again.  It failed to disconnect
again!  After doing a hard disconnect, I reconnected and did spot/bye
again.  This time it worked fine, sending the prompt and disconnecting
the user.  I've now set byetime to 10.

With Dick's permission, I have placed V5.4-27 on DX-BBS.  If you would
like to experiment with the BYETIME parameter, it is available here via
the UPD-PC door.

If you learn anything, be sure to share it with us!

73,  Jay

Date: 09-15-92 (00:06)              Number: 1160 of 1173
  To: PA3ERC                        Refer#: NONE
From: W6GO                            Read: 09-16-92 (14:56)
Subj: SH/HOUR                       Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Rob,
   Thank you very much for the uploads.  I asked K6PBT to review the
SH/HOUR one for possible installation on the W6GO node.  He got it
working and was pleased with it, running on his standalone node.  Based
on his recommendation, I installed it here.  I immediately removed it,
however, and here's why:
   Apparently the program reads the entire DX-DAT file from the
beginning.  My DX.DAT file is about 4.5Mb in size so that queries may be
made over a long period of time.  My cluster machine is a 486-25 with
8Mb of RAM cache.  The process took almost two minutes to run!
   I really like the concept, however, and I can see that it would be
satisfactory for nodes who keep the DX.DAT to a much smaller size.  I
would like to propose the following changes be made:
   1. Change the file access to DX.DAT to a "random" access.  Each
record in the file has a fixed length, so the number of records may be
determined by reading the file size and dividing by the record length.
Then read the last record in the file, the one before it, etc, until 24
hours of data is read.
   2. Update the HOUR.HLP file each hour, always showing 24 hours of
data.  Don't clear it, just replace the oldest hour with the newest
hour.  The 0000Z clearing and start over isn't reasonable here, for
instance, as that is in the middle of the afternoon!
   3. At 0000Z each day write a new HOUR.FUL file with one record, the
current HOUR.HLP file.  Add to it the date.  Call that record "Y" for
yesterday.  Then, SH/HOUR Y will get "yesterday's" data for the user.
   I hope these suggestions find favor with the programmer!
      73,  Jay

Date: 09-16-92 (16:52)              Number: 1165 of 1173
  To: W6GO                          Refer#: NONE
From: K4CEF                           Read: 09-16-92 (17:26) HAS REPLIES
Subj: HAMCALL UPDATE                Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Jay,

I've been looking for sometime for the new HAMCALL update, since
others have had theirs by mail or somewhere for a coupla weeks
now--called Dick, and he said it is on both CTBBS and yours, but
he didn't know what name you'd called it...He gave me JUL92UPD.EXE
on CTBBS, but it keeps telling me that there's no file by that name
on the disk--likewise, can't find it here...Is there some valid
registration list that I am supposed to be in to find it? I forgot
to ask Dick that question--I am indeed a valid user of it and I
wonder if he forgot to put me in some equivalent of the Cluster V5
registration list....I should be in whatever list there is....
Can u help me find the update?

Thanks!!

Date: 09-16-92 (17:26)              Number: 1166 of 1173
  To: K4CEF                         Refer#: 1165
From: W6GO                            Read: 09-16-92 (22:19)
Subj: HAMCALL UPDATE                Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Bart,
   I've asked Dick for naming convention and a correction to the readme
text file.  He has not responded to my fax.  As soon as I get the
information from Dick I will post the file.  Sorry for the delay.
   73,  Jay

Date: 09-16-92 (17:28)              Number: 1167 of 1173
  To: ALL                           Refer#: 1159
From: W6GO                            Read: (N/A)
Subj: BPQ INCOMPLETE DISCONNECT     Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

The new BPQ406 code SEEMS to have taken care of the problem, with
SET/BYETIME at 0.  Lets hope!

73, Jay

Date: 09-16-92 (17:33)              Number: 1168 of 1173
  To: ALL                           Refer#: NONE
From: W6GO                            Read: (N/A)
Subj: BPQ VERSION 4.06 CHANGES      Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

Comparison of BPQ documentation, Version 4.05e vs Version 4.06.  Info
extracted which affects PacketCluster use.  This is not a complete
comparison.  Review the files themselves for additional info.

CHANGES.BPQ:
============
Version 4.06  September 92 adds:

All numeric alises were treated as port numbers.

Reflected routes now get OBSCOUNT set, so they dont vanish too soon.

ON-OFF keying for CWID (mainly for use with G3RUH type modems, and
radios with a fast keying characteristic (eg Kantronics DataRadios)).

Code added to stop sessions sticking in Disconnecting state.


PROGS.DOC:
==========
This is a new file.  The files BPQNODES.DOC, SWITCH.DOC, SYSOP.DOC,
PAC2.DOC and PAC4.DOC have been placed into this file and may be
discarded in their original form.

Descriptions of BPQCODE.EXE, BPQCFG.EXE and BPQDUMP.COM are new.


BPQCODE.DOC:
============
The file CONFIG.DOC has been added to this file.  CONFIG.DOC may be
discarded in its original form.


DRIVERS.DOC:
============
The documentation on the DEDHOST is in this file and has not changed.
Other drivers have been updated.


COMMANDS.DOC:
=============
The STAY argument, used with the CONNECT command, is explained.
ROUND TRIP TIMES and FRAME count added to NODE N display.
ROUTES R (R R) command and display explained.
More discussion of STATS display results.


PORTS.DOC:
==========
CWIDTYPE=ONOFF parameter added.


I hope this helps some of you out there...  As long as I am crazy enough
to see what John has changed, I might as well share it with you!

73, Jay

PS: (Added AFTER installing BPQ406 at W6GO)

   I installed the new COM and EXE files and rebooted.  No changes were
made to BPQCFG.TXT.  It came up fine and seems to be running ok.  I am
running the special (V5.4-27) version of PacketCluster with the
SET/BYETIME parm set to 0 which should eliminate that function.
   After 10 hours I did a spot/bye test (per K1XX procedure) and it
worked properly, disconnecting the user.  It looks like this has the
problem fixed.

Date: 09-16-92 (17:46)              Number: 1169 of 1173
  To: ALL                           Refer#: NONE
From: W6GO                            Read: (N/A)
Subj: BPQ406 VALIDCALLS             Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

   The VALIDCALLS function in BPQ406 is still broken.  I have VALIDCALLS
lists for ports 3,4,5 and 6, but no VALIDCALLS lists for ports 1 and 2.

   In the SYSOPH function I can display the lists for ports 3-6.  It
shows a "No Valid Calls defined on this port" message for ports 1 and 2.

   ANY callsign may connect to me on ANY port.  The VALIDCALLS function
is completely inoperative.  This has never worked in any version of BPQ
that I have run.  Has ANYONE been able to make VALIDCALLS work, to
restrict PacketCluster backbone connects to nodes identified in the
VALIDCALLS list?

   73,  Jay

Date: 09-16-92 (22:21)              Number: 1171 of 1173
  To: W6GO                          Refer#: NONE
From: K4CEF                           Read: 09-16-92 (22:36)
Subj: THANKS                        Status: RECEIVER ONLY
Conf: GODISK (1)                 Read Type: GENERAL (+)

Thanks, Jay--will check back in later...I downloaded 4.06 BPQ and it
has been running nicely here all afternoon--but I seldom had the
disconnect problem others described--I did not try your method to
test it, however...will keep you posted--no changes here to BPQCFG.TXT
file either--just loaded and went...CUL..73

Date: 09-17-92 (03:17)              Number: 1173 of 1173
  To: KA5EJX                        Refer#: 1172
From: W6GO                            Read: NO
Subj: NEED BPQ HELP !               Status: PUBLIC MESSAGE
Conf: GODISK (1)                 Read Type: GENERAL (+)

BPQ406 is available here now.
73, Jay
-
**********************************************************************
		Messages from DX-BBS Main Board:
**********************************************************************
-
Date: 08-15-92 (17:13)              Number: 1541 of 1629
  To: K2GX                          Refer#: 1540
From: W6GO                            Read: 08-15-92 (19:34)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

-> Hi Jay, I hope all is well.  I tried to download the 5.4-21 version
-> of Packetcluster and was not able to get through the gateway.  I used
-> the password given to me by Dick but it didn't seem to work.  I also
-> tried the password I use on the system.  Your help would be
-> appreciated.
Joe, as the NEWS tells you (like BULLETIN on PacketCluster, it isn't
shown to you again unless it changes), you must read the PacketCluster
bulletin for the "door" password.  To review NEWS, just type NEWS at a
menu prompt.

You have to use three passwords.  1)The p/w you set up to access DX-BBS.
2)The password in the bulletin, which I change regularly, which allows
access to the UPD-PC door. 3)The password that Dick gave you, once you
access the UPD-PC door and Dick's software.  Hope this explains how it
works!

-> We're in the process of bringing our backbone links up to 9600 end to
-> end.  Wondering if you have any recommendations (radio, tnc, etc).
-> Frequencies we're going to be using are 420 and 430. Radios seem to
-> be a problem in this area.  We are using Maxons in a few of our links
-> and it might be the best way to go.  Have you heard anything on
-> Baycomm?   They have a 12 and 9600 baud combo.  I'll try to connect
-> and download later.
Joe, we absolutely LOVE the YAESU FT-712RHs.  Half of the radio is a
heat sink!  And, you can negotiate group buys with Chip Margelli at
YAESU.  The radios we buy do not come with microphones (big deal!).
These radios have proven themselves reliable under the severest
conditions and I suggest you include them in your list of radios to
consider.  They cover 430-450 now, and I have the mod specs (change
solder bridges and restart the microprocessor) to take the radios down
to 420.  I haven't (yet) tried that mod, but I have no reason to believe
that it will not work.

-> Thanks for all the help you have given us.     Joe
Glad I can be of some help.  Sure wish your cluster was more involved
with GOQSL, as I have lots of subscribers there I'm not reaching.
Please download READ149.ZIP and look especially at the GOQSL149.TXT file
that is included.  You are listed there and already have an impressive
percentage of W6GO/K6HHD subscribers who use your node!
73,  Jay


Date: 08-15-92 (17:44)              Number: 1544 of 1629
  To: AA4LU                         Refer#: 1542
From: W6GO                            Read: 08-23-92 (04:16)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

-> Jay,
-> Thanks for looking after me.  I am NOT very experienced at using BBS
-> Systems, so I could use a little tutoring...HIHI
-> By the way, I wonder what I need to do in order to get a little more
-> time available on ur BBS.  The 15 minutes sort of limits me sometimes
-> especially since I am pretty slow at this.  Dean and I (with ur OK)
-> will try to keep ur BBS current with info about DXbase and any info
-> that general users might find of value.  Seems like ur BBS is used by
-> a large number of folks and seems to be a good place to keep things
-> current.
Both of you are now shown as PacketCluster SYSOPs.  That will give you
30 minutes/day.  Let me know if that is still a problem.
73, Jay

Date: 08-16-92 (00:36)              Number: 1545 of 1629
  To: SYSOP                         Refer#: NONE
From: WD5B                            Read: 08-16-92 (05:03) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi -
  I am a Cluster user and have an old W6GO qsl table.  But, I am
not a subscriber.  I would like to get "right" with you and get
everything up to date.  What all do I need to do.  I understand
that I need to subscribe to your service and that some
of the databases are available here.  I did not want to download
any of them without being a subscriber.  I don't mind paying for
the updates either -- just need to know what all I need to
do.
  Thanks - Rich WD5B

Date: 08-16-92 (23:46)              Number: 1547 of 1629
  To: NH6HF                         Refer#: NONE
From: W6GO                            Read: 09-02-92 (09:13)
Subj: GOQSL                         Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi Cliff,
   Nice to hear from you again.  Your letter was received on the
15th.  Lots has changed since you inquired about putting GOQSL on your
node in March 1991. Please review Bulletin 3 here on DX-BBS and the
files to which Bulletin 3 refers.
   Unfortunately, I can't accept your copyright statement as you sent
it.  It is not dated, and it is an old copyright statement that does not
acknowledge our 1992 copyright.  You may use the form in bulletin 4, if
you like.  If timing is a problem (I need your OPERNAM.DAT file by
September 8th at 1700Z (see Bulletin 11), you may fax the copyright
statement to us at 916 991-1000.
   I note that you are using XModem.  That is really unsatisfactory for
transfers of data over a few thousand bytes or so.  My suggestion is
that you obtain a fast modem (9600 or 14400) and Procomm+ V2 which
includes ZModem.  With a V.32bis modem you will see relaible transfer
rates of 1650 cps or so, contrasted to the 90 cps you presently obtain
with the modem and communications software you are using.  Besides, just
one little burst of noise will queer an entire XModem transfer, while
ZModem just keeps right on going through the interruptions.  Just
changing to ZModem even at 2400 baud will raise your thruput from 90 cps
to 225-230cps!   See Bulletin 8 for suggestions on modems.

   To recap what I need from you to get you going as a GOQSL node:

1. Signed, current, Copyright agreement.
2. Copy of OPERNAM.DAT, renamed NH6HF.OPR, Zipped and uploaded before
   the deadline shown in Bulletin 11.
3. Something better than XModem as a transfer mode.  A minimum must be
   ZModem at 2400 baud, but faster speeds are desired.

   73, Jay

Date: 08-17-92 (18:04)              Number: 1548 of 1629
  To: ALL                           Refer#: NONE
From: W6GO                            Read: (N/A)
Subj: HF PACKET VS ARRL/FCC         Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

   The ARRL's intent to request the FCC to not authorize UNATTENDED
HF packet operation has resulted in a large outcry from those who
feel that the ARRL's action will disenfranchise them in some way.
Even some PacketCluster SYSOPs are concerned.  Lets examine the
situation and be careful of what we say.

   Unattended HF packet operation is NOT presently allowed, except
that a special temporary authorization (7230-J) was negotiated
between the ARRL and the FCC in July 1987 that lists specific
stations authorized to operate unattended on HF under certain
conditions, "for the purpose of testing and demonstrating packet
radio autoforwarding".   There are 127 calls listed in the most
current list I can find, and of them, only five of the calls are
PacketCluster SYSOPs who have the current version of PacketCluster.
Those five are KK4L, N1DL, N5OK, WB8CQV, and WD5B.  These SYSOPs
(and ONLY these SYSOPs) are authorized unattended HF operation.

   If your PacketCluster linking is via one or more of these five
stations, then you may be able to say that what the ARRL is doing
will affect you.

   If your PacketCluster linking is via some other SYSOP operating
on HF, his operation is ATTENDED.  If it is unattended, it is
illegal.  Every one of the HF SYSOPs has obviously found some way to
be in attendance when their stations are in use for the HF linking
purpose.  As they are required to be attended now, the ARRL proposal
will not affect their operations!

   If you cry wolf, saying that the ARRL's proposal will ruin
PacketCluster linking, you are only proving their point, that
unattended HF operation cannot be controlled.  You are doing that by
implying that the present operation is unattended, and thus in
violation of the rules!

   Please be careful of what you say and to whom.

   It may well be that PacketCluster HF linking would benefit from
some relaxation of the rules which cover unattended operation on
HF.  Make that point rather than complaining that the ARRL would
shut you down!

   73,  Jay  W6GO

PS.  This message and other related files, including a complete
     list of the stations listed in the STA, are included in a file
     called HFPACKET.ZIP on DX-BBS.

Date: 08-18-92 (01:10)              Number: 1549 of 1629
  To: W6GO                          Refer#: NONE
From: N4UCK                           Read: 08-18-92 (05:55) HAS REPLIES
Subj: STUFF                         Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Noth sure if TheNet discussion involves tsr or eprom stuff, if tsr it
would be nice to be able to save the current status for reboot and
recover the staus on recovery so users do not have to reconnect.
also, if you don't mind you might include in your communications with
ak1a the deirability of an/distro.lst and other such similar general
distribution to a list of nodes (i.e. announce/atlanta or wx/atlanta)
thanks for the use of ur fine machine.
73, Jim

Date: 08-18-92 (05:55)              Number: 1550 of 1629
  To: N4UCK                         Refer#: 1549
From: W6GO                            Read: 08-23-92 (01:38)
Subj: STUFF                         Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi Jim..
   I've made your message public so that KI3V (TheNet) and AK1A will see
your message (hopefully).  You really ought to send messages to both
with more details.  You should send the messages to them in the GODISK
conference.
   73, Jay

Date: 08-18-92 (18:03)              Number: 1551 of 1629
  To: W6GO                          Refer#: NONE
From: K9EC                            Read: 08-18-92 (21:04) HAS REPLIES
Subj: QSL MANAGER ADDRESS           Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi Jay,

I'm the QSL manager for VS6WO and I've just recently moved to a new
QTH.  The callbook address is now no good as the post office will
only forward mail for another 60 days or so.  Please change the listing
for VS6WO in your managers list to reflect my new address.

VS6WO via K9EC

Michael Zeug
9N317 Corron Rd
Elgin, IL  60123

Thanks


By the way, during my move my packetcluster node has been running at
N9AKE's place.  I hope to have my first tower up within a month or so
depending on my work load at the office.

CUL 73  mike K9EC

Date: 08-18-92 (21:04)              Number: 1552 of 1629
  To: K9EC                          Refer#: 1551
From: W6GO                            Read: 08-21-92 (20:19)
Subj: QSL MANAGER ADDRESS           Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Mike,
    We have already printed that info in the latest list.  Thank you for
the further confirmation.
   73, Jay

Date: 08-21-92 (02:28)              Number: 1553 of 1629
  To: NN6U                          Refer#: 1539
From: KC4LWI                          Read: 08-28-92 (01:47)
Subj: STACKER W/PACKETCLUSTER       Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

    Be cautious about the Stacker.... True it does save alot of drive
space, but the HAMCALL is a very large tight binary file... You are
probably going to find that it will appear to take up more space than
you may initially think. A good example is that ZIP files on a STACKER
Drive will not compress enough to make it worth using... However, with
Packet Cluster and all the ASCII files, it is very much worth installing
Stacker, as some files may achieve better than a 16:1 ratio. Let me know
actually what you compression ratio is on the HAMCALL... I am highly
interested. I  will be surprised if the compression ratio is better than
1.2:1.

73's - John (KC4LWI)

Date: 08-21-92 (02:31)              Number: 1554 of 1629
  To: AK1A                          Refer#: NONE
From: KC4LWI                          Read: 08-24-92 (18:53)
Subj: PACKET CLUSTER VER 6.0        Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Dick,

   I  can  think of a couple of items to add to Packet Cluster Ver 6.0
when it is released.  They are:

   1.) Auto update of User Name....  IE, A new user logs on  that  has
never  been  on  before...  If Buckmaster or Hamcall is available, the
cluster will look up his call, and identify him or  here...   I  thing
that  this  would  be an impressive feature for a new 1st time user to
log on and be identified on his/here first call.

    2.)    Auto  request  WWV...   Command  would   be   similiar   to
SET/WWV_REQUEST 10.  It would simply keep tabs of the WWV Data that is
on  the  system...  If it was enable and the request set to 10 as show
above, then 10 hours after no update had been made to  the  WWV  Data,
the  cluster  would  at  approx  15  min past the hour put out a local
announcement "CLUSTER NEEDS WWV UPDATE!".  This would  help  eliminate
the  problem  of  infrequent WWV data being on the system.  If the WWV
Request was set to 0, then it would be disabled...  You could  have  a
range  set  of  3  min to a max of 48 or so, and allow a 0 so that the
function could be disabled if desired.

    3.) More Support for BPQ Code!

73's - John - KC4LWI

Date: 08-22-92 (02:12)              Number: 1555 of 1629
  To: SYSOP                         Refer#: NONE
From: WB5EUC                          Read: 08-22-92 (03:28)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi Jay.  Thanks for Dick's (AK1A) phone number.  I spoke briefly with
him concerning PacketCluster + KAM.  It still isn't working but I think
(hope) I am getting closer.  I would like to request some of your files:
 Modemdr3.zip    QWHITE10.zip    and   TA.EXE   from your personal
directory B.  Thanks.  Will look for them next time.
By the way, if you know ANYBODY using a KAM (vs. 2.85 - yes, it's older
than dirt) with PacketCluster.... I'd very very much like to know about
it.  This thing is driving me nuts.
Also, the local club - the Panhandle ARC has the DXCluster with callsign
W5WX-5 (Dick's sending a copy with just W5WX) and I have the password
here in the documentation.  I'll be getting some files from the related
directory later this call.  I have moved my PC-GO files into the DB
subdirectory of PACKCLUS for use in testing the NODE here at my house.
Other than disrupting my use of pc-go, I hope nothing else catastrophic
occurs while I'm testing it out (trying to get it to work).  I am
realitively certain that I'm overlooking some little switch or setting
and that it's totally my operator error that's keeping the system from
functioning.... but I can't figure what it is.  Anyway... I'll sign for
now and get the reference files from GODISK 3 and be on my way.
73 es gud dx de WB5EUC (John - Amarillo, TX)

Date: 08-24-92 (10:31)              Number: 1562 of 1629
  To: SYSOP                         Refer#: NONE
From: WP4K                            Read: 08-25-92 (04:56) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi,Jay.. hope all is ok, down here we are Ok, only to mention something
as you see I have been using the RASZ,for dloading the latest msg but
something happen, if I forget(it does happen) to remove the dx-bbs.zip
file from my dload directory, it sees it there(system) and then just
get's back and said transfer finish, I was wondering if there is a way
to have the System make that file with a different namae every day,
something like**24dxbbs,25dxbbs, meaning the day and your mark. Is just
a lot easy to then developed a script to come here and pick all new mail
and don't have to worry about your old ones, sometimes it can be day's
unnatended and can still get the msg. Just a sugestion I'll see what I
can come uo on my side.
See you around, best 73
and by the way KP4BZ,KP4GY,MYSELF and some others are preparing another
station for contest(small) to take over were we lefted after HUGO damage
all KP4BZ state. Looking forward to October......

Date: 08-25-92 (02:54)              Number: 1564 of 1629
  To: SYSOP                         Refer#: NONE
From: WB5EUC                          Read: 08-25-92 (04:57)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

FB Jay.  We are in contact with Les and others in the Midland area.  It
may take awhile, but we are getting there.  Thanks again for the input.
I was relatively sure the DRSI problems had been taken care of.  We will
end up with the G8BPQ (or is it PBQ - whatever!) because I've downloaded
it from DX-BBS.  We're getting there.  Our ultimate goal is to link via
TexNet to Les in Midland.  I'll keep you informed of our progress.
73 es gud dx de WB5EUC (John - Amarillo, TX)

Date: 08-25-92 (03:13)              Number: 1565 of 1629
  To: N6VB                          Refer#: 1529
From: AK1A                            Read: NO
Subj: LIMITED PROTOCOL VERSIONS     Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi Scott, yes, the External node stuff is now in the latest
version....go ahead and copy it...
73, Dick

Date: 08-25-92 (04:56)              Number: 1566 of 1629
  To: WP4K                          Refer#: 1562
From: W6GO                            Read: 08-25-92 (10:21)
Subj: COMMENT (1)                   Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

-> I have been using the RASZ,for dloading the
-> latest msg but something happen, if I forget(it does happen) to
-> remove the dx-bbs.zip file from my dload directory, it sees it
-> there(system) and then just get's back and said transfer finish, I
-> was wondering if there is a way to have the System make that file
-> with a different namae every day, something like**24dxbbs,25dxbbs,
-> meaning the day and your mark. Is just a lot easy to then developed a
-> script to come here and pick all new mail and don't have to worry
-> about your old ones, sometimes it can be day's unnatended and can
-> still get the msg. Just a sugestion I'll see what I can come uo on my
-> side.
Carmelo, You would have the same trouble with PacketCluster updates and
with GODISK if you didn't first clean up your download directory.  If
the message download file was changed every time, then I would also have
to do the same for all the other files which you download more than
once.

If you forget again, just go and look at the last file you have and note
the highest message number from each conference.  Then log to each
conference and type R SET and set your last message read pointer and run
RASZ again.

73, Jay

Date: 08-25-92 (21:41)              Number: 1567 of 1629
  To: ALL                           Refer#: NONE
From: W6GO                            Read: (N/A)
Subj: FREE VSERIES 9600 UPGRADE     Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

To DX-BBS Users with Hayes V-Series 9600 Baud modems:

A super offer from Hayes.  You are on your own.   Give Ricky a call.
   73, Jay


sg#:23279 *Help Desk*
08/18/92 14:53:21
From: HAYES TECH SUPPORT 1
  To: JAY O'BRIEN
Subj: REPLY TO MSG# 23205 (ULTRA 14400 V1.1)
Jay,
    As for your V-series problem, I have done some more research on
that, I've had one other sysop since you and I last exchanged
messages also come up with that same problem with a 1.1.  It turns
out he had only one V-series user showing this problem and that user
had an absolutely ancient version of the V-series.  I upgraded the
V-series user's ROM and the problem was fixed.  I would like to try
the same with one of your's.  If it follows the same symptoms, the
ones having the problem will be using an ancient V-series that only
does LAPB and maybe ADC.  If you'll have one of those call me, I'll
not only upgrade him/her to a current level of ROM for their modem,
I'll go ahead and upgrade them to V.42/V.42bis for free just as a
token of appreciation (that's normally a feature upgrade carrying a
charge).


Ricky Lacy
Hayes SYSOP program
404-840-9200


Date: 08-29-92 (06:59)              Number: 1573 of 1629
  To: SYSOP                         Refer#: NONE
From: WB5EUC                          Read: 08-29-92 (07:16)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi Jay.  I knew you'd be right and of course you were!  I need to learn
to follow instructions (to the letter).  Got the BPQ switch and Cluster
up and running with the 232 just as you said it would.  I was 100
percent certain it was operator error... just called to ease my
frittered nerves, I guess.  The dual vhf port DRSI board that Coleman
(WA4NXI) ordered should be here this weekend, so we'll move the test
site of W5WX-5 to his QTH.  We hope to be tied in with Les - WF5E -
before too long.  We're investigating the possibility to hit NMDX in
Santa Fe (W7LHO (I think)) also.  Sure would be nice.  It's something we
can plan on for the future.  Thanks Very Very much for all your help and
patience with me.  It is deeply appreciated.  Best wishes and take care.
 73 es gud dx de WB5EUC (John - Amarillo, TX).

Date: 08-29-92 (22:50)              Number: 1574 of 1629
  To: SYSOP                         Refer#: NONE
From: WB5EUC                          Read: 08-30-92 (03:59) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

I always thought that Freddy Kruger was everybodies worst nightmare...
now I find myself being possibily your worst nightmare!  The user that
wouldn't go away!!!
   Evidently, you have to add a PacketCluster SYSOP to your records
online DX-BBS before downloading of upgrades can take effect.  Dick said
he'd be adding me too his list (for the Panhandle ARC - W5WX) but I
wasn't sure it that list would show up here (I imagine it will but I'm
not sure).
   Here's my confusion... do I check in as WB5EUC or does the club need
to register with DX-BBS so W5WX will be listed?  That's possible, if
needed.
   Also, I am dragging my feet on GOQSL for the local cluster.  I have
two reasons:  one is the info is available via WF5E (or one of the nodes
connected to him) and secondly because I am not ready to commit to all
that's required to being a full time sysop of a cluster.  I think
Coleman (WA4NXI - club president and main sysop) is unaware of
everything that's involved.  He may well think it's free with little or
no effort on his part.  I plan on educating him to the facts as I have
opportunity to work with him.  Initially, in the sparsely populated
Panhandle of Texas... there isn't going to be much activity locally.
The major benefit we can provide will be linking other areas.  That is,
making the "territory" larger.
   I've downloaded your bulletins and will share them with Coleman so he
can see what support is involved with being a SYSOP of a Cluster and
what info he would need to provide for getting the support of GOQSL on
the local node/cluster here in Amarillo.
   I have a sample form on GOQSL but it indicates a more involved form
is provided by you for the full service.  Anyway... how do I go about
getting  V.5.4.24 of Packetcluster?  Do I wait for the update file with
my callsign to be provided by AK1A?  or  Is there a file you have to add
me too on DX-BBS?
   Will I ever be cured of terminal question asking?  My biggest fear is
not remembering what I've already asked and becoming a worthless pest to
you and the system.  (Evidently I don't mind being a pest... just don't
want to be a worthless pest.  It's a matter of degrees I guess.)
   Thanks for all the support/suggestions/info/ideas.  73 es gud dx de
WB5EUC (John - Amarillo, TX).


Date: 08-30-92 (03:59)              Number: 1576 of 1629
  To: WB5EUC                        Refer#: 1574
From: W6GO                            Read: 09-16-92 (05:04)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

-> Evidently, you have to add a PacketCluster SYSOP to your records
-> online DX-BBS before downloading of upgrades can take effect.  Dick
-> said he'd be adding me too his list (for the Panhandle ARC - W5WX)
-> but I wasn't sure it that list would show up here (I imagine it will
-> but I'm not sure).
Dick periodically replaces his file which has the passwords.  Each
person who checks in is identified by callsign and looked up in Dick's
table.  That user call is authorized one or more PacketCluster callsigns
for which the update may be downloaded.  Several user callsigns may be
authorized to download the same PacketCluster node software.

-> Here's my confusion... do I check in as WB5EUC or does the club need
-> to register with DX-BBS so W5WX will be listed?  That's possible, if
-> needed.
Thats up to Dick.  If he knows your callsign, he will no doubt authorize
you to download the file.

-> Also, I am dragging my feet on GOQSL for the local cluster.  I have
-> two reasons:  one is the info is available via WF5E (or one of the
-> nodes connected to him) and secondly because I am not ready to commit
-> to all that's required to being a full time sysop of a cluster.
If you are able to reliably link to WF5E you should get the QSL database
as a remote off of his node.

-> I have a sample form on GOQSL but it indicates a more involved form
-> is provided by you for the full service.
I don't understand this question.

-> Anyway... how do I go about
-> getting  V.5.4.24 of Packetcluster?  Do I wait for the update file
-> with my callsign to be provided by AK1A?  or  Is there a file you
-> have to add me too on DX-BBS?
You are already registered here.  It is entirely up to Dick at this
point.  He must assign you a password and give that to you.

73, Jay

Date: 08-31-92 (00:11)              Number: 1579 of 1629
  To: WS7I                          Refer#: NONE
From: W6GO                            Read: 08-31-92 (01:12)
Subj: LANTASTIC                     Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Jay,
   If one of the machines on your Lantastic network is your
PacketCluster node, you need a file I have posted here for you.  It is
called PCBCOPY.ZIP.  In it is PCBCOPY, a COPY program which uses DOS
COPY arguments but will copy an open file in a non-network aware
application such as PacketCluster.  If, for example, you are running
CONSOLE logging to a file called CONSOLE.TXT, and you want to either
view that file over the netowrk or copy it to another computer, you
can't do it with DOS COPY.  You can, however, do it with PCBCOPY.
   Try it!
      73, Jay

Date: 08-31-92 (00:49)              Number: 1580 of 1629
  To: SYSOP                         Refer#: NONE
From: K1EA                            Read: 08-31-92 (02:02)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Jay, Feel free to pass out both versions of OP_SORT with any naming
convention you like. PacketCluster does not know enough to rebuild
OPERNAM after OP_SORT has run (according to Dick), and when I tried it
here, things got all screwed up. Perhaps your OPERNAM was in well sorted
form with no bad calls to begin with, so things didn't change much.
I will try to ressurect the keystroke-from-a-file format I used two
years ago at Dayton. The code to read the keys from a file is still in
CT...the magic I lost is the program to *make* the keystroke file.
More later. - Ken

Date: 08-31-92 (13:30)              Number: 1581 of 1629
  To: SYSOP                         Refer#: NONE
From: K5NV                            Read: 08-31-92 (15:29)
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

JAY:
JUST UPLOADED THE MONTHY NODE DISK.
CHECKOUT THE README.TXT FILE
COMMENTS ON CONVENTION.
PROBLEM HAVING THIS MONTH.
TNX DE K5NV SK

Date: 09-01-92 (04:18)              Number: 1584 of 1629
  To: SYSOP                         Refer#: NONE
From: N4SR                            Read: 09-01-92 (05:12) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi Jay, 3 things. I tried to download the latest version of
packetcluster, I got to the point where I was actually downloading, but
the file that I was getting was labeled  unknown.$$$. It really dosent
matter cause I am tired of the problems with using the hard drive
buckmaster anyway but thought you would like to know abt this.  secondly
N2FB had some sort of problem and somehow wiped some of his files off
his hard drive. An observant user  K3ZO spotted something strange about
the response he was getting while doing updates, and alerted us to it.
come to find out that wayne had trashed all his templates. They are back
in place now, but some data was lost and I don't really know how long
the templates were missing   important thing is that they are back in
now.  3rd  i noted ko4nu using the sh/go command  he says he is a
subscriber under his old call kd4emt. i didn't see it on the listing
just thought you would like to know   i am not sure if non subscribers
can use sh/go or not?  am now sending a personal note to those who use
the sh/qsl a lot and who are not subscribing. don't know if it will help
but am trying anyhow. 73   Steve

Date: 09-01-92 (05:12)              Number: 1585 of 1629
  To: N4SR                          Refer#: 1584
From: W6GO                            Read: NO
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hi Steve...

-> I tried to download the latest version of
-> packetcluster, I got to the point where I was actually downloading,
-> but the file that I was getting was labeled  unknown.$$$.
I see that you are using YModem which does strange things like you
describe IF a file of the same name already resides in your download
directory when you begin the download.  It will write the file ok but
name it something else. If this is the case, you might like to write a
batch file that cleans your download directory before executing your
communications program.

-> N2FB had some sort of problem and somehow wiped some of his
-> files off his hard drive. An observant user  K3ZO spotted something
Fred isn't just observant.  He is clairvoyant!

-> wayne had trashed all his
-> templates. They are back in place now
Thanks for alerting me.  Glad it's fixed, and the templates being
missing helped to spot the problem.  All's well that ends well!

-> ko4nu using the
-> sh/go command  he says he is a subscriber under his old call kd4emt.
Yep! sure is.  He expires with next month's issue, hopefully he will
send a call sign change with the renewal.

-> i didn't see it on the listing
You wouldn't, unless he had used the old call on your cluster in the
last three months.

-> i am not sure if non subscribers can use sh/go or not?
Well, it is "special" for subscribers.  However, you really aren't
expected to police it.

-> am now
-> sending a personal note to those who use the sh/qsl a lot and who are
-> not subscribing. don't know if it will help but am trying anyhow.
Your efforts are very much appreciated, believe me!

73, Jay


Date: 09-03-92 (23:24)              Number: 1592 of 1629
  To: K1XX                          Refer#: 1591
From: W6GO                            Read: 09-04-92 (17:11)
Subj: DISCONNECT MESSAGE            Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

WONDERFUL!!!!!

Yes, please upload the file.  I'll see if I can get our UK contingent to
download the file and get it to G8BPQ for his review.  It would be
helpful if you would edit the file to place your comments in the file,
perhaps enclosing your comments in <<<< >>>> like I do in the LTRSnnn
files here on DX-BBS.  Any method will be just fine, as long as you tell
us what it is.

Thanks for your diligence!  Maybe we'll get this bug squashed yet.

73,  Jay

Date: 09-05-92 (20:33)              Number: 1595 of 1629
  To: SYSOP                         Refer#: NONE
From: NH6HF                           Read: 09-05-92 (23:05) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

JAY ... JUST GOT MY HIGHER SPEED MODEM IN AND AM GETTING FAMILIAR WITH
IT AND THE SOFTWARE.  WILL FORWARD THE AGREEMENT DOCUMENT AND GO FOR THE
QSL MANAGERS' DATABASE FOR OCTOBER 1992.  THANKS.  P.S. I LIVE IN BACK
OF THE COCO PALMS HOTEL JUST ABOUT THE BASE OF THE "SLEEPING GIANT".

Date: 09-05-92 (23:05)              Number: 1596 of 1629
  To: NH6HF                         Refer#: 1595
From: W6GO                            Read: NO
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Great!
   We stayed at the Coco Palms a few years ago.  Wonderful place,
wonderful Island, wonderful people.  Someday we'll find the opportunity
to return.
   73,  Jay

Date: 09-14-92 (23:13)              Number: 1614 of 1629
  To: VE3CDX                        Refer#: NONE
From: W6GO                            Read: NO
Subj: CLUSTER MAPS                  Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Barry,
   Based on the maps you provided for DX-BBS (CLUSMAPS.ZIP), K6PBT has
prepared two maps which describe our system.  They are NOCAL.MAP and
RENO.MAP. I've placed them here on DX-BBS as NCA-NEV.ZIP for you (and
anyone else interested).  Once you include them in your upload to me,
I'll delete NCA-NEV.ZIP.
   73, Jay

Date: 09-16-92 (04:43)              Number: 1620 of 1629
  To: ALL                           Refer#: NONE
From: WA4NXI                          Read: (N/A)
Subj: CLUSTER/BBS                   Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

I am running a Packet Cluster on a 386 25 mhz with 150 Meg HD and 4 meg
of memory. I am also using th G8BPQ swithc ver. 4.05e.  I am looking for
any information about running both a cluster and a BBS on the same
switch.  I also have 2 type 2 DRSI boards.  I would at least like to run
both applications on the same PC if possible.  I currently have both
QEMM and DesView. Any Help would be greatly appreciated.


Date: 09-16-92 (15:05)              Number: 1623 of 1629
  To: K1EA                          Refer#: NONE
From: PA3ERC                          Read: NO
Subj: DVP SERIAL NUMBERS            Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Hello contesters,
I have received my DVP card and started playing with CT version 8.
I wonder if it is possible to generate serial numbers ?
I could not find this in the manual, maby a nice suggestion for a
next update, if the card can speak then a serial numbers must be no
problem.

Date: 09-17-92 (06:09)              Number: 1625 of 1629
  To: SYSOP                         Refer#: NONE
From: KJ9D                            Read: 09-17-92 (06:28) HAS REPLIES
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Jay,
    What am I doing wrong now?  I've called a few times recently in
anticipation of downloading the GO list.  Am I missing the file or what?
Must I wait till the Sept 18 download period?  How about the Aug
download?  The users on the node are screaming, we paid for this back at
dayton and don't have it yet!
73-joe/KJ9D

Date: 09-17-92 (06:28)              Number: 1626 of 1629
  To: KJ9D                          Refer#: 1625
From: W6GO                            Read: NO
Subj: COMMENT (1)                   Status: RECEIVER ONLY
Conf: MAIN BOARD (0)             Read Type: GENERAL (+)

Joe, Responding to your message quoted below:

->   What am I doing wrong now?  I've called a few times recently in
-> anticipation of downloading the GO list.  Am I missing the file or
-> what? Must I wait till the Sept 18 download period?
The data is not prepared for you until the data is prepared for
publication.  It will be prepared for you at the same time it is
prepared for all of the other SYSOPs.  Bulletin 11 has the schedule, and
if all goes well I will be able to meet my committment and will have the
files prepared for all SYSOPs sometime tomorrow.

-> How about the Aug download?
You didn't upload anything and no file was prepared for you.

-> The users on the node are screaming, we paid for this
-> back at dayton and don't have it yet!
The GOQSL data is prepared for SYSOPs who participate at no charge to
the SYSOPs.  It is required that the SYSOP be a subscriber because of
the Copyright agreement.  You didn't pay for anything at Dayton other
than your subscription.  REPEAT: There is no charge for GOQSL data.  It
is provided free to better serve our subscribers who are your users.

If the users are screaming, have them call me.  I will explain the
process to them too.  No data in, no data out.  It is that simple.  You
meet your committment to me and I meet mine to your users who are my
subscribers.

If this sounds terse, it is because I am behind my schedule to get the
data prepared for you and the time spent answering this doesn't help in
that effort.  All of this information is covered in bulletins and files
which you should have.

73, Jay

-
