root@caus-dp.UUCP (The Super User) (12/18/87)
I was approached by a man from Intellience Communication Services (I think thats the company) about a product that their company is reselling called 'blast'. Apparently it is a GREAT (:-) program that does EVERYTHING (Ever heard of these before?) Actually it was described to me as almost a uucp/kermit/terminal program replacement for the Xenix, Unix, MSDOS, BTOS, etc operating system inter- connectivity. It allows for file transfer between the various operating systems from a menuing system so your users don't have to learn unix to use the thing. My question is this, is there anyone out there who has a copy of this program that is working in a semi-rough enviroment and is working correctly? I'd like to hear the scoop about all these beer runs that you guys take anyway! Marcos Della
jmatrow@ncrwic.Wichita.NCR.COM (John Matrow) (12/21/87)
In article <335@caus-dp.UUCP> root@caus-dp.UUCP (The Super User) writes: >I was approached by a man from Intellience Communication Services (I think >thats the company) about a product that their company is reselling called >'blast'. Apparently it is a GREAT (:-) program that does EVERYTHING (Ever >heard of these before?) > >Actually it was described to me as almost a uucp/kermit/terminal program >replacement for the Xenix, Unix, MSDOS, BTOS, etc operating system inter- >connectivity. It allows for file transfer between the various operating >systems from a menuing system so your users don't have to learn unix to >use the thing. > BLAST is from Communications Research Group, 5615 Corporate Blvd, Baton Rouge, LA 70808, 1-800-24-BLAST. It stands for BLocked ASynchronous Transmission. It runs on many, many machines. Among the UNIX(tm) machines are: Altos, AT&T, Convergent Tech., Fortune, Gould, Harris, IBM (Xenix), Integrated Solutions, Intel, Masscomp, Molecular Poppy, NCR, ONYX, Pixel, Plexus, Pyramid, Sun, VAX, Zilog. We used it in a VAX-VMS, DG, NCR Tower, NCR PC environment. The new PC BLAST-II comes with VT100, VT52, D200, and TTY emulation. It also supports Xmodem checksum protocol. A comparison in May 13, 1985 COMPUTERWORLD between BLAST, TANGO (a.k.a. SYNCHRONY) and PC Works conducted at Yates Ventures showed that the three has similar throughput UNTIL the line got noisy. Then, only BLAST came through. Articles have also appeared in Jan. 18, 1984 COMPUTERWORLD ON COMMUNICA- TIONS; March 1984 HARDCOPY; October, 1985 HARDCOPY; Sept. 1986 DATA BASE MONTHLY. In addition to the file transfer and terminal emulation modes, it has a data capture mode which we have found useful at our facility. Also, files can be transferred in both directions simultaneously. Yes, all functions are through a menu. I also consider Chapter 5, Communications Concepts, of the BLAST Manual to be one of the best little tutorials on RS-232, flow control, etc. that I have ever come across. I found it useful in a heterogenous environment. -- John Matrow Automation Engineering, NCR E&M Wichita NCR:654-8851 <J.Matrow@Wichita.NCR.COM> (316)688-8851 <{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!j.matrow> <{sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!ncrwic!j.matrow>
michael@macom1.UUCP (John Michael Mullins) (12/22/87)
in article <335@caus-dp.UUCP>, root@caus-dp.UUCP (The Super User) says: > Xref: macom1 comp.dcom.modems:830 comp.misc:410 comp.protocols.misc:74 > Actually it was described to me as almost a uucp/kermit/terminal program > replacement for the Xenix, Unix, MSDOS, BTOS, etc operating system inter- They (Communications Research Corp.) make the claim that BLAST will run on _any_ system, (If it doesn't yet, they will make BLAST do so for some $$$). At the time I had dealings with them, BLAST was the only communications package that was certified 100% error free by the Bureau os Standards. I used the product to transfer files between an Intel 310 (Xenix 3.2) and an Amdhal (TSO?). Other boxes include Mac and CP/M. My relationship with Communications Research Corp. involved several Beta's and provided developement resources for the Intel 310. -- John Michael Mullins CENTEL Business Information Systems, Inc. 5515 Security Lane, Rockville, Maryland, 20852, (301) 984-3636 UUCP: michael@macom1.UUCP or decuac!macom1!michael
jack@cwi.nl (Jack Jansen) (12/22/87)
In article <2395@macom1.UUCP> michael@macom1.UUCP (John Michael Mullins) writes: >At the time I had dealings with them, BLAST was the only communications >package that was certified 100% error free by the Bureau os Standards. Well, well! 100% error free is quite good for a program that doesn't run infinitely long:-) (Or do I misinterpret it, and did the Bureau mean something else than 100% error free file transmission?) -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
syap@ur-tut.UUCP (James Fitzwilliam) (12/22/87)
Blast sounds really solid. How much is it? Who do I call? Is it available in a version for the Macintosh? What speeds does it support? Does it have a procedure language or function of some sort similar to the one in Red Ryder that allows you to create auto-login or auto-receive or other handy semi-intelligent keystroke-savers? Thanks in advance. James arpa: syap@tut.cc.rochester.edu uucp: rochester!ur-tut!syap ===================================================================
michael@macom1.UUCP (John Michael Mullins) (12/24/87)
in article <150@piring.cwi.nl>, jack@cwi.nl (Jack Jansen) says: > Well, well! 100% error free is quite good for a program that doesn't > run infinitely long:-) > > (Or do I misinterpret it, and did the Bureau mean something else > than 100% error free file transmission?) > -- I think the interpretation on the 100% error free is along the line of: After the file gets to it's destination, the source and the destination will be exactly the same, 100% of the time. The certification may be something like a therom, it is true until proven false. The protocal includes ways to handle loss of connection and other major transfer problems (not just resending of blocks due to line noise). Happy Holidays -- John Michael Mullins CENTEL Business Information Systems, Inc. 5515 Security Lane, Rockville, Maryland, 20852, (301) 984-3636 UUCP: michael@macom1.UUCP or decuac!macom1!michael
jack@cwi.nl (Jack Jansen) (12/24/87)
In article <2396@macom1.UUCP> michael@macom1.UUCP (John Michael Mullins) writes: >I think the interpretation on the 100% error free is along the line of: >After the file gets to it's destination, the source and the destination >will be exactly the same, 100% of the time. > Yes, it probably is, but unfortunately this is theoretically impossible. As a very simple example: assume the last packet is broken, and at the same time some random line noise happens to look like 'yes, thank you, it was delicious'. Adding another set of acknowledgements doesn't help: then I make the line noise do the same thing to those packets. It's a variation of the 2 army problem. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
mjr@osiris.UUCP (Marcus J. Ranum) (12/25/87)
In article <2396@macom1.UUCP>, michael@macom1.UUCP (John Michael Mullins) writes: > I think the interpretation on the 100% error free is along the line of: > After the file gets to it's destination, the source and the destination > will be exactly the same, 100% of the time. > :-) :-) :-) :-) :-) :-) I can think of lots of ways to do this: 1) truncate source. (both files are same size:0) 2) never complete the transaction. (after file gets there, it would arguably be 100% the same) (if someone waited to find out) Just what the world needs: another bogus testing criterion ! It's like all the PC dealers who sell "OS/2 compatible" systems.... what's it MEAN !? --mjr(); -- Once, there was NO fun... This was before MENU planning, FASHION statements or NAUTILUS equipment... Then, in 1985.. FUN was completely encoded in this tiny MICROCHIP... It contains 14,768 vaguely amusing SIT-COM pilots!!
tgm@xroads.UUCP (Sloan Tash) (12/25/87)
Maybe this was posted earlier, and you guys are trying other alternatives, but, if it was, I missed it. I know this works in Arizona, and probably other places, but dialing *70 (wait about 2 seconds), then the number you're calling will produce a busy-signal for any incoming callers to that line.. I hope this wasn't a repeat of a previous message. TGM ihnp4!mot!nud!xroads!tgm -- \ / C r o s s r o a d s C o m m u n i c a t i o n s \/ (602) 971-2240 /\ (602) 992-5007 300|1200 Baud 24 hrs/day / \ ihnp4!mot!nud!xroads!*
rfox@amelia.nas.nasa.gov (Richard Fox) (12/29/87)
In article <2395@macom1.UUCP> michael@macom1.UUCP (John Michael Mullins) writes: >in article <335@caus-dp.UUCP>, root@caus-dp.UUCP (The Super User) says: >They (Communications Research Corp.) make the claim that BLAST will run on >_any_ system, (If it doesn't yet, they will make BLAST do so for some $$$). >At the time I had dealings with them, BLAST was the only communications >package that was certified 100% error free by the Bureau os Standards. > >I used the product to transfer files between an Intel 310 (Xenix 3.2) and >an Amdhal (TSO?). Other boxes include Mac and CP/M. > >John Michael Mullins John, do you have any performance measurements that you could share with the net? Also can you tell us basically what kind of protocol is used? thanks richard fox rfox@ames-amelia.ARPA (415)694-4358
dncar@dcatla.UUCP (Chris A. Roussel) (01/01/88)
In article <59@amelia.nas.nasa.gov> rfox@amelia.nas.nasa.gov (Richard Fox) writes: > >John, > > do you have any performance measurements that you could share >with the net? Also can you tell us basically what kind of protocol is >used? > >thanks > richard fox > rfox@ames-amelia.ARPA > (415)694-4358 Glenn Smith and myself wrote the current version of the BLAST protocol when we were employed at Communication Research Group a few years ago. The earlier verssions of BLAST used a protocol which required 8-bit transparencyon circuits. We sold a lot of that product and we also learned a lot about how it should be done right. The current version of BLAST (I don't think they've changed it) uses a protocol that can tolerate 7-bit circuits, but will make use of all 8-bits for higher throughput if available. Only printable ASCII characters are used in packets ([A-Z][a-z][0-9]['"]) so that the packets themselves would be ignored by most system input facilities. Files are treated as a stream of binary bytes which are encoded into packets (similar to uuencode/decode). The protocol is also flow controllable by the usual XON/XOFF technique. It's a full-duplex protocol with a 16-packet maximum window. File transfer is supported in both directions simultaneously. Packet length defaults to around 100 bytes but can be made as large as a given implementation will allow. The protocol senses when the receiver can't keep up, and slow down packet transmission (important for going in to mini's). Selective-retransmission is used, that is, only those packets known to be received in error are retransmitted. This is much more efficient on noisy circuits than "go back N" but requires much more information in the ACK. Most of these features are negotiated to the lowest common denominator of both ends when the protocol starts up. Note that I am no longer an employee or a stockholder of CRG, but I still believe that it's a pretty neat product. -- Chris Roussel Digital Communications Associates 1000 Alderman Drive Alpharetta, Georgia 30201 (404)442-4722
jimp@cognos.uucp (Jim Patterson) (01/04/88)
In article <335@caus-dp.UUCP> root@caus-dp.UUCP (The Super User) writes: >I was approached by a man from Intellience Communication Services (I think >thats the company) about a product that their company is reselling called >'blast'. > >My question is this, is there anyone out there who has a copy of this >program that is working in a semi-rough enviroment and is working correctly? We've been using BLAST in an environment which has VAX/VMS, DG/AOS/VS and HP/3000 computers. Basically, the product does what it says it does (remote logon and reliable file transfer). However, it isn't without its problems. It certainly isn't a replacement for a decent LAN setup. I haven't been working with this software for about a year now, so please note that some things may have changed since then. The most difficult thing that I found with BLAST was in setting up a reliable configuration. BLAST has menus to define logon sequences to the various systems you need to access. You can enter control sequences to pause a second, wait for a given string, etc. However, you can't do anything that is truly intelligent, such as retransmit a prompt if the original prompt didn't trigger the right response. (In contrast, Reflection on the IBM PC does allow this, and so is considerably more powerful in practice). Getting a configuration that "works" is largely a process of trial and error, and even then varying loads on the systems or a system upgrade can easily confuse things enough that your configuration will fail to work. We were able to get assistance in setting up configurations and other problems from the vendor, so support for BLAST seems to be reasonable. (They weren't able to solve all of our problems, though). We've gotten BLAST to work reasonably well from the VAX/VMS side to both of the other systems. We have been less successful in getting BLAST to operate from the DG system (though we can still move files back and forth, as long as we move them FROM the VAX system). I think we've had similar problems on the HP/3000. Also, we found that the VAX batch file transfer option didn't work, but that might be fixed by now. I haven't had any experience with BLAST on the PC or other systems. We found that other products like Reflection did the job for PC communications for less cost. Something else that you should know about is that BLAST is a menu-driven product which supports a limited repertoire of terminals. If you have a VT100 terminal or compatible, you're okay. With other terminals you may be less fortunate. In summary, I think that BLAST is a reasonable product for small file transfer applications, and does support a wide range of systems. It isn't appropriate, though, for large scale computer communications for several reasons: the inherent bandwidth limitation of RS232 communications, the fallability of establishing connections, and problems (possibly fixed by now) with batch operations. -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4