>Just of out of curiosity, does the new PDUTIL support XXencoding (for
>users behind mistranslating gateways and blessed with XXdecoders)?
>I would check for myself but the path from RICEVM1 to RPIECS is down
>at the moment.
>
>Mark R. Williamson, Rice U., Houston TX; [log in to unmask] or @RICEVM1
 
The PDUTIL module supports XXencoding, but the feature is not supported by
LISTSERV as a valid file-format option.
 
Actually, PDUTIL has several options that you may find useful though they
may not be relavent to LISTSERV.  (PDUTIL was written independently of
LISTSERV and its uuencoding support; it handles the encoding/translation
functions supported by the public-domain/shareware software server in
operation at RPIECS and NDSUVM1.  Ergo the P.D. in PDUTIL.)  It supports:
 
    UUencoding
    UUencoding, older format that uses blanks and an extra character
                appended to each line to protect from blank trimming.
                (The "M-guard" method; "M" is the appended character.)
    UUencoding of EBCDIC files.  They get translated to ASCII with
                cr+lf inserted at record boundaries.  Both the new and
                M-guard formats are available.
    XXencoding, with and without translation to ASCII.
    Translation to EBCDIC from ASCII with (limited) carriage control
                interpretation.
 
Since I never really planned it as an end-user program, I have no
documentation written for it other than the program comments and code.
However, here is a brief summary of the command syntax:
 
    PDUTIL  <function>  <inputfile>  <outputfile>
 
<function> may be any of the following:
 
    UUENCODE  -- standard uuencoding.
    UUEASCII  -- uuencoding, but translate input to ASCII first.
    UUEMCODE  -- old-style uuencoding.
    UUEMSCII  -- .. with translation.
    XXENCODE  -- standard xxencoding.
    XXEASCII  -- .. with translation.
    EBCDICxx  -- Translate ASCII to EBCDIC.  "xx" specifies maximum
                 output record length.  The only valid choices are:
                    32 -- 132-byte records.
                    80 -- 80-byte records.
                    24 -- 1024-byte records.
                    96 -- 4096-byte records.
                 (If this function is really important to you, you'd
                 probably be happier with the translation abilities of
                 ARCUTIL.  It does tab expansion, can generate ASA
                 carriage control, and supports more arbitrary output
                 record lengths.)
 
Both in uuencoding and xxencoding, the first significant record of the output
file contains the filename of the original.  With source update LSV01 applied,
the PDUTIL command line input filename is used.  Without the update, the output
filename is used.  (This seemingly strange behavior is needed by my software
server:  Files are not stored under the "real" names.)  As distributed, the
PDUTIL MODULE includes update LSV01.
 
/JSFisher