On 2017 Mar 03 22:40:44, you wrote to Janis Kracht:
A reminder to ALL FDN Coordinators that you should ONLY be sending out
8X3 filenames!
I know I'm still pretty new to the Filegate crowd, but I am most
curious as to why we are still sticking to the 8x3 filenames. Just
about every software out there, and computers that are modern, use
longer filenames.
I can understand 8x3 for systems that are still running legacy
software. But even some of the legacy software can do long filenames.
as previously noted, lowest common denominator... that because there's not yet any way to carry one file with both naming formats and have it recognized by all involved software... years back there were some ideas tossed out there but nothing was really done to see if they worked as desired so nothing was done to
document them...
one idea was to transmit the files with 8.3 and let the receiving mailer decide
whether to use the 8.3 or the LFN on saving it when it has been received... how
would the mailer know if it had this option? the mailers would have to be smarter than they currently are... more like a dynamic mailer that reads the netmail and packs it itself on the fly depending on how the schedules qualify mail for sending... the mailer protocol would either need to be changed such that there's two filenames sent for the one file or the mailer would need to learn how to read and parse TIC files... we won't even touch on the OS generated 8.3 names of which there's several formulas to generate and none match the others' results...
there was a time when mailers transmitted the data files in whatever order they
wanted but that lead to TIC files arriving before the actual file being distributed... if the connection were broken before the file the TIC described was transmitted the TIC processor would complain about the file missing and set
the TIC aside... depending on the installation, it may or may not be processed later... then there's the problem with the file possibly being updated and changed before the next connection between the systems... we see this now with some files in a few areas that are apparently updated multiple times a day but tossing schedules or connections may get in the way and cause one's "TICBAD" area to accumulate said files...
then there's the current documentation on TIC files which was done by the FTSC... it may not be totally accurate since it was written by looking at the available TIC files' contents... that along with some probing and testing to see what broke and what worked instead of getting the necessary information from the TIC processors' documentation... oh wait... the TIC processors were written in a time before today's openness in software... i have the original allfix and the docs, while 350k in plain text, lists 14 TIC file verbs... the descriptions of those verbs, leave a bit to be desired... EG: are there supposed to be multiple DESC lines? is there a limit on the number of them or their length? same questions for LDESC... on the CRC, which formula is the proper one to use? the REPLACES verb? now that opens a can'o'worms with possibilities... the MAGIC verb? does anyone really distribute their files with
a defined MAGIC name to be used everywhere? what happens if it conflicts with a
system's existing setup?
that's just a few things to think about... file distribution isn't quite as easy and simple as echomail distribution... heck, i've lost entire directories of historic files because i forgot and didn't realize that when those areas stopped being distributed the TIC processor was still maintaining them and removing files older than XX days... that's a good idea, in and of itself, but can be quite destructive and painful in some cases...
)\/(ark
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... You are standing in the way of my plan for total world domination.
---
* Origin: (1:3634/12.73)