This can easily be done with a small shell script and standard linux commands.

   #!/usr/bin/bash
   
   MAILTEXT=$(grep "dbkey" db.txt)
   
   cat emails.lst|while read ADDR NAME
   do
      mail -s "Subject" $ADDR <<EOT
   Dear $NAME

   $MAILTEXT

   EOT
   
   done

Schedule with cron.

This is unsafe (glob injection).

Never use bash unless you know exactly what you are doing, and even then, better don't.

Even worse to recommend bash to somebody who already stated that they don't know what they are doing.

Just use Python for such scripts, it won't let you shoot yourself into the foot with surprising behavior.

Another reason is that farming machinery compacts the soil.

Techniques such as min-till and no-till aim to minimise soil disturbance (to reduce emissions from deep ploughing and improve soil fertility), but to achieve this you really need to make sure the equipment accurately follows the same path through a field every time, so that the area affected by compaction is mimimised.

Not a farmer, I learned this from the youtube channel Harry's Farm.

grep has a bad interaction with set -e, since it (infuriatingly) exits with 1 if no lines are matched.

Well, otherwise `if grep "line" $file; then` wouldn't work, which in my opinion is the primary use case for grep in scripts.

I'd still prefer a `grep <args> || true` over not having `set -e` for the whole file.

You can `set +e` before and `set -e` after every such command. I indent those commands to make it look like a block and to make sure setting errexit again isn’t forgotten.

But you probably still want an error if the input file does not exist. To handle grep correctly in a robust manner requires many lines of boilerplate, set +e, storing $?, set -e, distinguishing exit values 0, 1, and 2.

I remember back in the day these were used by the A86 assembler to identify code assembled with the unregistered version of the software.

Not exactly. It used the two different encodings possible for source/destination operand when both are registers.

For example, 'ADD AL,CL' can be encoded as (values in octal):

    000 310 : 3=reg/reg  1=source is CL  0=dest. is AL
    002 301 : 3=reg/reg  0=dest is AL    1=src. is CL

Other assemblers always use one of these consistently, A86 switches between them depending on some bits of the opcode and operands (but each instruction will always be encoded the same when it appears multiple times, there is no steganographic message embedded).

I think it was because in the 80's the US was wealthier and systems with disk drives were a lot more common.

People would swap games on disk, and there was less pressure to learn how the underlying system works.

Having a disk drive also enables more complex, larger games, which would be harder to produce as a lone programmer.

Contrast this with the UK - we had much less money, it was common to type games in from magazines, which is how a lot of us learned programming.

We mostly had to make do with tapes, which limits the size of a game and its sound and graphics to physical RAM. It was entirely possible as a lone programmer to create a commercial level game with a few weeks of late night hacking.

The thing I miss about Usenet is maintaining article and comment scoring in trn (based on the subject, keywords and/or author)

With this I could easily surface interesting articles or replies by insightful people, while avoiding subjects and authors in which I had no interest.

This worked at a thread level, so I could quickly see any new threads, and new replies added to threads I was following, skipping over everything I had already marked as read.

For me this was more effective than the communal post scoring that took over on web forums, reddit, hn etc.

I'm curious - are there any features of System/360, that we don't have in modern operating systems, that would be worth implementing?

Channelized I/O, intent-based security policies (e.g. from RACF), multi-layered error handling and recovery. It's a rich garden. However, it's not as simple as "implementing a feature," since the interesting things are all systems of activity with interlocking assumptions and expectations with all the other systems. You can't "just" pluck pieces out of context any more than you can grab a cool phrase from Mandarin or Urdu, or admire a lobster's claw and decide to graft it onto your own arm.

But for anyone interested in evolving systems/OSs, definitely study S/3x0 and Z successors, or the proprietary mainframes and minicomputers in general. In many cases we are now stumbling into reinventing techniques that mainframes or minicomputer teams built many years earlier. Best case in point probably virtual machines (VMs), in which VMware et al started in ~2003 rebuilding a technology capability that had been developed in Z systems in 1967/68.

ELI5: What is "channelized" I/O? How does it differ from, say, handing off I/O to a DMA controller?

It's essentially having a small CPU as a DMA controller. For a prototypical DMA controller, you just give a list of source and destination addresses + transfer size and it runs off an performs those transfers and tells you when it's done. Maybe they can even be chained together (one DMA channel writes to control registers of another then starts that channel).

For "channelized" IO, you had CPU instructions which would effectively hand off small programs to another processor that was extremely limited in capability compared to your CPU. The channel processor would handle the direct interrupts/events from physical IO devices, do basic processing, then kick off (a) DMA transfer(s) to and from main memory, or as a data stream straight to the CPU.

For some mainframe architectures, you could implement things like text-editors and filesystem drivers that would run on the channel processors so that basic tasks didn't take up core CPU time. The main CPU could allocate memory for a process to be placed in, then send off a channel program to the tape drive and go and do something else for awhile while the tape drive found and loaded the executable completely independent of the CPU.

Probably a more realistic example would be to take something like a database and have a separate CPU processing the on-disk format, or a separate CPU to process your network protocol's wire format and only having the actual data it contains seen by the main CPU.

These days processing power is so ridiculously cheap compared to those days that flexibility rules the day. Might as well have a bunch of dumb IO devices because even a basic CPU core can move and process gigabytes of data per second.

