I thought I would update everyone with where things stand with the
Tops-20 finger server.
Johnny and I agreed that, by default, the response to a DECnet finger
query is a sequences of records, each no longer than 132 bytes (more
typically 90), terminated by a line-feed.  If the remote finger client
or operating system can handle larger buffers, then it can connect with
optional data=STREAM. Tops-20 will then dump everything in one giant
record. Only the Tops-20 finger client can handle this, although I
suspect maybe a VAX client might also be able to do it.
I had been making steady progress until I started stress testing it,
meaning having a session active on MIM::, TOMMYT::, and VENTI2::
(local), each having a finger command in ready to go and then pushing
carriage return on all three as simultaneously as possible.
This started generating errors on MIM:: that the "object wasn't
available". What was going on was that the structure of the Tops-20
finger server really wasn't architected to have real time response for
that much curiosity. It only opens a single SRV:117 (finger) object at a
time, waits for a connection, reads the data, hands it off to an idle
finger client fork via a pipe, and then gets a new SRV:117 object.
In other words, it isn't until the finger client is started with the
connection redirected to DECnet that the server is ready to accept
another connection. That has what I would consider to be noticeable
latency, particularly on failure.   An error doesn't really matter for
SMTP as it is a background task and just tries again, later. An
interactive finger on the other hand, has a user sitting there waiting
for a response, so it seemed to me that this wasn't really going to cut it.
I took the model of the Tops-20 FAL server, which has a single control
fork, looking for illness in sub-forks, all of which open their own FAL
server object. The new finger controller now starts separate FNGSRV
sub-server forks, creating a FINGER sub-fork for each, gets all the
communications lined up, and starts all the FNGSRV sub-forks to listen
for connections.
This has the advantage of not clobbering the system on FNGSRV startup
because resources are gotten or creating sequentially, so there isn't
much for a FNGSRV sub-fork to do except wait for a connection and manage
its own single FINGER sub-fork.
Startup resource allocation looks like this:
   [Fork FNGSRV opening PIP:1;RECORD-LENGTH:200 for writing]
   [Fork FNGSRV opening PIP:1.1 for reading]
   [Fork FNGSRV opening SRV:117 for reading, writing]
   [Fork FNGSRV opening PIP:2;RECORD-LENGTH:200 for writing]
   [Fork FNGSRV opening PIP:2.2 for reading]
   [Fork FNGSRV opening SRV:117 for reading, writing]
   [Fork FNGSRV opening PIP:3;RECORD-LENGTH:200 for writing]
   [Fork FNGSRV opening PIP:3.3 for reading]
   [Fork FNGSRV opening SRV:117 for reading, writing]
The resulting JFN's being:
       JFN File Mode     Bytes(Size)
        2  FNGSRV.EXE.330            Read, Execute
        3  FINGER.EXE.116            Read, Execute
        15 PIP:1;RECORD-LENGTH:200   Append         0.(8)
        16 PIP:1.1                   Read           0.(8)
        17 SRV:117                   Read, Append   0.(8)
        20 PIP:2;RECORD-LENGTH:200   Append         0.(8)
        21 PIP:2.2                   Read           0.(8)
        22 SRV:117                   Read, Append   0.(8)
        23 PIP:3;RECORD-LENGTH:200   Append         0.(8)
        24 PIP:3.3                   Read           0.(8)
        25 SRV:117                   Read, Append   0.(8)
The resulting fork structure is:
   => FNGSRV (2): HALT at STARTS+13, 0.02719
         Fork 12: HALT at 0, 0.00018
            Fork 13: HALT at 0, 0.00016
         Fork 10: HALT at 0, 0.00012
            Fork 11: HALT at 0, 0.00012
         Fork 6: HALT at 0, 0.00008
            Fork 7: HALT at 0, 0.00007
