NOTE: The difax mailing list is no longer active. The list archives are made available for historical reasons.
CRD/SIO and Difax/Unisys, A Progress Report
Several people have asked me to report on what we've experienced so far with
the Unisys version of difax. The answer is, not much.
to get the contract through our legal office and even more prodding to get the legal
beagles at Unisys to let go of it, but it finally happened. The original contract was
for five (?) years and we had to get all of our products from Unisys. We demurred and
they relented (which may have been what got their beagles to barking). The final
contract is for two years and we have to get any products from Unisys that they can
provide AT LESS COST than anyone else. A "do-able" deal.
The major systemic drawback (or "positive feature", depending on your prejudices) is that
the Unisys difax system is totally passive. It's just an ftp site where we go to get what we want.
The (possible) positive aspect is that you are not inundated with products you don't want.
Unfortunately, I've been told that we (Scripps) want "everything".
It should be relatively easy to write a cron script to go out once every
one/two/three hour(s) and get whatever you want (or everything) since you last
ran the script, since the date/time of file creation is part of the file name.
Well, easy for a unix guru, which I'm not. I'm told that Yale has already
implemented such a system and I intend to e-mail a shameless request to them
for their help.
Another drawback for Scripps is that the files we get come up as "white on
black" in our version of xv. I don't know if this is something I'm doing wrong, a
fluke in our system (ultrix), or bad programming on Unisys part. Does anybody know? If
anyone wants to see how they look on their workstation, see below.
It's not much of a problem to reverse the video using xv, just time consuming. The
images are made "just as they come off of the circuit", which means that most
of them are upside down or side-ways. Again, not a serious problem, just time consuming.
I used xv3 to make postscript files for our DEC LPS20 line printer (high speed
laser) with the output sized to 11x17 inch paper. They look wonderful. SO
MUCH NICER than the Okidata product, the old wet paper product, or (for those
of you even older still) the incredibly poor carbon paper product. I've placed
two of the larger products (North American [217.gif] and North Pacific Ocean
[165.gif] surface analyses) on our anonymous ftp server. The postscript files
for those two products are also there (postscript.tar.Z).
I would appreciate comments from anyone who tries out these products. Is there
a better way to look at them than xv? Do they come up on your screen as white
on black (Unisys' problem) or are they black on white (Scripps problem)?.
To get to our anonymous ftp server:
WWW = http://meteora.ucsd.edu/weather.html
ftp = aeolus.ucsd.edu
The directory: weather/special/unisys.
These are two of the largest maps coming across the difax circuit. The black & white gif files are approximately
a half meg in size. The output postscript files are around 1.3 megs and print in about two minutes on our LPS20.
Caution! If you use xv to create your postscript files, be sure to create the files at their "normal" size
and dithered B&W. I tried grey scaling them and the 1.3 MB postscript files grew to 31 MB files and took an hour
to print on our LPS20. If you don't "save" them at "normal" resolution, xv writes them out at
screen resolution.
Unisys runs this system from an "older, slower" computer across a 56kb bottle-necked
line. I've seen transfer rates running from as low as 0.45 Kbytes/s to as high as 5.8 Kbytes/s.
Tony Lombardi (Unisys) states they are going to move their operation to a faster computer
"soon" and are trying to get a T1 line. This, of couirse, depends on the number of
customers they get.
I anyone has any comments/questions, please feel free.
Larry
difax archives: