Re: Future of cctalk/cctech (comment on address fields) , capturing Discord server traffi

[Eric Smith via cctalk]

On Thu, Jun 25, 2020 at 2:27 PM jim stephens via cctalk <
cctalk@classiccmp.org> wrote:

> The current message
> "From" field contains the name of the original sender but with the
> encoded address of the list as the email address
>

Unfortunately now there's no practical way for a mailing list to avoid
rewriting the From header to indicate that the messages are sent from the
list. If you don't do that, many (or most) mail servers (MTAs) will
silently drop the mail due to DKIM/SPF/DMARC failures.

If I send mail from f...@example.com to a classiccmp.org list, and then the
list sends it to all the subscribers _without_ rewriting the From header,
many (or most) receiving MTAs will find that the message fails origin
verification because classiccmp.org can't be validated as a legitimate SMTP
originator for email from example.com.

I'm surprised that use of an "X-Original-From" header or similar isn't
commonly used to work around this. Possibly people may think that it would
help spammers harvest email addresses, but it wouldn't make the harvesting
problem any worse than it was before From rewriting.

Some list software puts the entire original From address in the comment
part of the rewritten From header, rather than only the comment part of the
original.

Re: Future of cctalk/cctech (comment on address fields) , capturing Discord server traffi

[Maciej W. Rozycki via cctalk]

On Thu, 25 Jun 2020, jim stephens via cctalk wrote:

> I have an observation for when the list migrates.  The current message "From"
> field contains the name of the original sender but with the encoded address of
> the list as the email address
> 
> For example this has
> 
> Al Kossow via cctalk 

 That has been a nuisance in many ways, however regrettably it seems the 
lesser evil in the current world of e-mail infested with DMARC, invented 
with little concern as to its impact on mailing lists.  Sigh...

  Maciej

Re: Future of cctalk/cctech (comment on address fields) , capturing Discord server traffi

[jim stephens via cctalk]

On 6/16/2020 5:21 AM, Al Kossow via cctalk wrote:

With Jay retiring, what are the hosting plans for these mailing lists?

I have an observation for when the list migrates.  The current message 
"From" field contains the name of the original sender but with the 
encoded address of the list as the email address


For example this has

Al Kossow via cctalk 

Some email clients have a feature which try to automatically capture the 
"from" and add them to a local address book.  Thunderbird has 3 layers 
(at least) of address books.  The "discovered" email addresses as I 
describe here, the local address book if you use it with your manually 
added contacts, and finally if you sync it with an outside contact 
facility such as Google or another server.


The addresses from these mailings end up with a number of captured 
entries in the local address books which don't point back at the actual 
sender, but to the list.  I've not had it happen many times, but you do 
have to watch using short names (like if I create an email to "al") that 
it gets the correct address.


I don't recall what the list used to do, but I know there were changes 
made a few years ago which resulted in this. I don't have a criticism, 
just an observation to toss in to the mix once the list(s) are migrated 
to visit this.  I know Jay tore his hair out then, and appreciate this 
isn't a simple problem (maybe others too).


I know Jay mentioned the Discord server which is very active, but I wish 
that it could be captured as an archive to be perused in the same way as 
the cctalk list (I have all the emails since I joined), the vcf list 
(searchable I think mostly by google).  These serve as a great resource, 
and I'm not sure that the discord server where such information is 
discussed is captured.


thanks
Jim

Re: Future of cctalk/cctech - text encoding

[ben via cctalk]

On 6/24/2020 12:06 PM, jim stephens via cctalk wrote:



On 6/24/2020 10:02 AM, Curious Marc via cctalk wrote:
But I would strongly suggest that we limit it to using characters from 
the Baudot set. If not they don’t print right on my 1930 Teletype.
I can peruse the list on my Teletype ASR-32(s).  Can archive the list 
with the 5 level paper tape (at least till the three rolls of tape run 
out).


Well if you can trim the posts,and remove sigs,I bet you can don't need 
to buy more rolls until the next 5 years.

Are there still places that sell paper tape and paper rolls?
Ben.

Re: Future of cctalk/cctech - text encoding

[jim stephens via cctalk]

On 6/24/2020 10:02 AM, Curious Marc via cctalk wrote:

But I would strongly suggest that we limit it to using characters from the 
Baudot set. If not they don’t print right on my 1930 Teletype.
I can peruse the list on my Teletype ASR-32(s).  Can archive the list 
with the 5 level paper tape (at least till the three rolls of tape run out).

Re: Future of cctalk/cctech - text encoding

[Peter Coghlan via cctalk]

Someone whose name might be Marc might have written:
 Peter Coghlan wrote:
 Does anyone use ASCII anymore?
>>> 
>>> I read and write my email with Emacs running in a terminal emulator.
>>> I rarely need anything beoynd codepoint 126.
>> 
>> I vote we move the list to an Exchange server behind a SSL VPN and mandate
>> the use of Outlook, then force all messages to be in quoted-printable
>> encoding. This way nobody “wins” and everyone is equally miserable.
>> It’s only fair.
>

C'mon, quoted-printable is usually fairly readable.  How about base-64?
Or if this is regarded as too modern or too universal, how about uuencoding?

>
> +1 on the Exchange server. You might even be able to have more than 2 people
> connected to it at the same time without crashing, if you put enough admins
> on the problem.
>

You can't use an Exchange server.  I believe Exchange servers silently
discard messages whose message-id it has previously seen.  This would solve
(actually hide) the duplicated messages problem and we can't have that!

> 
> But I would strongly suggest that we limit it to using characters from the
> Baudot set. If not they don’t print right on my 1930 Teletype.
> 
> Also Darwin recently wrote a paper about us, and revoked his theory of
> evolution. 
> 
> Unlike the God-awfull Yahoo Groups, Groups.io works OK for the other lists
> I follow. Meaning it’s functional and tolerable, and only moderately
> infuriating. But it is certainly not as clean and efficient as this list
> by a good margin. It would be good if we could preserve this.
> 
> Maybe evolve to the use of pictures or attachments, just to prove Darwin
> wrong? Limited to ASCII art only pictures, of course.
>

Hang on, what about those who prefer their art in upper case EBCDIC only?

Regards,
Peter Coghlan

> 
> Marc

Re: Future of cctalk/cctech - text encoding

[Curious Marc via cctalk]

>>> Peter Coghlan wrote:
>>> Does anyone use ASCII anymore?
>> 
>> I read and write my email with Emacs running in a terminal emulator.
>> I rarely need anything beoynd codepoint 126.
> 
> I vote we move the list to an Exchange server behind a SSL VPN and mandate 
> the use of Outlook, then force all messages to be in quoted-printable 
> encoding. This way nobody “wins” and everyone is equally miserable. It’s only 
> fair.

+1 on the Exchange server. You might even be able to have more than 2 people 
connected to it at the same time without crashing, if you put enough admins on 
the problem.

But I would strongly suggest that we limit it to using characters from the 
Baudot set. If not they don’t print right on my 1930 Teletype.

Also Darwin recently wrote a paper about us, and revoked his theory of 
evolution. 

Unlike the God-awfull Yahoo Groups, Groups.io works OK for the other lists I 
follow. Meaning it’s functional and tolerable, and only moderately infuriating. 
But it is certainly not as clean and efficient as this list by a good margin. 
It would be good if we could preserve this.

Maybe evolve to the use of pictures or attachments, just to prove Darwin wrong? 
Limited to ASCII art only pictures, of course.

Marc

Re: Future of cctalk/cctech

[Grant Taylor via cctalk]

On 6/19/20 9:42 PM, Fred Cisin via cctalk wrote:

We need, or at least want, to handle BOTH.


Agreed.

Long-term, "permanent" content, as well as the casual "What is 
this? here's what it looks like"


I think that short term can sort of ride the coat tales of the long term 
solution.


I have no idea whether it is practical to handle those the same, or 
differently.


What if the "short term" is the current URL to files that have been 
removed from emails (or uploaded directly).  Admittedly this would be 
somewhat subject to the current location of the archive.


Conversely the "long term" solution could simply be URL agnostic in that 
you go to the at the time current URL and navigate to the message you 
are looking for attachments to.  I'd like to see the ability to search 
by subject / date / sender / message ID / etc.


I think this method of long term solution makes the actual archive 
somewhat URL agnostic.  As in you get there, wherever there is, and then 
pick the file(s) you want.


With this type of long term solution, it doesn't really matter if the 
URL in the email breaks in the future.




--
Grant. . . .
unix || die

Re: Future of cctalk/cctech - text encoding

[Grant Taylor via cctalk]

On 6/18/20 7:34 AM, Daniel Seagraves via cctalk wrote:
I vote we move the list to an Exchange server behind a SSL VPN 
and mandate the use of Outlook, then force all messages to be in 
quoted-printable encoding.


I see your quoted-printable and raise you TNEF.

This way nobody “wins” and everyone is equally miserable. It’s 
only fair.


Are you listening to "The Trees" from Rush?



--
Grant. . . .
unix || die

Re: Future of cctalk/cctech

[emanuel stiebler via cctalk]

On 2020-06-19 23:42, Fred Cisin via cctalk wrote:
>>> Images take up a lot of space and are best dealt with via links.
> 
> On Fri, 19 Jun 2020, Al Kossow via cctalk wrote:
>> Which rot over time.
>> If you're going to create a permanent archive, you need to archive any
>> attachments as well.
>> http://www.vcfed.org/forum is a perfect example of messages full of
>> link rot.
> 
> We need, or at least want, to handle BOTH.
> Long-term, "permanent" content, as well as
> the casual "What is this? here's what it looks like"
> 
> I have no idea whether it is practical to handle those the same, or
> differently.

Some mailing lists accept only attachments, if those are links into the
permanent storage at the mail server ...

Re: Future of cctalk/cctech

[Toby Thain via cctalk]

On 2020-06-19 11:27 p.m., Al Kossow via cctalk wrote:
> 
>> Images take up a lot of space and are best dealt with via links. 
> 
> Which rot over time.
> 
> If you're going to create a permanent archive, you need to archive any
> attachments as well.
> 
> http://www.vcfed.org/forum is a perfect example of messages full of link
> rot.
> 

Yes, we could have learned from the fact that Photobucket and dozens of
other image hosting services chosen arbitrarily by users have
disappeared, leaving forums full of posts without context, often making
them useless.

--Toby

Re: Future of cctalk/cctech

[Fred Cisin via cctalk]

Images take up a lot of space and are best dealt with via links.


On Fri, 19 Jun 2020, Al Kossow via cctalk wrote:

Which rot over time.
If you're going to create a permanent archive, you need to archive any 
attachments as well.

http://www.vcfed.org/forum is a perfect example of messages full of link rot.


We need, or at least want, to handle BOTH.
Long-term, "permanent" content, as well as
the casual "What is this? here's what it looks like"

I have no idea whether it is practical to handle those the same, or 
differently.

Re: Future of cctalk/cctech

[Al Kossow via cctalk]

Images take up a lot of space and are best dealt with via links. 


Which rot over time.

If you're going to create a permanent archive, you need to archive any 
attachments as well.

http://www.vcfed.org/forum is a perfect example of messages full of link rot.

Re: Future of cctalk/cctech

[Boris Gimbarzevsky via cctalk]

Agree that current mailing list format is best as simple, low 
bandwidth and can always post links to images or other large 
files.  I still use Eudora as my email client and have text only 
emails.  Seems to perplex a lot of people I deal with when I can't 
read their emails, but it seems somewhat wastefull to use 1-2 Mb to 
send a message that only needs 200 bytes at most (once one strips off 
all zero-information fluff from the email).  Run my own mailserver as 
well so can email myself massive attachments when email is only way 
of getting data off a remote machine.


Images take up a lot of space and are best dealt with via 
links.  I've run my own webserver/ftpserver since 1999 and find 
that's the easiest way of sharing large files with people.  While 
it's nice having high resolution photos like those that Samsung 
phones creat, they're in the 3-5 Mb size range.  If I need to put a 
lot of photos on a web page, I'll use the free Photo Studio program 
(written by John Hawkins) which creates a web page with a series of 
thumbnails with full image available by clicking on thumbnail and can 
set size of thumbnail image.  Rather old, but works fine for simple 
web pages where all one wants to do is serve up a set of images.


Remember 15 years ago that online documentation was sparse but have 
found most DEC manuals are online and C64 stuff a lot easier to find 
than it used to be.  Being rather paranoid, I've downloaded manuals 
for all machines I have and keep a duplicate copy of everything.


Not sure how many people are on cctalk/cctech, but keeping everything 
text only would be best way of minimizing bandwidth for whoever hosts it,


Boris Gimbarzevsky


On Fri, Jun 19, 2020 at 3:31 PM Maciej W. Rozycki via cctalk <
cctalk@classiccmp.org> wrote:

> Sure, there's always `uuencode' when you do need to post that non-text
> piece (which I guess will keep the eyes of Luddites away from it too).
>

Or an http, https, ftp, or gopher url to somewhere else hosting the image.

Pat

Re: Future of cctalk/cctech

[Fred Cisin via cctalk]

Or an http, https, ftp, or gopher url to somewhere else hosting the image.


On Fri, 19 Jun 2020, Maciej W. Rozycki via cctalk wrote:

Well, not everyone can afford to host their own site, for various
reasons, and if hosting externally you have to agree to T's you may not
necessarily be happy about.


