INFO/BOOKS/FAQ
Try my new Books page!
|
|
Wang VS INFO/BOOKS/FAQ
|
Try my new Books page!
|
Quick links within this page
In addition to the information presented below about the New VS, there is now a special FAQ page dedicated just to the New VS:
If you have questions not answered by the new New VS FAQ, please contact us so we may improve the FAQ.There is a New VS, available from TransVirtual Systems. The New VS utilizes Dell and IBM x86 and x64 systems to provide a seamless upgrade path from legacy Wang VS systems. 100% binary compatibility means there is no more need for VS conversions and no need to make difficult choices involving giving up valuable VS features.
 Dell PowerEdge 2850 (now also Dell 29x0, 29x0 III and 710 series) | |
| |
 Front view w/out bezel |
 Rear view |
The New VS:
Realistic "futures." The New VS will have:
The New VS has very important implications for Wang VS sites:
Even without counting on any new features not yet available, the New VS immediately provides you with new capabilities simply because of its virtualization technology:
If you are still operating one or more legacy VS systems, you're in luck. You can now upgrade to the New VS and continue forward without changing a single line of code or losing a single VS feature.
If you have already converted to some non-VS platform, you might be out of luck:
In the general vicinity of what it would cost you to upgrade to a new legacy VS. If you have ever priced a conversion of your VS applications to some non-VS platform, the New VS will cost less than a conversion, making it pretty much of a no-brainer. It will also save you the calendar time, workarounds, incompatibilities, data conversions, risks and other headaches of a conversion. The New VS is a VS, just in new hardware.
If your next question is, "Why does it cost so much if it runs on Linux on affordable servers?" then consider that the VS and the New VS are mainframe-class systems. Many people had to do a lot of work to bring you the VS OS and system software, and a lot of work had to be done to virtualize the VS to make it viable into the future. The New VS runs on Intel and IBM x86 and x64 server hardware, but it is not a mere server. The New VS brings you the 32-year repertoire of mainframe-class VS software running seamlessly and has been tested to more than 500 connected Lightspeed NVS users.
You can also get an IBM S/390 (now the "zSeries) in a very small package, but don't expect to get that for the price of a PC server, either.
The traditional way was to use a Wang 2228N or 2229N Synchronous Null Modem and two 25-pin RS-232 cables. The Synchronous Null Modems have been very difficult to find in recent years, and unless the VS TC ports are far enough from each other to use up all of the standard lengths of 25-pin RS-232 cables it usually results in a mess of extra, coiled cable. If the ports are very close to each other, as in the case of shoulder-to-shoulder VS5000/6000, it's awful.
Now there is a much simpler solution. It uses a pair of specially wired DB25 adapters and a length of standard 10BaseT or better network patch cable. Since network cables are easy to make up yourself, you can make yours just the right length with nothing extra to get in the way or use a standard cable from the computer store.
Here is the picture page: 2228NT Synchronous Null Modem by Thomas Junker.
NOTE: The New VS now supports WSN over TCP/IP for networking New VS systems, and at speeds far higher than traditional WSN. The New VS can also interoperate with legacy VS systems by means of WSN over traditional async and synchronous TC links.
The New VS changes everything. It is a direct upgrade path from legacy VS systems, with no conversions, no program changes, and no loss of VS features. Without question the New VS is the only truly viable alternative to the legacy VS.
If you own and manage your own applications in COBOL, you can move to unix using COBOL ReSource. If your applications are in VS Assembler, there is a VS Binary Compatibility Layer (VSBCL) option for COBOL ReSource. If your applications are in PACE, there is work underway to be able to run PACE on VSBCL.
COBOL ReSource provides a VS look-and-feel environment for two unix platforms: IBM RS/6000 running AIX and HP-9000 running HP/UX. It is the only such product based on actual Wang utility and file system source code ported from the VS.
This is included for the benefit of non-VS management and senior technical staff who suddenly find themselves responsible for a Wang VS.
The most important concept is that all VS models spanning 25 years essentially run the same software. There's nothing special or magical about any VS model. Some are older, some are newer, some are faster, some are slower, but they all run the same application software, interchangeably. The few exceptions to this rule are so old as to be irrelevant.
The hardware has evolved over the past 25 years and the VS family tree has sprouted several branches that ultimately dead-ended, leaving just two branches that are current today. The main effect of different branches, though, is just in the internal architecture. The most visible aspect is in the packaging and the interoperability of CPU, memory, I/O and other boards. Little or no hardware inside the VS cabinet of dead models can be carried forward to the surviving models, although almost all external peripherals are completely independent of VS model.
Today there are two lines of VS that are viable: the large-format VS and the small-format VS. The large VS is descended from the VS300 of 1985 and runs through cabinets designed in the 1990s and CPU boards as recent as 1999. The small VS is descended from the VS5000 of 1988 and runs through two generations of cabinets in two sizes each, and CPU boards as recent as 2000. Within each of these two surviving lines, all I/O boards are interchangeable and in most cases CPUs are as well. The latest CPU boards of each line can be fitted to the oldest system cabinets of their respective line.
| Central Processor Generation | State | VS Models |
| CP3 | DEAD | VS50, 60, 80 |
| CP4 | DEAD | VS85, 90, 100 |
| CP5 | DEAD | VS5, 15, 25, 45 |
| CP7 | DEAD | VS6, 6E, 65, 75E |
| CP8 | ALIVE – Large format | VS150, 300, 7000, 8000 |
| CP9 | ALIVE – Large format | VS5000 |
| CP9E | ALIVE – Small format | VS6000 |
| CP10 | ALIVE – Large format | VS10000 |
| CP11 | ALIVE – Small format | VS6230, 6230T |
| CP12 | ALIVE – Large format | VS7000, 8000, 9000 |
| CP14 | ALIVE – large format | VS12000 |
| CP15 | ALIVE – small format | VS6760, 6780 |
| CP16 | ALIVE – Large format | VS16000 |
| CP18 | ALIVE – Large format | VS18000 |
| NEW VS Replaces all prior CP Types Can run as: CP8, 10, 12, 14, 16, 18 | CURRENT – Rackmount and tower formats Completely new hardware, fully modern, fully maintainable | VS22000 |
Note: Models shown ending in "00" are actually families of models. The last two digits usually indicate the CPU option within the family. In some families the third digit from the right indicates a cabinet variant.
Of the models that are technically alive, several have been withdrawn from support. In particular, the VS10000, 7000 and 12000 are no longer supported for hardware maintenance, but may still be in use in the field and can still interchange I/O and memory boards with most other large format models. In general the models that are still alive but not current are not cost effective to operate. They have effectively been replaced by newer, faster models.
The VS10000 and the VS12550 are special CPUs that can only be accommodated in the 5' tall VS10000 cabinet. The I/O boards for that cabinet, however, are the same as the rest of the large-format group.
The VS6700, 16000 and 18000 exist only as CPU board upgrades. They have no unique cabinets of their own. If ordered as new machines they are delivered in the latest cabinets of their format – the VS6010 cabinet for the VS6700 CPU and the VS9000 cabinet for the VS16000 or 18000.
The 1999 VS18000 CPU can be installed in the 1985 VS300 system cabinet.
There may be no other line of systems in the history of computers that has maintained a 25-year run of software compatibility and an 18-year run of hardware compatibility.
The 2005 New VS, which is officially the "VS22000" family, continues VS software compatibility unbroken into the future, essentially without limit.
You no longer have to get your application data out of the VS. You can now upgrade to the New VS, retain all the good features that have made the VS such a solid system for 32 years, and go forward with modern hardware and high performance devices. Everything you presently do on the VS will become more efficient and more reliable, and you will gain new capabilities going forward, including substantial data interoperability that was never possible in the legacy VS.
In small quantities you can use Lightspeed File Exchange or VS TCP/IP. Expect transfer rates no greater than about 30 Kbytes/sec for WLOC Lightspeed, about 70 KB/sec for SCSI Lightspeed, and 40-100 KB/sec for VS FTP, depending on CPU speed.
Lightspeed and FTP transfer rates in the New VS are substantially higher than in legacy systems, due to the elimination of the gateway PC and direct communication between the LS desktop client and the New VS by TCP/IP.On the New VS, Lightspeed File Exchange can transfer data at up to 175 KB/sec due to elimination of the WLOC or SCSI LS gateway PC.
In large quantities or for frequent repetition, the only good way we know of is disk-to-disk transfer to a New VS or COBOL ReSource platform. We are the only people we know of who can do this. Expect transfer rates of at least 500 KB/sec. All other forms of intersystem VS data transfer are slower than disk-to-disk. FTP using VS TCP/IP may run 40-70 KB/sec on mid-range systems and 100 KB/sec on high-end systems. All forms of tape are disappointingly slow with the possible exception of the DLT 8000 tape technology available for the VS. The New VS has a Virtual Tape feature that redirects VS tape operations to/from Linux files. Not only does this eliminate physical tapes and tape errors, it is very much faster than physical tape. Virtual Tape functions for all VS tape operations, including all the standard backup/restore packages, and TAPECOPY.
You can. Getronics (Wang) has offered 9 and 16 GB disk drives for some time now, and more recently, a 34.3 GB disk drive. If you have not upgraded your VS OS to 7.53 or 7.54, that is probably a good starting point. Contact your VS sales rep about OS upgrade and large SCSI disk capability.
The New VS handles all VS disk sizes in virtual VS storage, all the way up to the latest 34.3 GB size, and all but some very ancient Wang SCSI disk drives in direct-connect mode. In addition, the New VS supports Volume Sets, allowing individual volumes to be aggregated to form larger volumes. VS disks in the New VS are virtual, residing as files in RAID.
Because the VS SCSI microcode has traditionally expected a special Wang "thumbprint" in the microcode of the SCSI devices it will accept.
The New VS does not have any such restriction on the SCSI devices it supports.
In the past the only way to connect non-Wang SCSI devices was to use the SEEK SCSI IOC, which looked to the VS like an SMD controller. To operate with the traditional Wang SCSI IOC, it used to be that drives had to have a Wang "thumbprint" in their firmware.
Recently, Getronics released new SCSI microcode referred to as "generic." Although not truly generic, it supports Seagate drives of 9 GB or larger and certain RAID devices. I'm told that this new "generic" microcode is standard and that if you have Getronics maintenance you can get it as a matter of course. Reports from the field suggest that it is not a good idea to mix brands and types of disk drive with the new microcode.
Wang implemented the "thumbprint" identification of certified drives in order to prevent the possibly endless complications of customers using just any drives on a VS. The fact is, though, that there are many high quality drives on the market and there are other computer systems that seem able to use them without difficulty. Still, you will find that most large computer manufacturers offer their own certified drives with their own firmware. Some non-Wang systems reject "foreign" drives; some don't. I favor opening the presently "closed" VS SCSI door and letting customers make informed decisions about the kinds of drives they wish to connect to their VS systems.
SEEK is effectively out of the VS market as far as I know. If you have failing SEEK SCSI subsystems, consider replacing them with Wang/Getronics SCSI.
If you're using the SEEK disk/tape IOC, you're on borrowed time. You really should consider upgrading your whole system to the New VS for stability, maintainability, future viability and peace of mind.
In short, WSN can be tunneled through IP networks. But a better solution is to replace legacy VS systems with New VS systems. The New VS even interoperates with legacy VS systems via WSN, and will also communicate with other New VS systems using WSN over direct TCP/IP with no external, router-based tunneling. WSN-over-IP between New VS systems is much faster than legacy WSN.
This issue has been on my mind for a long time, but only recently have I come across information that points to a solution.
WSN is superb networking for VS systems. The only real problem is the requirement to have dedicated lines, either dial-up or leased, either Point-to-Point or Multipoint, often running to several thousand US$ per month each. Obviously, in today's landscape of almost ubiquitous WANs and IP networks, it would be very nice to be able to plug the VS systems into the WAN that often runs side-by-side with the expensive WSN lines to the same remote locations. It seems that this may indeed be possible, and at very modest cost.
From Cisco:
Cisco's serial tunnel (STUN) implementation allows Synchronous Data Link Control (SDLC) devices and High-Level Data Link Control (HDLC) devices to connect to one another through a multiprotocol internetwork.
The basic STUN protocol is unconcerned with details of serial protocol addressing and is used when addressing is unimportant. Use this when your goal with STUN is to replace one or more sets of point-to-point (not multidrop) serial links by using a protocol other than SDLC.
It has since come to my attention that a client successfully tunnelled WSN over IP between two offices in Houston in the past, and that Getronics experimented with WSN over IP after repeated inquiries of mine and demonstrated that it works.
From the information that has come to light I think it fair to say that you may be able to tunnel WSN over IP if the network latency isn't too great for the message window used by WSN. WSN is HDLC. Cisco supports local handshaking in its SDLC form of STUN to short-circuit wide area network latencies. Whether that can be made to work with WSN HDLC I don't know.
I have a Cisco 2503 router and could support one side of a test of WSN over IP through real networks with real latencies, but so far I have not heard from anyone who has a current need to do WSN over IP.
The New VS will finally make TCP/IP fully usable in the VS context. Legacy VS TCP/IP over 802.3 has been usable but has not been as robust as most of would have liked. The New VS will make native Linux TCP/IP available to VS applications.
Earlier explanation of VS TCP/IP connectivity for legacy VS systems:
 |
Note: VS5000/6000 systems can avoid the use of a transceiver because their 802.3 IOCs have a BNC connector for Thin Ethernet in addition to the 15-pin DIX connector for an AUI drop cable. |
To run Wang TCP/IP in its present incarnation, the VS must have either a LAN IOC or a TC device capable of running X.25. VS TCP/IP can utilize both LAN and serial X.25 at the same time, by the way. I have experience only with the LAN IOC, so I will describe only that connection here. It is also the case that most host computers in the Internet and in intranets that are not on dial-up links are LAN-connected.
Large-cabinet VS models (VS300/7000/8000/9000/10000/12000/16000/18000) use:
Small-cabinet VS models (VS5000/6000/6230/6230T/6760/6780) use:
To make matters a bit more confusing the "A" and "B" are not different hardware, but there are two different IOCs -- the old and the new. Both IOCs are configured on the board for Thick or Thin Ethernet. The old is configured by changing a daughterboard, while the new is configured by moving a jumper block. The "A" or "B" configured in GENEDIT must match the board configuration, but it doesn't matter whether the old or the new board is used.
In either case you will generally need something to make the transition from Thick or Thin Ethernet to 10BaseT twisted pair or a hub or router that has a 15-pin Thick port or a BNC Thin port. In many cases the easiest transition is made to 10BaseT using a transceiver and then into a standard RJ45 port on a hub or router.
Transceivers are common LAN accessories. The types required to interface the 802.3 15-pin Thick standard or the BNC Thin ethernet standard to commonly used 10BaseT are available from half a dozen manufacturers, cost between $30 and $150, and are cigarette-pack size. The transceiver then connects to everyday hubs or routers in the usual way.
Small VS cabinet LAN IOCs may be directly connected to Thin ethernet segments. This is particularly convenient when testing or developing, using a direct connection to a PC equipped with a Network Interface Card that also presents a Thin ethernet BNC connector. In that case one only needs a length of Thin ethernet coax, two "T" connectors, and two terminators, all standard LAN components.
Both large and small cabinet VS LAN IOCs can carry WSN traffic in addition to 802.3. If you have several VS systems interconnected with WSN links, the 802.3 LAN interconnect can also be defined in WSNEDIT as another transport (data link) for WSN, providing backup to 56/64kbps serial and CIU links and additional bandwidth.
Software required is VS TCP/IP, and WSN is a prerequisite. The optional VS TCP/IP Services include ftp, SMTP, echo and Inbound Telnet servers, and outbound telnet for native Wang terminals.
EVERYTHING CHANGED IN 2005. The VS has been re-launched on modern server hardware with 100% binary compatibility with existing VS software, as the New VS. The New VS is virtual, running on Dell and IBM servers, free of proprietary Wang hardware. It is the official new generation of Wang VS systems.
Previous explanation from 1995, 1997 and 2003:
In the strict sense of being functional and maintainable, yes, without question, with the possible exception of certain older models. The availability of very inexpensive used and reconditioned equipment in recent years has further made it a very difficult platform to leave behind without clear and compelling reasons for doing so.
21 Jun 03: The VS is still functional and, theoretically, maintainable, but with the severe decline of the VS population more and more geographical areas are dropping below the level at which it is feasible for Getronics to maintain a service presence. I am receiving increasing reports from around the world of declining or nonexistent VS maintenance. Even in "hot spots" where clusters of VS sites still exist, I have reports of maintenance difficulties and of the local Getronics service unit going into the open market to buy needed parts.
In the larger sense of where the computer industry is going, the VS must be considered a closed, proprietary system running a proprietary OS -- things that have become very much out of "fashion" lately, except...
The IBM AS/400 is *also* a closed, proprietary system running a proprietary OS. So what's the difference? Marketing. Many of the same companies that rushed to move away from the VS because it didn't have the air of "open systems" about it have embraced the AS/400, which is about as peculiarly proprietary as you can get and available from only one vendor on the planet. Go figure.
If you don't already have a VS, you're probably not going to rush out and buy one, corporate politics and Information Systems fashion trends being what they are today.
On the other hand, if you already have a VS, there's no reason to panic unless you are in an area where there is no VS maintenance presence. Wang (now Getronics) is still there with one of the largest manufacturer-independent field service organizations in the world (thanks to Wang's acquisition of France's Groupe Bull and Getronics' later acquisition of Wang Global). The VS is no longer prominent on their radar screen, though, and there are very real practical obstacles to the continuing availability of VS service in areas where very few VS customers still exist.
UPDATE: AS OF AUGUST, 2008, GETRONICS IS NO LONGER IN THE BUSINESS OF MAINTAINING VS SYSTEMS. WITH THE JULY, 2008 SALE OF GETRONICS NORTH AMERICA TO COMPUCOM, GETRONICS ENTITIES WORLDWIDE NO LONGER HAVE ACCESS TO PARTS OR SOFTWARE. ANY MAINTENANCE THEY CLAIM TO OFFER IS BASED STRICTLY ON THEIR OWN AGING SPARE PARTS, AND THEY ARE UNABLE TO PROVIDE VS SOFTWARE UPDATES.The fastest VS CPU was released in 1999: the VS18000 family. The newest VS CPU was released in 2000: the VS6700 family. An upgrade from an otherwise up to date VS300/7000/8000/9000/12000/16000 or VS6000 is a one-hour board upgrade. The VS18000 is a significant step up from the VS16000 and the VS6700 is a big step up from the VS6230T. UPDATE: THE NEW VS IS A FAST AND EASY UPGRADE FROM ANY LEGACY VS.
It is unlikely that there will ever be another new VS CPU. (This statement is no longer valid. The New VS is a family of new VS CPUs -- virtual CPUs -- with performance up to three times the fastest legacy VS ever made.)
If you want to get the most out of an installed VS, check to see if you might benefit by upgrading it inexpensively to a more recent model, and look into TCP/IP connectivity and other tools that can integrate the VS with the emerging standards for distributed processing. But the time is at hand when you must plan for life after the VS. (This statement is no longer valid. Your best option is now to upgrade to the New VS.)
Yes. PACE database files can be accessed from programs written in just about any supported VS language.
I've never used the Wang C compiler. I suspect few outside of Wang have. Large parts of PACE (or was it the never-released PACE 3.0?) were rumored to have been written in C, using host language interfaces never to my knowledge released to the user community.First, there is nothing all that special about PACE-created databases. Unlike Oracle (just to name one), PACE makes full use of the native indexed file system and OS-integrated rollback recovery instead of burying everything inside a monster file carved out of the OS-managed disk space. PACE database tables reside in standard VS indexed files, either regular Indexed or the newer Indexed-Plus. The files can be read, updated and written from any VS language that provides access to indexed files. Wang COBOL provides support for transaction boundary demarcation and multilevel transaction commit and rollback. It's very slick.
Sometimes the PACE tables are defined to share a file, called a Multi Table File. All this means is that a Table Identifier Field has been defined in the table layouts -- an old COBOL trick for stuffing multiple record formats into a single file. Any tables that use alternate indexes in such a case must use different ones to avoid indexing each other's records on portions of the record that may not be there or may be unrelated to the other tables' fields. As long as you have or can figure out the table layouts you can treat them as standard files from any standard language.
The preferred form of program access to PACE tables is through COBOL HLI (Host Language Interface). This is similar to Oracle's C and COBOL extensions, in which a preprocessor expands lines of meta code into whatever it takes to interface to the database system's runtime modules. If the database uses view tables, or depends more than trivially on referential integrity, you must do this or you will go nuts trying to replicate the assembly of virtual table fields and other things that together produce complete view table records at run time.
If the database uses few or no views, and if there is little or no referential integrity in place OR you are only reading the data, you can use standalone COBOL or BASIC (or whatever) programs, since the base tables are in the files, laid out exactly as shown in the Data Dictionary when you view the storage characteristics. You're better off using PACE HLI, though. It's far easier.
PACE HLI is generally always compiled and linked under PACE control. You edit, compile and, if necessary (for standalone HLI), link, from the PACE Manager. It's really quite good, if you don't mind static queries that can refer to variables but whose structure must be set at compile time, and if you don't mind a restricted subset of SQL.
HLI is concise, effective, and templates are either available in the system or, in the case of table, view and Application Builder exit subroutines, constructed for you at the push of a button.