Subj : Filegate file releases.
To : Allen Prunty
From : mark lewis
Date : Sat Mar 04 2017 07:22 am
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!
AP> I know I'm still pretty new to the Filegate crowd, but I am most
AP> curious as to why we are still sticking to the 8x3 filenames. Just
AP> about every software out there, and computers that are modern, use
AP> longer filenames.
AP> I can understand 8x3 for systems that are still running legacy
AP> 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)