I thought that it was generally agreed that we were talking about a 
"files" section on the server(s) hosting the list.
That would have a lower resource requirement than including every 
attachment within every email.  (AND them being replicated indefinitely by 
everybody who doesn't trim their posts)

Re: Future of cctalk/cctech

[Maciej W. Rozycki via cctalk]

On Fri, 19 Jun 2020, Patrick Finnegan via cctalk wrote:

> > Sure, there's always `uuencode' when you do need to post that non-text
> > piece (which I guess will keep the eyes of Luddites away from it too).
> >
> 
> Or an http, https, ftp, or gopher url to somewhere else hosting the image.

 Well, not everyone can afford to host their own site, for various 
reasons, and if hosting externally you have to agree to T's you may not 
necessarily be happy about.

  Maciej

Re: Future of cctalk/cctech

[Patrick Finnegan via cctalk]

On Fri, Jun 19, 2020 at 3:31 PM Maciej W. Rozycki via cctalk <
cctalk@classiccmp.org> wrote:

> Sure, there's always `uuencode' when you do need to post that non-text
> piece (which I guess will keep the eyes of Luddites away from it too).
>

Or an http, https, ftp, or gopher url to somewhere else hosting the image.

Pat

RE: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Coghlan via cctalk]

Dave Wade wrote:
> > -Original Message-
> > From: Ethan Dicks 
> > Sent: 19 June 2020 15:44
> > To: Dave Wade ; General Discussion: On-Topic
> > and Off-Topic Posts 
> > Subject: Re: Synchronous serial Re: E-Mail Formats RE: Future of
> > cctalk/cctech
> > 
> > On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk 
> > wrote:
> > > Its been ages since I did this but looking here
> > >DPV11
> > > https://www.aggsoft.com/rs232-pinout-cable/RS232.htm
> > >
> > > I see we have a transmit clock output on pin 24,  transmit clock input on 
> > > 15
> > and RX clock input on 17.
> > > So if on checking with a scope I have clocks on 24, I would try linking 
> > > 24 and
> > 15 on one side to 17 on the other side.
> > > If you have only one clock running then that goes to 15 and 17 on both
> > ends
> > 
> > None of the devices I worked with in the 80s and 90s had clock available on
> > pin 24.  I'm not saying none exist, but they weren't around in the era I was
> > doing this.
> > 
> 
> Ethan,
> Well some do, some don't. In general we avoided using it because we probably
> wanted to set other signals, 
> However the first card for which I could find documents, the QBUS DPV11 has
> a configurable clock on pin 24
> 
> http://www.bitsavers.org/pdf/dec/qbus/EK-DPV11-UM-001_Aug80.pdf
> 
> page 2-5 and 2-7. Its called "null modem" but you can see its connected back
> to the clocks so you can test the interface.
>

I took a look at pin 24 on my setup and it has a steady negative voltage
so it is getting driven at least.  It looks very likely that it can be
configured to generate a clock signal for loopback tests.

Before figuring out how to do that, I had a go at making a clock from a 555.
The random bunch of components I grabbed produced a roughly 600Hz output
according to the frequency range on my multimeter and it is probably far
from square.  I decided to live dangerously, skip the MAX232 and connect
the output of the 555 directly to the clock signal inputs.  Along with
a birds nest of crossover connections, this allowed the example programs
to successfully write and read some data over the line!

Next, I tried starting up HUJI-NJE.  Initially, the link failed to connect
because one end wasn't listening when the other end was sending.  However,
I found that if I started both ends at more or less the same time, the
link managed to connect successfully.  It looks like I need to tweak the
handshaking crossovers so that this works more reliably.

I suspect the meaning of the lack of support for "BISYNC" in the DST32 may
be that I don't get the ability to generate the bisync CRCs in the hardware.
By coincidence, I was involved in a thread on generating CRCs for bisync
links on another mailing list recently so I am now fairly well versed in how
to do this in software.

Many thanks to everyone for your help with this project, especially Antonio,
Ethan, Paul and Dave.

Regards,
Peter Coghlan.

> Dave 

Re: Future of cctalk/cctech

[Maciej W. Rozycki via cctalk]

On Fri, 19 Jun 2020, Peter Corlett via cctalk wrote:

> > It's time to adopt a platform that can handle modern mail. Some may still
> > choose a degraded experience, but everyone is entitled to their own fetish.
> 
> Any old mail client can read "modern mail": MIME is designed to be
> backwards-compatible and the text parts readable on non-MIME clients. One
> quickly learns the ASCII renderings of important non-ASCII characters after
> using such a client for a while. (How do I know this? I still use trn, which
> doesn't understand character sets at all. There are *no* "modern" newsreaders,
> apart from the occasional kitchen-sink monstrosity which does nothing well.)

 I guess depending on how you define "modern".  For instance (AL)PINE does 
handle UTF-8 (your UI might not however, if you run say on a VT220), which 
fulfils my definition of modernity, and it happens to have handled NNTP as 
well, since time immemorial.  I have stopped participating with Usenet due 
to the lack of NNTP servers I could access, but I used to use PINE in this 
manner for years, and it did the right thing there.

 I continue using ALPINE for e-mail and I'm quite happy with the stuff it 
keeps away from me.  An occasional PDF attachment I can deal with.  And I 
can pipe a Git commit being read directly to `git am' with no fuss and no 
need to bother if it has been encoded in any way for transport.

> The "no attachments" rule on many mailing lists is not a Luddite thing, but a
> quality filter. There is a strong inverse correlation between those who feel
> that they can't communicate without images and fancy text formatting, and 
> those
> who have something useful or interesting to say. Less is more, and all that.

 Sure, there's always `uuencode' when you do need to post that non-text 
piece (which I guess will keep the eyes of Luddites away from it too).

  Maciej

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Paul Koning via cctalk]

> On Jun 19, 2020, at 10:43 AM, Ethan Dicks via cctalk  
> wrote:
> 
> On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk
>  wrote:
>> Its been ages since I did this but looking here
>> 
>> https://www.aggsoft.com/rs232-pinout-cable/RS232.htm
>> 
>> I see we have a transmit clock output on pin 24,  transmit clock input on 15 
>> and RX clock input on 17.
>> So if on checking with a scope I have clocks on 24, I would try linking 24 
>> and 15 on one side to 17 on the other side.
>> If you have only one clock running then that goes to 15 and 17 on both 
>> ends
> 
> None of the devices I worked with in the 80s and 90s had clock
> available on pin 24.  I'm not saying none exist, but they weren't
> around in the era I was doing this.

I had the same reaction.  The sync serial devices I know use modem-supplied 
clocks.  That's why there is such a device as a "modem eliminator", which is 
different from the familiar asynchronous "null modem".  A modem eliminator is 
essentially a null modem plus a clock source along the lines discussed a day or 
two ago.

If you had a sync device that had the ability to send a local clock out, you 
could make a sync null modem that would just be wires, as an async null modem 
is.  Perhaps this is something RS232 standardized but that wasn't adopted in 
the real world.

paul

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Antonio Carlini via cctalk]

On 19/06/2020 11:07, Peter Coghlan via cctalk wrote:
I already tried extracting ZSDRIVER.EXE from the DECnet/OSI kit for 
VAX/VMS 7.3
and placing it in SYS$LOADABLE_IMAGES but ZSA0: remained stubbornly 
offline
until I installed the rest of DECnet/OSI and the LES$ACP_V30 process 
started.
I think I have an old CD containing a WANDD kit somewhere but I can't 
seem to

put a hand on it right now.  I probably put it in a "safe place" :-(



I think messing with the kits isn't likely to produce a working system. 
You need more than the driver to make everything work.


At the very least LES (Layered Environment Services) has to be available.


These manuals mention the DSV11 and DST32 but there is no reference to 
the
DSH32 anywhere.  The installation guide says the device driver for the 
DST32

is ZSDRIVER.EXE so this seems to suggest that the DST32 and DSH32 are the
same thing or at least very similar.  Maybe there was a difference of 
opinion
between the hardware people and the software people as to what it 
should be

called :-)



I've found some notes that suggest that the DST32 and DSH32 both use the 
same driver (ZSDRIVER, as you've found).


The other "busless" one was the DSW21/DSW41/DSW42.


I can't find a WANDD SPD either locally nor online, but (iirc) V1.2 was 
Phase IV and certainly ran on V5.5-2.


A bunch of stuff changed radically in V6.0 so if there was a Phase IV 
release for V6 then it would almost certainly have been post-V1.2.



Antonio


--
Antonio Carlini
anto...@acarlini.com

Re: Future of cctalk/cctech

[Liam Proven via cctalk]

On Fri, 19 Jun 2020 at 17:36, Peter Corlett via cctalk
 wrote:

>  There are *no* "modern" newsreaders,
> apart from the occasional kitchen-sink monstrosity which does nothing well.)

There was...

https://panic.com/blog/the-future-of-unison/

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Paul Berger via cctalk]

On 2020-06-19 11:43 a.m., Ethan Dicks via cctalk wrote:

On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk
 wrote:

Its been ages since I did this but looking here

https://www.aggsoft.com/rs232-pinout-cable/RS232.htm

I see we have a transmit clock output on pin 24,  transmit clock input on 15 
and RX clock input on 17.
So if on checking with a scope I have clocks on 24, I would try linking 24 and 
15 on one side to 17 on the other side.
If you have only one clock running then that goes to 15 and 17 on both ends

None of the devices I worked with in the 80s and 90s had clock
available on pin 24.  I'm not saying none exist, but they weren't
around in the era I was doing this.

-ethan


On the machines I worked on it was an option, but I never saw it used as 
the modem  clocking was usually  synchronized across the common 
carrier's network making it much more reliable.  Most customers also 
used modems provided by the common carrier, which was a good thing as it 
was pretty easy to determine where the fault was.  When one of our 
modems was used trouble shooting was more difficult, but I do recall 
discussing with the common carrier that receive level was too low, and 
having the deny that was possible only to have the level come up while 
still on the phone with them.


Paul.

RE: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Dave Wade via cctalk]

> -Original Message-
> From: Ethan Dicks 
> Sent: 19 June 2020 15:44
> To: Dave Wade ; General Discussion: On-Topic
> and Off-Topic Posts 
> Subject: Re: Synchronous serial Re: E-Mail Formats RE: Future of
> cctalk/cctech
> 
> On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk 
> wrote:
> > Its been ages since I did this but looking here
> >DPV11
> > https://www.aggsoft.com/rs232-pinout-cable/RS232.htm
> >
> > I see we have a transmit clock output on pin 24,  transmit clock input on 15
> and RX clock input on 17.
> > So if on checking with a scope I have clocks on 24, I would try linking 24 
> > and
> 15 on one side to 17 on the other side.
> > If you have only one clock running then that goes to 15 and 17 on both
> ends
> 
> None of the devices I worked with in the 80s and 90s had clock available on
> pin 24.  I'm not saying none exist, but they weren't around in the era I was
> doing this.
> 

Ethan,
Well some do, some don't. In general we avoided using it because we probably 
wanted to set other signals, 
However the first card for which I could find documents, the QBUS DPV11 has a 
configurable clock on pin 24

http://www.bitsavers.org/pdf/dec/qbus/EK-DPV11-UM-001_Aug80.pdf

page 2-5 and 2-7. Its called "null modem" but you can see its connected back to 
the clocks so you can test the interface.
Dave



> -ethan

Re: Future of cctalk/cctech

[Peter Corlett via cctalk]

On Thu, Jun 18, 2020 at 10:28:05PM -0400, Tony Aiuto via cctalk wrote:
[...]
> And sometimes, a picture really is worth 1000 words.

But pictures also consume magnitudes-of-order more resources than a thousand
words, and should be used rather more judiciously than they are.

> A tiny SVG diagram in the middle of a description can do wonders. Did your
> physics textbook pull all the diagrams out to an appendix, just leaving a
> reference in the text? No it didn't. That would have been inconvenient and
> unnecessary. Except for those who choose otherwise, we all have the
> capability to view mail that presents like any other printed matter.

My physics textbooks had editors who ensured that the text made sense and the
images were useful to the reader. I'm sorry if you went to a bad school where
your physics textbooks were similar to the vast majority of email.

> It's time to adopt a platform that can handle modern mail. Some may still
> choose a degraded experience, but everyone is entitled to their own fetish.

Any old mail client can read "modern mail": MIME is designed to be
backwards-compatible and the text parts readable on non-MIME clients. One
quickly learns the ASCII renderings of important non-ASCII characters after
using such a client for a while. (How do I know this? I still use trn, which
doesn't understand character sets at all. There are *no* "modern" newsreaders,
apart from the occasional kitchen-sink monstrosity which does nothing well.)

The "no attachments" rule on many mailing lists is not a Luddite thing, but a
quality filter. There is a strong inverse correlation between those who feel
that they can't communicate without images and fancy text formatting, and those
who have something useful or interesting to say. Less is more, and all that.

Images and HTML formatting also present an accessibility problem. At least one
of the posters to this list gives a few "tells" in the way they write which
suggest they are blind. Good luck doing text-to-speech on a JPEG.

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Ethan Dicks via cctalk]

On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk
 wrote:
> Its been ages since I did this but looking here
>
> https://www.aggsoft.com/rs232-pinout-cable/RS232.htm
>
> I see we have a transmit clock output on pin 24,  transmit clock input on 15 
> and RX clock input on 17.
> So if on checking with a scope I have clocks on 24, I would try linking 24 
> and 15 on one side to 17 on the other side.
> If you have only one clock running then that goes to 15 and 17 on both 
> ends

None of the devices I worked with in the 80s and 90s had clock
available on pin 24.  I'm not saying none exist, but they weren't
around in the era I was doing this.

-ethan

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Paul Koning via cctalk]

