>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