19 May
2023
19 May
'23
2:52 a.m.
I finished the auto-mounting code for Tops-20 DAP, viz:
NFT>*dir venti2::dsk*:<Help>units.hlp*
VENTI2::TOMMYT:<HELP>
UNITS.HLP.1;P777752 1 2210(7) 28-Apr-1980 17:23:03
VENTI2::TOPS20:<HELP>
UNITS.HLP.1;P777752 1 2210(7) 28-Apr-1980 17:23:03
NFT>
Over in FAL, one finds the following debugging output:
[Received Access message (Flg=LEN Cnt=30.)]
[Parsing Access message]
[DSK*: PS:<HELP>UNITS.HLP.1, JFN 7, Unit* High]
[Trying file TOMMYT:<Help>units.hlp]
[Assigned JFN 7, Unit* High]
.
.
.
[Trying file STAR:<Help>units.hlp]
[Failed. No such directory name]
[Mounted file structure TOPS20: on behalf of SLOGIN]
[Trying file TOPS20:<Help>units.hlp]
[Assigned JFN 7, Unit* High]
.
.
.
[Dismounted file structure TOPS20: on behalf of SLOGIN]
Like many things I do, I tend to have an overly optimistic if not naive
idea of the development involved and bump into edge cases. I had to
split DAPLIB up into three separate sources to accommodate the changes,
which kept getting longer as I found another case I hadn't considered.
The same thing happened in spades when I put NRT support into
Kermit-20. The changes were so pervasive that I started looking around
for regression tests. C-Kermit itself has wonderful scripting, which
you can even use to write a compiler. But not testing scripts, so I
wrote my own batch control files.
Anybody know what's available for DECnet; in particular, DAP? I seem to
remember there being something for UETP, but it wasn't extensive.
20 May
20 May
2:23 a.m.
There are some test scripts and tools in the RSX DECnet sources, but
they are really RSX specific, and for testing RSX against different
types of systems.
I've never used them, and I don't know what would be required for them
to even be usable.
Apart from those, I don't think I've seen anything.
But there is something for RSX, which might be answering parts of your
question, but it's nothing general.
Johnny
On 2023-05-19 02:52, Thomas DeBellis wrote:
I finished the auto-mounting code for Tops-20 DAP,
viz:
NFT>*dir venti2::dsk*:<Help>units.hlp*
VENTI2::TOMMYT:<HELP>
UNITS.HLP.1;P777752 1 2210(7) 28-Apr-1980 17:23:03
VENTI2::TOPS20:<HELP>
UNITS.HLP.1;P777752 1 2210(7) 28-Apr-1980 17:23:03
NFT>
Over in FAL, one finds the following debugging output:
[Received Access message (Flg=LEN Cnt=30.)]
[Parsing Access message]
[DSK*: PS:<HELP>UNITS.HLP.1, JFN 7, Unit* High]
[Trying file TOMMYT:<Help>units.hlp]
[Assigned JFN 7, Unit* High]
.
.
.
[Trying file STAR:<Help>units.hlp]
[Failed. No such directory name]
[Mounted file structure TOPS20: on behalf of SLOGIN]
[Trying file TOPS20:<Help>units.hlp]
[Assigned JFN 7, Unit* High]
.
.
.
[Dismounted file structure TOPS20: on behalf of SLOGIN]
Like many things I do, I tend to have an overly optimistic if not naive
idea of the development involved and bump into edge cases. I had to
split DAPLIB up into three separate sources to accommodate the changes,
which kept getting longer as I found another case I hadn't considered.
The same thing happened in spades when I put NRT support into
Kermit-20. The changes were so pervasive that I started looking around
for regression tests. C-Kermit itself has wonderful scripting, which
you can even use to write a compiler. But not testing scripts, soI
wrote my own batch control files.
Anybody know what's available for DECnet; in particular, DAP? I seem to
remember there being something for UETP, but it wasn't extensive.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)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
24 May
24 May
8:15 p.m.
On May 19, 2023, at 8:23 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
There are some test scripts and tools in the RSX DECnet sources, but they are really RSX
specific, and for testing RSX against different types of systems.
I've never used them, and I don't know what would be required for them to even be
usable.
Apart from those, I don't think I've seen anything.
But there is something for RSX, which might be answering parts of your question, but
it's nothing general.
PyDECnet comes with a large body of unit tests.
But apart from that, it does seem the picture is pretty bleak. RSTS (DECnet/E) has two
set of tests; I'm not sure if both are published or some are internal only.
One set is the "exerciser", part of a suite of "xyEXER" programs to
put test loads on various I/O subsystems. For example there are also disk and tape
exercisers. Those were done partly for installation checkout by customers, and may also
help with the final assembly and test process that DEC used for PDP-11 systems. Those
were normally load-tested with RSTS, for those hardware configs that RSTS can run on. The
experience was that RSTS was better at breaking marginal problems than other tests,
certainly better than the diagnostics.
The other test set is the DTS/DTR (or DTSEND/DTRECV) program pair, which can do DECnet
traffic tests with a variety of parameters. In RSTS, flow control is chosen by the
application rather than the DECnet core, and DTS/DTR allow data tests to be run with all
the flow control variants.
paul
8:35 p.m.
On May 24, 2023, at 2:15 PM, Paul Koning
<paulkoning(a)comcast.net> wrote:
And that suggests an interesting notion. Many of those tests are of the form:
1. Construct a test packet
2. Submit that test packet to the system being tested (PyDECnet)
3. If a response is expected, check that it arrives and contains what we expect
4. Check the resulting sytem state
Those could, in many cases, be adapted to do "black box" testing of other DECnet
implementations. The key difference is that as written the tests typically poke at a
single protocol layer, and check state by looking into the internals of the layer. A
black box test would have to wrap the test packets in the necessary lower layer envelopes
to get them to the destination, and the state checks would be limited to what is visible
via the management interface (counters and state) or other application APIs.
Those would not be terribly difficult things to do. For example, PyDECnet already
contains lower layer envelope descriptions, so to take, say, an NSP test packet and wrap
it in routing and datalink layer envelopes is not hard to do, nor is unwrapping the
reply.
One part of my PyDECnet tests is random packet tests, where I construct random crud to
send to a layer to verify that it doesn't die. Obviously random packets don't do
anything useful, and typically would just get discarded, but it's well known that such
abuse tests often break code that isn't sufficiently paranoid. It would be
entertaining to subject other DECnets to such abuse.
paul
On May 19, 2023, at 8:23 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
There are some test scripts and tools in the RSX DECnet sources, but they are really RSX
specific, and for testing RSX against different types of systems.
I've never used them, and I don't know what would be required for them to even be
usable.
Apart from those, I don't think I've seen anything.
But there is something for RSX, which might be answering parts of your question, but
it's nothing general.
PyDECnet comes with a large body of unit tests. 
25 May
25 May
6:39 p.m.
-----Original Message-----
From: Paul Koning <paulkoning(a)comcast.net>
Sent: 24 May 2023 19:36
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: DECnet Regression Tests?
they
On May 24, 2023, at 2:15 PM, Paul Koning
<paulkoning(a)comcast.net>
wrote:
>
>
>
>> On May 19, 2023, at 8:23 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
>>
>> There are some test scripts and tools in the RSX DECnet sources, but are really RSX specific, and for testing RSX against
different types of
systems.
>
> I've never used them, and I don't know what would be required for them
to even be usable.
>
> Apart from those, I don't think I've seen anything.
> But there is something for RSX, which might be answering parts of your
question, but it's nothing general.
PyDECnet comes with a large body of unit tests.
And that suggests an interesting notion. Many of those tests are of the
1. Construct a test packet
2. Submit that test packet to the system being tested (PyDECnet) 3. If a
response is expected, check that it arrives and contains what we expect 4.
Check the resulting sytem state
Those could, in many cases, be adapted to do "black box" testing of other
DECnet implementations. The key difference is that as written the tests
typically poke at a single protocol layer, and check state by looking into
the
internals of the layer. A black box test would have
to wrap the test
packets in
the necessary lower layer envelopes to get them to the
destination, and
the
state checks would be limited to what is visible via
the management
interface
(counters and state) or other application APIs.
Those would not be terribly difficult things to do. For example, PyDECnet
already contains lower layer envelope descriptions, so to take, say, an
NSP
test packet and wrap it in routing and datalink layer
envelopes is not
hard to
do, nor is unwrapping the reply.
One part of my PyDECnet tests is random packet tests, where I construct
random crud to send to a layer to verify that it doesn't die. Obviously
random packets don't do anything useful, and typically would just get
discarded, but it's well known that such abuse tests often break code that
isn't sufficiently paranoid. It would be entertaining to subject other
DECnets
to such abuse.
I usually write a lot of automated tests, but for my own user mode router I
didn't do that, which makes me feel very bad. It would be interesting to
subject my router to a fuzz test to see how it copes
.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email
to hecnet-leave(a)lists.dfupdate.se
18 Jun
18 Jun
6:56 p.m.
I have learned the hard way to never trust anything I write until I've
run tests on it... The worst part is that I keep having to relearn it.
The hard way...
These days, I try to write the tests with the code, pounding on the edge
cases, /first/.
Part of the reason that I'm coding diagnostic packet decoding (for
configuration negotiation, for example) is to eventually put together
some 'fuzz' tests. Assuming I break something, it should enable me to
more quickly understand why something blew up. That's the hope,
anyway. If nothing else, I've gained a better understanding of DAP.
------------------------------------------------------------------------
On 5/25/23 12:39 PM, Rob Jarratt wrote:
form:
-----Original Message-----
From: Paul Koning<paulkoning(a)comcast.net>
Sent: 24 May 2023 19:36
To: The Hobbyist DECnet mailing list<hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: DECnet Regression Tests?
they
On May 24, 2023, at 2:15 PM, Paul
Koning<paulkoning(a)comcast.net>
wrote:
>
>
>> On May 19, 2023, at 8:23 PM, Johnny Billquist<bqt(a)softjar.se> wrote:
>>
>> There are some test scripts and tools in the RSX DECnet sources, but are really RSX specific, and for testing RSX
against different types of
systems.
>
I've never used them, and I don't know what would be required for them
to
even be usable.
> Apart from those, I don't think I've
seen anything.
> But there is something for RSX, which might be answering parts of your
question, but it's nothing general.
PyDECnet comes with a large body of unit tests.
And that suggests an interesting notion. Many of those tests are of the 1. Construct a test packet
2. Submit that test packet to the system being tested (PyDECnet) 3. If a
response is expected, check that it arrives and contains what we expect 4.
Check the resulting sytem state
Those could, in many cases, be adapted to do "black box" testing of other
DECnet implementations. The key difference is that as written the tests
typically poke at a single protocol layer, and check state by looking into
the
internals of the layer. A black box test would
have to wrap the test
packets in
the necessary lower layer envelopes to get them
to the destination, and
the
state checks would be limited to what is visible
via the management
interface
(counters and state) or other application APIs.
Those would not be terribly difficult things to do. For example, PyDECnet
already contains lower layer envelope descriptions, so to take, say, an
NSP
test packet and wrap it in routing and datalink
layer envelopes is not
hard to
do, nor is unwrapping the reply.
One part of my PyDECnet tests is random packet tests, where I construct
random crud to send to a layer to verify that it doesn't die. Obviously
random packets don't do anything useful, and typically would just get
discarded, but it's well known that such abuse tests often break code that
isn't sufficiently paranoid. It would be entertaining to subject other
DECnets
to such abuse.
I usually write a lot of
automated tests, but for my own user mode router I
didn't do that, which makes me feel very bad. It would be interesting to
subject my router to a fuzz test to see how it copes
.
paul
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se To unsubscribe send an
email
tohecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
325
days inactive
355
days old
5 comments
4 participants
participants (4)
-
Johnny Billquist -
Paul Koning -
Rob Jarratt -
Thomas DeBellis