> On Jun 19, 2020, at 6:07 AM, Peter Coghlan via cctalk  
> wrote:
> 
>> ...
> 
> The specifications manual says that the maximum speed for the DST32 is
> 19200 bps (for HDLC or SDLC) or 9600 bps (for DDCMP) but worryingly
> doesn't list a speed for BISYNC which is what I want to do with it :-(
> 
> It also says the supported line interfaces for the DST32 are:
> RS-232-C/V.24/V.28, RS-423-A/V.10/RS-449 and RS-422-A/V.11/RS-449 but not
> V.35 which seems strange because the only reaction I have got from it so
> far is using the V.35 interface cable.  At least it suggests it should work
> with the V.24 cables when once I manage to come up with a suitable clock.

The interfaces should all work about the same, for short cables.  RS232 isn't 
rated as high as the others but if you're just running a 6 foot cable across 
the bench that isn't much of a problem.

Interesting that DDCMP is rated lower.  I wonder why that would be.  If the 
device handles the data CRC, the software would do the header CRC but that is 
easy.

I'd expect 9600 or so for BISYNC.  I forgot how CRC works -- are the escape 
characters in BISYNC included in the CRC, or not?  If not then you're probably 
looking at software CRC.  Still, 9600 baud with software CRC is doable for a 
J-11, so it should be for a MicroVAX as well.

paul

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Coghlan via cctalk]

Antonio Carlini wrote:

On 18/06/2020 14:06, Peter Coghlan via cctalk wrote:
>
> I have found the whole thing very confusing too.  My suspicion was also
> that they were pretty much the same thing but the DST32 had exernal
> connectors suitable for mounting in a MicroVAX 2000 while the DST32 had
> external connectors that could be mounted in a MicroVAX 3100. That is,
> until I also came across the preliminary version of EK-283AA-AD-001
> which threw cold water on that theory.  Unless it was originally called
> the DSH32 and then renamed to DST32 for the MicroVAX 2000 or something...


I expect that the uVAX 2000 interface was around well before the uVAX 
3100 one. I suspect that the docs was wrong or that something got 
renamed at some stage. If I ever frind my notebooks from the time I can 
take a look.




I'd be very interested to know what the story was if you manage to locate
those notebooks.



>
> I was hoping to use VAX WANDD but I ended up having to install DECnet OSI
> on VMS 7.3.  Perhaps if I dig up an earlier VMS version, I can avoid 
> using

> DECnet OSI?


If you further along it got renamed to DECnet-Plus ... would that help :-)

I don't know when Phase IV support stopped for WANDD. DECnet-VAX 
Extensions went out in the V5.4-3 timeframe IIRC. Certainly for a while 
you have a choice and were not required to run DECnet/OSI. In fact the 
only reason that DECnet-VAX Extensions shipped was (iirc) that PSI/WANDD 
was ready and DECnet/OSI wasn't.



Anyway, pre VMS V6.0 I'm sure you can just pull the latest contemporary 
WANDD kit off a VMS CD and you'll be fine.




I already tried extracting ZSDRIVER.EXE from the DECnet/OSI kit for VAX/VMS 7.3
and placing it in SYS$LOADABLE_IMAGES but ZSA0: remained stubbornly offline
until I installed the rest of DECnet/OSI and the LES$ACP_V30 process started.
I think I have an old CD containing a WANDD kit somewhere but I can't seem to
put a hand on it right now.  I probably put it in a "safe place" :-(

I was pleased to find that I have a grey DEC folder containing AA-LN26B-TE VAX
WAN Device Drivers Installation Guide, Specifications and Programmer's Guide
for VAX/VMS 5.0  Software Version: VAX Wide Area Network Device Drivers V1.1
First Printing July 1988  Revised, January 1989.  I'd forgotten I had these!

These manuals mention the DSV11 and DST32 but there is no reference to the
DSH32 anywhere.  The installation guide says the device driver for the DST32
is ZSDRIVER.EXE so this seems to suggest that the DST32 and DSH32 are the
same thing or at least very similar.  Maybe there was a difference of opinion
between the hardware people and the software people as to what it should be
called :-)

The specifications manual says: "The DST32 is a single line interface for
single board VAX systems. It provides RS-232-C, RS-442-A and RS-423-A
connections to dial-up or leased synchronous communications lines and
operates in both character-oriented and bit-stuffing mode.



On the synch side the idea was to get away from having a set of (often 
different) cables for each interface. Instead everything had the same 
50-pin connector and then you picked the appropriate cable for V.25 or 
X.21 or whatever you needed. My DST32 has such a connector, as does your 
DSH32. I expect that the DSV-11 also is the same. DECnis certainly is.



>
> and I also have two Nokia DS 60100 baseband modems, one with a V.35
> interface card and one with an X.21 interface card.  When I hook up the
> former with the BC19F cable, I can get the lights on the modem to react
> when I try to access ZSA0: on the MicroVAX.  However, I can't get any
> reaction when I use the BC19C cable with the latter even when I jumper
> the modem to take account of the fewer signals available in X.21. It
> may be that the BC19C is meant for something other than the DSH/T32...


I don't remember the cable part numbers (although they will be in the 
manuals) but if it plugs into the 50-pin connector then it should work.




I found details about many of the interface cables, including wiring diagrams
in EK-DRT90-OM DEC WANrouter 90 Owner's Manual on the web and more stuff
in EK-A0497-IN DEC WANserver 150 Installation/Owner's Guide.




> Anyway, this whole line of attack is fairly academic as the modems can
> only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be
> 19200bps.
>

I'd be surprised if they don't work at up to 56k at least. Maybe not 64k 
(I remember the DSV11 firmware engineer telling my that some extra work 
had to be done to get one of the DSV11 modes to work properly at 64k 
even in pathological cases, so maybe other, lower-end interfaces didn't 
get the same love).



Above 64k would not have been a normal use case back in the day - I 
don't have any data handy to check what should work though.




The specifications manual says that the maximum speed for the DST32 is
19200 bps (for HDLC or SDLC) or 9600 bps (for DDCMP) but worryingly
doesn't list a speed for BISYNC which is what I 

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Corlett via cctalk]

On Fri, Jun 19, 2020 at 12:21:14AM +0100, Pete Turnbull via cctalk wrote:
> [...] Some of the UK banking systems like HOBS survived using viewdata that
> way up to the end of the 1990s, and I still have at least a couple of 1275
> modems.

Hobbyists are still running Viewdata BBSes. Here's one connected to the
Internet and provided with a JavaScript client so you can log in and have a
poke around: http://fish.ccl4.org/java/.

Offering access to one's BBS via TCP/IP isn't really optional any more now that
many of us no longer have suitable analogue POTS lines to plug our old modems
into, what with a mobile being a better choice for most purposes. I think
(HS)CSD might have carried over from GSM into 3G, and it's even possible that
my tinpot telco would connect such a call, but the odds that I could convince
my mobile to make the call is pretty much zero. How do you enter AT commands on
an iPhone anyway?

Also, I resent paying per minute for low-bandwidth phone calls when I've got
unmetered VDSL.

I would write Viewdata clients in the nostalgia wave of the late 1990s and
early 2000s, as it was also a nice easy introduction into a new platform's
graphics and I/O subsystems. Maybe I'll do one in WebAssembly for old time's
sake.

> The idea was to use 1200 for the transmission from central computer to
> consumer, and the back channel for user responses/commands. Not many people
> type faster than 7.5cps.

That's 75WPM with the usual rule of thumb of six characters per word. I can
copy-type at about 75-85WPM, which would interact badly with a small FIFO on a
very basic terminal, what with that being an average and some words are typed
at a faster rate. Fortunately, I've never suffered a Viewdata terminal that
awful: the BBC Micro backed its 6850 UART and its 1-byte FIFO with a luxurious
192-byte software FIFO, for example. Having to stop for a sip of tea while the
buffer drains isn't so terrible.

Normally one would compose longer bits of text offline, of course, so that BT
would get the smallest pound of flesh possible. Definitely a company with the
"never mind the quality, feel the price" mentality, but that's all telcos for
you.

RE: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Peter Coghlan
> via cctalk
> Sent: 18 June 2020 23:11
> To: General Discussion: On-Topic and Off-Topic Posts
> 
> Subject: Re: Synchronous serial Re: E-Mail Formats RE: Future of
> cctalk/cctech
> 
> Ethan Dicks wrote:
> > On Thu, Jun 18, 2020 at 2:42 PM Peter Coghlan via cctalk
> >  wrote:
> > > Thanks for your reply Paul.  My eventual goal is to be able to use
> > > the synchronous serial interface on a MicroVAX to connect to IBM
> > > machines that only support bisync lines.

I trimmed this because we seem to be missing the crux of clocks and why we need 
them! 
In async data we take our clock from the edge of the start bit, and we have a 
stop bit which is really there to stop characters running together.
With sync we just have a stream of digital data and we use the clock to know 
when to sample it.
There are no stop bits or start bits, and we use a synchronisation character at 
the start of each block to work out how the characters are positioned in the 
data stream.
So we need clocks...

Its been ages since I did this but looking here

https://www.aggsoft.com/rs232-pinout-cable/RS232.htm

I see we have a transmit clock output on pin 24,  transmit clock input on 15 
and RX clock input on 17.
So if on checking with a scope I have clocks on 24, I would try linking 24 and 
15 on one side to 17 on the other side.
If you have only one clock running then that goes to 15 and 17 on both ends
 as suggested here:-

https://www.synclink.com/nullmodem.html

This assumes you have RS232 interfaces. If its X21 then eliminators are 
available on e-bay for a few pounds.

Dave

RE: Future of cctalk/cctech

[jwest--- via cctalk]

Tony Aiuto wrote
>It's time to adopt a platform that can handle modern mail.
>Some may still choose a degraded experience, but everyone is entitled to their 
>own fetish.

Yes, everyone is free to chose to use the list or the discord server or 
whatever is down the road years from now; but as a side note,
the irony of posting that on a mailing list dedicated to teletypes and perkin 
elmers and 1401's and such... is not lost I'm sure 

J

Re: Future of cctalk/cctech

[Tony Aiuto via cctalk]

On Thu, Jun 18, 2020 at 9:47 AM geneb via cctalk 
wrote:

> On Thu, 18 Jun 2020, Peter Coghlan via cctalk wrote:
>
> > ED SHARPE wrote:
> >> Use modern email program that sees expanded char. Sets and graphics
> it
> >> is a brand new world !I love old hardware to look at but if
> >> communicating  I like  the ability to see graphical  things...  and I
> >> think tell majority of people like  images of things..   Ed#
> >>
> >
> > Let me get this straight.  If I stop using VMS MAIL for this list and use
> > one of these new fangled things instead, I too will be able to make high
> > quality postings to the list, just like this one???
> >
>
> Yes, you too can produce a bountiful word salad with UTF-16 characters in
> place of spaces!  Amaze your friends!  Women will want you!  Men will want
> to BE you!
>
> g.
>

I don't mean to point at anyone on this thread. I'm not good at seeing who
is
serious or sarcastic in this thread, and I really don't care, because this

This conversation has come up again and again and gotten stale. It
fundamentally
amounts to a few people asserting "There is nothing worth saying that can't
be said with the 25 letters of the English alphabet, so therefore the list
should
only include text that I can't read on a teletype".

I say enough.

We live in a remarkable world where it is possible to share knowledge and
experiences
with people from all over the world. Some of them might be disruptive
enough to have
things like ASCII-inconvenient accented characters in their names. I would
like to
be able to spell my friends and colleagues' names correctly.

And sometimes, a picture really is worth 1000 words.  A tiny SVG diagram in
the
middle of a description can do wonders. Did your physics textbook pull all
the diagrams
out to an appendix, just leaving a reference in the text? No it didn't.
That would have
been inconvenient and unnecessary. Except for those who choose otherwise,
we all have
the capability to view mail that presents like any other printed matter.

It's time to adopt a platform that can handle modern mail.
Some may still choose a degraded experience, but everyone is entitled to
their own fetish.

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Paul Koning via cctalk]

> On Jun 18, 2020, at 5:47 PM, Antonio Carlini via cctalk 
>  wrote:
> 
> ...
>> Anyway, this whole line of attack is fairly academic as the modems can
>> only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be
>> 19200bps.
>> 
> 
> I'd be surprised if they don't work at up to 56k at least. Maybe not 64k (I 
> remember the DSV11 firmware engineer telling my that some extra work had to 
> be done to get one of the DSV11 modes to work properly at 64k even in 
> pathological cases, so maybe other, lower-end interfaces didn't get the same 
> love).
> 
> 
> Above 64k would not have been a normal use case back in the day - I don't 
> have any data handy to check what should work though.

Not with modems, but of course the "local" line cards (coax pairs) for the 
DMC/DMR/DMP sync DDCMP controllers could go at 1 Mb/s.  DMC only barely (with a 
few bugs).  The DMV doesn't have that capability if I remember right.

paul

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Paul Koning via cctalk]

> On Jun 18, 2020, at 5:55 PM, Peter Coghlan via cctalk  
> wrote:
> 
> ...
> I can rustle up +/-12V with a bench supply or two but I don't have a
> 1488 handy.  I should be able to borrow a MAX232 from something though.
> I don't have any baud rate generators lying around either.  How about a
> 555 generating square waves round about 10kHz for something approximating
> 9600 bps?  Does it have to be spot on a "valid" rate or will anything
> "close" do as long as it is the same at both ends?
> 
> To be absolutely clear, do I have to drive pins 15 and 17 going to both
> interfaces ie four loads on the driver in total?

Yes.  Both sides are looking for a receive clock to tell them were the incoming 
bits begin, and a transmit clock to control the shifting out of the transmit 
bits.

Any speed should work so long as it's slow enough.  So a 555 feeding a MAX232 
should be fine.  Most variants of that device have several drivers so you can 
split the four loads over more than one driver if you want to.  That's probably 
not necessary.

paul

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Chuck Guzis via cctalk]

