We have a couple of programs that run headless on servers, processing little text files generated by our system and POS and doing lots of useful things like generating emails and web pages, printing pericetags etc.

The core of each program is an endless loop that does:

Code:
direct_input channel 2 ("dir:"+sSomePath+"/*.*)
While (not(seqeof))
    readln channel 2 sBuffer

<and then do lots of things based on filename, fileext and content>

<each of those things finishes by removing the file indicated by sBuffer into a Goodfile or Badfile folder
A version of this has run 24/7 for 20 or more years, except when stopped deliberately. The programs printing tags have to liaise with three or four diffeernt types of printer all of which want text files as input so the channel use gets complicated. So I decided to bring things up to date and get their seq channels the 'better' way, with seq_new_channel. I started with the easiest fix, bring the goodfile/badfile procedures up to date.

We didn't connect the two events but the program in question began to go unresponsive, and only process a file at a time, then need to be restarted.

Turns out seq_new_channel allocates channel 2 again, so when the goodfile/badfile procedures close channel 2 the main program loop stops reading filenames.

Shouldn't seq_new_channel realise channel 2 has been explicitly allocated and steer clear?