Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
30 Jan
2022
30 Jan
'22
1:04 a.m.
L.S.
With a bit time on hand and the standstill after Paul's initial test from
dup to pydecnet which appeared to be successful, I now undertook a test as
Mark liked to have it preferably.
So I did a fresh netgen on a simple configuration from simple basic install
Rsx11MP system for only a Decnet end-node with one single Dup line
communicating to a known working Pdp11 Rsx11MP Dmc circuit.
I saw no difference from what I reported initially and later with logging,
as was to be expected; my complex setup behaves exactly the same in this
respect as it does for years in a complex network setup for Rsx and Rsts,
and RT11 without network.
This is on a Windows-2008R2 server and I suspect Paul did his test on
unix/linux , however although it differs, that should be moot as far as
Simh is concerned.
There could be another difference though. Paul would probably have taken the
default route and used Ddcmp withouth KG11 support: Dup without Kdp is the
only sync line to use it, though async Decnet DL/DZ/VH might use it as well.
As I prefer the most complex configs possible (any two of a kind where
possible as Dec used to have them), I do also employ the KG11, so for Dup
support it will be used when configured so in Decnet11MP.
On a sim it is not that effective, but in hardware in the past it did make a
difference for fast crc computing.
So I retested with no KG11 support and indeed, now the Dup works as
expected.
What appears to be strange is, that small packets up to 8 bytes are not
corrupted but the larger ones do. Maybe in Decnet11MP, the small packets are
totally preconfigured in the software program with crc inclusive and the
KG11 is then bypassed effectively, bu, that should have to be verified. At
least the combination KG11 and Decnet11MP KG11 support is defective.
So Simh Dup works in software Ddcmp packet generation, but the Simh KG11
seem to generate bad checksums and/or checks.
For the Pdp8A, I have a functioning KG8 simulation that works in Rts-8, so
there is a test reference to fall back on.
So I admit and confirm that basic Dup in simh software wise between Pdp11's
and with various counterparts (DMC) indeed works, which would make it serve
as a base for other sync line implementations like DP8-E(A).
Reindert
-----Original Message-----
From: owner-hecnet(a)Update.UU.SE [mailto:owner-hecnet@Update.UU.SE] On Behalf
Of Paul Koning
Sent: Thursday, 23 December, 2021 20:18
To: hecnet(a)update.uu.se
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests
reveals problems --> test setup?
On Dec 23, 2021, at 4:14 AM, R. Voorhorst
<R.Voorhorst(a)swabhawat.com>
wrote:
Hi Paul,
How was this tested: 11M+ to 11M+ or 11M+ to PyDecnet?
M+ to PyDECnet, with Wireshark watching the traffic.
I'm going to do some tracing in SIMH. It may be that the behavior depends
on how the driver talks to the emulated device.
paul
30 Jan
30 Jan
1:25 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote:
L.S.
With a bit time on hand and the standstill after Paul's initial test from dup to
pydecnet which appeared to be successful, I now undertook a test as Mark
liked to have it preferably.
So I did a fresh netgen on a simple configuration from simple basic install
Rsx11MP system for only a Decnet end-node with one single Dup line
communicating to a known working Pdp11 Rsx11MP Dmc circuit.
I saw no difference from what I reported initially and later with logging, as
was to be expected; my complex setup behaves exactly the same in this
respect as it does for years in a complex network setup for Rsx and Rsts, and
RT11 without network.
This is on a Windows-2008R2 server and I suspect Paul did his test on
unix/linux , however although it differs, that should be moot as far as Simh is
concerned.
There could be another difference though. Paul would probably have taken
the default route and used Ddcmp withouth KG11 support: Dup without Kdp
is the only sync line to use it, though async Decnet DL/DZ/VH might use it as
well.
As I prefer the most complex configs possible (any two of a kind where
possible as Dec used to have them), I do also employ the KG11, so for Dup
support it will be used when configured so in Decnet11MP.
On a sim it is not that effective, but in hardware in the past it did make a
difference for fast crc computing.
So I retested with no KG11 support and indeed, now the Dup works as
expected.
What appears to be strange is, that small packets up to 8 bytes are not
corrupted but the larger ones do. Maybe in Decnet11MP, the small packets
are totally preconfigured in the software program with crc inclusive and the
KG11 is then bypassed effectively, bu, that should have to be verified. At
least the combination KG11 and Decnet11MP KG11 support is defective.
So Simh Dup works in software Ddcmp packet generation, but the Simh KG11
seem to generate bad checksums and/or checks.
For the Pdp8A, I have a functioning KG8 simulation that works in Rts-8, so
there is a test reference to fall back on.
So I admit and confirm that basic Dup in simh software wise between Pdp11's
and with various counterparts (DMC) indeed works, which would make it
serve as a base for other sync line implementations like DP8-E(A).
So, you've proven to yourself that the KG11 is at least somewhat broken.
Looking back at the change history for this device, I've made changes relating
to how it glues into the PDP11 I/O space, but nothing at all about how the
device actually functions.
What else uses this device?
Is there a diagnostic?
- Mark
1:37 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 2022-01-30 01:04, R. Voorhorst wrote:
L.S.
With a bit time on hand and the standstill after Paul's initial test from
dup to pydecnet which appeared to be successful, I now undertook a test as
Mark liked to have it preferably.
So I did a fresh netgen on a simple configuration from simple basic install
Rsx11MP system for only a Decnet end-node with one single Dup line
communicating to a known working Pdp11 Rsx11MP Dmc circuit.
I saw no difference from what I reported initially and later with logging,
as was to be expected; my complex setup behaves exactly the same in this
respect as it does for years in a complex network setup for Rsx and Rsts,
and RT11 without network.
This is on a Windows-2008R2 server and I suspect Paul did his test on
unix/linux , however although it differs, that should be moot as far as
Simh is concerned.
There could be another difference though. Paul would probably have taken the
default route and used Ddcmp withouth KG11 support: Dup without Kdp is the
only sync line to use it, though async Decnet DL/DZ/VH might use it as well.
As I prefer the most complex configs possible (any two of a kind where
possible as Dec used to have them), I do also employ the KG11, so for Dup
support it will be used when configured so in Decnet11MP.
I would suspect Paul did not run with KG11.
I agree that the host system shouldn't make a difference.
On a sim it is not that effective, but in hardware in
the past it did make a
difference for fast crc computing.
Actually, as the DECnet installation manual mentions, on an 11/44 or
11/70, you probably do not want to use the KG11 even if you have it, as
the software computation is faster than the hardware device
(see page 5-31 of the DECnet-RSX generation and installation manual).
So I retested with no KG11 support and indeed, now the
Dup works as
expected.
What appears to be strange is, that small packets up to 8 bytes are not
corrupted but the larger ones do. Maybe in Decnet11MP, the small packets are
totally preconfigured in the software program with crc inclusive and the
KG11 is then bypassed effectively, bu, that should have to be verified. At
least the combination KG11 and Decnet11MP KG11 support is defective.
No. Nothing is "preconfigured" about this. Seems the KG11 device in simh
have some bug, but this should be investigated more I guess.
But short packets just might not be triggering the bug.
Johnny
--
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
7:30 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On Jan 29, 2022, at 7:37 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-01-30 01:04, R. Voorhorst wrote:
Correct, I was not aware it's possible to use it. The only software I have seen that
uses the KG11 is 2780 emulation.
L.S.
With a bit time on hand and the standstill after Paul's initial test from
dup to pydecnet which appeared to be successful, I now undertook a test as
Mark liked to have it preferably.
So I did a fresh netgen on a simple configuration from simple basic install
Rsx11MP system for only a Decnet end-node with one single Dup line
communicating to a known working Pdp11 Rsx11MP Dmc circuit.
I saw no difference from what I reported initially and later with logging,
as was to be expected; my complex setup behaves exactly the same in this
respect as it does for years in a complex network setup for Rsx and Rsts,
and RT11 without network.
This is on a Windows-2008R2 server and I suspect Paul did his test on
unix/linux , however although it differs, that should be moot as far as
Simh is concerned.
There could be another difference though. Paul would probably have taken the
default route and used Ddcmp withouth KG11 support: Dup without Kdp is the
only sync line to use it, though async Decnet DL/DZ/VH might use it as well.
As I prefer the most complex configs possible (any two of a kind where
possible as Dec used to have them), I do also employ the KG11, so for Dup
support it will be used when configured so in Decnet11MP.
I would suspect Paul did not run with KG11. I agree that the host system shouldn't make a
difference.
Not unless it's big endian, in which case getting this stuff to come out right
requires some care.
On a sim it is
not that effective, but in hardware in the past it did make a
difference for fast crc computing.
Actually, as the DECnet installation manual mentions, on an 11/44 or 11/70, you probably
do not want to use the KG11 even if you have it, as the software computation is faster
than the hardware device
(see page 5-31 of the DECnet-RSX generation and installation manual). 
31 Jan
31 Jan
8:48 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
Paul Koning wrote ...
Correct, I was not aware it's possible to use it.
The only software I
have seen that uses the KG11 is 2780 emulation.
I am very interested in getting 2780 emulation for a PDP-11.
Paul, or anyone else, do you know where I can get it?
Cheers
Peter Allan
On Sun, 30 Jan 2022 at 18:31, Paul Koning <paulkoning(a)comcast.net> wrote:
>
>
> > On Jan 29, 2022, at 7:37 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
> >
> > On 2022-01-30 01:04, R. Voorhorst wrote:
> >> L.S.
> >> With a bit time on hand and the standstill after Paul's initial test
> from
> >> dup to pydecnet which appeared to be successful, I now undertook a test
> as
> >> Mark liked to have it preferably.
> >> So I did a fresh netgen on a simple configuration from simple basic
> install
> >> Rsx11MP system for only a Decnet end-node with one single Dup line
> >> communicating to a known working Pdp11 Rsx11MP Dmc circuit.
> >> I saw no difference from what I reported initially and later with
> logging,
> >> as was to be expected; my complex setup behaves exactly the same in this
> >> respect as it does for years in a complex network setup for Rsx and
> Rsts,
> >> and RT11 without network.
> >> This is on a Windows-2008R2 server and I suspect Paul did his test on
> >> unix/linux , however although it differs, that should be moot as far as
> >> Simh is concerned.
> >> There could be another difference though. Paul would probably have
> taken the
> >> default route and used Ddcmp withouth KG11 support: Dup without Kdp is
> the
> >> only sync line to use it, though async Decnet DL/DZ/VH might use it as
> well.
> >> As I prefer the most complex configs possible (any two of a kind where
> >> possible as Dec used to have them), I do also employ the KG11, so for
> Dup
> >> support it will be used when configured so in Decnet11MP.
> >
> > I would suspect Paul did not run with KG11.
>
Correct, I was not aware it's possible to use it.
The only software I
> have seen that uses the KG11 is 2780 emulation.
>
> > I agree that the host system shouldn't make a difference.
>
> Not unless it's big endian, in which case getting this stuff to come out
> right requires some care.
>
> >> On a sim it is not that effective, but in hardware in the past it did
> make a
> >> difference for fast crc computing.
> >
> > Actually, as the DECnet installation manual mentions, on an 11/44 or
> 11/70, you probably do not want to use the KG11 even if you have it, as the
> software computation is faster than the hardware device
> > (see page 5-31 of the DECnet-RSX generation and installation manual).
>
> Makes sense. The KG11 is pretty old; if it was created back in the 11/20
> days that would make much more sense, with basic instruction times in the
> 3-5 microsecond range.
>
> paul
>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>
8:52 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
I wanted to make sure I wasn't getting lost; are you referring to the
PDP-11 software that forms part of the Galaxy IBM workstation product?
It's called DN60/DN65 and also does 3780 and HASP. Is this what you're
referring to?
On 1/31/22 2:48 PM, Peter Allan wrote:
Paul Koning wrote ...
Correct, I was not aware it's possible to use
it. The only software
I have seen that uses the KG11 is 2780 emulation.
I am very interested in getting 2780 emulation for a PDP-11.
Paul, or anyone else, do you know where I can get it?
Cheers
Peter Allan
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
9 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
What I mentioned is one or several PDP-11 products, available for RSTS and I believe RSX.
There definitely is an "RJ2780 emulator" -- the official name may not be quite
that. And I think there was also a 3271 emulator, though I'm not sure if that existed
on RSTS.
I have no idea what these things do, since 2780 is something I've never used. Some
sort of remote job entry station? Anyway, it is the only RSTS software that uses a KG11.
DECnet doesn't because on RSTS DECnet only supported devices with hardware CRC: DMC
and friends and later Ethernet. I did an unsupported software DDCMP, but that does CRC in
software (8 bits at a time, the classic table driven fast software implementation). That
probably outruns a KG11 and in any case I never had access to that hardware.
paul
On Jan 31, 2022, at 2:52 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
I wanted to make sure I wasn't getting lost; are you referring to the PDP-11 software
that forms part of the Galaxy IBM workstation product? It's called DN60/DN65 and also
does 3780 and HASP. Is this what you're referring to?
On 1/31/22 2:48 PM, Peter Allan wrote:
Paul Koning wrote ...
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Correct, I was not aware it's possible to use
it. The only software I have seen that uses the KG11 is 2780 emulation.
I am very interested in getting 2780 emulation for a PDP-11.
Paul, or anyone else, do you know where I can get it?
Cheers
Peter Allan
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
9:22 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
Then we are probably talking apples and pineapples.
The product that I'm talking about is exclusively for the 36 bit line,
requiring a DTE to get the data to the PDP-10. I think it also needed a
KMC to do some offloading, so the 11/34 could keep up, but I wouldn't
swear to it. There's code for a KMC, anyway.
The software appears to be a complete embedded design: there are no
users, no file system, minimum memory management and no task
preemption. Thus, I don't believe it has any code basis in either RSX
or RSTS. I wouldn't be surprised if part of it got lifted from RT-11,
but I don't have an informed opinion on that.
The DN60/DN65 spoke 2780, 3780 and HASP. The first two are remote job
entry (RJE) 'workstations' that had card readers and line printers (no
terminals). HASP is a variant that IBM did not develop, yet adopted. I
believe it was wizzy because it allowed multiple concurrent streams.
The job of IBMSPL was to fool the remote IBM host that a card deck was
being submitted by a timesharing user and to take the resulting print
output and to get it to wherever the right place was (printer, file, etc.)
I don't recall a 3271, I guess you mean those green screen terminals?
What a beast... I do recall using 3270, 3276 and the like when I was
hacking the bisync drivers on VM to talk to IBMSPL. There was a product
that you could run on Tops-20 to show up as a 3270 on an IBM box,
provided the target spoke TCP/IP. I can't remember the name, but it was
based on TELNET negotiating some additional options. It's a lot of
work; a 3270 is not like anything you ever heard of in ÅSCII land.
A number of us swore that IBMSPL was the only reasonable way to use an
IBM mainframe as the 3270 was a half-duplex terminal that was all to
ready to lock the keyboard if you even thought of typing ahead. The
more modern emulators don't lock like that, but you are still
effectively in a late 1960's half duplex paradigm. Still. Today. Really.
On 1/31/22 3:00 PM, Paul Koning wrote:
What I mentioned is one or several PDP-11 products,
available for RSTS and I believe RSX. There definitely is an "RJ2780 emulator"
-- the official name may not be quite that. And I think there was also a 3271 emulator,
though I'm not sure if that existed on RSTS.
I have no idea what these things do, since 2780 is something I've never used. Some
sort of remote job entry station? Anyway, it is the only RSTS software that uses a KG11.
DECnet doesn't because on RSTS DECnet only supported devices with hardware CRC: DMC
and friends and later Ethernet. I did an unsupported software DDCMP, but that does CRC in
software (8 bits at a time, the classic table driven fast software implementation). That
probably outruns a KG11 and in any case I never had access to that hardware.
paul
On Jan 31, 2022, at 2:52 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
I wanted to make sure I wasn't getting lost; are you referring to the PDP-11 software
that forms part of the Galaxy IBM workstation product? It's called DN60/DN65 and also
does 3780 and HASP. Is this what you're referring to?
On 1/31/22 2:48 PM, Peter Allan wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Paul Koning wrote ...
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Correct, I was not aware it's possible to use
it. The only software I have seen that uses the KG11 is 2780 emulation.
I am very
interested in getting 2780 emulation for a PDP-11.
Paul, or anyone else, do you know where I can get it?
Cheers
Peter Allan
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 
10:08 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 3:22 PM, Thomas DeBellis wrote:
Then we are probably talking apples and pineapples.
The product that I'm talking about is exclusively for the 36 bit line,
requiring a DTE to get the data to the PDP-10.
Well, Peter Allan did say he's interested in "2780 emulation for a
PDP-11".
And, Peter, so am I. We have several running mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like to
demonstrate is interoperability between disparate architectures; I'd
love to get something like that working such that we could demonstrate
RJE from a PDP-11 to a mainframe on the other side of the exhibit floor.
I don't recall a 3271, I guess you mean those
green screen terminals?
What a beast... I do recall using 3270, 3276 and the like when I was
hacking the bisync drivers on VM to talk to IBMSPL.
The 3271 is a remote terminal cluster controller for 3270-protocol
terminals.
A number of us swore that IBMSPL was the only
reasonable way to use an
IBM mainframe as the 3270 was a half-duplex terminal that was all to
ready to lock the keyboard if you even thought of typing ahead. The
more modern emulators don't lock like that, but you are still
effectively in a late 1960's half duplex paradigm. Still. Today. Really.
Tom, I'm sorry but that's not a fair assessment at all. It's not so
much a "half-duplex paradigm" as it is forms- and screen-based. You've
used these systems; I know you know this.
The world thought it was a good enough paradigm to reinvent it for
the WWW, and it's still the most efficient way to get to a big machine,
rather than peck-peck-peck and flood the box with interrupts. There's
nothing "still today really" obsolete about it at all; it's just that
people like you (and me) who are accustomed to character-by-character
interaction with the machine see it as foreign.
And of course it turns into a painful experience when you try to fake
a character-by-character interface with it, with something like VM or
TSO. Think about what's going on to make that happen; there's no way it
won't be at least somewhat painful.
And I'm saying this as a late-comer to the mainframe world; I cut my
teeth on PDP-8 and PDP-11 systems.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
11:14 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
Ignoring the whole part about the screen/form based communication...
For RSX, there are/were several relevant products:
DECnet/SNA Gateway
RSX-11M+ 2780/3780 Emulator
RSX-11M+ 3271 Protocol Emulator
Unfortunately, I have never seen any of these products in real life, and
have no idea where they might be found today.
In the same vein, I have also not seen P.S.I for RSX in the wild. If
anyone would happen to have a distribution, it could be fun to look at.
Johnny
On 2022-01-31 22:08, Dave McGuire wrote:
On 1/31/22 3:22 PM, Thomas DeBellis wrote:
--
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
Then we are probably talking apples and
pineapples.
The product that I'm talking about is exclusively for the 36 bit line,
requiring a DTE to get the data to the PDP-10.
Well, Peter Allan did say he's interested in "2780 emulation for a
PDP-11".
And, Peter, so am I. We have several running mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like to
demonstrate is interoperability between disparate architectures; I'd
love to get something like that working such that we could demonstrate
RJE from a PDP-11 to a mainframe on the other side of the exhibit floor.
I don't recall a 3271, I guess you mean those
green screen terminals?
What a beast... I do recall using 3270, 3276 and the like when I was
hacking the bisync drivers on VM to talk to IBMSPL.
The 3271 is a remote terminal cluster controller for 3270-protocol
terminals.
A number of us swore that IBMSPL was the only
reasonable way to use an
IBM mainframe as the 3270 was a half-duplex terminal that was all to
ready to lock the keyboard if you even thought of typing ahead. The
more modern emulators don't lock like that, but you are still
effectively in a late 1960's half duplex paradigm. Still. Today.
Really.
Tom, I'm sorry but that's not a fair assessment at all. It's not so
much a "half-duplex paradigm" as it is forms- and screen-based. You've
used these systems; I know you know this.
The world thought it was a good enough paradigm to reinvent it for
the WWW, and it's still the most efficient way to get to a big machine,
rather than peck-peck-peck and flood the box with interrupts. There's
nothing "still today really" obsolete about it at all; it's just that
people like you (and me) who are accustomed to character-by-character
interaction with the machine see it as foreign.
And of course it turns into a painful experience when you try to fake
a character-by-character interface with it, with something like VM or
TSO. Think about what's going on to make that happen; there's no way it
won't be at least somewhat painful.
And I'm saying this as a late-comer to the mainframe world; I cut my
teeth on PDP-8 and PDP-11 systems.
-Dave
11:16 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 5:14 PM, Johnny Billquist wrote:
For RSX, there are/were several relevant products:
DECnet/SNA Gateway
RSX-11M+ 2780/3780 Emulator
RSX-11M+ 3271 Protocol Emulator
Unfortunately, I have never seen any of these products in real life, and
have no idea where they might be found today.
In the same vein, I have also not seen P.S.I for RSX in the wild. If
anyone would happen to have a distribution, it could be fun to look at.
This is unfortunate. If you or anyone else comes across it, please
try to preserve it.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
11:20 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 2022-01-31 23:16, Dave McGuire wrote:
On 1/31/22 5:14 PM, Johnny Billquist wrote:
There are so many things seemingly lost right now it is depressing.
I do have RSX and DECnet (I even have properly signed documents allowing
me to have them), but unfortunately all the layered software seems to
have been lost in the Mentec Inc. disolvement.
Heck, if I could just locate the layered products, I'm even allowed to
have them. But they are currently lost. :-(
The current owner of it all is XX2247. However, I seem to have lost
contact with Dave Carroll, which is another problem. I'm not sure if
he's still alive or not, which might leave things even more in limbo
than before.
It's all a mess that just keeps going on.
Johnny
--
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
For RSX, there are/were several relevant
products:
DECnet/SNA Gateway
RSX-11M+ 2780/3780 Emulator
RSX-11M+ 3271 Protocol Emulator
Unfortunately, I have never seen any of these products in real life,
and have no idea where they might be found today.
In the same vein, I have also not seen P.S.I for RSX in the wild. If
anyone would happen to have a distribution, it could be fun to look at.
This is unfortunate. If you or anyone else comes across it, please
try to preserve it.
1 Feb
1 Feb
12:05 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 5:20 PM, Johnny Billquist wrote:
There are so many things seemingly lost right now it
is depressing.
I do have RSX and DECnet (I even have properly signed documents allowing
me to have them), but unfortunately all the layered software seems to
have been lost in the Mentec Inc. disolvement.
Heck, if I could just locate the layered products, I'm even allowed to
have them. But they are currently lost. :-(
The current owner of it all is XX2247. However, I seem to have lost
contact with Dave Carroll, which is another problem. I'm not sure if
he's still alive or not, which might leave things even more in limbo
than before.
It's all a mess that just keeps going on.
Yes, it is particularly sad. A lot of people are looking at it very
short-sightedly; I've come across a number of people who are sitting on
this or that tape or disk pack, with attitudes that exacerbate the problem:
1. "Oh, nobody cares about this, despite the fact that you just told
me they do."
2. "This forty-year-old code is copyrighted, screw historical
preservation, I'll err on the side of protecting my personal safety in
this near-zero-risk situation and just sit on it, or destroy it."
3. "No, I won't turn loose of this disk or that tape, because I don't
trust anyone else to handle it, but I don't have time to mess with it
myself, so I'll just sit on it so my wife can trash it after my estate
sale."
The DECnet-RT distribution is in situation #3, and the source code
for a third-party IP stack and other packages for VMS was lost just last
year because of #2. In the latter instance, LSSM got all of the
development machines, but the drives had been pulled and the guy refused
to give them to us, or even save them himself.
So, people need to CARE, and people need to take the occasional very
low RISK. Heh, on Earth in 2022...good luck with either.
I don't know what happened to Dave Carroll either, but I see no
obituary listings for his name in Colorado Springs. Perhaps he really
did buy it all just to sit on it. If so, that's really crappy.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
12:25 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 2022-02-01 00:05, Dave McGuire wrote:
On 1/31/22 5:20 PM, Johnny Billquist wrote:
Well, you are very much oversimplifying things here...
There are so many things seemingly lost right now
it is depressing.
I do have RSX and DECnet (I even have properly signed documents
allowing me to have them), but unfortunately all the layered software
seems to have been lost in the Mentec Inc. disolvement.
Heck, if I could just locate the layered products, I'm even allowed to
have them. But they are currently lost. :-(
The current owner of it all is XX2247. However, I seem to have lost
contact with Dave Carroll, which is another problem. I'm not sure if
he's still alive or not, which might leave things even more in limbo
than before.
It's all a mess that just keeps going on.
Yes, it is particularly sad. A lot of people are looking at it very
short-sightedly; I've come across a number of people who are sitting on
this or that tape or disk pack, with attitudes that exacerbate the problem: 1. "Oh, nobody cares about this, despite the
fact that you just told
me they do."
That might happen. I'd say it's more likely it happened 20 years ago.
The few people who have hung on to things until now are likely not in
this category.
2. "This forty-year-old code is copyrighted,
screw historical
preservation, I'll err on the side of protecting my personal safety in
this near-zero-risk situation and just sit on it, or destroy it."
How near zero the risk is is a bit unknown, but it might be worse than
you know/think. So don't pass judgement so easily.
If someone destroys things, then it's really sad. But if someone hangs
on to things in the hope that the situation will eventually become
better, or they will at least find some solution that improves the
situation are actually good things.
3. "No, I won't turn loose of this disk or
that tape, because I don't
trust anyone else to handle it, but I don't have time to mess with it
myself, so I'll just sit on it so my wife can trash it after my estate
sale."
Hanging on to things are always the first step. Complaining about that
is the wrong thing. And noone knows what tomorrow brings. We can all
just hope that we are here tomorrow and can do something more.
If not, that's hardly something you can blame them for. It's not what
they hoped for.
The DECnet-RT distribution is in situation #3, and
the source code
for a third-party IP stack and other packages for VMS was lost just last
year because of #2. In the latter instance, LSSM got all of the
development machines, but the drives had been pulled and the guy refused
to give them to us, or even save them himself.
Sad when that happens.
So, people need to CARE, and people need to take
the occasional very
low RISK. Heh, on Earth in 2022...good luck with either.
I don't know what happened to Dave Carroll either, but I see no
obituary listings for his name in Colorado Springs. Perhaps he really
did buy it all just to sit on it. If so, that's really crappy.
I do happen to know a bit more about the situation than you, it seems.
Yes, Dave bought it all from the remains of Mentec Inc. The purpose was
to try and make it all available for hobbyists.
However, the contract between DEC and Mentec is poison, and that
contract is still active, with it today being HPE and XX2247. And Dave
was definitely worried about his house and everything with regards to
that contract, which is why it stayed locked down. I did have several
discussions with him about it, and he was having lots of concerns about
what to do, and how to handle the whole thing.
Four or five years ago, he almost transferred all of it over to me, but
I didn't jump fast enough, and it remained an open question. Right about
the same time, I started talking with people at VSI who could possibly
help working things out with HPE. But right then, Dave stopped
communicating, and I have not heard a single thing since. And XX2247
seems to have gone defunct, and I do wonder if Dave might have left us,
or something bad happened. But I don't really know. I've also tried
through friends to locate him without success.
But the purpose was to preserve and make the software available for
everyone. But as of now, it's still not possible because of the contract
between DEC and Mentec. And no, I have not seen that contract. So I
don't know the exact wording of it. And Dave preferred that it was kept
buried, because he felt it was pure poison, and actually better if HPE
was not even reminded of it.
And I have a contract with XX2247, giving me access to whatever. You
could say that I'm the last RSX developer. :-)
Johnny
--
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
12:38 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 6:25 PM, Johnny Billquist wrote:
Perhaps, but I doubt it. How so?
I'm not speaking in theoretical terms. That exact sentence has been
said TO MY FACE, more than once, by people in conversations about
sending materials to LSSM.
I will happily pass judgment. A hundred years from now, people will
still care about the history of technology, but nobody will care about
that stupid legal BS from one company from a century prior. But then it
will be too late to go back and retrieve the stuff.
NOW, it is not too late, for a lot of it.
Yes, very.
I don't know much about it, and from threads elsewhere I know that
you've looked into it extensively, so yes, you most definitely do know
more about it than I do. From my "don't know the guy personally" and
"wasn't there" perspective, someone bought it and did nothing with it,
and now he's unreachable and it's in limbo.
I deliberately did not read your text below this paragraph until now,
such that I could clearly explain my point of view to you.
Yes, it is
particularly sad. A lot of people are looking at it
very short-sightedly; I've come across a number of people who are
sitting on this or that tape or disk pack, with attitudes that
exacerbate the problem:
Well, you are very much oversimplifying things here... 1.
"Oh, nobody cares about this, despite the fact that you just
told me they do."
That might happen. I'd say it's more likely it happened 20 years ago.
The few people who have hung on to things until now are likely not in
this category. 2.
"This forty-year-old code is copyrighted, screw historical
preservation, I'll err on the side of protecting my personal safety in
this near-zero-risk situation and just sit on it, or destroy it."
How near zero the risk is is a bit unknown, but it might be worse than
you know/think. So don't pass judgement so easily. If someone destroys things, then it's really sad.
But if someone hangs
on to things in the hope that the situation will eventually become
better, or they will at least find some solution that improves the
situation are actually good things.
As long as they make arrangements for it to be preserved when they
can no longer do it, yes, I can agree with that.
The
DECnet-RT distribution is in situation #3, and the source code
for a third-party IP stack and other packages for VMS was lost just
last year because of #2. In the latter instance, LSSM got all of the
development machines, but the drives had been pulled and the guy
refused to give them to us, or even save them himself.
Sad when that happens. I don't
know what happened to Dave Carroll either, but I see no
obituary listings for his name in Colorado Springs. Perhaps he really
did buy it all just to sit on it. If so, that's really crappy.
I do happen to know a bit more about the situation than you, it seems. Yes, Dave bought it all from the remains of Mentec
Inc. The purpose was
to try and make it all available for hobbyists.
However, the contract between DEC and Mentec is poison, and that
contract is still active, with it today being HPE and XX2247. And Dave
was definitely worried about his house and everything with regards to
that contract, which is why it stayed locked down. I did have several
discussions with him about it, and he was having lots of concerns about
what to do, and how to handle the whole thing.
That's absolutely awful, and now I understand the situation a lot
better. It would probably have been beneficial for him to have said
something about this in some forum somewhere, so that people who aren't
"in the cool kids crowd" can know what happened.
So, as with pretty much everything else, the damn suits ruined it.
Four or five years ago, he almost transferred all of
it over to me, but
I didn't jump fast enough, and it remained an open question. Right about
the same time, I started talking with people at VSI who could possibly
help working things out with HPE. But right then, Dave stopped
communicating, and I have not heard a single thing since. And XX2247
seems to have gone defunct, and I do wonder if Dave might have left us,
or something bad happened. But I don't really know. I've also tried
through friends to locate him without success.
I understand. That's just awful. :-( But I'm sure I speak for
everyone here when I say thank you for trying.
I will try to locate him. It's possible that he may be amenable to
an arrangement with a corporate nonprofit entity like LSSM, whose
purpose is to preserve such things, rather than an individual.
But the purpose was to preserve and make the software
available for
everyone. But as of now, it's still not possible because of the contract
between DEC and Mentec. And no, I have not seen that contract. So I
don't know the exact wording of it. And Dave preferred that it was kept
buried, because he felt it was pure poison, and actually better if HPE
was not even reminded of it.
That figures. Damn suits. I sure hope it doesn't die with him,
whenever he goes.
And I have a contract with XX2247, giving me access to
whatever. You
could say that I'm the last RSX developer. :-)
...and it is in excellent hands. :-)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
1:03 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 2022-02-01 00:38, Dave McGuire wrote:
I'm not speaking in theoretical terms. That exact sentence has been
said TO MY FACE, more than once, by people in conversations about
sending materials to LSSM.
If you've experienced that recently, then I am a little amazed. Because
that means people have been hanging on to things for a *long* time, but
now they don't care. Which for me sounds like an unusual situation.
But of course, everything is possible.
I will happily pass judgment. A hundred years from now, people will
still care about the history of technology, but nobody will care about
that stupid legal BS from one company from a century prior. But then it
will be too late to go back and retrieve the stuff.
NOW, it is not too late, for a lot of it.
For some people, the risk of legal action might still be very real. To
ask them to risk their personal life for such ideas is for me asking a
lot. I am happy when someone does, but I certainly will not expect or
demand such a thing.
Making arrangements would be nice, but it's not always that easy. But at
least keeping the bits around allows for the rest to possibly happen. If
the bits are lost, the rest don't matter.
So obviously, preserving the bits are the first priority no matter what
the rest looks like.
The rest we can work on later.
I don't know much about it, and from threads elsewhere I know that
you've looked into it extensively, so yes, you most definitely do know
more about it than I do. From my "don't know the guy personally" and
"wasn't there" perspective, someone bought it and did nothing with it,
and now he's unreachable and it's in limbo.
I still am trying all the time to maybe get something more sorted. But
it's been no true progress so far.
But Dave is definitely a guy who was trying to do things right. I see no
reason to blame him because of that.
He didn't see any point of talking about that in other forums. All he
felt that could do was to possibly catch the attention of HPE, which he
definitely did not want to happen.
Al Kossov from bitsavers were in the loop, and also trying to help get
things released. But he had no more luck than the rest of us.
So it's not that noone else knew or were involved. But Dave kept the
number low for the stated reasons, and I guess you are just too new to
have become involved in this loop.
Well. Like I said - I do have the RSX bits. I know he also had/have
RSTS/E and RT-11. But the disks with the layered products were lost at
Mentec Inc.
So he owns it legally, but don't have any copies.
Until the day I die... Who knows what happens then.
Johnny
--
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
On 1/31/22 6:25 PM, Johnny Billquist wrote:
Perhaps, but I doubt it. How so?
Because for some people, that "near zero risk" is maybe not so "near
zero", and that have actual implications for actual people.
You seem to really just treat it as "there is no risk, so why aren't
people just doing whatever I think they should do", without considering
that for others the situation might actually look very different.
Yes,
it is particularly sad. A lot of people are looking at it
very short-sightedly; I've come across a number of people who are
sitting on this or that tape or disk pack, with attitudes that
exacerbate the problem:
Well, you are very much oversimplifying things here... 1. "Oh, nobody cares about this, despite the
fact that you just
told me they do."
That might happen. I'd say it's more likely it happened 20 years ago.
The few people who have hung on to things until now are likely not in
this category. 2. "This forty-year-old code is copyrighted,
screw historical
preservation, I'll err on the side of protecting my personal safety
in this near-zero-risk situation and just sit on it, or destroy it."
How near zero the risk is is a bit unknown, but it might be worse than
you know/think. So don't pass judgement so easily. If someone
destroys things, then it's really sad. But if someone hangs
on to things in the hope that the situation will eventually become
better, or they will at least find some solution that improves the
situation are actually good things.
As long as they make arrangements for it to be preserved when they
can no longer do it, yes, I can agree with that. I don't know what happened to Dave Carroll
either, but I see no
obituary listings for his name in Colorado Springs. Perhaps he
really did buy it all just to sit on it. If so, that's really crappy.
I do happen to know a bit more about the situation than you, it seems. Yes, Dave
bought it all from the remains of Mentec Inc. The purpose
was to try and make it all available for hobbyists.
However, the contract between DEC and Mentec is poison, and that
contract is still active, with it today being HPE and XX2247. And Dave
was definitely worried about his house and everything with regards to
that contract, which is why it stayed locked down. I did have several
discussions with him about it, and he was having lots of concerns
about what to do, and how to handle the whole thing.
That's absolutely awful, and now I understand the situation a lot
better. It would probably have been beneficial for him to have said
something about this in some forum somewhere, so that people who aren't
"in the cool kids crowd" can know what happened. So, as with pretty much everything else, the damn
suits ruined it.
That is definitely true. The specifics of the contract between DEC and
Mentec seems to have been complex. DEC sold the software to Mentec.
However, there is some clause in there that allows DEC to just take it
all back under some circumstances, if I got it right. And that is what
Dave was worried about HPE potentially doing, which would legally force
him to delete everything he had. Which in his eyes would have been very
bad, since he obviously didn't trust HPE to actually do anything good if
that happened.
And it also prevented him from just releasing the software, or even
selling it. I think licenses could be sold in some way, but it sounded
like that was a headache in itself, so XX2247 didn't really sell any
licenses either. I *think* CHM might have received a license from
XX2247, but I'm not sure. But I don't think any other were issued.
And I think HPE had to be somehow looped in whenever that happened.
Part of the problem is that some bits of this software, in a refined
form, is still used in VMS, meaning still at HPE, which then sold it to
VSI. But if I got things right, HPE still have some kind of control
interest in it, even though it's sold to VSI. So it's all horribly
complicated, and leads up to actual still ongoing business.
In that way, PDP-11 software is in a more complex situation than for
example PDP-10.
I will try to locate him. It's possible that
he may be amenable to
an arrangement with a corporate nonprofit entity like LSSM, whose
purpose is to preserve such things, rather than an individual.
If you manage to locate him, that would already be a good start.
Let's start with that. Dave certainly talked a lot with CHM earlier as
well, but didn't transfer to them either.
Because in the end, it's not so much about who it passed on to. It's
more about possibly drawing the attention of HPE that worried him.
And if HPE got involved, the risk was that all the software actually
would become unavailable. In Dave's view, the current situation was
better than that alternative.
But the
purpose was to preserve and make the software available for
everyone. But as of now, it's still not possible because of the
contract between DEC and Mentec. And no, I have not seen that
contract. So I don't know the exact wording of it. And Dave preferred
that it was kept buried, because he felt it was pure poison, and
actually better if HPE was not even reminded of it.
That figures. Damn suits. I sure hope it doesn't die with him,
whenever he goes. And I have a
contract with XX2247, giving me access to whatever. You
could say that I'm the last RSX developer. :-)
...and it is in excellent hands. :-)
1:47 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On Jan 31, 2022, at 7:03 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
...
Well. Like I said - I do have the RSX bits. I know he also had/have RSTS/E and RT-11. But
the disks with the layered products were lost at Mentec Inc.
So he owns it legally, but don't have any copies.
I've run into a scenario like that. It was with PLATO, or by its official name
"CYBIS" (since CDC sold the product to X and the name to Y, sort of like
Rolls-Royce selling the name to P and the factory to Q). We tracked down the current
owner and he was willing to give permission to run a copy of it in emulation with public
(non-commercial) access. But he didn't actually have a copy to hand out.
Then we found an actual running production system, and a system admin who was
exceptionally helpful, willing and able to make a full copy of the system. He even went
through the effort to delete proprietary (customer owned) bits, I sometimes wonder just
how much time that required. Net result: we ended up with legal bits, but the
"legal" and the "bits" came from two places.
So similarly, if XX2247 has the rights to bits, and those bits can be found, the two can
be put together.
paul
2:15 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 2022-02-01 01:47, Paul Koning wrote:
Nice!
On Jan 31, 2022, at 7:03 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
...
Well. Like I said - I do have the RSX bits. I know he also had/have RSTS/E and RT-11. But
the disks with the layered products were lost at Mentec Inc.
So he owns it legally, but don't have any copies.
I've run into a scenario like that. It was with PLATO, or by its official name
"CYBIS" (since CDC sold the product to X and the name to Y, sort of like
Rolls-Royce selling the name to P and the factory to Q). We tracked down the current
owner and he was willing to give permission to run a copy of it in emulation with public
(non-commercial) access. But he didn't actually have a copy to hand out.
Then we found an actual running production system, and a system admin who was
exceptionally helpful, willing and able to make a full copy of the system. He even went
through the effort to delete proprietary (customer owned) bits, I sometimes wonder just
how much time that required. Net result: we ended up with legal bits, but the
"legal" and the "bits" came from two places. So similarly, if XX2247 has the rights to bits, and
those bits can be found, the two can be put together.
Been working on that for quite a while now. Not much success to show for
it. :-(
But I keep hoping.
Johnny
--
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
2:45 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On Jan 31, 2022, at 8:15 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-02-01 01:47, Paul Koning wrote:
Nice!
Yes, the Cyber1.org system had some good luck in a few key spots. The one I just
described is one of them. Another is that the then-owner of the CDC software (BT Systems,
if I remember right) back in 2007 or so not only was willing to give permission to run the
latest release of NOS (from just before 2000, with Y2K patches as well) but actually
supplied a full tape of the entire distribution, OS and "layered products" (or
whatever CDC called those) included. And a manual, so I could run a full install by the
book.
And then, not too many years later, they amended the earlier "you can use this on
Cyber1" permission to be "this is open for any hobbyists non-commercial
use". HPE could learn from these folks.
paul
On Jan
31, 2022, at 7:03 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
...
Well. Like I said - I do have the RSX bits. I know he also had/have RSTS/E and RT-11. But
the disks with the layered products were lost at Mentec Inc.
So he owns it legally, but don't have any copies.
I've run into a scenario
like that. It was with PLATO, or by its official name "CYBIS" (since CDC sold
the product to X and the name to Y, sort of like Rolls-Royce selling the name to P and the
factory to Q). We tracked down the current owner and he was willing to give permission to
run a copy of it in emulation with public (non-commercial) access. But he didn't
actually have a copy to hand out.
Then we found an actual running production system, and a system admin who was
exceptionally helpful, willing and able to make a full copy of the system. He even went
through the effort to delete proprietary (customer owned) bits, I sometimes wonder just
how much time that required. Net result: we ended up with legal bits, but the
"legal" and the "bits" came from two places.
2:06 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 7:03 PM, Johnny Billquist wrote:
Then be amazed. It happened most recently just a few months ago, and
several times last year. This is a lot more common in the real world
than you've assumed.
Well, that's a tough choice then.
Wow, DEC sure did go down a bad path with suits. :-/
Understood.
(sorry for being terse, I'm being called for dinner)
Until the day I die... Who knows what happens then.
Well, I'm trying to get more (and younger) people interested in
PDP-11s, and I'm having pretty good success at that. You could try that
too.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Because for some people, that "near zero
risk" is maybe not so "near
zero", and that have actual implications for actual people.
Yes, but they've been poorly (and selfishly) prioritized.
You seem to really just treat it as "there is no
risk, so why aren't
people just doing whatever I think they should do", without considering
that for others the situation might actually look very different.
You've jumped to a conclusion about what I think, and (with respect)
you're incorrect. I think risking some suit in a glass building getting
angry with me, or even filing a lawsuit against me, is not, and will
never be, more important than a piece of history that stands to be lost
forever.
At the very least, things can be quietly copied around and saved, for
the day when all of those suits (and the short-term profits that they
care about) are dead and the materials can be shared freely and openly.
I'm not
speaking in theoretical terms. That exact sentence has
been said TO MY FACE, more than once, by people in conversations about
sending materials to LSSM.
If you've experienced that recently, then I am a little amazed. Because
that means people have been hanging on to things for a *long* time, but
now they don't care. Which for me sounds like an unusual situation.
But of course, everything is possible. Making arrangements would be nice, but it's not
always that easy. But at
least keeping the bits around allows for the rest to possibly happen. If
the bits are lost, the rest don't matter.
So obviously, preserving the bits are the first priority no matter what
the rest looks like.
The rest we can work on later.
I agree with you here.
I still am trying all the time to maybe get something
more sorted. But
it's been no true progress so far.
But Dave is definitely a guy who was trying to do things right. I see no
reason to blame him because of that.
Ok, I understand, and I appreciate being informed.
That's
absolutely awful, and now I understand the situation a lot
better. It would probably have been beneficial for him to have said
something about this in some forum somewhere, so that people who
aren't "in the cool kids crowd" can know what happened.
He didn't see any point of talking about that in other forums. All he
felt that could do was to possibly catch the attention of HPE, which he
definitely did not want to happen. Al Kossov from bitsavers were in the loop, and also
trying to help get
things released. But he had no more luck than the rest of us.
So it's not that noone else knew or were involved. But Dave kept the
number low for the stated reasons, and I guess you are just too new to
have become involved in this loop.
Well, neither Al nor most of the rest of that crowd tend to pay me
any mind, despite what I've accomplished over the years. That's a
different matter. But like it or not, I'm preserving things too, as we
are at LSSM.
"New" I am not. For 37 years I've been running, programming,
repairing, buying, selling, etc DEC hardware and software, and I've
accomplished quite a bit. I guess I just don't brag about it enough;
people chose not to involve me.
So, as with
pretty much everything else, the damn suits ruined it.
That is definitely true. The specifics of the contract between DEC and
Mentec seems to have been complex. DEC sold the software to Mentec.
However, there is some clause in there that allows DEC to just take it
all back under some circumstances, if I got it right. And that is what
Dave was worried about HPE potentially doing, which would legally force
him to delete everything he had. Which in his eyes would have been very
bad, since he obviously didn't trust HPE to actually do anything good if
that happened.
That's a reasonable stance. But "yes sir I've deleted that" are
words that are easy to say.
Again, thank you for explaining the situation to me.
I will try
to locate him. It's possible that he may be amenable to
an arrangement with a corporate nonprofit entity like LSSM, whose
purpose is to preserve such things, rather than an individual.
If you manage to locate him, that would already be a good start.
Let's start with that. Dave certainly talked a lot with CHM earlier as
well, but didn't transfer to them either.
Because in the end, it's not so much about who it passed on to. It's
more about possibly drawing the attention of HPE that worried him.
And if HPE got involved, the risk was that all the software actually
would become unavailable. In Dave's view, the current situation was
better than that alternative. And I have a contract with XX2247, giving me access to
whatever. You
could say that I'm the last RSX developer. :-)
...and it is in excellent hands. :-)
2:28 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 2022-02-01 02:06, Dave McGuire wrote:
Seems you just described exactly what I tried do describe above. So how
did I get it wrong?
Then be amazed. It happened most recently just a few months ago, and
several times last year. This is a lot more common in the real world
than you've assumed.
Hmm. Maybe we're talking about something else than PDP-11 software now?
Considering that I'm usually even more overlooked than you are, you can
go with that complaint somewhere else.
The only reason I'm this deep into this specific topic is because of all
the things I'm doing with RSX, and have been for a very long time.
Which got me in contact with Dave, and it continued from there.
Take PDP-8 stuff for example - I've been around the block, done more,
seen more, and have more information and stuff than most everyone on
those lists nowadays. But I don't actually care anymore. They can talk
and do things as much as they want. I don't need them, and they don't
even know I exist. Their problem. Not mine. And since it's also not a
problem for them, it's not a problem at all.
It's only a problem when you want attention and recognition.
Wow, DEC sure did go down a bad path with suits. :-/
Yes.
And for some people, saying they do something, while not doing it, means
also exposing themselves to risks they are not willing to take.
Different people are willing to expose themselves to different amount of
risk. Not to mention doing what they feel is morally correct...
I'm daily facing the same dilemma. I have done so much improvements to
RSX. I'd like to release V5.0, which I have sitting here. But I can't. I
signed documents with XX2247 that limits what I can do, and I am not
willing to break the trust Dave put in me. Even though that improved
version have lots of stuff that would be really fun to share.
Instead I'm trying to find ways of resolving the problem. Meanwhile it's
sitting at my place, and nowhere else.
Until the day I die... Who knows what happens then.
Well, I'm trying to get more (and younger) people interested in
PDP-11s, and I'm having pretty good success at that. You could try that
too.
I'll leave that to others. I'm busy just fixing things in RSX...
If someone really interested comes along, I'm happy to help with
information and guidance, but I'm not trying to enlighten people.
Johnny
--
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
On 1/31/22 7:03 PM, Johnny Billquist wrote:
Yeah. Tell that to their kids when they are thrown into the street.
Because for some people, that "near zero
risk" is maybe not so "near
zero", and that have actual implications for actual people.
Yes, but they've been poorly (and selfishly) prioritized. You seem to
really just treat it as "there is no risk, so why aren't
people just doing whatever I think they should do", without
considering that for others the situation might actually look very
different.
You've jumped to a conclusion about what I think, and (with respect)
you're incorrect. I think risking some suit in a glass building getting
angry with me, or even filing a lawsuit against me, is not, and will
never be, more important than a piece of history that stands to be lost
forever. I'm not speaking in theoretical terms. That
exact sentence has
been said TO MY FACE, more than once, by people in conversations
about sending materials to LSSM.
If you've experienced that recently, then I am a little amazed.
Because that means people have been hanging on to things for a *long*
time, but now they don't care. Which for me sounds like an unusual
situation.
But of course, everything is possible. Al Kossov from
bitsavers were in the loop, and also trying to help get
things released. But he had no more luck than the rest of us.
So it's not that noone else knew or were involved. But Dave kept the
number low for the stated reasons, and I guess you are just too new to
have become involved in this loop.
Well, neither Al nor most of the rest of that crowd tend to pay me
any mind, despite what I've accomplished over the years. That's a
different matter. But like it or not, I'm preserving things too, as we
are at LSSM.
"New" I am not. For 37 years I've been running, programming,
repairing, buying, selling, etc DEC hardware and software, and I've
accomplished quite a bit. I guess I just don't brag about it enough;
people chose not to involve me. So, as with pretty much everything else, the damn
suits ruined it.
That is definitely true. The specifics of the contract between DEC and
Mentec seems to have been complex. DEC sold the software to Mentec.
However, there is some clause in there that allows DEC to just take it
all back under some circumstances, if I got it right. And that is
what Dave was worried about HPE potentially doing, which
would legally force him to delete everything he had. Which in his eyes
would have been very bad, since he obviously didn't trust HPE to
actually do anything good if that happened.
That's a reasonable stance. But "yes sir I've deleted that" are
words that are easy to say. And I have a
contract with XX2247, giving me access to whatever. You
could say that I'm the last RSX developer. :-)
...and it is in excellent hands. :-)
3:10 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 8:28 PM, Johnny Billquist wrote:
Yeah. Tell that to their kids when they are thrown into the street.
I do see your point, but it's an increasingly hypothetical point.
Seems you just described exactly what I tried do describe above. So how
did I get it wrong?
What I'm saying is that it's better to do something for the greater
good, than to "play it safe" with some hypothetical "risk" that some
suit at HPE (or whomever) will somehow come after you about decades-old
software that they've never even heard of.
I mean, come on. Yes, the potential consequence is huge, but the
risk is vanishingly small. Yes, it has happened, I'm well aware of
that. But the risk is still vanishingly small.
Hmm. Maybe we're talking about something else than PDP-11 software now?
Actually it hasn't come up about PDP-11 software; it was VAX software
most recently.
I'll leave that to others. I'm busy just fixing things in RSX...
If someone really interested comes along, I'm happy to help with
information and guidance, but I'm not trying to enlighten people.
Well, we do that a lot at LSSM. In particular, there's a teenage kid
who lives in Michigan who is OBSESSED with PDP-11s. He's writing code
in assembler and running it under simh. He doesn't know this yet, but
the next time his parents bring him down here for a visit, I'm going to
give him a PDP-11/73.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Because for some people, that "near zero
risk" is maybe not so "near
zero", and that have actual implications for actual people.
Yes, but they've been poorly (and selfishly) prioritized. You seem to really just treat it as "there is no
risk, so why aren't
people just doing whatever I think they should do", without
considering that for others the situation might actually look very
different.
You've jumped to a conclusion about what I think, and (with
respect) you're incorrect. I think risking some suit in a glass
building getting angry with me, or even filing a lawsuit against me,
is not, and will never be, more important than a piece of history that
stands to be lost forever. If you've experienced that recently, then I am a
little amazed.
Because that means people have been hanging on to things for a *long*
time, but now they don't care. Which for me sounds like an unusual
situation.
But of course, everything is possible.
Then be amazed. It happened most recently just a few months ago,
and several times last year. This is a lot more common in the real
world than you've assumed. Considering that I'm usually even more overlooked
than you are, you can
go with that complaint somewhere else.
I will (sorry) but everyone who knows what a PDP-11 is knows your
name. ;)
Take PDP-8 stuff for example - I've been around
the block, done more,
seen more, and have more information and stuff than most everyone on
those lists nowadays. But I don't actually care anymore. They can talk
and do things as much as they want. I don't need them, and they don't
even know I exist. Their problem. Not mine. And since it's also not a
problem for them, it's not a problem at all.
I'm with you on that. But passing knowledge on is important, and far
too few people do it. The excuse I hear most often is "nobody's
interested in this stuff".
It's only a problem when you want attention and
recognition.
Or if you just want to be kept in the damn loop once in a while.
I'm daily facing the same dilemma. I have done so
much improvements to
RSX. I'd like to release V5.0, which I have sitting here. But I can't. I
signed documents with XX2247 that limits what I can do, and I am not
willing to break the trust Dave put in me. Even though that improved
version have lots of stuff that would be really fun to share.
Instead I'm trying to find ways of resolving the problem. Meanwhile it's
sitting at my place, and nowhere else.
I will run that within *minutes* of its release. Assuming I'm still
breathing, of course!
Until the day I die... Who knows what happens then.
Well, I'm trying to get more (and younger) people interested in
PDP-11s, and I'm having pretty good success at that. You could try
that too.
3:38 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 2022-02-01 03:10, Dave McGuire wrote:
Seems you just described exactly what I tried do describe above. So
how did I get it wrong?
What I'm saying is that it's better to do something for the greater
good, than to "play it safe" with some hypothetical "risk" that some
suit at HPE (or whomever) will somehow come after you about decades-old
software that they've never even heard of.
I mean, come on. Yes, the potential consequence is huge, but the
risk is vanishingly small. Yes, it has happened, I'm well aware of
that. But the risk is still vanishingly small.
Dave obviously was *very* worried about potential risks that he was not
willing to take. The amount of papers I had to sign before I got access
should tell you something.
And he have (had?) information I don't have. So I prefer to not second
guess him, but just trust that he made his decisions based on the
information he had, and they made sense for him. And I'll just accept
that, and respect his decisions.
Hmm. Maybe we're talking about something else than PDP-11 software now?
Actually it hasn't come up about PDP-11 software; it was VAX software
most recently.
Ah. Yes. VAX is a different story. There things are still fresh, so it's
a different ballpark.
So I apologize. I was very much PDP-11 focused in my responses.
VAX, in a way, seems to be falling down into the same pit the PDP-11 is
in. But it's far more recent, so a lot of stuff is still around at a
different scale. And of course, VMS as such isn't dead, which is kind of
a different situation as well.
Not even that. It's not too uncommon that I get into some discussion and
people have no clue. This mailing list and environment isn't exactly
representative for people in general out there. Just go check on VCF (or
whatever the name is, I can't even remember - vintage computing
something...)
From my point, it's more that it's so much a club for internal
admiration. People are more interested in their turf than actually
finding information.
Take the ftp site of Update. It's been around since the early 90s.
Still, most people don't know about it. And lots of stuff have been
copied out from there elsewhere, and that's where people find various
bits and pieces.
And a bunch of PDP-8 stuff there are things that I dragged out of
numerous disks and DECtapes I have. Most of it done in the 90s. Some of
it still totally unknown by others.
And various software that I've written as well...
That mostly happens by accident, unless you are in the center.
Who knows when I can do it. I keep hoping... But every year, there will
be fewer interested.
I'll leave that to others. I'm busy just fixing things in RSX...
If someone really interested comes along, I'm happy to help with
information and guidance, but I'm not trying to enlighten people.
Well, we do that a lot at LSSM. In particular, there's a teenage kid
who lives in Michigan who is OBSESSED with PDP-11s. He's writing code
in assembler and running it under simh. He doesn't know this yet, but
the next time his parents bring him down here for a visit, I'm going to
give him a PDP-11/73.
That should be exciting. :-)
Also, will be interesting if it carries over to working on real hardware
as compared to simh.
Johnny
--
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
On 1/31/22 8:28 PM, Johnny Billquist wrote:
Yeah. Tell that to their kids when they are thrown into the street.
I do see your point, but it's an increasingly hypothetical point.
That might be. And I probably agree with it. But each person has to do
his own assessment on that point. And it might not look the same for all.
Because for some people, that "near zero
risk" is maybe not so "near
zero", and that have actual implications for actual people.
Yes, but they've been poorly (and selfishly) prioritized. You seem to
really just treat it as "there is no risk, so why aren't
people just doing whatever I think they should do", without
considering that for others the situation might actually look very
different.
You've jumped to a conclusion about what I think, and (with
respect) you're incorrect. I think risking some suit in a glass
building getting angry with me, or even filing a lawsuit against me,
is not, and will never be, more important than a piece of history
that stands to be lost forever. If you've
experienced that recently, then I am a little amazed.
Because that means people have been hanging on to things for a
*long* time, but now they don't care. Which for me sounds like an
unusual situation.
But of course, everything is possible.
Then be amazed. It happened most recently just a few months ago,
and several times last year. This is a lot more common in the real
world than you've assumed. Considering
that I'm usually even more overlooked than you are, you
can go with that complaint somewhere else.
I will (sorry) but everyone who knows what a PDP-11 is knows your
name. ;) Take PDP-8
stuff for example - I've been around the block, done more,
seen more, and have more information and stuff than most everyone on
those lists nowadays. But I don't actually care anymore. They can talk
and do things as much as they want. I don't need them, and they don't
even know I exist. Their problem. Not mine. And since it's also not a
problem for them, it's not a problem at all.
I'm with you on that. But passing knowledge on is important, and far
too few people do it. The excuse I hear most often is "nobody's
interested in this stuff". It's only
a problem when you want attention and recognition.
Or if you just want to be kept in the damn loop once in a while. I'm daily
facing the same dilemma. I have done so much improvements to
RSX. I'd like to release V5.0, which I have sitting here. But I can't.
I signed documents with XX2247 that limits what I can do, and I am not
willing to break the trust Dave put in me. Even though that improved
version have lots of stuff that would be really fun to share.
Instead I'm trying to find ways of resolving the problem. Meanwhile
it's sitting at my place, and nowhere else.
I will run that within *minutes* of its release. Assuming I'm still
breathing, of course! Until the day
I die... Who knows what happens then.
Well, I'm trying to get more (and younger) people interested in
PDP-11s, and I'm having pretty good success at that. You could try
that too.
1:40 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On Jan 31, 2022, at 6:25 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
...
Yes, Dave bought it all from the remains of Mentec Inc. The purpose was to try and make
it all available for hobbyists.
However, the contract between DEC and Mentec is poison, and that contract is still
active, with it today being HPE and XX2247. And Dave was definitely worried about his
house and everything with regards to that contract, which is why it stayed locked down.
I think this is a situation where creating an Inc. or LLC, perhaps a non-profit one, is a
legal tool to put some bozo shields between your private property and the bad lawyers.
paul
2:07 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 7:40 PM, Paul Koning wrote:
This in fact exactly why LLCs and other types of corporate structures
exist. Properly done, his personal property and effects would've been
completely shielded from any legal action as long as it wasn't criminal
in nature.
However, this is the USA, and whoever has the more expensive lawyers
wins, so..
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Yes, Dave
bought it all from the remains of Mentec Inc. The purpose was to try and make it all
available for hobbyists.
However, the contract between DEC and Mentec is poison, and that contract is still
active, with it today being HPE and XX2247. And Dave was definitely worried about his
house and everything with regards to that contract, which is why it stayed locked down.
I think this is a situation where creating an Inc. or LLC, perhaps a non-profit one, is a
legal tool to put some bozo shields between your private property and the bad lawyers.
11:26 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
-----Original Message-----
From: Dave McGuire <mcguire(a)neurotica.com>
Sent: 01 February 2022 01:08
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup
test on
pdp11 --> problem solved: Simh KG11 emulation
probably defective
On 1/31/22 7:40 PM, Paul Koning wrote:
non-profit
> Yes, Dave bought it all from the remains of
Mentec Inc. The purpose was
to try and make it all available for hobbyists.
> However, the contract between DEC and Mentec
is poison, and that
contract is still active, with it today being HPE and XX2247.
And Dave was
definitely worried about his house and everything with regards to that
contract, which is why it stayed locked down.
>
> I think this is a situation where creating an Inc. or LLC, perhaps a
one, is a legal tool to put some bozo shields between
your private
property
and the bad lawyers.
This in fact exactly why LLCs and other types of corporate structures
exist.
Properly done, his personal property and effects
would've been completely
shielded from any legal action as long as it wasn't criminal in nature.
However, this is the USA, and whoever has the more expensive lawyers
wins, so..
And as a certain UK Prince and an ex Autonomy boss are both finding out, the
USA will apply its law in almost any country...
... which I guess is why LZLABS is in Switzerland...
https://www.lzlabs.com/
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Dave
G4UGM & EA7KAE
2:13 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 2022-02-01 01:40, Paul Koning wrote:
I think you know that XX2247 was an LLC. :-)
Johnny
--
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
On Jan 31, 2022, at 6:25 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
...
Yes, Dave bought it all from the remains of Mentec Inc. The purpose was to try and make
it all available for hobbyists.
However, the contract between DEC and Mentec is poison, and that contract is still
active, with it today being HPE and XX2247. And Dave was definitely worried about his
house and everything with regards to that contract, which is why it stayed locked down.
I think this is a situation where creating an Inc. or LLC, perhaps a non-profit one, is a
legal tool to put some bozo shields between your private property and the bad lawyers.
3:19 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
Paul,
That is part of my thinking as well. When I decided to form a LLC a couple years ago I
had the firm run a trademark search for RSX11M. They did not turn up anything related to
DEC, Compaq, Mentec, HP or anyone else. Apparently they have let things lapse to the point
it doesn’t show up in the trademark databases. They did find Honda’s RSX related to cars
and a few other odds and ends but gave me a green light to use it. This of course does not
provide any license or anything else except a thin shield to liability to personal
property.
I had found a few years earlier that RSX11M.com was available and picked it up as well.
Someday I hope to convert the crude static html web site to a wiki more like what
gunkies.org but I just have too many things going on to invest the time now. Also it may
be best to just keep a low profile.
Best,
Mark
On Jan 31, 2022, at 6:40 PM, Paul Koning
<paulkoning(a)comcast.net> wrote:
On Jan 31, 2022, at 6:25 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
...
Yes, Dave bought it all from the remains of Mentec Inc. The purpose was to try and make
it all available for hobbyists.
However, the contract between DEC and Mentec is poison, and that contract is still
active, with it today being HPE and XX2247. And Dave was definitely worried about his
house and everything with regards to that contract, which is why it stayed locked down.
I think this is a situation where creating an Inc. or LLC, perhaps a non-profit one, is a
legal tool to put some bozo shields between your private property and the bad lawyers.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
31 Jan
31 Jan
11:27 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
Fair is an interesting word. What is abundantly true is that the full
duplex and the half duplex folks NEVER agreed. I was one of the very
few people who spent significant time on both (as long as the half
duplex terminal was a 3270).
And it's also true that the 3270 could blow a lot of things out of the
water in terms of speed (when on a byte selector channel) and field
definitions. If you could afford it. Everything about them had some
serious technology, except the price. Yet you couldn't do WSIWYG, not
real WSIWYG. And an attempted port of VisiCalc failed because of this.
A full duplex terminal allowed chording and language understanding,
which allowed faster movement to 'the right place'. It was easier to
get where you wanted instead of having to arrow key because a 3270 has
no idea where you want to go. You can certainly write REXX macros to do
some of this and bind them to function keys. You can get some decent
thing, but now you're hitting the CPU, which defeats the purpose of the
buffering.
I always picked EMAÇS over XEDIT, 100% of the time, but I didn't whine
about using XEDIT, either. A similar fight happened with bringing EMACS
up under Multics. An entire book got written about it. People blabbed
about CPU usage and it's true unless it doesn't matter.
And nobody agrees. I could bring an IBM programmer into my office and
show him EMACS on a 9600 baud terminal. "Look how easy and it knows what
you're typing and ... " Blah, Blah, Blah. They were utterly unmoved, so
I gave up.
For me, my official response was, "I like whatever I'm paid to use".
Right now, that's Windows and a virtual 3270. Privately, it was just
less fingering to do development. I am glad there is no more keyboard
unlock any more. I can't remember how many times I pushed that thing.
On 1/31/22 4:08 PM, Dave McGuire wrote:
On 1/31/22 3:22 PM, Thomas DeBellis wrote:
Then we are probably talking apples and
pineapples.
The product that I'm talking about is exclusively for the 36 bit
line, requiring a DTE to get the data to the PDP-10.
Well, Peter Allan did say he's interested in "2780 emulation for a
PDP-11".
And, Peter, so am I. We have several running mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like to
demonstrate is interoperability between disparate architectures; I'd
love to get something like that working such that we could demonstrate
RJE from a PDP-11 to a mainframe on the other side of the exhibit floor.
I don't recall a 3271, I guess you mean those
green screen terminals?
What a beast... I do recall using 3270, 3276 and the like when I was
hacking the bisync drivers on VM to talk to IBMSPL.
The 3271 is a remote terminal cluster controller for 3270-protocol
terminals.
A number of us swore that IBMSPL was the only
reasonable way to use
an IBM mainframe as the 3270 was a half-duplex terminal that was all
to ready to lock the keyboard if you even thought of typing ahead.
The more modern emulators don't lock like that, but you are still
effectively in a late 1960's half duplex paradigm. Still. Today.
Really.
Tom, I'm sorry but that's not a fair assessment at all. It's not so
much a "half-duplex paradigm" as it is forms- and screen-based.
You've used these systems; I know you know this.
The world thought it was a good enough paradigm to reinvent it for
the WWW, and it's still the most efficient way to get to a big
machine, rather than peck-peck-peck and flood the box with
interrupts. There's nothing "still today really" obsolete about it at
all; it's just that people like you (and me) who are accustomed to
character-by-character interaction with the machine see it as foreign.
And of course it turns into a painful experience when you try to
fake a character-by-character interface with it, with something like
VM or TSO. Think about what's going on to make that happen; there's
no way it won't be at least somewhat painful.
And I'm saying this as a late-comer to the mainframe world; I cut my
teeth on PDP-8 and PDP-11 systems.
-Dave
11:35 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
We're in agreement on many of those points. Most vehemently, I'm an
emacs user too, and I think pretty much all other editors (except EDT)
are retarded.
What I take issue with is your insinuation that a particular
current-technology terminal interaction paradigm is somehow obsolete
simply because it is not your preference. That's just BS and you're
more than intelligent enough to know that.
And you sure as hell can do WYSIWYG on a 3270-protocol terminal.
Come see some of the 3290s at LSSM and I'll show you.
-Dave
On 1/31/22 5:27 PM, Thomas DeBellis wrote:
Fair is an interesting word. What is abundantly true
is that the full
duplex and the half duplex folks NEVER agreed. I was one of the very
few people who spent significant time on both (as long as the half
duplex terminal was a 3270).
And it's also true that the 3270 could blow a lot of things out of the
water in terms of speed (when on a byte selector channel) and field
definitions. If you could afford it. Everything about them had some
serious technology, except the price. Yet you couldn't do WSIWYG, not
real WSIWYG. And an attempted port of VisiCalc failed because of this.
A full duplex terminal allowed chording and language understanding,
which allowed faster movement to 'the right place'. It was easier to
get where you wanted instead of having to arrow key because a 3270 has
no idea where you want to go. You can certainly write REXX macros to do
some of this and bind them to function keys. You can get some decent
thing, but now you're hitting the CPU, which defeats the purpose of the
buffering.
I always picked EMAÇS over XEDIT, 100% of the time, but I didn't whine
about using XEDIT, either. A similar fight happened with bringing EMACS
up under Multics. An entire book got written about it. People blabbed
about CPU usage and it's true unless it doesn't matter.
And nobody agrees. I could bring an IBM programmer into my office and
show him EMACS on a 9600 baud terminal. "Look how easy and it knows what
you're typing and ... " Blah, Blah, Blah. They were utterly unmoved, so
I gave up.
For me, my official response was, "I like whatever I'm paid to use".
Right now, that's Windows and a virtual 3270. Privately, it was just
less fingering to do development. I am glad there is no more keyboard
unlock any more. I can't remember how many times I pushed that thing.
On 1/31/22 4:08 PM, Dave McGuire wrote:
--
Dave McGuire, AK4HZ
New Kensington, PA
On 1/31/22 3:22 PM, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Then we are probably talking apples and
pineapples.
The product that I'm talking about is exclusively for the 36 bit
line, requiring a DTE to get the data to the PDP-10.
Well, Peter Allan did say he's interested in "2780 emulation for a
PDP-11".
And, Peter, so am I. We have several running mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like to
demonstrate is interoperability between disparate architectures; I'd
love to get something like that working such that we could demonstrate
RJE from a PDP-11 to a mainframe on the other side of the exhibit floor.
I don't recall a 3271, I guess you mean those
green screen terminals?
What a beast... I do recall using 3270, 3276 and the like when I was
hacking the bisync drivers on VM to talk to IBMSPL.
The 3271 is a remote terminal cluster controller for 3270-protocol
terminals.
A number of us swore that IBMSPL was the only
reasonable way to use
an IBM mainframe as the 3270 was a half-duplex terminal that was all
to ready to lock the keyboard if you even thought of typing ahead.
The more modern emulators don't lock like that, but you are still
effectively in a late 1960's half duplex paradigm. Still. Today.
Really.
Tom, I'm sorry but that's not a fair assessment at all. It's not so
much a "half-duplex paradigm" as it is forms- and screen-based. You've
used these systems; I know you know this.
The world thought it was a good enough paradigm to reinvent it for
the WWW, and it's still the most efficient way to get to a big
machine, rather than peck-peck-peck and flood the box with
interrupts. There's nothing "still today really" obsolete about it at
all; it's just that people like you (and me) who are accustomed to
character-by-character interaction with the machine see it as foreign.
And of course it turns into a painful experience when you try to
fake a character-by-character interface with it, with something like
VM or TSO. Think about what's going on to make that happen; there's
no way it won't be at least somewhat painful.
And I'm saying this as a late-comer to the mainframe world; I cut my
teeth on PDP-8 and PDP-11 systems.
-Dave
11:52 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
Oh, let's not overestimate my intelligence; I've been known to say some
exceptionally stupid things and have been corrected so many times by my
betters that it has almost gotten to be habit forming.
I don't think I was insinuating, I think I was more flat out
emphatically stating it. Today, if you are on z/OS, then the typical
way you do development is via a TSO/E session where you write JCL,
submit a batch job and look at the output (or the abend). Nothing's
changed, which is the point--I have programs I wrote back in the 70's
that still run. And the editor than I'm using is little changed from XEDIT.
If I had a choice of using a 3270 to use z/OS in this way, then I would
pick EMACS on a 20 and using IBMSPL. That changes, of course, if you
are using 'foreground' programs. I don't have enough experience with
the OMVS segment (the Unix interface) to have an informed opinion on that.
There is plenty of space for transactional services; CICS has been
evolved to the point that it will do a web interface. A 3270 is really
great for forms fill out; a very tough act to follow. So was a Haziltine
2000, but it's advantage is that it would do both full and half duplex
and cost less.
I would be delighted to come by LSSM. Heck, at this point after being
cooped up so long, I'd be delighted to go anywhere. Was the 3290 the
plasma display? I miss mine. Post a video on YouTube and allow me to
admit the error of my ways. And chording and everything? Control Meta
keys? I don't recall that, just function keys that you could bind to
macros to do the automatic nice things.
On 1/31/22 5:35 PM, Dave McGuire wrote:
We're in agreement on many of those points. Most vehemently, I'm an
emacs user too, and I think pretty much all other editors (except EDT)
are retarded.
What I take issue with is your insinuation that a particular
current-technology terminal interaction paradigm is somehow obsolete
simply because it is not your preference. That's just BS and you're
more than intelligent enough to know that.
And you sure as hell can do WYSIWYG on a 3270-protocol terminal.
Come see some of the 3290s at LSSM and I'll show you.
-Dave
On 1/31/22 5:27 PM, Thomas DeBellis wrote:
Fair is an interesting word. What is abundantly
true is that the
full duplex and the half duplex folks NEVER agreed. I was one of the
very few people who spent significant time on both (as long as the
half duplex terminal was a 3270).
And it's also true that the 3270 could blow a lot of things out of
the water in terms of speed (when on a byte selector channel) and
field definitions. If you could afford it. Everything about them
had some serious technology, except the price. Yet you couldn't do
WSIWYG, not real WSIWYG. And an attempted port of VisiCalc failed
because of this.
A full duplex terminal allowed chording and language understanding,
which allowed faster movement to 'the right place'. It was easier to
get where you wanted instead of having to arrow key because a 3270
has no idea where you want to go. You can certainly write REXX macros
to do some of this and bind them to function keys. You can get some
decent thing, but now you're hitting the CPU, which defeats the
purpose of the buffering.
I always picked EMAÇS over XEDIT, 100% of the time, but I didn't
whine about using XEDIT, either. A similar fight happened with
bringing EMACS up under Multics. An entire book got written about
it. People blabbed about CPU usage and it's true unless it doesn't
matter.
And nobody agrees. I could bring an IBM programmer into my office
and show him EMACS on a 9600 baud terminal. "Look how easy and it
knows what you're typing and ... " Blah, Blah, Blah. They were
utterly unmoved, so I gave up.
For me, my official response was, "I like whatever I'm paid to use".
Right now, that's Windows and a virtual 3270. Privately, it was just
less fingering to do development. I am glad there is no more
keyboard unlock any more. I can't remember how many times I pushed
that thing.
On 1/31/22 4:08 PM, Dave McGuire wrote:
On 1/31/22 3:22 PM, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Then we are probably talking apples and
pineapples.
The product that I'm talking about is exclusively for the 36 bit
line, requiring a DTE to get the data to the PDP-10.
Well, Peter Allan did say he's interested in "2780 emulation for a
PDP-11".
And, Peter, so am I. We have several running mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like
to demonstrate is interoperability between disparate architectures;
I'd love to get something like that working such that we could
demonstrate RJE from a PDP-11 to a mainframe on the other side of
the exhibit floor.
I don't recall a 3271, I guess you mean those
green screen
terminals? What a beast... I do recall using 3270, 3276 and the
like when I was hacking the bisync drivers on VM to talk to IBMSPL.
The 3271 is a remote terminal cluster controller for 3270-protocol
terminals.
A number of us swore that IBMSPL was the only
reasonable way to use
an IBM mainframe as the 3270 was a half-duplex terminal that was
all to ready to lock the keyboard if you even thought of typing
ahead. The more modern emulators don't lock like that, but you are
still effectively in a late 1960's half duplex paradigm. Still.
Today. Really.
Tom, I'm sorry but that's not a fair assessment at all. It's not
so much a "half-duplex paradigm" as it is forms- and screen-based.
You've used these systems; I know you know this.
The world thought it was a good enough paradigm to reinvent it for
the WWW, and it's still the most efficient way to get to a big
machine, rather than peck-peck-peck and flood the box with
interrupts. There's nothing "still today really" obsolete about it
at all; it's just that people like you (and me) who are accustomed
to character-by-character interaction with the machine see it as
foreign.
And of course it turns into a painful experience when you try to
fake a character-by-character interface with it, with something like
VM or TSO. Think about what's going on to make that happen; there's
no way it won't be at least somewhat painful.
And I'm saying this as a late-comer to the mainframe world; I cut
my teeth on PDP-8 and PDP-11 systems.
-Dave
1 Feb
1 Feb
12:14 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
Thomas, Dave,
So Thomas, you say "expensive" well IBM wasn't always more expensive. You
need to put the CPU cycles to handle the character editing somewhere. So if you were using
IBM you distributed some of it in the 3274/3174 controllers.
If you were DEC you simply sold more PDP11 or VAX which meant you needed more hardware and
probably more software licences. It wasn't always cheaper.
A very good friend once confided with me he was reluctantly rolling out All-In-One to
senior staff in a big UK bank but was giving lower levels PROFS because it was cheaper.
I don't know the details of the pricing, but I can't think why he would lie to
me.....
IBM also gave generous discounts to academia. Back in the day they would often loan a
machine to a university for 12 months trial, with an option to buy after the trial, but at
the used price, with academic discount which was typically 50%...
These days I have both. A few VaxStations and MicroVax, plus an IBM P390 . I enjoy both,
but when I fire up the VaxStation VLC I feel sad that Digital dropped the ball and that I
can no longer legally use it with VMS.
It must once have had a VMS licence, and I can't see that it was transferred any where
☹
What a different world it would be if we had all had one of those on our desks instead of
IBM PC's...
Dave
-----Original Message-----
From: Thomas DeBellis <tommytimesharing(a)gmail.com>
Sent: 31 January 2022 22:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on
pdp11 --> problem solved: Simh KG11 emulation probably defective
Fair is an interesting word. What is abundantly true is that the full duplex and
the half duplex folks NEVER agreed. I was one of the very few people who
spent significant time on both (as long as the half duplex terminal was a
3270).
And it's also true that the 3270 could blow a lot of things out of the water in
terms of speed (when on a byte selector channel) and field definitions. If
you could afford it. Everything about them had some serious technology,
except the price. Yet you couldn't do WSIWYG, not real WSIWYG. And an
attempted port of VisiCalc failed because of this.
A full duplex terminal allowed chording and language understanding, which
allowed faster movement to 'the right place'. It was easier to get where you
wanted instead of having to arrow key because a 3270 has no idea where you
want to go. You can certainly write REXX macros to do some of this and bind
them to function keys. You can get some decent thing, but now you're
hitting the CPU, which defeats the purpose of the buffering.
I always picked EMAÇS over XEDIT, 100% of the time, but I didn't whine about
using XEDIT, either. A similar fight happened with bringing EMACS up under
Multics. An entire book got written about it. People blabbed about CPU
usage and it's true unless it doesn't matter.
And nobody agrees. I could bring an IBM programmer into my office and
show him EMACS on a 9600 baud terminal. "Look how easy and it knows
what you're typing and ... " Blah, Blah, Blah. They were utterly unmoved, so I
gave up.
For me, my official response was, "I like whatever I'm paid to use". Right
now, that's Windows and a virtual 3270. Privately, it was just less fingering to
do development. I am glad there is no more keyboard unlock any more. I
can't remember how many times I pushed that thing.
On 1/31/22 4:08 PM, Dave McGuire wrote:
On 1/31/22 3:22 PM, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se Then we are probably talking apples and
pineapples.
The product that I'm talking about is exclusively for the 36 bit
line, requiring a DTE to get the data to the PDP-10.
Well, Peter Allan did say he's interested in "2780 emulation for a
PDP-11".
And, Peter, so am I. We have several running mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like to
demonstrate is interoperability between disparate architectures; I'd
love to get something like that working such that we could demonstrate
RJE from a PDP-11 to a mainframe on the other side of the exhibit floor.
I don't recall a 3271, I guess you mean those
green screen terminals?
What a beast... I do recall using 3270, 3276 and the like when I was
hacking the bisync drivers on VM to talk to IBMSPL.
The 3271 is a remote terminal cluster controller for 3270-protocol
terminals.
A number of us swore that IBMSPL was the only
reasonable way to use
an IBM mainframe as the 3270 was a half-duplex terminal that was all
to ready to lock the keyboard if you even thought of typing ahead.
The more modern emulators don't lock like that, but you are still
effectively in a late 1960's half duplex paradigm. Still. Today.
Really.
Tom, I'm sorry but that's not a fair assessment at all. It's not so
much a "half-duplex paradigm" as it is forms- and screen-based.
You've used these systems; I know you know this.
The world thought it was a good enough paradigm to reinvent it for
the WWW, and it's still the most efficient way to get to a big
machine, rather than peck-peck-peck and flood the box with interrupts.
There's nothing "still today really" obsolete about it at all; it's
just that people like you (and me) who are accustomed to
character-by-character interaction with the machine see it as foreign.
And of course it turns into a painful experience when you try to
fake a character-by-character interface with it, with something like
VM or TSO. Think about what's going on to make that happen; there's
no way it won't be at least somewhat painful.
And I'm saying this as a late-comer to the mainframe world; I cut my
teeth on PDP-8 and PDP-11 systems.
-Dave
12:26 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
You know, I think you might be right. Columbia did get a big discount
from IBM and we had some stuff that was not commonly available (like the
360/91, of which three we made, I believe). I don't remember DEC giving
us that kind of discount on our 20's except when they were desperately
trying to save the account after they pulled the plug on 36 bits.
That point about CPU usage really was /the/ point. I think I remember
an IBM 3033 demonstration system with some absurd number of 3270's on
it; I mean something like 11,000. No way you could that with full
duplex; too many Start I/O's. Even if you did a Start I/O no-release,
you just would never had the gas.
All things being equal, the deals we could get on a 3270 were about
twice as expensive as what we could get for a HP2621 or something of
that caliber. The wiring was more expensive to do. What I remember is
our com guys complaining about the coax being difficult to work with
while RS232 being nowhere as difficult and the wire itself costing less
(not sure about plenum grade).
I think the IBM controllers may have cost more; at least a controller
for 16 3270's cost more than a DH11, but I don't think that's a
completely fair comparison because it didn't factor the cost of the
front end (which you needed no matter what you did).
On 1/31/22 6:14 PM, dave.g4ugm(a)gmail.com wrote:
Thomas, Dave,
So Thomas, you say "expensive" well IBM wasn't always more expensive. You
need to put the CPU cycles to handle the character editing somewhere. So if you were using
IBM you distributed some of it in the 3274/3174 controllers.
If you were DEC you simply sold more PDP11 or VAX which meant you needed more hardware
and probably more software licences. It wasn't always cheaper.
A very good friend once confided with me he was reluctantly rolling out All-In-One to
senior staff in a big UK bank but was giving lower levels PROFS because it was cheaper.
I don't know the details of the pricing, but I can't think why he would lie to
me.....
IBM also gave generous discounts to academia. Back in the day they would often loan a
machine to a university for 12 months trial, with an option to buy after the trial, but at
the used price, with academic discount which was typically 50%...
These days I have both. A few VaxStations and MicroVax, plus an IBM P390 . I enjoy both,
but when I fire up the VaxStation VLC I feel sad that Digital dropped the ball and that I
can no longer legally use it with VMS.
It must once have had a VMS licence, and I can't see that it was transferred any
where ☹
What a different world it would be if we had all had one of those on our desks instead of
IBM PC's...
Dave
-----Original Message-----
From: Thomas DeBellis<tommytimesharing(a)gmail.com>
Sent: 31 January 2022 22:28
To:hecnet@lists.dfupdate.se
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on
pdp11 --> problem solved: Simh KG11 emulation probably defective
Fair is an interesting word. What is abundantly true is that the full duplex and
the half duplex folks NEVER agreed. I was one of the very few people who
spent significant time on both (as long as the half duplex terminal was a
3270).
And it's also true that the 3270 could blow a lot of things out of the water in
terms of speed (when on a byte selector channel) and field definitions. If
you could afford it. Everything about them had some serious technology,
except the price. Yet you couldn't do WSIWYG, not real WSIWYG. And an
attempted port of VisiCalc failed because of this.
A full duplex terminal allowed chording and language understanding, which
allowed faster movement to 'the right place'. It was easier to get where you
wanted instead of having to arrow key because a 3270 has no idea where you
want to go. You can certainly write REXX macros to do some of this and bind
them to function keys. You can get some decent thing, but now you're
hitting the CPU, which defeats the purpose of the buffering.
I always picked EMAÇS over XEDIT, 100% of the time, but I didn't whine about
using XEDIT, either. A similar fight happened with bringing EMACS up under
Multics. An entire book got written about it. People blabbed about CPU
usage and it's true unless it doesn't matter.
And nobody agrees. I could bring an IBM programmer into my office and
show him EMACS on a 9600 baud terminal. "Look how easy and it knows
what you're typing and ... " Blah, Blah, Blah. They were utterly unmoved, so I
gave up.
For me, my official response was, "I like whatever I'm paid to use". Right
now, that's Windows and a virtual 3270. Privately, it was just less fingering to
do development. I am glad there is no more keyboard unlock any more. I
can't remember how many times I pushed that thing.
On 1/31/22 4:08 PM, Dave McGuire wrote:
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se On 1/31/22 3:22 PM, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se To unsubscribe send an email
tohecnet-leave(a)lists.dfupdate.se Then we are probably talking apples and
pineapples.
The product that I'm talking about is exclusively for the 36 bit
line, requiring a DTE to get the data to the PDP-10.
Well, Peter Allan did say
he's interested in "2780 emulation for a
PDP-11".
And, Peter, so am I. We have several running mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like to
demonstrate is interoperability between disparate architectures; I'd
love to get something like that working such that we could demonstrate
RJE from a PDP-11 to a mainframe on the other side of the exhibit floor.
I don't recall a 3271, I guess you mean those
green screen terminals?
What a beast... I do recall using 3270, 3276 and the like when I was
hacking the bisync drivers on VM to talk to IBMSPL.
The 3271 is a remote
terminal cluster controller for 3270-protocol
terminals.
A number of us swore that IBMSPL was the only
reasonable way to use
an IBM mainframe as the 3270 was a half-duplex terminal that was all
to ready to lock the keyboard if you even thought of typing ahead.
The more modern emulators don't lock like that, but you are still
effectively in a late 1960's half duplex paradigm. Still. Today.
Really.
Tom, I'm sorry but that's not a fair assessment at all.
It's not so
much a "half-duplex paradigm" as it is forms- and screen-based.
You've used these systems; I know you know this.
The world thought it was a good enough paradigm to reinvent it for
the WWW, and it's still the most efficient way to get to a big
machine, rather than peck-peck-peck and flood the box with interrupts.
There's nothing "still today really" obsolete about it at all; it's
just that people like you (and me) who are accustomed to
character-by-character interaction with the machine see it as foreign.
And of course it turns into a painful experience when you try to
fake a character-by-character interface with it, with something like
VM or TSO. Think about what's going on to make that happen; there's
no way it won't be at least somewhat painful.
And I'm saying this as a late-comer to the mainframe world; I cut my
teeth on PDP-8 and PDP-11 systems.
-Dave
12:32 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
DEC-20s were never cheap. :-)
PDP-8s and PDP-11s on the other hand. And you got all the sources, and
all the drawings. Completely different crowd, completely different cost
model. Customers did a lot of things on their own. And DEC did huge
discounts to academia. At least up to the mid 80s. After that, IBM
suites took over DEC, and everything broke.
But yes, for those really large installations, I think IBM wasn't that
bad. Not my cup of tea, but I've always been too much into nerdy
details, and not enough interested in the business aspects.
Johnny
On 2022-02-01 00:26, Thomas DeBellis wrote:
You know, I think you might be right. Columbia did get
a big discount
from IBM and we had some stuff that was not commonly available (like the
360/91, of which three we made, I believe). I don't remember DEC giving
us that kind of discount on our 20's except when they were desperately
trying to save the account after they pulled the plug on 36 bits.
That point about CPU usage really was /the/ point. I think I remember
an IBM 3033 demonstration system with some absurd number of 3270's on
it; I mean something like 11,000. No way you could that with full
duplex; too many Start I/O's. Even if you did a Start I/O no-release,
you just would never had the gas.
All things being equal, the deals we could get on a 3270 were about
twice as expensive as what we could get for a HP2621 or something of
that caliber. The wiring was more expensive to do. What I remember is
our com guys complaining about the coax being difficult to work with
while RS232 being nowhere as difficult and the wire itself costing less
(not sure about plenum grade).
I think the IBM controllers may have cost more; at least a controller
for 16 3270's cost more than a DH11, but I don't think that's a
completely fair comparison because it didn't factor the cost of the
front end (which you needed no matter what you did).
On 1/31/22 6:14 PM, dave.g4ugm(a)gmail.com wrote:
--
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
Thomas, Dave,
So Thomas, you say "expensive" well IBM wasn't always more expensive. You
need to put the CPU cycles to handle the character editing somewhere. So if you were using
IBM you distributed some of it in the 3274/3174 controllers.
If you were DEC you simply sold more PDP11 or VAX which meant you needed more hardware
and probably more software licences. It wasn't always cheaper.
A very good friend once confided with me he was reluctantly rolling out All-In-One to
senior staff in a big UK bank but was giving lower levels PROFS because it was cheaper.
I don't know the details of the pricing, but I can't think why he would lie to
me.....
IBM also gave generous discounts to academia. Back in the day they would often loan a
machine to a university for 12 months trial, with an option to buy after the trial, but at
the used price, with academic discount which was typically 50%...
These days I have both. A few VaxStations and MicroVax, plus an IBM P390 . I enjoy both,
but when I fire up the VaxStation VLC I feel sad that Digital dropped the ball and that I
can no longer legally use it with VMS.
It must once have had a VMS licence, and I can't see that it was transferred any
where ☹
What a different world it would be if we had all had one of those on our desks instead of
IBM PC's...
Dave
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se -----Original Message-----
From: Thomas DeBellis<tommytimesharing(a)gmail.com>
Sent: 31 January 2022 22:28
To:hecnet@lists.dfupdate.se
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on
pdp11 --> problem solved: Simh KG11 emulation probably defective
Fair is an interesting word. What is abundantly true is that the full duplex and
the half duplex folks NEVER agreed. I was one of the very few people who
spent significant time on both (as long as the half duplex terminal was a
3270).
And it's also true that the 3270 could blow a lot of things out of the water in
terms of speed (when on a byte selector channel) and field definitions. If
you could afford it. Everything about them had some serious technology,
except the price. Yet you couldn't do WSIWYG, not real WSIWYG. And an
attempted port of VisiCalc failed because of this.
A full duplex terminal allowed chording and language understanding, which
allowed faster movement to 'the right place'. It was easier to get where you
wanted instead of having to arrow key because a 3270 has no idea where you
want to go. You can certainly write REXX macros to do some of this and bind
them to function keys. You can get some decent thing, but now you're
hitting the CPU, which defeats the purpose of the buffering.
I always picked EMAÇS over XEDIT, 100% of the time, but I didn't whine about
using XEDIT, either. A similar fight happened with bringing EMACS up under
Multics. An entire book got written about it. People blabbed about CPU
usage and it's true unless it doesn't matter.
And nobody agrees. I could bring an IBM programmer into my office and
show him EMACS on a 9600 baud terminal. "Look how easy and it knows
what you're typing and ... " Blah, Blah, Blah. They were utterly unmoved, so I
gave up.
For me, my official response was, "I like whatever I'm paid to use". Right
now, that's Windows and a virtual 3270. Privately, it was just less fingering to
do development. I am glad there is no more keyboard unlock any more. I
can't remember how many times I pushed that thing.
On 1/31/22 4:08 PM, Dave McGuire wrote:
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se On 1/31/22 3:22 PM, Thomas DeBellis wrote:
> Then we are probably talking apples and pineapples.
>
> The product that I'm talking about is exclusively for the 36 bit
> line, requiring a DTE to get the data to the PDP-10.
Well, Peter Allan did say he's interested in "2780 emulation for a
PDP-11".
And, Peter, so am I. We have several running mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like to
demonstrate is interoperability between disparate architectures; I'd
love to get something like that working such that we could demonstrate
RJE from a PDP-11 to a mainframe on the other side of the exhibit floor.
> I don't recall a 3271, I guess you mean those green screen terminals?
> What a beast... I do recall using 3270, 3276 and the like when I was
> hacking the bisync drivers on VM to talk to IBMSPL.
The 3271 is a remote terminal cluster controller for 3270-protocol
terminals.
> A number of us swore that IBMSPL was the only reasonable way to use
> an IBM mainframe as the 3270 was a half-duplex terminal that was all
> to ready to lock the keyboard if you even thought of typing ahead.
> The more modern emulators don't lock like that, but you are still
> effectively in a late 1960's half duplex paradigm. Still. Today.
> Really.
Tom, I'm sorry but that's not a fair assessment at all. It's not so
much a "half-duplex paradigm" as it is forms- and screen-based.
You've used these systems; I know you know this.
The world thought it was a good enough paradigm to reinvent it for
the WWW, and it's still the most efficient way to get to a big
machine, rather than peck-peck-peck and flood the box with interrupts.
There's nothing "still today really" obsolete about it at all; it's
just that people like you (and me) who are accustomed to
character-by-character interaction with the machine see it as foreign.
And of course it turns into a painful experience when you try to
fake a character-by-character interface with it, with something like
VM or TSO. Think about what's going on to make that happen; there's
no way it won't be at least somewhat painful.
And I'm saying this as a late-comer to the mainframe world; I cut my
teeth on PDP-8 and PDP-11 systems.
-Dave
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se To unsubscribe send an email
tohecnet-leave(a)lists.dfupdate.se
12:45 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 6:26 PM, Thomas DeBellis wrote:
That point about CPU usage really was /the/ point. I
think I remember
an IBM 3033 demonstration system with some absurd number of 3270's on
it; I mean something like 11,000. No way you could that with full
duplex; too many Start I/O's. Even if you did a Start I/O no-release,
you just would never had the gas.
Very much so.
All things being equal, the deals we could get on a
3270 were about
twice as expensive as what we could get for a HP2621 or something of
that caliber.
That's pure typical IBM-overpricedness and nothing more. The
electronics are no more complex (in many cases, it's less complex) than
character-mode ASCII terminals.
The wiring was more expensive to do. What I remember
is
our com guys complaining about the coax being difficult to work with
while RS232 being nowhere as difficult and the wire itself costing less
(not sure about plenum grade).
Even plenum-grade multiconductor non-coaxial cable is cheaper than
coax. IBM could've used 50-ohm coax which would've given them access to
RG-174 cable, which is ~1/8" diameter and very "soft", and it wouldn't
have cost them much in the distance capabilities, but they chose not to
do so.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
1:03 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
Thomas,
Modern S390 I/O is different. XA, ESA, Z/OS could/can sustain I/O rates unthought of on
S360/370. And I think the big discounts went bye bye.
Aug
Sent from my iPad
On Jan 31, 2022, at 5:26 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
You know, I think you might be right. Columbia did get a big discount from IBM and we had
some stuff that was not commonly available (like the 360/91, of which three we made, I
believe). I don't remember DEC giving us that kind of discount on our 20's except
when they were desperately trying to save the account after they pulled the plug on 36
bits.
That point about CPU usage really was the point. I think I remember an IBM 3033
demonstration system with some absurd number of 3270's on it; I mean something like
11,000. No way you could that with full duplex; too many Start I/O's. Even if you
did a Start I/O no-release, you just would never had the gas.
All things being equal, the deals we could get on a 3270 were about twice as expensive as
what we could get for a HP2621 or something of that caliber. The wiring was more
expensive to do. What I remember is our com guys complaining about the coax being
difficult to work with while RS232 being nowhere as difficult and the wire itself costing
less (not sure about plenum grade).
I think the IBM controllers may have cost more; at least a controller for 16 3270's
cost more than a DH11, but I don't think that's a completely fair comparison
because it didn't factor the cost of the front end (which you needed no matter what
you did).
On 1/31/22 6:14 PM, dave.g4ugm(a)gmail.com wrote:
Thomas, Dave,
So Thomas, you say "expensive" well IBM wasn't always more expensive. You
need to put the CPU cycles to handle the character editing somewhere. So if you were using
IBM you distributed some of it in the 3274/3174 controllers.
If you were DEC you simply sold more PDP11 or VAX which meant you needed more hardware
and probably more software licences. It wasn't always cheaper.
A very good friend once confided with me he was reluctantly rolling out All-In-One to
senior staff in a big UK bank but was giving lower levels PROFS because it was cheaper.
I don't know the details of the pricing, but I can't think why he would lie to
me.....
IBM also gave generous discounts to academia. Back in the day they would often loan a
machine to a university for 12 months trial, with an option to buy after the trial, but at
the used price, with academic discount which was typically 50%...
These days I have both. A few VaxStations and MicroVax, plus an IBM P390 . I enjoy both,
but when I fire up the VaxStation VLC I feel sad that Digital dropped the ball and that I
can no longer legally use it with VMS.
It must once have had a VMS licence, and I can't see that it was transferred any
where ☹
What a different world it would be if we had all had one of those on our desks instead of
IBM PC's...
Dave
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se -----Original Message-----
From: Thomas DeBellis <tommytimesharing(a)gmail.com>
Sent: 31 January 2022 22:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on
pdp11 --> problem solved: Simh KG11 emulation probably defective
Fair is an interesting word. What is abundantly true is that the full duplex and
the half duplex folks NEVER agreed. I was one of the very few people who
spent significant time on both (as long as the half duplex terminal was a
3270).
And it's also true that the 3270 could blow a lot of things out of the water in
terms of speed (when on a byte selector channel) and field definitions. If
you could afford it. Everything about them had some serious technology,
except the price. Yet you couldn't do WSIWYG, not real WSIWYG. And an
attempted port of VisiCalc failed because of this.
A full duplex terminal allowed chording and language understanding, which
allowed faster movement to 'the right place'. It was easier to get where you
wanted instead of having to arrow key because a 3270 has no idea where you
want to go. You can certainly write REXX macros to do some of this and bind
them to function keys. You can get some decent thing, but now you're
hitting the CPU, which defeats the purpose of the buffering.
I always picked EMAÇS over XEDIT, 100% of the time, but I didn't whine about
using XEDIT, either. A similar fight happened with bringing EMACS up under
Multics. An entire book got written about it. People blabbed about CPU
usage and it's true unless it doesn't matter.
And nobody agrees. I could bring an IBM programmer into my office and
show him EMACS on a 9600 baud terminal. "Look how easy and it knows
what you're typing and ... " Blah, Blah, Blah. They were utterly unmoved, so I
gave up.
For me, my official response was, "I like whatever I'm paid to use". Right
now, that's Windows and a virtual 3270. Privately, it was just less fingering to
do development. I am glad there is no more keyboard unlock any more. I
can't remember how many times I pushed that thing.
On 1/31/22 4:08 PM, Dave McGuire wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se > On 1/31/22 3:22 PM, Thomas DeBellis wrote:
> Then we are probably talking apples and pineapples.
>
> The product that I'm talking about is exclusively for the 36 bit
> line, requiring a DTE to get the data to the PDP-10.
Well, Peter Allan did say he's interested in "2780 emulation for a
PDP-11".
And, Peter, so am I. We have several running mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like to
demonstrate is interoperability between disparate architectures; I'd
love to get something like that working such that we could demonstrate
RJE from a PDP-11 to a mainframe on the other side of the exhibit floor.
> I don't recall a 3271, I guess you mean those green screen terminals?
> What a beast... I do recall using 3270, 3276 and the like when I was
> hacking the bisync drivers on VM to talk to IBMSPL.
The 3271 is a remote terminal cluster controller for 3270-protocol
terminals.
> A number of us swore that IBMSPL was the only reasonable way to use
> an IBM mainframe as the 3270 was a half-duplex terminal that was all
> to ready to lock the keyboard if you even thought of typing ahead.
> The more modern emulators don't lock like that, but you are still
> effectively in a late 1960's half duplex paradigm. Still. Today.
> Really.
Tom, I'm sorry but that's not a fair assessment at all. It's not so
much a "half-duplex paradigm" as it is forms- and screen-based.
You've used these systems; I know you know this.
The world thought it was a good enough paradigm to reinvent it for
the WWW, and it's still the most efficient way to get to a big
machine, rather than peck-peck-peck and flood the box with interrupts.
There's nothing "still today really" obsolete about it at all; it's
just that people like you (and me) who are accustomed to
character-by-character interaction with the machine see it as foreign.
And of course it turns into a painful experience when you try to
fake a character-by-character interface with it, with something like
VM or TSO. Think about what's going on to make that happen; there's
no way it won't be at least somewhat painful.
And I'm saying this as a late-comer to the mainframe world; I cut my
teeth on PDP-8 and PDP-11 systems.
-Dave
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
1:55 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 7:03 PM, August Treubig wrote:
Modern S390 I/O is different. XA, ESA, Z/OS could/can
sustain I/O rates
unthought of on S360/370. And I think the big discounts went bye bye.
The discounts may have gone bye bye, but the machines are a whole lot
cheaper to begin with.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
3:30 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 4:08 PM, Dave McGuire wrote:
And, Peter, so am I. We have several running
mainframes at LSSM,
across the room from a bunch of PDP-11s. One of the things we like to
demonstrate is interoperability between disparate architectures; I'd
love to get something like that working such that we could demonstrate
RJE from a PDP-11 to a mainframe on the other side of the exhibit floor.
Dave - I am not sure if you can at least have a VAX talking TCPNJE to
the mainframe, but this is very easy to do (from OpenVMS V7.3 in the
following example; also tested doable from VAX/VMS 4.7).
$ show net
Product: DECNET Node: QCOCAL Address(es): 31.10
Product: TCP/IP Node: sanyalnet-vax.sanyalnet.lan Address(es):
10.42.2
.5
$ send/command irlearn "cpq ind"
$
(IRLEARN) - CPQ: CPU-005% APU-000% Q1-00 Q2-00 STORAGE-017% RATIO-01.0
$ send/command irlearn "cpq t"
$
(IRLEARN) - CPQ: TIME IS 02:22:21 GMT TUESDAY 02/01/22
$
(IRLEARN) - CPQ: CONNECT= 79:43:13 VIRTCPU= 607:02.92 TOTCPU= 687:08.42
$
$ send/command irlearn "q sys"
$
(IRLEARN) - LINK ADMIN INACTIVE
$
(IRLEARN) - LINK IPVAX INACTIVE
(IRLEARN) - LINK IEGBOX INACTIVE
(IRLEARN) - LINK CCVAX INACTIVE
(IRLEARN) - LINK IRTCCARL INACTIVE
$
(IRLEARN) - LINK IRUCCIBM INACTIVE
$
(IRLEARN) - LINK UKACRL INACTIVE
(IRLEARN) - LINK PRTRSCS INACTIVE
(IRLEARN) - LINK BTP CONNECT -- LINE 038 NOH
(IRLEARN) - LINK CEIRE INACTIVE
(IRLEARN) - LINK SCOTTY INACTIVE
(IRLEARN) - LINK KEWTORIA CONNECT -- LINE 040 NOH
(IRLEARN) - LINK KEWRONI INACTIVE
(IRLEARN) - LINK AEARN CONNECT -- LINE 042 NOH
(IRLEARN) - LINK MOSHIX ACTIVE -- LINE 043 NOH
(IRLEARN) - LINK IMPVAX CONNECT -- LINE 044 NOH
(IRLEARN) - LINK NCCMAX CONNECT -- LINE 045 NOH
(IRLEARN) - LINK N00DLE CONNECT -- LINE 046 NOH
(IRLEARN) - LINK ETEXAS INACTIVE
(IRLEARN) - LINK VMF INACTIVE
(IRLEARN) - LINK FRIWVM01 INACTIVE
(IRLEARN) - LINK WABMVS CONNECT -- LINE 04A NOH
(IRLEARN) - LINK PJJV0 CONNECT -- LINE 04B NOH
$
(IRLEARN) - LINK MISERVM INACTIVE
(IRLEARN) - LINK THCHVM01 INACTIVE
(IRLEARN) - LINK CEARN CONNECT -- LINE 04E NOH
(IRLEARN) - LINK TANJPVM1 INACTIVE
(IRLEARN) - LINK IRUCDTST INACTIVE
$
31 Jan
31 Jan
10:10 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 3:00 PM, Paul Koning wrote:
What I mentioned is one or several PDP-11 products,
available for RSTS and I believe RSX. There definitely is an "RJ2780 emulator"
-- the official name may not be quite that. And I think there was also a 3271 emulator,
though I'm not sure if that existed on RSTS.
I have no idea what these things do, since 2780 is something I've never used. Some
sort of remote job entry station? Anyway, it is the only RSTS software that uses a KG11.
DECnet doesn't because on RSTS DECnet only supported devices with hardware CRC: DMC
and friends and later Ethernet.
Yes, 2780 is an RJE protocol.
I did an unsupported software DDCMP, but that does CRC
in software (8 bits at a time, the classic table driven fast software implementation).
That probably outruns a KG11 and in any case I never had access to that hardware.
The KG11 looks like all TTL logic; are you really sure it'd be faster
to do it in software running on similar-generation hardware?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
11:18 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On Jan 31, 2022, at 4:10 PM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
On 1/31/22 3:00 PM, Paul Koning wrote:
Johnny says that RSX said so, for the fast machines like 11/70 and 11/44. And that makes
sense, with basic instruction times under a microsecond and Unibus accesses rather
expensive due to mapping. The software CRC takes 7 instructions per byte, all register
instructions except for one table reference. The KG11 does a bit at a time, with a 10 MHz
clock if I read it right, so that fits the statement that the operation is complete in a
microsecond so software may not need to test the Done bit depending on what machine you
have. At least two unibus cycles plus a microsecond processing time is not obviously
faster than 7 fast CPU instructions.
The KG11 dates back to the 11/20; as I said earlier, it very obviously makes sense on that
machine where software CRC would probably take around 30 microseconds per byte.
paul
What I mentioned is one or several PDP-11
products, available for RSTS and I believe RSX. There definitely is an "RJ2780
emulator" -- the official name may not be quite that. And I think there was also a
3271 emulator, though I'm not sure if that existed on RSTS.
I have no idea what these things do, since 2780 is something I've never used. Some
sort of remote job entry station? Anyway, it is the only RSTS software that uses a KG11.
DECnet doesn't because on RSTS DECnet only supported devices with hardware CRC: DMC
and friends and later Ethernet.
Yes, 2780 is an RJE protocol.
I did an unsupported software DDCMP, but that
does CRC in software (8 bits at a time, the classic table driven fast software
implementation). That probably outruns a KG11 and in any case I never had access to that
hardware.
The KG11 looks like all TTL logic; are you really sure it'd be faster to do it in
software running on similar-generation hardware?
11:57 p.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 1/31/22 5:18 PM, Paul Koning wrote:
Johnny says that RSX said so, for the fast machines like 11/70 and 11/44. And that makes
sense, with basic instruction times under a microsecond and Unibus accesses rather
expensive due to mapping. The software CRC takes 7 instructions per byte, all register
instructions except for one table reference. The KG11 does a bit at a time, with a 10 MHz
clock if I read it right, so that fits the statement that the operation is complete in a
microsecond so software may not need to test the Done bit depending on what machine you
have. At least two unibus cycles plus a microsecond processing time is not obviously
faster than 7 fast CPU instructions.
The KG11 dates back to the 11/20; as I said earlier, it very obviously makes sense on
that machine where software CRC would probably take around 30 microseconds per byte.
Ok, executing mostly out of cache I can see now how that might be
faster, especially on something like an 11/70 with a screaming fast
processor but a slow Unibus interface. Interesting!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
I did an unsupported software DDCMP, but that does CRC
in software (8 bits at a time, the classic table driven fast software implementation).
That probably outruns a KG11 and in any case I never had access to that hardware.
The KG11 looks like all TTL logic; are you really sure it'd be faster to do it in
software running on similar-generation hardware?
1 Feb
1 Feb
12:06 a.m.
New subject: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective
On 2022-01-31 23:57, Dave McGuire wrote:
On 1/31/22 5:18 PM, Paul Koning wrote:
Johnny says that RSX said so, for the fast machines like 11/70 and
11/44. And that makes sense, with basic instruction times under a
microsecond and Unibus accesses rather expensive due to mapping. The
software CRC takes 7 instructions per byte, all register instructions
except for one table reference. The KG11 does a bit at a time, with a
10 MHz clock if I read it right, so that fits the statement that the
operation is complete in a microsecond so software may not need to
test the Done bit depending on what machine you have. At least two
unibus cycles plus a microsecond processing time is not obviously
faster than 7 fast CPU instructions.
The KG11 dates back to the 11/20; as I said earlier, it very obviously
makes sense on that machine where software CRC would probably take
around 30 microseconds per byte.
Ok, executing mostly out of cache I can see now how that might be
faster, especially on something like an 11/70 with a screaming fast
processor but a slow Unibus interface. Interesting!
Well, the DECnet/RSX manuals explicitly state that you don't want to
enable the KG11 even if you have one, if you run on an 11/44 or 11/70.
So yeah, slow...
Johnny
--
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
I did an unsupported software DDCMP, but that does CRC
in software
(8 bits at a time, the classic table driven fast software
implementation). That probably outruns a KG11 and in any case I
never had access to that hardware.
The KG11 looks like all TTL logic; are you really sure it'd be
faster to do it in software running on similar-generation hardware?
1025
days inactive
1027
days old
41 comments
11 participants
participants (11)
-
August Treubig -
Dave McGuire -
dave.g4ugm＠gmail.com -
Johnny Billquist -
Mark Matlock -
Mark Pizzolato - Info Comm -
Paul Koning -
Peter Allan -
R. Voorhorst -
Supratim Sanyal -
Thomas DeBellis