On 6/18/20 2:55 PM, Peter Coghlan via cctalk wrote:
> Ethan Dicks wrote:

> I can rustle up +/-12V with a bench supply or two but I don't have a
> 1488 handy.  I should be able to borrow a MAX232 from something though.
> I don't have any baud rate generators lying around either.  How about a
> 555 generating square waves round about 10kHz for something approximating
> 9600 bps?  Does it have to be spot on a "valid" rate or will anything
> "close" do as long as it is the same at both ends?

Sync, in my recollection, is a bit fussier than async with respect to
the clock signal.  Unlike async, which "samples" the bit cell
more-or-less in the center  (hexce the 16x or 64x clock rate),
synchronous is edge-sampled, so that the clock signal must match the
data signal with respect to phase.

The clock signal for receive data is recovered by the receiving modem
and so is always in-phase.

Such stuff as protocol details can differ greatly (e.g. Bisync vs.
SDLC), but remember that there are no start or stop bits like as in
async.  Synchronization is done by pattern-matching with "idle" bits
being sent to fill gaps or to form preamble to sync.   In some respects,
not terribly different from hard disk recording.

It's been years since I fooled with the stuff, so I may have quite a bit
wrong.

--Chuck

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Chris Zach via cctalk]

Sometimes I'll log into alembic and read my mail with BABYL.


On 6/18/2020 6:03 PM, Eric Korpela via cctalk wrote:

I used to use netcat, but now I just watch an oscilloscope.

On Wed, Jun 17, 2020 at 1:41 PM Cameron Kaiser via cctalk <
cctalk@classiccmp.org> wrote:


I read this list on PINE, on a shell account at my ISP.


Barbarian!  At least upgrade to Alpine.  (That's what I use.) :D


Philistines, all of you. I use a hacked version of Elm.

--
 personal:
http://www.cameronkaiser.com/ --
   Cameron Kaiser * Floodgap Systems * www.floodgap.com *
ckai...@floodgap.com
-- Never interrupt your enemy when he is making a mistake. -- Napoleon

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Pete Turnbull via cctalk]

On 18/06/2020 21:31, Paul Koning via cctalk wrote:


I did see something vaguely similar.  Bell 202 modems are 1200 baud FSK, so on 
a voice channel they normally are 1200 bps half duplex.  They can also be 
hooked up to 4-wire fixed circuits.  But they have a reverse channel, good for 
150 baud if I remember right.


IIRC the Bell standard allows for only 50 baud and the back channel uses 
ASK (basically switching a carrier on and off).  The CCITT equivalent 
standard is 1200/75 baud, FSK both ways, and in the 1980s and early 90s 
that was used for Prestel and similar systems, including Micronet, 
Telecom Gold email, Packet SwitchStream (PSS), BT Tymnet and some online 
banking systems, here in the UK.  It was also used for Minitel in 
France, BTX in Germany and later for Telidon in Canada.  Some of the UK 
banking systems like HOBS survived using viewdata that way up to the end 
of the 1990s, and I still have at least a couple of 1275 modems.


The idea was to use 1200 for the transmission from central computer to 
consumer, and the back channel for user responses/commands.   Not many 
people type faster than 7.5cps.


--
Pete
Pete Turnbull

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Pete Turnbull via cctalk]

On 18/06/2020 23:03, Eric Korpela via cctalk wrote:

I used to use netcat, but now I just watch an oscilloscope.


Reminds me of a cartoon in a HiFi mag several years ago.  Enthusiast 
talking to friend in front of dual 'scopes, "Why listen to it when I can 
see it's perfect?"


--
Pete
Pete Turnbull

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Coghlan via cctalk]

Ethan Dicks wrote:
> On Thu, Jun 18, 2020 at 2:42 PM Peter Coghlan via cctalk
>  wrote:
> > Thanks for your reply Paul.  My eventual goal is to be able to use the
> > synchronous serial interface on a MicroVAX to connect to IBM machines that
> > only support bisync lines.
> 
> I'm curious which software package you are using.  In the 80s and 90s,
> I worked for Software Results Corp, and we sold hundreds (small
> thousands?) of Unibus, Qbus, and VAXBI interfaces and software suites
> under the name COMBOARD for Bisync and SNA comms from DEC-to-IBM
> (RSTS, RSX-11, VMS, and UNIX).  In my experience, people paid us
> $10K-$25K per line because they had problems with whatever other
> solution they were looking at that cost less.  I don't know any
> specific details on where the gaps were, but just that people did
> experience bugs or missing features that made them come to us.  I'd
> like to hear about what you are encountering once you get to the point
> of passing bytes.
>

I am using a very old package called HUJI-NJE which implements NJE links
on VAX/VMS and UNIX.  This was later developed into "funetnje" which added
some enhancements but broke the VMS functionality.  I backported some
of the funetnje enhancements into HUJI-NJE in order to use them on VMS.
NJE over TCP/IP is implemented on both platforms but on VAX/VMS, there
is also supposed to be support for using synchronous serial interfaces in
the form of a DMF32, DMB32 or DSV32 (is that like a DSV11 I wonder?).
If this all works out, it may be possible to use it to get NJE links into
IBM mainframe hardware that only has support for bisync lines.  It might
also have applications in talking to 3270 terminals connected via bisync
lines.

HUJI-NJE is not great for debugging the hardware with so I am also using
a pair of of example programs I found in AA�PHEPB�TE DECnet/OSI for VMS
VAX WANDD Programming.

> 
> >  However, I don't have access to any such IBM kit
> > at the moment so I have to make do with trying to get the MicroVAX to talk
> > to another instance of itself for now.
> 
> For bisync (3780/HASP) that should be just fine.  There's a simple
> difference in the protocol so that each end can tell who is the
> master, and AFAIK, any implementation you encounter should be able to
> be set in the appropriate mode, but you _do_ have to tell each end
> what their role is or they will chatter endlessly if they both think
> they are the master.
>

NJE is supposed to be able to use hardware features of devices such as
the 2703 to be able to decide which end gets to be primary and which
end gets to be secondary.  Sounds like it will be fun to implement...
I think endless chatter whether idle or not seems to be a feature of
bisync.

> 
> Apologies if you already know this.  It's been a long time and I'm not
> sure who remembers what details about obscure comms from 30-40 years
> ago.  I myself haven't even set up a bisync connection in 25 years.  I
> used to do this stuff every day, then by the mid-90s, it entirely
> evaporated.
>

I am fairly well up on NJE but only over TCP/IP until now.  All this
synchronous serial stuff is completely new to me so I am grateful for
any and all information I can get about it.

Regards,
Peter.

> -ethan

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Ethan Dicks via cctalk]

On Thu, Jun 18, 2020 at 6:08 PM Peter Coghlan via cctalk
 wrote:
> Ethan Dicks wrote:
> > As for the clocking, yes, a modem or modem eliminator provides the
> > baud rate clocking on pins 15 and 17.  You could use any one of a
> > number of baud rate generators...

> I can rustle up +/-12V with a bench supply or two but I don't have a
> 1488 handy.  I should be able to borrow a MAX232 from something though.

I have an abundance of 1488/1489 chips, but I used to make comms
devices.  I only have a few MAX232 devices not already baked into
projects.

> I don't have any baud rate generators lying around either.  How about a
> 555 generating square waves round about 10kHz for something approximating
> 9600 bps?  Does it have to be spot on a "valid" rate or will anything
> "close" do as long as it is the same at both ends?

It does need to be the same on both ends, and, yes, a 555 should work,
but it's unlikely to be within 1% of a "real" rate.

> To be absolutely clear, do I have to drive pins 15 and 17 going to both
> interfaces ie four loads on the driver in total?

Yes.  Pins 15 and 17 on both ends.  4 loads.

You can do asymmetric speeds, but the TX for one end has to match the
RX for the other end.  I see some discussion of that in this thread,
but in my experience, we always had same-room direct connect lines, or
dial-up lines over POTS and modem speeds like 1200 bps or 2400 bps
because we didn't want to pay for leased or conditioned lines.

Every connection I ever set up was symmetric.  99.9% were 56kbps or slower.

-ethan

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Coghlan via cctalk]

Ethan Dicks wrote:
> On Thu, Jun 18, 2020 at 5:53 AM Peter Coghlan via cctalk
>  wrote:
> > To get somewhere near back on topic, I am trying to set up a synchronous
> > serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe)
> > interfaces.  One of the options I have is a BC19D cable and a BC19V cable
> > which seem to be identical or nearly identical.  Each plugs into a DSH32
> > at one end and has a V.24 DB25 connector at the other end.  I don't seem
> > to have anything available in the way of a pair of suitably similar modems
> > or a modem eliminator to put between the two V.24 connectors.  Can anyone
> > suggest some kind of a quick hardware hack that I could use to fill the
> > gap?  Is a pair of DB25 sockets with crossed over wiring betweeen them
> > sufficient or do I need something that generates clock signals too?
> 
> If both ends don't care about delays in the handshake lines that would
> be natural with a modem or high-end modem eliminator, you can just
> match up the signals between the two devices as you would for a null
> modem.
> 
> As for the clocking, yes, a modem or modem eliminator provides the
> baud rate clocking on pins 15 and 17.  You could use any one of a
> number of baud rate generators, from the COM 8116 (one that we used at
> work in the early 80s for a simple modem eliminator) to a modern
> microcontroller thumping out pulses at the right frequency.  You'll
> need to drive both sides of the connection at RS-232 levels, so a
> level shifter (1488 if you have +/-12V handy, or MAX232 if you do
> not).  AFAIK, you can drive both ends from one line driver, but the
> safer course would be to drive each clock pin independently.
> 

Hi Ethan,

Thanks for your reply.

I can rustle up +/-12V with a bench supply or two but I don't have a
1488 handy.  I should be able to borrow a MAX232 from something though.
I don't have any baud rate generators lying around either.  How about a
555 generating square waves round about 10kHz for something approximating
9600 bps?  Does it have to be spot on a "valid" rate or will anything
"close" do as long as it is the same at both ends?

To be absolutely clear, do I have to drive pins 15 and 17 going to both
interfaces ie four loads on the driver in total?

Regards,
Peter.

> -ethan

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Eric Korpela via cctalk]

I used to use netcat, but now I just watch an oscilloscope.

On Wed, Jun 17, 2020 at 1:41 PM Cameron Kaiser via cctalk <
cctalk@classiccmp.org> wrote:

> > > I read this list on PINE, on a shell account at my ISP.
> >
> > Barbarian!  At least upgrade to Alpine.  (That's what I use.) :D
>
> Philistines, all of you. I use a hacked version of Elm.
>
> --
>  personal:
> http://www.cameronkaiser.com/ --
>   Cameron Kaiser * Floodgap Systems * www.floodgap.com *
> ckai...@floodgap.com
> -- Never interrupt your enemy when he is making a mistake. -- Napoleon
> 
>


-- 
Eric Korpela
korp...@ssl.berkeley.edu
AST:7731^29u18e3

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Coghlan via cctalk]

Paul Koning wrote:
>
> > On Jun 18, 2020, at 2:14 PM, Peter Coghlan via cctalk  >
> > ...
> > As I mentioned in another reply, I have a pair of baseband synchronous mode
> > and were it not for a speed incompatibility between them and the MicroVAX
> > synchronous serial interfaces I have access to, ...
>
> I'm curious about that.  Synchronous modems supply the bit clock to the
> interface.  So a synchronous interface works at whatever speed the modem
> delivers, so long as it's not too fast for the interface. What are the
> Microvax sync interfaces you have?  DMV?  DUV?  A DMV will work at up to
> 56 kbps.
>

There is conflicting information about what exactly the interface I have
which is fitted in a MicroVAX 3100 is called.  It looks most likely to be a
DSH32 or a DSH32-B which may amount to the same thing but it could also be
a DST32 which may also amount to the same thing...  Documentation suggests
that the synchronous interface part of a DSH32 (which for added confusion
is referred to as DSH32-S) is DSV11 compatible but limited to a maximum
of 19200 bps.

The modems I have (which were intended for use with 64 kbps lines attached
to Cisco routers) don't have jumpers for clock speeds lower than 48 kbps.

Regards,
Peter.

>   paul

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Antonio Carlini via cctalk]

On 18/06/2020 14:06, Peter Coghlan via cctalk wrote:


I have found the whole thing very confusing too.  My suspicion was also
that they were pretty much the same thing but the DST32 had exernal
connectors suitable for mounting in a MicroVAX 2000 while the DST32 had
external connectors that could be mounted in a MicroVAX 3100. That is,
until I also came across the preliminary version of EK-283AA-AD-001
which threw cold water on that theory.  Unless it was originally called
the DSH32 and then renamed to DST32 for the MicroVAX 2000 or something...



I expect that the uVAX 2000 interface was around well before the uVAX 
3100 one. I suspect that the docs was wrong or that something got 
renamed at some stage. If I ever frind my notebooks from the time I can 
take a look.





The console code in one of my MicroVAX 3100 machines shows this:


test 50


KA41-D  V1.0

[snip]

  DSH32-A  00FF.0001  V1.0
  DSH32-S  .0001  V3.0
  NI   .0001




Yet in VAX/VMS 7.3, I see this:

$ ANALYZE /SYSTEM

OpenVMS (TM) VAX System analyzer

SDA> show dev zsa0

I/O data structures
---
ZSA0    ZS_DST32  UCB address: 
814EAA40


[snip]



Wonderfully confusing :-)




I was hoping to use VAX WANDD but I ended up having to install DECnet OSI
on VMS 7.3.  Perhaps if I dig up an earlier VMS version, I can avoid 
using

DECnet OSI?



If you further along it got renamed to DECnet-Plus ... would that help :-)