So fork 2 is the finger server controller, forks 12, 10, and 6 are
finger server sub-forks, and forks 13, 11, and 7 are the respective
Tops-20 finger clients. Times are in tens of microseconds, the maximum
resolution that Tops-20 supports. What can be seen is that fork
creation is happening in sub-millisecond time. This was not the case in
the 1980's with KL10's (I /think/), and modifications were necessary to
Tops-20 and the EXEC to capture the increased resolution.
I guess I'll have another version ready in about two weeks.
MIM can be used as an intermediate node, yes.
If you send your mails to MIM::<whatever>::USER the mail will be queued
up if the <whatever>:: node isn't responding right now.
Johnny
On 2024-10-04 09:16, jdmail(a)zeelandnet.nl wrote:
> Then we need a node as a mailserver? Can that be done?
>
> Johan
>
>
> Johnny Billquist schreef op 2024-10-04 02:29:
>
>> And just if anyone wonders - yes, that also means you cannot send mail
>> to users on systems that are not currently online.
>> A thing that I always found a bit annoying/irritating.
>>
>> Another reason why I wrote the mail handling for BQTCP to also do the
>> writing and sending as two separate steps, with a queuing in between.
>>
>> Here is how it looks from VMS:
>>
>> MAIL> sen
>> To: Â Â josse::bqt
>> %MAIL-E-LOGLINK, error creating network link to node JOSSE
>> -SYSTEM-F-UNREACHABLE, remote node is not currently reachable
>>
>> MAIL> sen
>> To: Â Â anke::bqt
>> %MAIL-E-LOGLINK, error creating network link to node ANKE
>> -SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node
>>
>> MAIL>
>>
>>
>> It instantly tries to connect, and if that don't work, it immediately
>> fails.
>>
>> Â Johnny
>>
>> On 2024-10-04 01:38, Johnny Billquist wrote:
>>> Sounds like a good improvement.
>>>
>>> However, I saw something about mail here, that you should be aware of...
>>> My MAIL11 implementation is doing the queuing of mails, because that
>>> is normal with SMTP, and I just carried over the same behavior to all
>>> parts of the system.
>>>
>>> However, the "standard" MAIL11 application for RSX as well as RSTS/E
>>> , along with the DECUS MAIL for RSX (and I suspect also VMS) do not
>>> behave that way. If the connecting fails, the sending of mail
>>> immediately fail, and it is not queued for retrying. So it would
>>> appears that the mail for TOPS-20 you look at is also potentially
>>> flawed, which could cause issues.
>>>
>>> Of course, in that case, you'd normally have a human sitting in front
>>> of the terminal, who would then try again...
>>>
>>> Â Â Johnny
>>>
>>> On 2024-10-04 00:05, Thomas DeBellis wrote:
>>>> I thought I would update everyone with where things stand with the
>>>> Tops-20 finger server.
>>>>
>>>> Johnny and I agreed that, by default, the response to a DECnet
>>>> finger query is a sequences of records, each no longer than 132
>>>> bytes (more typically 90), terminated by a line-feed.  Ifthe
>>>> remote finger client or operating system can handle larger buffers,
>>>> then it can connect with optional data=STREAM. Tops-20 will then
>>>> dump everything in one giant record. Only the Tops-20 finger client
>>>> can handle this, although I suspect maybe a VAX client might also be
>>>> able to do it.
>>>>
>>>> I had been making steady progress until I started stress testing it,
>>>> meaning having a session active on MIM::, TOMMYT::, and VENTI2::
>>>> (local), each having a finger command in ready to go and then
>>>> pushing carriage return on all three as simultaneously as possible.
>>>>
>>>> This started generating errors on MIM:: that the "object wasn't
>>>> available". What was going on was that the structure of the Tops-20
>>>> finger server really wasn't architected to have real time response
>>>> for that much curiosity. It only opens a single SRV:117 (finger)
>>>> object at a time, waits for a connection, reads the data, hands it
>>>> off to an idle finger client fork via a pipe, and then gets a new
>>>> SRV:117 object.
>>>>
>>>> In other words, it isn't until the finger client is started with the
>>>> connection redirected to DECnet that the server is ready to accept
>>>> another connection. That has what I would consider to be noticeable
>>>> latency, particularly on failure.   An error doesn'treally matter
>>>> for SMTP as it is a background task and just tries again, later. An
>>>> interactive finger on the other hand, has a user sitting there
>>>> waiting for a response, so it seemed to me that this wasn't really
>>>> going to cutit.
>>>>
>>>> I took the model of the Tops-20 FAL server, which has a single
>>>> control fork, looking for illness in sub-forks, all of which open
>>>> their own FAL server object. The new finger controller now starts
>>>> separate FNGSRV sub-server forks, creating a FINGER sub-fork for
>>>> each, gets all the communications lined up, and starts all the
>>>> FNGSRV sub-forks to listen for connections.
>>>>
>>>> This has the advantage of not clobbering the system on FNGSRV
>>>> startup because resources are gotten or creating sequentially, so
>>>> there isn't much for a FNGSRV sub-fork to do except wait for a
>>>> connection and manage its own single FINGER sub-fork.
>>>>
>>>> Startup resource allocation looks like this:
>>>>
>>>> Â Â Â Â [Fork FNGSRV opening PIP:1;RECORD-LENGTH:200 for writing]
>>>> Â Â Â Â [Fork FNGSRV opening PIP:1.1 for reading]
>>>> Â Â Â Â [Fork FNGSRV opening SRV:117 for reading, writing]
>>>> Â Â Â Â [Fork FNGSRV opening PIP:2;RECORD-LENGTH:200 for writing]
>>>> Â Â Â Â [Fork FNGSRV opening PIP:2.2 for reading]
>>>> Â Â Â Â [Fork FNGSRV opening SRV:117 for reading, writing]
>>>> Â Â Â Â [Fork FNGSRV opening PIP:3;RECORD-LENGTH:200 for writing]
>>>> Â Â Â Â [Fork FNGSRV opening PIP:3.3 for reading]
>>>> Â Â Â Â [Fork FNGSRV opening SRV:117 for reading, writing]
>>>>
>>>> The resulting JFN's being:
>>>>
>>>>         JFN File Mode     Bytes(Size)
>>>>
>>>> Â Â Â Â Â Â Â Â Â 2Â Â FNGSRV.EXE.330Â Â Â Â Â Â Â Â Â Â Â Â Read, Execute
>>>> Â Â Â Â Â Â Â Â Â 3Â Â FINGER.EXE.116Â Â Â Â Â Â Â Â Â Â Â Â Read, Execute
>>>>          15 PIP:1;RECORD-LENGTH:200   Append         0.(8)
>>>>          16 PIP:1.1                   Read           0.(8)
>>>>          17 SRV:117                   Read, Append   0.(8)
>>>>          20 PIP:2;RECORD-LENGTH:200   Append         0.(8)
>>>>          21 PIP:2.2                   Read           0.(8)
>>>>          22 SRV:117                   Read, Append   0.(8)
>>>>          23 PIP:3;RECORD-LENGTH:200   Append         0.(8)
>>>>          24 PIP:3.3                   Read           0.(8)
>>>>          25 SRV:117                   Read, Append   0.(8)
>>>>
>>>> The resulting fork structure is:
>>>>
>>>> Â Â Â Â => FNGSRV (2): HALT at STARTS+13, 0.02719
>>>> Â Â Â Â Â Â Â Â Â Â Fork 12:HALT at 0, 0.00018
>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Fork 13: HALT at 0, 0.00016
>>>> Â Â Â Â Â Â Â Â Â Â Fork 10:HALT at 0, 0.00012
>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Fork 11: HALT at 0, 0.00012
>>>> Â Â Â Â Â Â Â Â Â Â Fork 6: HALT at 0, 0.00008
>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Fork 7: HALT at 0, 0.00007
>>>>
>>>> So fork 2 is the finger server controller, forks 12, 10, and 6 are
>>>> finger server sub-forks, and forks 13, 11, and 7 are the respective
>>>> Tops-20 finger clients. Times are in tens of microseconds, the
>>>> maximum resolution that Tops-20 supports. What can be seen is that
>>>> fork creation is happening in sub-millisecond time. This was notthe
>>>> case in the 1980's with KL10's (I /think/), and modifications were
>>>> necessary to Tops-20 and the EXEC to capture the increased resolution.
>>>>
>>>> I guess I'll have another version ready in about two weeks.
>>>>
>>>>
>>>> _______________________________________________
>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>>> <mailto:hecnet@lists.dfupdate.se>
>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>>> <mailto:hecnet-leave@lists.dfupdate.se>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Some time ago, I asked about a list of DECnet generic objects and what
they meant. I remember seeing a response and now I can't find it or
what I thought I saved as a file. Could somebody send me that again?Â
For now, all I have is what SYSDPY shows. This is an annotated list
(note that numbers are octal unless otherwise specified:
_Object#_ _Name_ _Comment_
        0     TASK
        1     FAL1
        2     URDS           Unit Record Device Service (DN200)
        3     ATS
        4     CTS
        5     TCL1
        6     OSI
        7     NRM
       10     3270           3270 Terminal
       11     2780           2780 Remote Job Entry protocol
       12     3790
       13     TPS
       14     DIBOL
       15     T20TRM         Tops-20/Tops-10/Ultrix Network Remote
Terminal (NRT)
       16     T20RSP
       17     TCL
       20     TLK
       21     FAL            File Access Listener
       22     RTL
       23     NCU            NICE?
       24     NETCPY
       25     ONCTH
       26     MAIL           How different from MAIL11?
       27     NVT
       30     TCON
       31     LOOP           Loopback Testing
       32     EVENT          DECnet Event Reporting
       33     MAIL11         VAX mail?
       34     FTS            File Transfer Service
       35     PHONE          Phone
       36     DDMF
       37     X25GAT         X.25 gateway
       40     UETP           User Environment Test Package
       41     VXMAIL
       42     X29SRV
       43     RDS
       44     X25HST         X.25 Host
       45     SNAGAT         SNA Gateway
       46     SNARJE         SNA Remote Job Entry
       47     SNAGIS
       50     MTSS
       51     ELF
       52     CTERM          Control Terminal
       53     DNSTA
       54     DNSUL
       55     DHCF
     ^D47     POSI           Remote OPR
     ^D63     DTR
     ^D65     TOPOL
     ^D66     DQS            Digital Queue Service (LAT?)
    ^D117     FINGER         Personal Name service
    ^D123     PMR
    ^D201     MS
I needed to take a break from finishing up the Tops-20 DECnet/SMTP code,
so I finally looked into doing a Tops-20 finger server.Over the weekend,
I cobbled something together.For example, on TOMMYT::
FINGER>oinky@venti2 /no-plan
OINKYGuinea PigOINKY not logged in
Last logout Sun 1-Sep-2024 1:40AM from TTY6 (NRT)
No new mail, last read on Tue 12-Apr-2022 10:00PM
The finger server is multi-forking and works by creating a group of
forks, putting the finger program in each fork and changing the primary
input and output to whatever connection is being served.It is general
enough so that you could probably have it run any program with little
tinkering.
Right now, it is in debugging mode and typing a lot of diagnostic
information about the link.So, for the above attempt from the client,
the finger server console output was:
FNGSRV: Connection from TOMMYT, User: SLOGIN, Data: Tops-20_Finger
Object Type: Generic (165), Segment Size: 1459
Local Flow Control: Segment, Remote Flow Control: Segment
Link Quota: Input Percentage: 50, Buffers: 16, Input Goal: 0
As can be seen, the Tops-20 finger client has been modified to send the
name of the local user and optional data identifying the finger
client.Probably I’ll change that to the finger version.The RFC for
TCP/IP finger is (naturally) silent on what you can send over DECnet, so
this doesn’t break anything.So, I can finger myself on MIM:: just fine, viz:
FINGER>debellis@mim
[Default directory: US00:[DEBELLIS]CLI: DCLSID: TDB
Last seen Sep 16 2024 23:04:37 on RT0: from VENTI2::
Logged on 16 times.
No plan.
Unfortunately, it /doesn’t /work when I sign on to MIM:: and try the
local finger client there, viz:
$ finger -d VENTI2::OINKY
[VENTI2::]
$
So, no obvious failure, but no output, either. On VENTI2::, what I’m
seeing appears to be a successful connection and that the finger program
running in the sub-fork is opening OINKY’s finger plan and sending it
back over the link, viz:
[Fork FNGSRV opening SRV:117 for reading, writing]
FNGSRV: Connection from MIM, Task: DEBELLIS
Object Type: Generic (165), Segment Size: 558
Local Flow Control: Segment, Remote Flow Control: Message
Link Quota: Input Percentage: 50, Buffers: 16, Input Goal: 0
[Fork 2 opening TOMMYT:FINGER.BIN.5 for reading thawed]
[Fork 2 opening TOMMYT:<OINKY>FINGER.PLAN.4 for reading]
Currently, the finger server is highly instrumented, so if it detected
that something was amiss (like the finger sub-fork was flat out
croaking), it would complain about it. Or it should… Finger itself is
not so highly instrumented as I wanted to make the changes there as
small as possible.
If you have a finger client that can do DECnet connections on another
platform (I’m thinking VMS or maybe RSTS) and can try it, let me know
how you make out. Be aware that I did just hack this together in two and
a half days, so I make no claims to any sort of stability. I'm just
trying to trouble shoot at this point.
—T
To the neighbors of area 27:
I have a new ISP which will hopefully prove better than Comcast did. My new addresses are:
IPv4: 165.188.116.102
IPv6: 2601:b058:1ff:0:d48b:ea7e:93ea:b795
As always, these addresses are in DNS as decnet.theberrymans.com <http://decnet.theberrymans.com/>.
I’m still making the final necessary changes on my router but everything should be up and running by the end of the day (GMT -0600).
Mark Berryman
I'm a bit late to the party, but I figured I'd chime in here anyway
8-}
I was the maintainer of VMS Finger from V50.1.00 (when I took it over
from Rand Hall) until V50.1.35 which was the last release in July 2000.
Which Finger you get by default (and what it supports) on VMS depends on
which TCP/IP package you have. There's no native DECnet-only Finger.
I've started working on VMS Finger again, including back-porting the
V50.1.35 back to VAX/VMS - VAX support was essentially frozen at
V50.1.29.
Idle time on VMS is a bucket full of eels - VMS kept track of idle
time
on physical terminals. I'm not sure if it still does. It never did it
for
terminal-like connections. Brian Schenkenberger wrote a loadable execu-
table image, loaded at boot time, that provides idle monitoring for TT
devices, as well as hooks to add monitoring of other terminal devices.
A separate utility hooks into it during normal systartup_vms.com proces-
sing to add monitoring to RT devices (since that device didn't exist at
boot time). Although it is copyrighted by him, he allows it to be dis-
tributed with VMS Finger (and it works on both VAX and Alpha). I never
had an Itanium system of my own (and never desire to), so if you have
one
and want to run Finger on it, drop me an email and I'll send you a test
kit once I have VMS Finger closer to release state.
Here's an example of VMS Finger (running on a real VAX to a virtual-
ized Alpha):
VX4200::$ finger @server/idle/version
[SERVER.DECnet]
OpenVMS Finger: Version V51.1.36 of 23-Aug-2024
Unauthorized Access Strictly Prohibited
SERVER DS10 616 MHz, OpenVMS V8.4-2L1, Thu, 12-Sep-2024 21:28, 4 Users,
0 Batch
Uptime 19 18:55, since Sat, 24-Aug-2024 02:33, Load: 0.06 0.04 0.07
PID Username Program Term Login CPU Idle Location
TT Type
0000AD16 TERRY $ NTY13: 02:55 0:00 1:19
bedroom.glaver.o VT3xx
0000AA2B TERRY Ltpad NTY14: 02:56 0:00 18:30
bedroom.glaver.o VT3xx
00008634 TERRY Ua NTY12: 16:47 0:38 1:19
portable3-wl.gla VT3xx
0000C496 TERRY $ NTY15: 14:00 0:00 2
office.glaver.or VT3xx
0000C497 TERRY Ltpad NTY16: 14:01 0:00 7:26
office.glaver.or VT3xx
Some info on that display - by default, if the node being fingered
looks like it could be a DECnet Phase IV node, it tries DECnet first.
If you specify something that either isn't a known DECnet node or can't
possibly be a DECnet node, it uses TCP/IP:
VX4200::$ finger @server.glaver.org/idle/version
[SERVER.GLAVER.ORG]
OpenVMS Finger: Version V51.1.36 of 23-Aug-2024
Unauthorized Access Strictly Prohibited
SERVER DS10 616 MHz, OpenVMS V8.4-2L1, Thu, 12-Sep-2024 21:31, 4 Users,
0 Batch
Uptime 19 18:57, since Sat, 24-Aug-2024 02:33, Load: 0.07 0.07 0.07
PID Username Program Term Login CPU Idle Location
TT Type
0000AD16 TERRY $ NTY13: 02:55 0:00 1:21
bedroom.glaver.o VT3xx
0000AA2B TERRY Ltpad NTY14: 02:56 0:00 18:33
bedroom.glaver.o VT3xx
00008634 TERRY Ua NTY12: 16:47 0:38 1:21
portable3-wl.gla VT3xx
0000C496 TERRY $ NTY15: 14:00 0:00 4
office.glaver.or VT3xx
0000C497 TERRY Ltpad NTY16: 14:01 0:00 7:29
office.glaver.or VT3xx
VMS Finger will still try to link code for use with Joiner Associates'
JNET (BITNET) networking stack if you ask for it, but it is untested for
decades. If anyone is still running JNET and connected to something,
drop me an email.
I'm only testing as far back as VAX/VMS V7.3 right now. Eventually
I'll
see how far back I can go. Hopefully VMS V5.5-2 and ideally VMS V4.4.
So much for VMS Finger...
I'm also the creator of RSTS/E Finger. It is DECnet-only, but can be
con-
figured to use any DECnet node as a gateway, either to other DECnet
areas
or to TCP/IP hosts.
Here's RSTS/E 10.1 being Fingered from VMS:
SERVER::$ finger @pidp11/version
[PIDP11.DECnet]
RSTS/E Finger: Version V1.2-09 of 06-Sep-2024
RSTS/E Your Organization Name Here PiDP-11
PIDP11 PDP-11/70, RSTS V10.1-L, Friday, 12-Sep-1924 21:33, 9 Jobs, 63
Max.
Uptime 4 07:33:52, since Monday, 8-Sep-1924 14:00
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location
TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:03 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:06 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB33: 14:01 00:00 ^C SERVER::[11,376]
VT320
8 TERRY 20,254 DCL KB34: 02:57 00:00 ^C SERVER::[11,376]
VT320
9 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
And here is RSTS/E 10.1 Fingering an Internet host:
$ finger @mim.stupi.net
[MIM.STUPI.NET via routing host SERVER]
[SERVER.DECnet]
[MIM.STUPI.NET]
RSX-11M-PLUS system MIM. Fri Sep 13 03:39:27 2024. Up: 1 day, 4:44.
Luser Real name Term Idle Logged in From
BILLQUIST Johnny Billquist TT15: 17 12 Sep 14:53
s-5eeaac7c-74736162
RSTS/E Finger requires RSTS/E V9.6 or later, since the DECnet/E
it relies on is V4.1, which itself requires RSTS/E V9.6 or later.
Moving right along:
I also wrote an MS-DOS Finger implementation. That isn't as useless
as it sounds. If you just say "finger", you get the message "You are
the only user, of course". But like RSTS/E Finger, it uses DECnet
(Pathworks or whatever product name du jour that product has). The
code still exists, but I don't know of any modern Microsoft Windows
system that has a DECnet stack available for it. If anyone knows of
a DECnet implementation that runs under Windows 10, let me know and
I'll resurrect MS-DOS finger as a CLI application for Windows. I can
even sign it 8-}
Once I have VMS and RSTS/E Finger updated to where I want them,
I'd love to have a network interoperability bake-off with as many
other implementations as possible. Probably the oddest one I ran
into in my testing 30+ years ago was the front-end CPU for a Cray.
--
Terri Kennedy
Version 5.3(277)-5 incorporates additional features, enhancements and
fixes since edit release 5.3(255)-5 in March of this year (29-Mar-2024).
Users of the HECnet community may anonymously transfer files from
VENTI2::TOMMYT:<OINKY.K20MIT> and related subdirectories.
The changes are summarized below and are further described in
TOMMYT:<OINKY.K20MIT.DOCUMENTATION>KERMIT-20_V5_3_277-5-ANNOUNCEMENT.TXT.
Rich text is also available in and .PDF and Microsoft .DOCX format.
Note that the FAL server on VENTI2:: is *beta code* which required
modifications to Tops-20 in order to function properly in an edge case
that could happen at boot time. Please email me any issues with FAL
transfers off list and I will investigate.
------------------------------------------------------------------------
[256] /PARITY switch to ECHO for batch and other testing purposes[257]
Teach INPUT to respect parity, if asked
[258] SET PARITY action /ABORT, /PROCEED
[259] Fix a few arcane bugs in the C constant expression expander
[260] Fix DEFINE to work (again) with ESCAPE and PARITY
[261] Decrease repeated parity error messing
[262] Remove the legacy INPUT code that uses BIN%'s
[263] Stop using a SIN% for a line at a time read
[264] Toggle session logging from command level
[265] Fix TTY Input Buffer full when doing a TRANSMIT on a PTY
[266] Turn TRANSMIT and CAPTURE increasingly hairy switches in SET
parameters
[267] Give effective data rate at end of TRANSMIT
[268] CAPTURE is no longer hidden. Further document it
[269] Review, update and correction of all help text
[270] Enhance default for SET PROMPT to give some extra useful information
[271] Fix TVT setting; it gets overwritten by automatic processing
[272] SET TRANSMIT DEFAULT-PROMPT
[273] SET TRANSMIT CASE OBSERVE/IGNORE
[274] Fix SET INPUT to better support DEFINE
[275] SET TRANSMIT SETTINGS-DEFAULTS for backwards compatibility
[276] Fix indirect recursion crash when reporting an error with REALLY
short packets
[277] Variable blips (so we don't get clobbered for very small packets)
Kermit-20-Testing-Battery-5.3(277)-5 Updates
Updated Help
Has anybody ever used this and had success with it? The magic switches,
please?
backwr.c is a user contribution to klh10 to write tape files that can be
'mounted' on a 10/20. It comes with no documentation nor does it
describe its usage. I puzzled out the command line parser and did:
./backwr -c -T -f ../k20mit-277/k20mit-277.tar > k20tar.tap
I want to copy the tar file off the tape to try to read it on the 20
with the 20's implementation of tar.
However, when I try to copy the file off the tape, I get ?File data
error on file MTA0:
If not backwr, what are alternative solutions? The klh10 micro-engine's
NI implementation has odd behavior in that if you do a download, you get
megabit speeds. If you try to upload on the other hand, you can barely
crack 1 kilobaud. So I'm currently uploading the tarball with Kermit,
but at 1KBd, it's going to take three days.
Hi,
I've been using narkive.com in readonly mode to look at comp.os.vms until fairly recently.
Now my browser is making the connection and it's being dropped by the other end.... that is, when I'm calling from a UK IP address.
If I change my location (access to several UK and non-UK points of presence) to an non-UK address, I can connect without a problem.
So far 8 uk-based ISPs (mobile and residential) are being dropped and 6 non-uk (US E, US W, Lux, Japan and Aus) are ok.
Pinging works from all.
Has narkive.com blocked connections from UK addresses?
Keith
I had been making some efficiency tweaks to a few things, particularly
GLXLIB, the Galaxy Object Time System when I began to notice that
programs sometimes appeared to not be using any processor time at all.Â
I found that the normal JSYS that returns fork run time (RUNTM%) only
gives millisecond resolution.
Tops-20 exposes a 100 Khz interface via the HPTIM% JSYS. 'High
precision' in this case meant the maximum internal clock rate of the
DK10 real time clock. So, although the KL10 had a megahertz clock,
Tops-20 lops off a decimal order of magnitude, presumably to remain
compatible with TENEX. The maximum resolution is thus 10 microseconds,
a hundred times the RUNTM% resolution.
Unfortunately, the HPTIM% JSYS only works for your own process, not
others. So, I modified the monitor code to be able to get high
precision run times for any forks in the job. I then modified the EXEC
to display the high precision times if requested. What I also found out
was that, by default, the EXEC will only display a tenth of a second,
whereas RUNTM% will return two decimal orders of magnitude more.
The comparisons below are perhaps of interest. About the shortest I've
seen is 1.5 ms (0.00015). Given the increasing speed of simulations,
one assumes that DK10 resolution will be exceeded at some point.
------------------------------------------------------------------------
$i fork ORION (1): Background, SLEEP at 767721, 0:00:00.1 QUASAR (2):
Background, SLEEP at 767721, 0:00:00.0 MOUNTR (3): Background, SLEEP at
2420, 0:00:00.0 BATCON (4): Background, SLEEP at 767723, 0:00:00.1
NMLT20 (5): Background, SLEEP at US%DES+165, 0:00:00.0 => FAL (6):
Background, SLEEP at 767721, 0:00:00.0 Fork 13: SLEEP at 767723,
0:00:00.0 Fork 12: SLEEP at 767723, 0:00:00.0 Fork 11: SLEEP at 767723,
0:00:00.0 Fork 10: SLEEP at 767723, 0:00:00.0 Fork 7: SLEEP at 767723,
0:00:00.0 $ $i fork /high-precision ORION (1): Background, SLEEP at
767721, 0:00:00.12459 QUASAR (2): Background, SLEEP at 767721,
0:00:00.05135 MOUNTR (3): Background, SLEEP at 2420, 0:00:00.06751
BATCON (4): Background, SLEEP at 767723, 0:00:00.19957 NMLT20 (5):
Background, SLEEP at US%DES+165, 0:00:00.09560 => FAL (6): Background,
SLEEP at 767721, 0:00:00.08322 Fork 13: SLEEP at 767723, 0:00:00.01310
Fork 12: SLEEP at 767723, 0:00:00.01577 Fork 11: SLEEP at 767723,
0:00:00.00381 Fork 10: SLEEP at 767723, 0:00:00.00362 Fork 7: SLEEP at
767723, 0:00:00.00320