It's something between that and RISC-V minion cores.

Your hard drive probably has a RISC-V core in it anyway. It seems like a distinction without a difference.

The channel I/O format has conditional jumps in the command stream and lets you as the application programmer offload large parts of the filesystem or database directly onto the hard drive controller without main CPU intervention. It's closer to GPU command submissions than what you see out of NVMe/SCSI/ATA. So, for one example, telling the controller to "walk an index tree in this format and retrieve the block that matches this key" is something you can code yourself in the channel I/O command stream as it's own sort of ISA.

From the "roads not taken" perspective, Intel actually made something like a channel IO engine for the 8086/8088 family called the 8089 (https://en.wikipedia.org/wiki/Intel_8089) which supported the 20-bit address space of those systems and proper 8 and 16-bit operations. You could write little programs for it which would communicate with IO devices and respond to interrupts on either a shared or private bus, do some processing, and then move the results to main memory.

IBM in a cost saving move grafted the DMA engine from the 8080 family (the 8237) and made it mostly work by adding a page register to cover the remaining bits and setting one up in an odd way for the 286 to get it to do IO <-> memory transfers for 16-bit devices (but unable to do memory-to-memory transfers).

See eg https://netfpga.org for pretty much exactly this for network. I believe it's more of a research platform than something that's used in production. It's not exactly new either.

Not quite, because this is reconfiguring the hardware itself, but similar in intent.

As a note, Commodore’s 1541 and 1571 drives ran the filesystem in the drive themselves. The computer only sent file commands to the drive.

And even a faster 6502 than the CPU! Yeah the true very programmable I/O offload you see in the C64 is very similar conceptually, and would be even closer if it could DMA into main RAM to communicate with the main CPU rather than bitbanging serial.

I wonder if one could do some useful computation within the drive itself, like adding columns from or sorting a CSV file.

The new "Z on demand" features they offer over the internet remind me a lot of how it easy it was to provision virtual S/360 (S/390 at the time) hardware and software with VM/CMS when I worked there in the 90's.

It's taken since then to get that on the PC.

I've been playing with VM/370 and MVS 3,8j on Hercules for some time, but I haven't figured that out yet. The concepts are so alien for a Unix person I may have gone over the instructions a couple times, without recognizing them as such.

Try moshix YouTube. He is good. Not beginner. At least you know what we are after.

Btw still think ispf is a great editor. Slimv vim with linux/macOS is better as lisp is better.

Cobol and 370 assembler is so 1960s. Both are 60s technology. And in fact car and cdr from ibm mainframe, not this arch?

But slime and ispf make some bearable.

Agree on ISPF being a great editor. It was trivial for new users to pick up, but at the same time had a rich feature set.

My favorite part was its support for folds, or what it called "excluded" lines. You could issue an initial command that excluded lines you wanted to ignore, and then issue subsequent commands to operate on lines not excluded, or "NX". Very nice. I occasionally wish I had ISPF while I'm in the middle of a Vim session.

The most fun thing in VM/CMS is REXX. It's an awesome language invented by Mike Colishaw with the express goal of being easy to program above all other considerations. Its PARSE instruction is one of the most powerful things I've ever seen in any language.

REXX was so great it became the standard scripting language for all IBM system products and was incorporated into the OS command line and the text editor, XEDIT. This meant you could have one language that ran commands and programs in any other language, could do anything at the command line (like create machines, etc), and could edit and save text files. Think about that for a second. It was WAAAAY ahead of its time.

Sadly, REXX predated the internet and never had a browser-savvy release. A miscarriage of REXX and OOPS called Object Rexx was also unsuccessful.

But it was an amazing tool for its day!

the EBCDIC encoding/character sets, however i don't know if it's worth implementing... (well, all terminal emulators have that)

All IBM emulators, at least.

I've looked at it only briefly, but... From my (mostly Unix-ish) perspective z/OS looks a bit like as if MS-DOS have been continuously developed by a few hundred people since the eighties. There are some nice things, but the overall system architecture is somewhat... nonexistant.

1) The contracting scene in the UK is massive, that's where a lot of the higher paying UK tech jobs are. I suspect this skews the salary averages.

2) I'm in South Africa, I've recently been approached on linked-in to (quote) "Earn a US based salary working remotely from South Africa". So it seems some US recruiters are starting to look further afield.

It's not really a conspiracy, just the natural outcome of design optimization - any part that still works reliably at the end of the design lifespan is a candidate for cost cutting in the next iteration.

> any part that still works reliably at the end of the design lifespan is a candidate for cost cutting in the next iteration

This assumes a positive correlation between quality and price for parts. That isn't always the case. There's no reason a better part will be more expensive.

And again, you're ignoring my primary argument: "lifespan" is not measurable in calendar years for electronics. Some people I know use their laptops 360 hrs/mo, and some people (like me) only use them when traveling, ~20 hrs/mo.

After a calendar year of that, my laptop has only 240 hrs of life lost, while another laptop might have 4,000+ hrs of life lost.

Please provide a source about how a hardware manufacturer (without the aid of software) could plan for a component to fail after either 240 hrs of usage or 4,000 hrs of usage.

Tyres are breeding grounds for mosquitos, shredding them stops this so this law is having the intended effect.

https://blog.epa.gov/2015/08/26/improperly-stored-tires-lead...