I don't know when Phase IV support stopped for WANDD. DECnet-VAX 
Extensions went out in the V5.4-3 timeframe IIRC. Certainly for a while 
you have a choice and were not required to run DECnet/OSI. In fact the 
only reason that DECnet-VAX Extensions shipped was (iirc) that PSI/WANDD 
was ready and DECnet/OSI wasn't.



Anyway, pre VMS V6.0 I'm sure you can just pull the latest contemporary 
WANDD kit off a VMS CD and you'll be fine.






I have two boards in two MicroVAX 3100 machines.  Each board has one
Synchronous serial port (50 pin D connector) and eight asynchronous
terminal lines (36 pin Centronics connector).  To add further confusion,
I have a third MicroVAX 3100 which has the 50 pin and 36 pin external
connectors on the back but no actual DSH32/DHT32 board inside!

I also have the following cables:

1   BC19C Rev B1  50 pin D (female) to 13/15 pin D (male) X.21
1   BC19D Rev B   50 pin D (female) to 16/25 pin D (male) V.24
1   BC19F Rev B   50 pin D (female) to 17/34 pin "square" thing (male) 
V.35

1   BC19V 50 pin D (female) to 16/25 pin D (male) V.24



On the synch side the idea was to get away from having a set of (often 
different) cables for each interface. Instead everything had the same 
50-pin connector and then you picked the appropriate cable for V.25 or 
X.21 or whatever you needed. My DST32 has such a connector, as does your 
DSH32. I expect that the DSV-11 also is the same. DECnis certainly is.





and I also have two Nokia DS 60100 baseband modems, one with a V.35
interface card and one with an X.21 interface card.  When I hook up the
former with the BC19F cable, I can get the lights on the modem to react
when I try to access ZSA0: on the MicroVAX.  However, I can't get any
reaction when I use the BC19C cable with the latter even when I jumper
the modem to take account of the fewer signals available in X.21. It
may be that the BC19C is meant for something other than the DSH/T32...



I don't remember the cable part numbers (although they will be in the 
manuals) but if it plugs into the 50-pin connector then it should work.





Anyway, this whole line of attack is fairly academic as the modems can
only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be
19200bps.



I'd be surprised if they don't work at up to 56k at least. Maybe not 64k 
(I remember the DSV11 firmware engineer telling my that some extra work 
had to be done to get one of the DSV11 modes to work properly at 64k 
even in pathological cases, so maybe other, lower-end interfaces didn't 
get the same love).



Above 64k would not have been a normal use case back in the day - I 
don't have any data handy to check what should work though.



Antonio



--
Antonio Carlini
anto...@acarlini.com

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Paul Berger via cctalk]

On 2020-06-18 3:34 p.m., Chuck Guzis via cctalk wrote:

On 6/18/20 6:06 AM, Peter Coghlan via cctalk wrote:


and I also have two Nokia DS 60100 baseband modems, one with a V.35
interface card and one with an X.21 interface card.  When I hook up the
former with the BC19F cable, I can get the lights on the modem to react
when I try to access ZSA0: on the MicroVAX.  However, I can't get any
reaction when I use the BC19C cable with the latter even when I jumper
the modem to take account of the fewer signals available in X.21.  It
may be that the BC19C is meant for something other than the DSH/T32...
Anyway, this whole line of attack is fairly academic as the modems can
only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be
19200bps.

We would have been delighted to get 19.2K on our 11/750.  Leased line
with a Bell 209 modem, 9600 sync.   Back then, that ran about $5K/month
for the hookup.

--Chuck

When I started out in customer service many years ago anything faster 
than 9600 was very rare and even then they where often split off using 
stat muxes or multi-drop lines.  I call one store have a 9600 line back 
to head office in Toronto that served two store controllers, four 3777s 
with 3203 to print orders, one with a tape drive to transmit orders 
entered on a Nixdorf mini, as well as some miscellaneous terminals in 
the local warehouse and order office.  It was not uncommon for users of 
3270 terminals to have the controllers in a few offices sharing a 
multi-drop line, the banks did the same thing with their terminal 
controllers and ATMs.


I also remember some data centers having conditioned dial-up lines that 
included a handset that you could talk on, but it was pretty weird as 
the conditioned lines did not have echo suppressors.


The first banking terminal I worked on where on a multi-drop 300 baud 
async line and I also worked on finance company terminals that where on 
a multi-drop telegraph line at a speedy 75 baud.


Paul.

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Paul Koning via cctalk]

> On Jun 18, 2020, at 3:26 PM, Ethan Dicks via cctalk  
> wrote:
> 
> On Thu, Jun 18, 2020 at 3:08 PM Chuck Guzis via cctalk
>  wrote:
>> On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote:
>> 
>>> We used to run our sync serial stuff between 9600 and 56kbps, both our
>>> own Bisync products, and DDCMP over interfaces like the one that's
>>> part of the DMF32...
>> 
>> My recollection of the Bell 209 is that it supported a low-speed reverse
>> channel in addition to the FDX primary.
> 
> I had to look that up.  Yes.  I see that in the spec, at *5*bps.

Wow, that's weird.

>> Did any DEC equipment ever take advantage of that?
> 
> I've never encountered it before, so I cannot confirm.

Not that I know of.

I did see something vaguely similar.  Bell 202 modems are 1200 baud FSK, so on 
a voice channel they normally are 1200 bps half duplex.  They can also be 
hooked up to 4-wire fixed circuits.  But they have a reverse channel, good for 
150 baud if I remember right.  PLATO used that in its original terminal 
connections, in a slightly strange way: 1260 bps data to the terminal, and 126 
bps data from terminal to host.  The protocols are peculiar: terminal output is 
"synchronous", 21 bit frames at 60 frames per second, but each frame has a 
start bit (no stop bit).  Data to the host is asynchronous, 1 start, 1 stop 
bit, 10 data bits.  Since a 202 modem is just plain FSK, it doesn't matter that 
the data rate is not quite the standard 1200 bps.

paul

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[ben via cctalk]

On 6/18/2020 6:33 AM, Jan-Benedict Glaw via cctalk wrote:


Indeed. I get quite a lot of emails and mutt allows me to properly
fight back.

err  Mutt bites back.
I use whats free.
Ben.

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Ethan Dicks via cctalk]

On Thu, Jun 18, 2020 at 3:08 PM Chuck Guzis via cctalk
 wrote:
> On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote:
>
> > We used to run our sync serial stuff between 9600 and 56kbps, both our
> > own Bisync products, and DDCMP over interfaces like the one that's
> > part of the DMF32...
>
> My recollection of the Bell 209 is that it supported a low-speed reverse
> channel in addition to the FDX primary.

I had to look that up.  Yes.  I see that in the spec, at *5*bps.

> Did any DEC equipment ever take advantage of that?

I've never encountered it before, so I cannot confirm.

-ethan

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Maciej W. Rozycki via cctalk]

On Thu, 18 Jun 2020, Peter Coghlan via cctalk wrote:

> However, Peter uses PMDF MAIL to post to the list because it has been
> pointed out to him that VMS MAIL doesn't do References: and In-Reply-To:
> headers correctly.  On that note, has anyone heard from Mouse?  I haven't
> seen anything posted by him in a very long time now.

 Yep, last Sat on the VAX/NetBSD mailing list.

  Maciej

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Chuck Guzis via cctalk]

On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote:

> We used to run our sync serial stuff between 9600 and 56kbps, both our
> own Bisync products, and DDCMP over interfaces like the one that's
> part of the DMF32.  We had customers in Europe running our products at
> 64kbps with no problems, and we did have one modem eliminator clocked
> at 115kbps for testing, which is the max speed for V.24, IIRC.
> 
> 56kbps should be safe for the devices you are describing, but it might
> go a little faster.

My recollection of the Bell 209 is that it supported a low-speed reverse
channel in addition to the FDX primary.   Did any DEC equipment ever
take advantage of that?

--Chuck

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Ethan Dicks via cctalk]

On Thu, Jun 18, 2020 at 2:42 PM Peter Coghlan via cctalk
 wrote:
> Thanks for your reply Paul.  My eventual goal is to be able to use the
> synchronous serial interface on a MicroVAX to connect to IBM machines that
> only support bisync lines.

I'm curious which software package you are using.  In the 80s and 90s,
I worked for Software Results Corp, and we sold hundreds (small
thousands?) of Unibus, Qbus, and VAXBI interfaces and software suites
under the name COMBOARD for Bisync and SNA comms from DEC-to-IBM
(RSTS, RSX-11, VMS, and UNIX).  In my experience, people paid us
$10K-$25K per line because they had problems with whatever other
solution they were looking at that cost less.  I don't know any
specific details on where the gaps were, but just that people did
experience bugs or missing features that made them come to us.  I'd
like to hear about what you are encountering once you get to the point
of passing bytes.

>  However, I don't have access to any such IBM kit
> at the moment so I have to make do with trying to get the MicroVAX to talk
> to another instance of itself for now.

For bisync (3780/HASP) that should be just fine.  There's a simple
difference in the protocol so that each end can tell who is the
master, and AFAIK, any implementation you encounter should be able to
be set in the appropriate mode, but you _do_ have to tell each end
what their role is or they will chatter endlessly if they both think
they are the master.

Apologies if you already know this.  It's been a long time and I'm not
sure who remembers what details about obscure comms from 30-40 years
ago.  I myself haven't even set up a bisync connection in 25 years.  I
used to do this stuff every day, then by the mid-90s, it entirely
evaporated.

-ethan

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Ethan Dicks via cctalk]

On Thu, Jun 18, 2020 at 2:48 PM Paul Koning via cctalk
 wrote:
> > On Jun 18, 2020, at 2:14 PM, Peter Coghlan via cctalk 
> >  wrote:
> > As I mentioned in another reply, I have a pair of baseband synchronous 
> > modems
> > and were it not for a speed incompatibility between them and the MicroVAX
> > synchronous serial interfaces I have access to, ...
>
> I'm curious about that.  Synchronous modems supply the bit clock to the 
> interface.  So a synchronous interface works at whatever speed the modem 
> delivers, so long as it's not too fast for the interface. What are the 
> Microvax sync interfaces you have?  DMV?  DUV?  A DMV will work at up to 56 
> kbps.

We used to run our sync serial stuff between 9600 and 56kbps, both our
own Bisync products, and DDCMP over interfaces like the one that's
part of the DMF32.  We had customers in Europe running our products at
64kbps with no problems, and we did have one modem eliminator clocked
at 115kbps for testing, which is the max speed for V.24, IIRC.

56kbps should be safe for the devices you are describing, but it might
go a little faster.

-ethan

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Ethan Dicks via cctalk]

On Thu, Jun 18, 2020 at 5:53 AM Peter Coghlan via cctalk
 wrote:
> To get somewhere near back on topic, I am trying to set up a synchronous
> serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe)
> interfaces.  One of the options I have is a BC19D cable and a BC19V cable
> which seem to be identical or nearly identical.  Each plugs into a DSH32
> at one end and has a V.24 DB25 connector at the other end.  I don't seem
> to have anything available in the way of a pair of suitably similar modems
> or a modem eliminator to put between the two V.24 connectors.  Can anyone
> suggest some kind of a quick hardware hack that I could use to fill the
> gap?  Is a pair of DB25 sockets with crossed over wiring betweeen them
> sufficient or do I need something that generates clock signals too?

If both ends don't care about delays in the handshake lines that would
be natural with a modem or high-end modem eliminator, you can just
match up the signals between the two devices as you would for a null
modem.

As for the clocking, yes, a modem or modem eliminator provides the
baud rate clocking on pins 15 and 17.  You could use any one of a
number of baud rate generators, from the COM 8116 (one that we used at
work in the early 80s for a simple modem eliminator) to a modern
microcontroller thumping out pulses at the right frequency.  You'll
need to drive both sides of the connection at RS-232 levels, so a
level shifter (1488 if you have +/-12V handy, or MAX232 if you do
not).  AFAIK, you can drive both ends from one line driver, but the
safer course would be to drive each clock pin independently.

-ethan

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Paul Koning via cctalk]

> On Jun 18, 2020, at 2:14 PM, Peter Coghlan via cctalk  
> wrote:
> 
> ...
> As I mentioned in another reply, I have a pair of baseband synchronous modems
> and were it not for a speed incompatibility between them and the MicroVAX
> synchronous serial interfaces I have access to, ...

I'm curious about that.  Synchronous modems supply the bit clock to the 
interface.  So a synchronous interface works at whatever speed the modem 
delivers, so long as it's not too fast for the interface. What are the Microvax 
sync interfaces you have?  DMV?  DUV?  A DMV will work at up to 56 kbps.  

paul

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Coghlan via cctalk]

Paul Berger wrote:

On 2020-06-18 6:06 a.m., Peter Coghlan via cctalk wrote:
>
>
> To get somewhere near back on topic, I am trying to set up a synchronous
> serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe)
> interfaces.  One of the options I have is a BC19D cable and a BC19V cable
> which seem to be identical or nearly identical.  Each plugs into a DSH32
> at one end and has a V.24 DB25 connector at the other end.  I don't seem
> to have anything available in the way of a pair of suitably similar modems
> or a modem eliminator to put between the two V.24 connectors.  Can anyone
> suggest some kind of a quick hardware hack that I could use to fill the
> gap?  Is a pair of DB25 sockets with crossed over wiring betweeen them
> sufficient or do I need something that generates clock signals too?
>
> Regards,
> Peter Coghlan.
>   
>
While I have no experience with MicroVAX, I do recall that  on the 
machine I was involved with synchronous communications on, IBM terminals 
and systems, there was an option for the interface to provide clocking 
and I suppose it might be possible to set one side to provide the 
transmit and receive clocks and cross them over to the other interface, 
but I have never tried that.  When I worked in a development center with 
a room full of S/38 and S/36 we had a modem rack with a large number of 
Gandalf modem eliminators that provided clocking to the interface.


