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