>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