In the field the most common setup was to have the modem provide the 
clocks as the common carrier could synchronize them over a long distance.




Thanks for your reply Paul.  My eventual goal is to be able to use the
synchronous serial interface on a MicroVAX to connect to IBM machines that
only support bisync lines.  However, I don't have access to any such IBM kit
at the moment so I have to make do with trying to get the MicroVAX to talk
to another instance of itself for now.

As I mentioned in another reply, I have a pair of baseband synchronous modems
and were it not for a speed incompatibility between them and the MicroVAX
synchronous serial interfaces I have access to, plus another probably minor
snag, it looks very much like they would do the job when suitably jumpered.
There is even a card in the bottom of each modem case giving details of
all the jumper settings!

Regards,
Peter.


Paul.

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Chuck Guzis via cctalk]

On 6/18/20 6:06 AM, Peter Coghlan via cctalk wrote:

> and I also have two Nokia DS 60100 baseband modems, one with a V.35
> interface card and one with an X.21 interface card.  When I hook up the
> former with the BC19F cable, I can get the lights on the modem to react
> when I try to access ZSA0: on the MicroVAX.  However, I can't get any
> reaction when I use the BC19C cable with the latter even when I jumper
> the modem to take account of the fewer signals available in X.21.  It
> may be that the BC19C is meant for something other than the DSH/T32...
> Anyway, this whole line of attack is fairly academic as the modems can
> only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be
> 19200bps.

We would have been delighted to get 19.2K on our 11/750.  Leased line
with a Bell 209 modem, 9600 sync.   Back then, that ran about $5K/month
for the hookup.

--Chuck

Re: Future of cctalk/cctech

[Rich Kulawiec via cctalk]

On Wed, Jun 17, 2020 at 09:46:53AM -0500, John Foust via cctalk wrote:
> 
> I'm most puzzled by the eager hosting volunteers who'd volunteer even before
> they have a full understanding of the job.  Wouldn't you want to know
> how much time it might take you to administer the list, how much 
> bandwidth it eats, storage, format of the archives, etc.?

I can't speak for anyone else, but in my case: I've been running mailing
lists for 35-ish years, so I may have a fairly good handle on the scope.

To address some of those points: administering a migrated mailing
list -- once it's past the transition -- requires very little effort.
How much effort it takes during the transition can be guesstimated via
the number of users and their aggregate clue level, e.g., technical
lists are usually much easier because people on them know how to
speak to Mailman/majordomo/et.al. or can figure it out.   Bandwidth is
inconsequential for all but the largest/busiest lists, e.g., thousands of
subscribers X thousands of messages a day.  Storage is too: I have decades
of archives of a few thousand mailing lists and they fit comfortably on
a 250G drive without even bothering to compress them.

Archives, if kept in mbox format, are easy to manipulate, combine,
separate, etc.  If they're not in mbox format, tools like formail can
assist in making them so.  (It's not at all unreasonable for every member
of a mailing list like this one to stash a complete copy of the archive
as insurance.)  This isn't entirely pain-free: I run a mailing list with
an approximately 250,000-message archive accumulated over many years
over multiple hosts, and there a few outlier messages that Mailman's
archiver won't process.  But: "few", so while it's an annoyance it's
really quite a minor problem.

---rsk

RE: Future of cctalk/cctech

[geneb via cctalk]

On Thu, 18 Jun 2020, Peter Coghlan via cctalk wrote:


ED SHARPE wrote:

Use modern email program that sees expanded char. Sets and graphics it
is a brand new world !    I love old hardware to look at but if
communicating  I like  the ability to see graphical  things...  and I
think tell majority of people like  images of things..   Ed#



Let me get this straight.  If I stop using VMS MAIL for this list and use
one of these new fangled things instead, I too will be able to make high
quality postings to the list, just like this one???



Yes, you too can produce a bountiful word salad with UTF-16 characters in 
place of spaces!  Amaze your friends!  Women will want you!  Men will want 
to BE you!


g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Coghlan via cctalk]

Antonio Carlini wrote:

On 18/06/2020 10:06, Peter Coghlan via cctalk wrote:
>
> To get somewhere near back on topic, I am trying to set up a synchronous
> serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe)
> interfaces.  One of the options I have is a BC19D cable and a BC19V cable
> which seem to be identical or nearly identical.  Each plugs into a DSH32
> at one end and has a V.24 DB25 connector at the other end.  I don't seem
> to have anything available in the way of a pair of suitably similar modems
> or a modem eliminator to put between the two V.24 connectors.  Can anyone
> suggest some kind of a quick hardware hack that I could use to fill the
> gap?  Is a pair of DB25 sockets with crossed over wiring betweeen them
> sufficient or do I need something that generates clock signals too?
>

I can't find my DHS32/DST32 docs right now but it's probably a simple 
re-spin of the DSH32.


I think that the DST32 was the uVAX2000 option and the DSH32 was for the 
uVAX 3100 series.


My notes say that my MicroVAX 2000 has a DST32 (54-17230) but the 
preliminary version of EK-283AA-AD-001 is for the DSH32 and that talks 
about the MicroVAX 2000!




Thanks for your reply Antonio.

I have found the whole thing very confusing too.  My suspicion was also
that they were pretty much the same thing but the DST32 had exernal
connectors suitable for mounting in a MicroVAX 2000 while the DST32 had
external connectors that could be mounted in a MicroVAX 3100.  That is,
until I also came across the preliminary version of EK-283AA-AD-001
which threw cold water on that theory.  Unless it was originally called
the DSH32 and then renamed to DST32 for the MicroVAX 2000 or something...

The console code in one of my MicroVAX 3100 machines shows this:


test 50


KA41-D  V1.0

[snip]

  DSH32-A  00FF.0001  V1.0
  DSH32-S  .0001  V3.0
  NI   .0001




Yet in VAX/VMS 7.3, I see this:

$ ANALYZE /SYSTEM

OpenVMS (TM) VAX System analyzer

SDA> show dev zsa0

I/O data structures
---
ZSA0ZS_DST32  UCB address: 814EAA40

[snip]



I think that in the lab at DEC I used a modem eliminator (I used to 
support all of the synch devices supported by VAX WANDD). I may even 
have some of those modem eliminators in the garage.




I was hoping to use VAX WANDD but I ended up having to install DECnet OSI
on VMS 7.3.  Perhaps if I dig up an earlier VMS version, I can avoid using
DECnet OSI?



Just to double check ... you definitely have synch boards and not (for 
example) 8-way asynch lines? There were a whole bunch of designators 
that were so very close: DST32, DHT32, DSH32, DHW41, DSW41!




I have two boards in two MicroVAX 3100 machines.  Each board has one
Synchronous serial port (50 pin D connector) and eight asynchronous
terminal lines (36 pin Centronics connector).  To add further confusion,
I have a third MicroVAX 3100 which has the 50 pin and 36 pin external
connectors on the back but no actual DSH32/DHT32 board inside!

I also have the following cables:

1   BC19C Rev B1  50 pin D (female) to 13/15 pin D (male) X.21
1   BC19D Rev B   50 pin D (female) to 16/25 pin D (male) V.24
1   BC19F Rev B   50 pin D (female) to 17/34 pin "square" thing (male) V.35
1   BC19V 50 pin D (female) to 16/25 pin D (male) V.24

and I also have two Nokia DS 60100 baseband modems, one with a V.35
interface card and one with an X.21 interface card.  When I hook up the
former with the BC19F cable, I can get the lights on the modem to react
when I try to access ZSA0: on the MicroVAX.  However, I can't get any
reaction when I use the BC19C cable with the latter even when I jumper
the modem to take account of the fewer signals available in X.21.  It
may be that the BC19C is meant for something other than the DSH/T32...
Anyway, this whole line of attack is fairly academic as the modems can
only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be
19200bps.

Regards,
Peter Coghlan.



Antonio

Re: Future of cctalk/cctech - text encoding

[Daniel Seagraves via cctalk]

> On Jun 18, 2020, at 4:03 AM, Lars Brinkhoff via cctalk 
>  wrote:
> 
> Peter Coghlan wrote:
>> Does anyone use ASCII anymore?
> 
> I read and write my email with Emacs running in a terminal emulator.
> I rarely need anything beoynd codepoint 126.

I vote we move the list to an Exchange server behind a SSL VPN and mandate the 
use of Outlook, then force all messages to be in quoted-printable encoding. 
This way nobody “wins” and everyone is equally miserable. It’s only fair.

Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Corlett via cctalk]

On Thu, Jun 18, 2020 at 09:42:16AM +0100, Dave Wade via cctalk wrote:
[...]
> I wrote this as one dollar => $1.00
> This as one pound => $1
> And this as one euro => €1
> Lastly one cent => ¢1

This came over the wire as follows:

> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
[...]
> I wrote this as one dollar =3D> $1.00
> This as one pound =3D> $1
> And this as one euro =3D> =E2=82=AC1
> Lastly one cent =3D> =C2=A21

IOW, it has the correct headers to unambiguously decode the text. Whether the
receiving software is competent enough to handle Q-P UTF-8 text is something
else entirely, especially if it's in an obscure or recently-added script or
symbol set where suitable fonts don't exist or haven't been installed, but your
example doesn't contain any difficult code points.

The correct Q-P UTF-8 encoding for "£" is "=C2=A3". (I've dealt with so much
broken software that I know this without looking it up.) It seems likely that
it got mangled by something at your end in whatever converts it to "modern"
(1993) email format.

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Jan-Benedict Glaw via cctalk]

On Wed, 2020-06-17 16:44:26 -0400, Diane Bruce via cctalk 
 wrote:
> On Wed, Jun 17, 2020 at 01:41:39PM -0700, Cameron Kaiser via cctalk wrote:
> > > > I read this list on PINE, on a shell account at my ISP.
> > >
> > > Barbarian!  At least upgrade to Alpine.  (That's what I use.) :D
> > 
> > Philistines, all of you. I use a hacked version of Elm.
> 
> mutt!

Indeed. I get quite a lot of emails and mutt allows me to properly
fight back.

MfG, JBG

-- 

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Paul Berger via cctalk]

On 2020-06-18 6:06 a.m., Peter Coghlan via cctalk wrote:



To get somewhere near back on topic, I am trying to set up a synchronous
serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe)
interfaces.  One of the options I have is a BC19D cable and a BC19V cable
which seem to be identical or nearly identical.  Each plugs into a DSH32
at one end and has a V.24 DB25 connector at the other end.  I don't seem
to have anything available in the way of a pair of suitably similar modems
or a modem eliminator to put between the two V.24 connectors.  Can anyone
suggest some kind of a quick hardware hack that I could use to fill the
gap?  Is a pair of DB25 sockets with crossed over wiring betweeen them
sufficient or do I need something that generates clock signals too?

Regards,
Peter Coghlan.
  

While I have no experience with MicroVAX, I do recall that  on the 
machine I was involved with synchronous communications on, IBM terminals 
and systems, there was an option for the interface to provide clocking 
and I suppose it might be possible to set one side to provide the 
transmit and receive clocks and cross them over to the other interface, 
but I have never tried that.  When I worked in a development center with 
a room full of S/38 and S/36 we had a modem rack with a large number of 
Gandalf modem eliminators that provided clocking to the interface.


In the field the most common setup was to have the modem provide the 
clocks as the common carrier could synchronize them over a long distance.


Paul.

Re: E-Mail Formats RE: Future of cctalk/cctech

[Liam Proven via cctalk]

On Thu, 18 Jun 2020 at 11:10, ED SHARPE via cctalk
 wrote:
>
> Dave --  I  suppose   the  solve  is  to  write  it  out  long hand  as in 
> One Dollar   One Cent  One  Pound...

Dear hypothetical deities, no. That causes problems with translation,
people not knowing the name of another country's currency in a foreign
language, etc.

There is a standardized internationally-agreed set of 3 ASCII letter
symbols for this reason and this is why people use them.

USD = US dollar
GBP = GB pound
EUR = Euro
CZK = Czech crown (korun/koruny/koruna, depending on quantity, in Czech)

Etc etc.

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: E-Mail Formats RE: Future of cctalk/cctech

[Liam Proven via cctalk]

On Thu, 18 Jun 2020 at 10:42, Dave Wade via cctalk
 wrote:
>
> I wrote this as one dollar => $1.00

Dollar symbol, one

> This as one pound => $1

Dollar symbol, 1

> And this as one euro => €1

Euro symbol, one

> Lastly one cent => ¢1

Cent symbol, one

Fascinating.

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Antonio Carlini via cctalk]

On 18/06/2020 10:06, Peter Coghlan via cctalk wrote:


To get somewhere near back on topic, I am trying to set up a synchronous
serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe)
interfaces.  One of the options I have is a BC19D cable and a BC19V cable
which seem to be identical or nearly identical.  Each plugs into a DSH32
at one end and has a V.24 DB25 connector at the other end.  I don't seem
to have anything available in the way of a pair of suitably similar modems
or a modem eliminator to put between the two V.24 connectors.  Can anyone
suggest some kind of a quick hardware hack that I could use to fill the
gap?  Is a pair of DB25 sockets with crossed over wiring betweeen them
sufficient or do I need something that generates clock signals too?



I can't find my DHS32/DST32 docs right now but it's probably a simple 
re-spin of the DSH32.


I think that the DST32 was the uVAX2000 option and the DSH32 was for the 
uVAX 3100 series.


