JG> I hope the new OPUS is able to understand "dietifna" - also
 JG> known as ZEDZIP in Binkley.
No, DietIFNA and ZedZip are quite different gadgets.  DietIFNA is a WaZOO 
extension to FTS-1/FTS-7 using Telink or SEAlink (perhaps plus 'overdrive') 
protocols.  It's also referred to as 'fast FTS-0001' in FTS-0006 (which 
describes negotiation for all four WaZOO protocols, plus Janus).
ZedZip is the same as ZedZap, except that block sizes are limited to the 1K 
of the original Zmodem protocol that WaZOO/ZedZap was derived from.
 JG> Opus locks up every time it
 JG> calls a PCB front end that isn't configured to do zedzap!
 JG> (at least, 1.73 burps..)
There's been some discussion of this with respect to at least the Windows 
version of Platinum Express mailer, which does ZedZip but not ZedZap (for 
some bufferspace reason?) but which then failed to fall back to FTS-1 (or 
even DietIFNA), instead failing session with 'no common protocol' error.  
Naughty?
Opus appears not to recognise the ZED_ZIPPER FTS-6 YooHoo capability bit, but 
then the code mentions that it will use 1K Zmodem where WaZOO is indicated, 
if ZedZap is not.  As to what the actual problem is, or whose 'fault' it is, 
who knows?  Mel Pheasant may, he's done a fair bit of research on these 
matters for his own 'mailer mess' :)
From Opus (1.20, I think):
     Hello.capabilities   = (no_zapzed)? Y_DIETIFNA: Y_DIETIFNA|ZED_ZAPPER;
From a superficial look through this, and bits of the Binkley code, it might 
even be as simple as adding the ZED_ZIPPER bit to Opus' advertised 
capability, and a small amount of code to report the type used, as Opus 
appears to set the WaZOO blocksize down to 1K if ZED_ZAPPER isn't set already 
.. but I suppose it couldn't be that easy .. and I doubt there's any time to 
fiddle with 1.79.

Cheers, Ian
---
---------------