Shrink to Fit Easing troublesome data communications
From "VS Workshop",  Access to Wang, July 1991
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

To my thinking, one of the limitations to common understanding among VS end users is the lack of a common, universal method of data communication. Aside from magnetic media, it is too hard to get files exchanged quickly using conventional dial-up means, and Wang message systems are too slow for casual communication. The result is a difficulty in moving public-domain software between users and no sense of community between VS users.

Much of this problem has to do with the fact that there have been no definitive Wang standards for data communications. The core Wang products provide good means for file transfer and message exchange, but typically only among users on a single network; the provisions for those not on the local network are poor.

This is not the case with other computing environments - particularly the PC and UNIX worlds. The command-oriented asynchronous nature of these systems lend themselves to casual browsing and file transfer. The PC bulletin boards are a good example: a cheap setup that provides one or more users access to program files on the system and some means of communications with other users.

Setting aside the issue of inter-system communication, file transfer alone would help spread good programs and good will among VS users. Providing a realistic means of file exchange among users could improve the VS environment and strengthen Wang's position in the marketplace. Looking to other computing environments as an example, I have a few suggestions for improving this situation.

File transfer approaches

Wang does provide file transfer approaches for VS users; some of these include:

• TTY, asynchronous subroutines: slow and generally unreliable, these products work best as terminal emulators, not file transfer systems. TTY is limited to plain text transfers; the asynch subroutines require you to write your own communications software. Neither supports modem command sets, autodialing, or any other modern features.

• Bisync file transfers: TCCOPY and VSCOPY work reasonably well for those that can afford to wait. A good choice for exchange with IBM shops and other archaic equipment; plagued by slow transfer rates and hefty equipment costs.

• Gateway products (SNA, All-In-One, etc.): usually work only within a closed network.

• 2110 terminal emulation with file transfer: a popular approach that can take advantage of PC standard protocols. Limited to 19,200 baud by current VS controllers; typically used for dial-up at 2400 baud.

Of these choices, the likeliest alternative for casual file exchange is the 2110 terminal emulation process. In this approach, the PC would dial into the target VS and use appropriate file transfer software to receive binary images of VS files. Once the desired files are received on the local PC, the communication session would end, with the files transferred to the local VS through a similar file transfer or by one of the several commercial products for exchange of VS and PC files over a coaxial connection. Let's explore how that might work in practice.

File compression

Since the speed of dial-up connections is limited, the size of the transferred files makes a large impact on the cost of the transfer. Typical VS program files are 50 blocks or more, requiring eight to ten minutes to transfer at 2400 baud. This can be a very expensive means of transferring files!

PC users solved part of this problem years ago by using file compression to reduce the size of files. Almost all bulletin boards use common archiving products to store files. These archived files reduce disk space requirements and allow related files to be grouped together into a single archive file so none will be misplaced. The space reduction is often dramatic - text files can be reduced to as little as 15% of their full size - and the transfer times are reduced correspondingly.

PC text files can also use the form of compression of substituting tabs for leading spaces, with tab stops set to every eight characters. ENTAB - a C program written by Peter Baker (based on examples in Software Toolworks by Kernighan and Plauger) performs this conversion for me, reducing the size of most text files by 10-30%. Like DMS compression on the VS, the presence of leading tabs is often invisible to native PC applications but may cause trouble in other environments. At least one VS file exchange tool - VSPC928 from Software Business Applications, Inc. - can convert tab markers set in this manner to leading spaces again.

Most VS files are already compressed. DMS compression used on the VS employs an algorithm that detects repeated characters and replaces them with character delimiters. In theory, binary images of these files should represent a very condensed form of the file's information; while true, PC archiving products use sophisticated approaches that can wring out much more space.

Unlike compressed VS files, archived PC files cannot be used directly by applications; they must first be decompressed. Most of the products available today for MS-DOS systems are proprietary, so the end user must have the specific product for the file type. Common products include ARC, LHarc, PKZIP, and ZOO.

Using PC archive products for VS files

To test the viability of using these archiving products, I examined several PC programs using binary images of VS files. The examples included straight text (COBOL source files), text with some non-ASCII information (Wang INFO files), and a mixture of DMS image files including object files, indexed files, and consecutive files (the entire 30 files required by the SMF utility, a VSAID). The archiving products I examined are LHarc by Haruyasu Yoshizaki and PKZIP from PKWARE, Inc. LHarc is free of cost if used in accordance with the licensing agreement; PKZIP is available as shareware from any number of PC software services and bulletin boards and carries a license fee of $25 or more, depending on use. C source code licenses are also available for PKZIP.

Figure 1 shows the file sizes and archiving time required for each of these two products using the sample file sets. The tests were performed on a 12 Mhz 286; faster PCs can improve on them somewhat. As shown, both produce similar reductions in file size, with PKZIP performing the archival process very quickly. LHarc's self-extracting option is very helpful: the recipient simply runs the file to perform the extract process. Both products produce files with no recognizable text, but PKZIP als offers encryption as additional security.

So how would this approach work in the VS world? Setting up would require a transfer of VS binary images to a PC, then file compression. The archived files would then be transferred back to the VS as images of PC files, ready to be picked up by dial-up users.

An obvious alternative to the convoluted approach described above is if the archival product were a native VS application and distributed free for the public good. Any readers care to give that a try?

For more information on PKzip, contact: PKWare, Inc., 9025 N. Deerwood Drive, Brown Deer, WI 53223 or call them at (414) 354-8699.

Figure 1: Comparison of the Performance of PC Archiving Products

Performance (Times in Seconds)	LHarc	PKZIP
Archive text files Archive VS INFO files Archive mixed DMS files	21 23 105	10 13 25
Unarchive text files Unarchive VS INFO files Unarchive mixed DMS files	5 8 26	3 4 11