My notes say that my MicroVAX 2000 has a DST32 (54-17230) but the 
preliminary version of EK-283AA-AD-001 is for the DSH32 and that talks 
about the MicroVAX 2000!


I think that in the lab at DEC I used a modem eliminator (I used to 
support all of the synch devices supported by VAX WANDD). I may even 
have some of those modem eliminators in the garage.



Just to double check ... you definitely have synch boards and not (for 
example) 8-way asynch lines? There were a whole bunch of designators 
that were so very close: DST32, DHT32, DSH32, DHW41, DSW41!



Antonio



--
Antonio Carlini
anto...@acarlini.com

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

[Peter Coghlan via cctalk]

Dave Wade wrote:
> 
> > -Original Message-
> > From: cctalk  On Behalf Of Peter Coghlan
> > via cctalk
> > Sent: 18 June 2020 08:22
> > To: General Discussion: On-Topic and Off-Topic Posts
> > 
> > Subject: RE: Future of cctalk/cctech
> > 
> > ED SHARPE wrote:
> > > Use modern email program that sees expanded char. Sets and
> > > graphics it is a brand new world !I love old hardware to look
> > > at but if communicating  I like  the ability to see graphical
> > > things...  and I think tell majority of people like  images of
> > > things..   Ed#
> > >
> > 
> 
> Just beware. Some environments, especially old EBCDIC ones put different 
> currency symbols on the same code points
> So:-
> 
> I wrote this as one dollar => $1.00
> This as one pound => $1
> And this as one euro => €1
> Lastly one cent => ¢1
> 
> I expect you all get that as sent except for perhaps the Euro which didn't 
> exist when Peters VAX was built
> ... but on an old UK EBCDIC mainframe Dollar becomes Pound and Cent becomes 
> dollar. This was a real pain as a UK user of Bitnet. 

Well, Peter reads cctalk using VMS MAIL on his alphas and this has it's own
problems.  Around VMS 8.something, someone had the bright idea that VMS MAIL
should replace certain "unusual" characters (such as the tilde for example)
with (you guessed it) a dollar sign rather than present them directly to the
reader for some unknown reason...

However, Peter uses PMDF MAIL to post to the list because it has been
pointed out to him that VMS MAIL doesn't do References: and In-Reply-To:
headers correctly.  On that note, has anyone heard from Mouse?  I haven't
seen anything posted by him in a very long time now.


To get somewhere near back on topic, I am trying to set up a synchronous
serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe)
interfaces.  One of the options I have is a BC19D cable and a BC19V cable
which seem to be identical or nearly identical.  Each plugs into a DSH32
at one end and has a V.24 DB25 connector at the other end.  I don't seem
to have anything available in the way of a pair of suitably similar modems
or a modem eliminator to put between the two V.24 connectors.  Can anyone
suggest some kind of a quick hardware hack that I could use to fill the
gap?  Is a pair of DB25 sockets with crossed over wiring betweeen them
sufficient or do I need something that generates clock signals too?

Regards,
Peter Coghlan.
 
> Dave

Re: E-Mail Formats RE: Future of cctalk/cctech

[ED SHARPE via cctalk]

Dave --  I  suppose   the  solve  is  to  write  it  out  long hand  as in One 
Dollar   One Cent  One  Pound... I never  considered  how  the  monetary vales  
 could  get  screwed up. Ed#...CIn a message dated 6/18/2020 1:42:27 AM US 
Mountain Standard Time, cctalk@classiccmp.org writes: 
 > -Original Message-> From: cctalk  On 
Behalf Of Peter Coghlan> via cctalk> Sent: 18 June 2020 08:22> To: General 
Discussion: On-Topic and Off-Topic Posts> > Subject: RE: 
Future of cctalk/cctech> > ED SHARPE wrote:> > Use modern email program that 
sees expanded char. Sets and> > graphics it is a brand new world !    I 
love old hardware to look> > at but if communicating  I like  the ability to 
see graphical> > things...  and I think tell majority of people like  images 
of> > things..  Ed#> >>  Just beware. Some environments, especially old 
EBCDIC ones put different currency symbols on the same code pointsSo:- I wrote 
this as one dollar => $1.00This as one pound => $1And this as one euro => 
€1Lastly one cent => ¢1 I expect you all get that as sent except for perhaps 
the Euro which didn't exist when Peters VAX was built... but on an old UK 
EBCDIC mainframe Dollar becomes Pound and Cent becomes dollar. This was a real 
pain as a UK user of Bitnet.  Dave > Let me get this straight.  If I stop using 
VMS MAIL for this list and use one of> these new fangled things instead, I too 
will be able to make high quality> postings to the list, just like this one???> 
> Regards,> Peter Coghlan

Re: Future of cctalk/cctech - text encoding

[Lars Brinkhoff via cctalk]

Peter Coghlan wrote:
> Does anyone use ASCII anymore?

I read and write my email with Emacs running in a terminal emulator.
I rarely need anything beoynd codepoint 126.

I hear MIT-MC is a popular host for mailing lists.  Remind me, is
ARPANET still up and running?

Re: Future of cctalk/cctech - text encoding

[Peter Coghlan via cctalk]

Christian Corti wrote:

On Wed, 17 Jun 2020, ben wrote:
> Does this mailing list have people using EBCDIC for example?

Yes, if for example I use Kermit on the IBM 5110 and connect to a UNIX 
host. ;-) But in this case, my Kermit is doing the translation between 
ASCII and EBCDIC.


Does anyone use ASCII anymore?  Most of the emails I get now are marked as
utf-8 with the occasional iso-8859-1.

Regards,
Peter Coghlan. 


Christian

E-Mail Formats RE: Future of cctalk/cctech

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Peter Coghlan
> via cctalk
> Sent: 18 June 2020 08:22
> To: General Discussion: On-Topic and Off-Topic Posts
> 
> Subject: RE: Future of cctalk/cctech
> 
> ED SHARPE wrote:
> > Use modern email program that sees expanded char. Sets and
> > graphics it is a brand new world !I love old hardware to look
> > at but if communicating  I like  the ability to see graphical
> > things...  and I think tell majority of people like  images of
> > things..   Ed#
> >
> 

Just beware. Some environments, especially old EBCDIC ones put different 
currency symbols on the same code points
So:-

I wrote this as one dollar => $1.00
This as one pound => $1
And this as one euro => €1
Lastly one cent => ¢1

I expect you all get that as sent except for perhaps the Euro which didn't 
exist when Peters VAX was built
... but on an old UK EBCDIC mainframe Dollar becomes Pound and Cent becomes 
dollar. This was a real pain as a UK user of Bitnet. 

Dave

> Let me get this straight.  If I stop using VMS MAIL for this list and use one 
> of
> these new fangled things instead, I too will be able to make high quality
> postings to the list, just like this one???
> 
> Regards,
> Peter Coghlan
> 
> >
> > On Wednesday, June 17, 2020 Fred Cisin via cctalk  cctalk@classiccmp.org> wrote:
> > On Wed, 17 Jun 2020, ED SHARPE @ AOHell.com via cctalk wrote:
> > > These 2 have my vote as well
> > > I do not know, anyone using a text only mail reader anymore!
> > >
> > >> The one thing I would change here is removal of the restriction on
> attachments.
> > >> Well, two things.. Getting rid of the cctalk/cctech split as well.
> >
> > I read this list on PINE, on a shell account at my ISP.
> >
> > In this group, I doubt that I am the only one.
> >
> >
> > Can we restrict to TEXT emails?
> >
> > --
> > Grumpy Ol' Fredci...@xenosoft.com
> >

RE: Future of cctalk/cctech

[Peter Coghlan via cctalk]

ED SHARPE wrote:
> Use modern email program that sees expanded char. Sets and graphics it
> is a brand new world !    I love old hardware to look at but if
> communicating  I like  the ability to see graphical  things...  and I
> think tell majority of people like  images of things..   Ed#
>

Let me get this straight.  If I stop using VMS MAIL for this list and use
one of these new fangled things instead, I too will be able to make high
quality postings to the list, just like this one???

Regards,
Peter Coghlan

>
> On Wednesday, June 17, 2020 Fred Cisin via cctalk  cctalk@classiccmp.org> wrote:
> On Wed, 17 Jun 2020, ED SHARPE @ AOHell.com via cctalk wrote:
> > These 2 have my vote as well
> > I do not know, anyone using a text only mail reader anymore!
> >
> >> The one thing I would change here is removal of the restriction on 
> >> attachments.
> >> Well, two things.. Getting rid of the cctalk/cctech split as well.
> 
> I read this list on PINE, on a shell account at my ISP.
> 
> In this group, I doubt that I am the only one.
> 
> 
> Can we restrict to TEXT emails?
> 
> --
> Grumpy Ol' Fred            ci...@xenosoft.com
> 

Re: Future of cctalk/cctech - text encoding

[Christian Corti via cctalk]

On Wed, 17 Jun 2020, ben wrote:

Does this mailing list have people using EBCDIC for example?


Yes, if for example I use Kermit on the IBM 5110 and connect to a UNIX 
host. ;-) But in this case, my Kermit is doing the translation between 
ASCII and EBCDIC.


Christian

RE: Future of cctalk/cctech

[Christian Corti via cctalk]

On Wed, 17 Jun 2020, ED SHARPE wrote:

These 2 have my vote as well
I do not know, anyone using a text only mail reader anymore!


Yes, of course. I'm exclusively using Alpine even at work.

Christian

Re: Future of cctalk/cctech

[Angel M Alganza via cctalk]

On Wed, Jun 17, 2020 at 10:48:19AM -0700, Fred Cisin via cctalk wrote:


I read this list on PINE, on a shell account at my ISP.
In this group, I doubt that I am the only one.


I use Mutt.


Can we restrict to TEXT emails?


Yes please!

Cheers,
Ángel

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Chris Elmquist via cctalk]

> On Jun 17, 2020, at 3:46 PM, Diane Bruce via cctalk  
> wrote:
> 
> On Wed, Jun 17, 2020 at 01:41:39PM -0700, Cameron Kaiser via cctalk wrote:
 I read this list on PINE, on a shell account at my ISP.
>>> 
>>> Barbarian!  At least upgrade to Alpine.  (That's what I use.) :D
>> 
>> Philistines, all of you. I use a hacked version of Elm.
> 
> mutt!

Ya! Exactly.  Woof.


cje

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Chris Elmquist via cctalk]

> On Jun 17, 2020, at 3:43 PM, Cameron Kaiser via cctalk 
>  wrote:
> 
> 
>> 
>>> I read this list on PINE, on a shell account at my ISP.
>> 
>> Barbarian!  At least upgrade to Alpine.  (That's what I use.) :D
> 
> Philistines, all of you. I use a hacked version of Elm.

And what’s wrong with Mutt?


I have yet to suffer a phishing attack with that.

Chris

Re: Future of cctalk/cctech

[Fred Cisin via cctalk]

On Thu, 18 Jun 2020, Doug Jackson via cctalk wrote:

If we do implement attachments that are limited to one SSDD 8" disk, can
there please be some technological way of chaining disk 'parts' to allow
larger attachments to be transmitted?


If you use MS-DOS, and have a large drive in addition to the 8" SSSD, you 
could type:

COPY file1 + file2 + file3 + file4 + file5 bigfile

Many Backup/Restore programs have capability of splitting and recombining 
files.


OR
have a CCTALK "files" storage area (maybe on a website?), that could host 
large files, and include LINKS, not CONTENT, in the emails.

Re: Future of cctalk/cctech

[ben via cctalk]

On 6/17/2020 4:44 PM, Doug Jackson via cctalk wrote:


If we do implement attachments that are limited to one SSDD 8" disk, can
there please be some technological way of chaining disk 'parts' to allow
larger attachments to be transmitted?


I am not turning my computer over, just to use the other side
of a 8" floppy. Ben.

Re: Future of cctalk/cctech

[Rich Kulawiec via cctalk]

I'd be happy to host the list at firemountain.net, where a Mailman 2.X
instance has been happily running a few dozen public and private lists for
15-ish years (majordomo before that) (homebrew scripts before that).
No charge, no ads.

If the archives are available in mbox format (or something that can
be massaged into mbox format) I can import all of those.

I would also suggest that -- to future-proof this -- that multiple
people stash those archives and stash future archives as they accrue.
Given archives and a subscriber list, a mailing list can be reconstituted
anywhere.

Merging lists: if the consensus is that it should be done, I can
do that.  (Whether that means the subscriber lists, the archives, or both.)

Attachments: that's also do-able if consensus indicates but I recommend
that they be limited to open formats, because delivering messages with
proprietary attachments is a quagmire even if all the recipients want
them. (long explanation omitted)  Many years of experience indicate
that doing this and imposing a soft large-but-finite maximum message
size facilitates communication without overwhelming people.

And since someone will ask: I use mutt.

---rsk

Re: Future of cctalk/cctech

[Doug Jackson via cctalk]

I gave up on hosting my own email years ago when I was the recipient of
tens of thousands of spam messages per day, both to this and my business
email address.  I now simply use gmail to handle email - seems like the G
beast has seen every bit of spam before, so the spam transfer rate is
approximating zero.

All of the old mailing lists I use are on groups.io -   I actually don't
log into their platform, instead they send me updates as messages.  These
often contain attachments, which don't bother me, as its using google mail
storage to store, and unless its interesting, I don't bother copying it
into my world.  That way, complete disk images can be sent and I don't mind.

Using a glass screen VDU with a mouse, means that the sparse, and expensive
to obtain paper for the TTY is not adversely used when somebody top or
bottom or sideways posts.   And I can even catch up on email while I am
using my phone in the bus.

If we do implement attachments that are limited to one SSDD 8" disk, can
there please be some technological way of chaining disk 'parts' to allow
larger attachments to be transmitted?

Kindest regards,

Doug Jackson

em: d...@doughq.com
ph: 0414 986878

Check out my awesome clocks at www.dougswordclocks.com
Follow my amateur radio adventures at vk1zdj.net

---

Just like an old fashioned letter, this email and any files transmitted
with it should probably be treated as confidential and intended solely for
your own use.

Please note that any interesting spelling is usually my own and may have
been caused by fat thumbs on a tiny tiny keyboard - for this I apologise in
advance - It's ok bec we don* nee* accu tex* to unde** actu**
mean***.

Should any part of this message prove to be useful in the event of the
imminent Zombie Apocalypse then the sender bears no personal, legal, or
moral responsibility for any outcome resulting from its usage unless the
result of said usage is the unlikely defeat of the Zombie Hordes in which
case the sender takes full credit without any theoretical or actual legal
liability. :-)

