HK>> Where lies the big problem with a convertion routine?
 HK>> As I can see, it is only a question of obtaining a
 HK>> pice of software and add a new line before the
 HK>> nodelist compiler in the .BAT or shellscript that
 HK>> handles nodelist compilations

 JB> You may also need to configure the mailer to look for a
 JB> expect a different filename to arrive in inbound
 JB> "nodelist"/"nodediff" are already taken and resusing
 JB> them could possibly cause headaches.

what does the mailer really care about what arrives in its inbound
directory? unless it in one of those all-in-one mailers, it shouldn't
matter one iota... my FD doesn't care, that's for sure... however, my .BAT
files do care...

 HK>> If the new list comes in a new file-echo and maybe
 HK>> with a new name there will be no confusion. The old
 HK>> software will not recognize it as a nodelist or
 HK>> nodediff until it has been converted. A list in the
 HK>> present format can be distributed in paralell during
 HK>> a reasonable time to make a smooth transition possible

 JB> And after old-style is no longer distributed the bossnode
 JB> can probably do the conversions for the last exoisting
 JB> nodes that can't run the conversion software...

exactly...

 JB> we need to pick a language for that conversion software,
 JB> I'd say perl would be a good choice because it's designed
 JB> for list munching and also is available on many platforms
 JB> and can be converted to C and compiled for those that
 JB> don't want to install perl to run the software.  (I don't
 JB> know perl well enough though. but C and Pascal are no
 JB> problem, C++ is a bit of a challenge)

the language that the conversion software is implemented in doesn't
matter... what does matter is adherence to the rules... the rules of the
new list and the rules of the old list... it is inevitable that a
conversion list will contain many PVT nodes as the info will not crossover
cleanly, if at all...

)\/(ark