>Well, does  the new PDUTIL support  regular MODULE files (by  that I mean
>that you can not  only encode it but also decode it  into a usable MODULE
>file). If not, I have to concur with  you that F=UUE is not a very useful
>option (I implemented it because many people were asking for it).
 
No, and there is no way it can.  The uuencoding scheme assumes files are
structureless blobs with absolutely no basic characteristics that any
intelligent operating system would provide, like record length and format.
Since CMS modules are truly recfm=V, and since uuencoding loses all trace of
where the record boundaries might have been, there is now way to recover the
original module.
 
However, for those cases where the recfm is fixed and the lrecl known (for
example, any card-image data file) the person "blessed" with an encoded
version of such a file can reconstruct the original with a grungy little
program that breaks the data back into records at the appropriate boundaries.
 
 
Maybe "the right thing to do" in LISTSERV is to offer some sort of compound
option for the file format.  For example, if the target system is VM/CMS then
it might be appropriate to capture the output from any of DMSDDL, CARD,
VMARC, or DISK-DUMP and uuencode that.  Each of those four programs encode
both file structure and data into card-images, so the careful person could
decode, shuffle into card-images, and then DMSDDL, CARD, VMARC, or DISK-LOAD
to recover the original file.  I do not know what would be the appropriate
combination for non-CMS systems, maybe something LPUN-like followed by UUE, but
since you'd be dealing mostly with plain text data anyway for non-CMS systems,
the UUE option is probably silly.
 
 
/JSFisher