Be nice to your parents.

Go outside and do something awesome - Draw, paint, walk, Setup a
radio station, go fishing or sailing - just do something that makes you
happy.





On Thu, Jun 18, 2020 at 7:49 AM ED SHARPE via cctalk 
wrote:

>
> We use groups,io for the tom swift discussion group real handy to post
> photos, files and etc..
> On Wednesday, June 17, 2020 Chris Hanson via cctalk <
> cmhan...@eschatologist.net; cctalk@classiccmp.org> wrote:
> On Jun 17, 2020, at 1:50 AM, Tor Arntsen via cctalk 
> wrote:
> >
>  There is also groups.io, and it has some very nice features compared
> to
> >
> > Please please, no groups of any kinds. They're all horrible to use.
>
> Do you mean "web forum" where you say "groups?"
>
> > A
> > genuine mailing list like this is infinitively easier to keep track of
> > and read at leisure. Can't stand groups.io.
>
> I've found the groups.io  mailing list mode to be
> perfectly reasonable for a number of groups I'm a part of. And it has a
> forum-like front end for people who insist on doing everything through a
> web page.
>
>   -- Chris
>

Re: Future of cctalk/cctech

[ED SHARPE via cctalk]

We use groups,io for the tom swift discussion group real handy to post photos, 
files and etc..
On Wednesday, June 17, 2020 Chris Hanson via cctalk 
 wrote:
On Jun 17, 2020, at 1:50 AM, Tor Arntsen via cctalk  
wrote:
> 
 There is also groups.io, and it has some very nice features compared to
> 
> Please please, no groups of any kinds. They're all horrible to use.

Do you mean "web forum" where you say "groups?"

> A
> genuine mailing list like this is infinitively easier to keep track of
> and read at leisure. Can't stand groups.io.

I've found the groups.io  mailing list mode to be perfectly 
reasonable for a number of groups I'm a part of. And it has a forum-like front 
end for people who insist on doing everything through a web page.

  -- Chris

Re: Future of cctalk/cctech

[Chris Hanson via cctalk]

On Jun 17, 2020, at 10:48 AM, Fred Cisin via cctalk  
wrote:
> 
> On Wed, 17 Jun 2020, ED SHARPE @ AOHell.com via cctalk wrote:
>> These 2 have my vote as well
>> I do not know, anyone using a text only mail reader anymore!
>> 
>>> The one thing I would change here is removal of the restriction on 
>>> attachments.
>>> Well, two things.. Getting rid of the cctalk/cctech split as well.
> 
> I read this list on PINE, on a shell account at my ISP.
> 
> In this group, I doubt that I am the only one.
> 
> 
> Can we restrict to TEXT emails?

Why?

Pine/Alpine should show the text portion of any multipart messages perfectly 
reasonably, and not even attempt to download non-text MIME content from your 
IMAP server. Crispin designed the application and the protocol that way 
intentionally; his approach was always that you should be able to run your MUA 
locally with just a 2400bps link to your IMAP server, and get perfectly 
reasonable performance.

  -- Chris

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Cameron Kaiser via cctalk]

> > > > > I read this list on PINE, on a shell account at my ISP.
> > > >
> > > > Barbarian!  At least upgrade to Alpine.  (That's what I use.) :D
> > >
> > > Philistines, all of you. I use a hacked version of Elm.
> >
> > mutt!
> 
> `less`, out of system spool.

tail -f $MAIL

But seriously, written in Elm. I think there are a lot of text terminal
mailers on this list.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Test-tube babies shouldn't throw stones. ---

Re: Future of cctalk/cctech

[Chris Hanson via cctalk]

On Jun 17, 2020, at 1:50 AM, Tor Arntsen via cctalk  
wrote:
> 
 There is also groups.io, and it has some very nice features compared to
> 
> Please please, no groups of any kinds. They're all horrible to use.

Do you mean "web forum" where you say "groups?"

> A
> genuine mailing list like this is infinitively easier to keep track of
> and read at leisure. Can't stand groups.io.

I've found the groups.io  mailing list mode to be perfectly 
reasonable for a number of groups I'm a part of. And it has a forum-like front 
end for people who insist on doing everything through a web page.

  -- Chris

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Mark Linimon via cctalk]

On Wed, Jun 17, 2020 at 04:44:26PM -0400, Diane Bruce via cctalk wrote:
> mutt!

+1

Re: Future of cctalk/cctech

[Chris Hanson via cctalk]

On Jun 16, 2020, at 10:23 PM, Lars Brinkhoff via cctalk  
wrote:
> 
> Jon Elson wrote:
>> Yes, several other groups I read and contribute to have moved to
>> groups.io, and they are working quite well and reliably.  Some options
>> require $10 a month to be free from ads.
> 
> That's a red flag.

Being able to pay a service not to show ads on their web site shows that 
they're willing to say "no" to advertisers, which is pretty much the opposite 
of a red flag to me.

  -- Chris

Re: Future of cctalk/cctech - text encoding

[Fred Cisin via cctalk]

Although I am using a larger drive, I would prefer that we not have any 
messages that wouldn't be possible to fit on an 8" SSSD disk.


On Wed, 17 Jun 2020, ben via cctalk wrote:

Does that include the TAG LINE?
I am happy just to have ASCII text, and trimmed messages.
Does this mailing list have people using EBCDIC for example?
What would be useful is a way to transfer things like paper tape
or punch card deck.


What I would like to see, is an available FILES web location, where people 
could put their "please ID this" pictures, and other worthwhile files.

But, links, NOT content, sent out in the email!
If there is enough cheap space, maybe even stuff like the GWBASIC stuff.
Q: is the original Microsoft BASIC paper tape released from copyright, 
yet?



Once the plain text rule is lifted, we are likely to also no longer get 
ANY trimming of messages, and every post will include everything that ever 
came before.  All the way back to THIS.

Re: Future of cctalk/cctech

[Liam Proven via cctalk]

On Wed, 17 Jun 2020 at 19:04, ED SHARPE via cctalk
 wrote:

> I do not know, anyone using a text only mail reader anymore!

Several of my colleagues at a Prominent German Linux Distributor use
Mutt/Neomutt. I don't, I am on Thunderbird and rather like it.

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: Future of cctalk/cctech - text encoding

[ben via cctalk]

On 6/17/2020 2:35 PM, Fred Cisin via cctalk wrote:

Although I am using a larger drive, I would prefer that we not have any 
messages that wouldn't be possible to fit on an 8" SSSD disk.



Does that include the TAG LINE?
I am happy just to have ASCII text, and trimmed messages.
Does this mailing list have people using EBCDIC for example?
What would be useful is a way to transfer things like paper tape
or punch card deck.
Ben.

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Dennis Boone via cctalk]

 > > > > I read this list on PINE, on a shell account at my ISP.

 > > > Barbarian!  At least upgrade to Alpine.  (That's what I use.) :D

 > > Philistines, all of you. I use a hacked version of Elm.

 > mutt!

`less`, out of system spool.

De

Re: MUA again [was: Re: Future of cctalk/cctech]

[Diane Bruce via cctalk]

On Wed, Jun 17, 2020 at 09:39:41PM +0200, Tomasz Rola via cctalk wrote:
> On Wed, Jun 17, 2020 at 07:24:40PM +, ED SHARPE via cctalk wrote:
> > 
> > Use modern email program that sees expanded char. Sets and
...
> 
> Besides, once the html or any other non-pure text format takes over,
> everybody will be receiving messages sized in megabytes if not worse,
> whose human-readable content would be only few lines of text. Just
> like modern web.

Happened with Meetup FWIW they have no plain text option
and it's annoying.


-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

Re: mail on spool as G-d intended was Re: Future of cctalk/cctech

[Diane Bruce via cctalk]

On Wed, Jun 17, 2020 at 01:41:39PM -0700, Cameron Kaiser via cctalk wrote:
> > > I read this list on PINE, on a shell account at my ISP.
> >
> > Barbarian!  At least upgrade to Alpine.  (That's what I use.) :D
> 
> Philistines, all of you. I use a hacked version of Elm.

mutt!

> -- 
>  personal: http://www.cameronkaiser.com/ 
> --
>   Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
> -- Never interrupt your enemy when he is making a mistake. -- Napoleon 
> 

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

mail on spool as G-d intended was Re: Future of cctalk/cctech

[Cameron Kaiser via cctalk]

> > I read this list on PINE, on a shell account at my ISP.
>
> Barbarian!  At least upgrade to Alpine.  (That's what I use.) :D

Philistines, all of you. I use a hacked version of Elm.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Never interrupt your enemy when he is making a mistake. -- Napoleon 

Re: Future of cctalk/cctech

[Fred Cisin via cctalk]

They take up a lot of space.


On Wed, 17 Jun 2020, William Donzelli via cctalk wrote:

Well, there is some circa 2005 thinking.


2005 was only 15 years ago.

Some of us have pre-Y2K thinking.

Have we finally gotten rid of discussion of a "ten year rule"/"twenty 
year rule"?

Is there ANYTHING classic post millenium?


Although I am using a larger drive, I would prefer that we not have any 
messages that wouldn't be possible to fit on an 8" SSSD disk.

RE: Future of cctalk/cctech

[Fred Cisin via cctalk]

I wonder what you don't like about "groups.io" Its pretty much a pure

mailing list?



The one thing I would change here is removal of the restriction on
attachments.

On Wed, 17 Jun 2020, Dave Wade via cctalk wrote:

They take up a lot of space.


FREE mail lists on groups.io have a size limit.  I don't think that it is 
a very strenuous limit.
BUT, larger volume, such as ATTACHMENTS, bumps it into having to pay a 
subscription fee.

Re: Future of cctalk/cctech

[William Donzelli via cctalk]

> They take up a lot of space.

Well, there is some circa 2005 thinking.

--
Will

RE: Future of cctalk/cctech

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Al Kossow via
> cctalk
> Sent: 17 June 2020 13:55
> To: cctalk@classiccmp.org
> Subject: Re: Future of cctalk/cctech
> 
> > I wonder what you don't like about "groups.io" Its pretty much a pure
> mailing list?
> 
> Like all of the webby time-wasters, they don't have easy to mirror zipped
> archives, because they want to to spend time hovering around clicking on
> their sites.
> 

As there are no adverts on their site, why would they want you clicking around 
on the site? That uses resource and costs them money.
It was primarily envisaged as a mail service. The web side was added because 
some folks wanted it.
As a group owner I can download zipped archives of all content.
The ability for members to download the message archive as a zipped file is 
configurable by the list owner.

> 
> http://www.classiccmp.org/pipermail/cctalk/
> 
> The one thing I would change here is removal of the restriction on
> attachments.
> 

They take up a lot of space.

> Well, two things.. Getting rid of the cctalk/cctech split as well.
> 

I think thats pretty irrelevant .

Dave

"Modern" computer science (Was: MUA again [was: Future of cctalk/cctech]

[Fred Cisin via cctalk]

Use modern email program that sees expanded char. Sets and
graphics it is a brand new world !    I love old hardware to
look at but if communicating  I like  the ability to see graphical 
things...  and I think tell majority of people like  images of
things..   Ed#


On Wed, 17 Jun 2020, Tomasz Rola via cctalk wrote:

In case of graphical MUA with graphical messages in them, I am of
opinion they open doors to various things and the majority happily
sees nothing.

Besides, once the html or any other non-pure text format takes over,
everybody will be receiving messages sized in megabytes if not worse,
whose human-readable content would be only few lines of text. Just
like modern web.



Those few lines of text might only be human-readable after OCR processing.


College administrators:
At the college, we had one administrator who insisted that compliance with 
the state mandates for community college curricula of "computer literacy" 
and "information competency" were already met.


He wrote a two line memo announcing a room change for a meeting.
He did it in a "feature rich" word processor,
then he printed it on a color printer,
then he scanned that piece of paper,
and then he attached that scanned graphic image to an email
with SUBJECT: "For your information",
and message text of "See the attachment".

He vetoed my proposal to create a beginning course in Information Science, 
on the grounds that one of the local universities taught something that he 
considered to be the same, as a GRADUATE course, and "therefore, it would 
be ILLEGAL for the community college to teach it."


One of our COBOL teachers got a gig at one of the local universities, and 
COPIED OUR COBOL class (the authors of the textbook, Jack Olson and Wil 
Price, were in our faculty) to be taught in the graduate school there. 
Our administrator said that it would be ILLEGAL for us to continue 
teaching it!




--
Grumpy Ol' Fred ci...@xenosoft.com

Re: Future of cctalk/cctech

[Curious Marc via cctalk]

> The one thing I would change here is removal of the restriction on 
> attachments.

> Well, two things.. Getting rid of the cctalk/cctech split as well.

 

Amen on that. The first one in particular. As simple as that and you’ve gotten 
yourself a very functional yet efficient system.

Marc