Wang Conversion Now Unnecessary
Straight Talk about Life after Wang
©2003-2005 by Thomas Junker ALL RIGHTS RESERVED
Page last updated: 
©2003-2005 by Thomas Junker ALL RIGHTS RESERVED
Page last updated:
You have a Wang VS. You're wondering how best to move your application(s) off the VS and onto a more modern, more flexible, more open platform. You probably fall into one of these categories (click on the one that applies):
I have been here for a long time and understand completely how and why we have a Wang VS
I am new, or inherited the VS, and don't know how or why it came to be here
I've heard about the New VS. Take me directly to the information about that.
|
OK. You already know that the VS was an excellent small or mid-range mainframe, was easy to operate and program, was a stellar data processing system, offered a wide range of I/O devices and networking, supported about a dozen languages, supported indexed files at the OS level, offered rollback recovery transaction processing, had an optional 4GL database system, ran up to four independent logon sessions per workstation, and supported Wang Word Processing.
You either have a very old system or a more or less up to date system. Click on the appropriate case:
|
|
The thing you should understand is that all your perceptions about how your system and applications perform are hopelessly out of date. It's like owning an ancient automobile and judging modern driving by the standard of your old car. Virtually everything you may presently consider to be a limitation of your old VS system can be addressed by upgrading it, moving the applications to a new platform, or replacing the applications.
You can substantially improve the performance and reliability of your Wang VS system by upgrading it to a newer, faster, more reliable model with newer peripheral devices. All your VS software would continue to run. Fortunately there is an exciting new product in the VS lineup that makes upgrading a more sensible option than ever. Click here if you have considered upgrading your VS.
On the other hand you can move your VS application(s) to another platform, but the ways of doing that are not clear, the risks of loss of functionality are mysterious, there are programmer, operator and user learning curve issues, and there is some risk of complete failure. Hmmm. What to do? Click here if you have considered migrating your VS application(s) to a new platform.
On the third hand you can just replace the VS applications with PC-type things you can either buy or cobble together yourselves. Click here if you have considered replacing your VS with a PC.
|
|
You may not know that there is a completely new VS now available...
To see the benefits of the New VS, click here.
(Or click you browser's BACK button to return)
|
|
OK. That's understandable. But everything you thought you knew about this has changed.
A new kind of VS is now available that will change everything you thought you knew about the VS. It uses standard PC server hardware, Linux, and runs the VS Operating System and all VS software. It is 100% binary compatible with the legacy VS.
The only real question is this: is your VS software worth saving?
Is it?
Yes, our software is worth saving
No, our software is not worth saving
|
|
If your VS software is worth saving, then you could upgrade to a better legacy model of VS or you could move your VS applications to a compatible platform and system.
An alternative to upgrade to another legacy VS is to move your application software and data files to a new type of compatible system that will understand them.
This is important:
If your VS software is worth saving, doesn't it make sense to preserve it in its present form, with procedures and data files also in the same form to which you are accustomed, and with the same user interface to which your users are accustomed? Doesn't it make sense to provide your programmers with all the same tools to which they are accustomed?
There are only two products that will allow you to move your VS applications and data to a newer, faster, more accessible platform without rewriting or converting your source code or having to convert data storage formats:
Learn more about COBOL ReSource
(Or click you browser's BACK button to return)
|
|
If your VS software is not worth saving, then upgrading your VS is probably not worth the effort.
An exception might be that you may need more performance now and don't really care what happens six months or a year from now.
It happens. On more than one occasion we've seen a VS customer buy or lease a new, large VS only months before phasing out their VS operations entirely. In this case you may wish to consider the New VS, which can run your VS applications with no need whatsoever for conversion of any kind.
If you choose another course you may need to extract data from the VS. We can help you do that.
(Click you browser's BACK button to return)
|
|
OK. Now for some really straight talk.
There are multiple firms out there who will promise to convert your VS application(s) to a new platform or provide tools with which you can do your own conversion. You may already have spoken with one or more of them. They fall into these categories:
Why conversion is a really, really bad idea
(Or click you browser's BACK button to return)
|
|
Unfortunately for the hit-and-run conversion firms, VS conversion is now completely unnecessary. But first let's look at how these companies work:
These are companies who offer to run your code through a converter, usually for a stated charge per line of source code, such as 25 cents. They do not come from a Wang VS background. They don't understand or care why you may wish to preserve the look and feel of the VS. They think you should retrain your staff and users to learn Unix. If pressed, they may tell you that actually getting your code to work after conversion is your problem. They may be vague about data file transfer. If you ask about Procedure Language and VSSUBS they may say something like, "Oh, yeah, we will give you some stuff to handle that until you get used to Unix."
These companies care about only one thing: your conversion dollars. They believe that you were stupid to have used a Wang VS and that the best thing in the world for you will be to relearn everything in the Unix context. Some of them even think your users should learn the unix command line. They have cobbled together something like a Procedure Interpreter and some VSSUBS merely as crutches to help you along until you learn how to do things "the right way." Their converter is static and they have no long-term development or maintenance of the VS look and feel in their converted environment. They will take you to MicroFocus or ACCUCobol hell and leave you stranded there without a life line.
If you mention COBOL ReSource to one of these places they may immediately cut their quote in half to do the conversion using COBOL ReSource. There's only one problem with that: they have never done it using COBOL ReSource and don't have any idea what they are talking about. If they had ever used COBOL ReSource, we would know about it.
If you mention the New VS to one of these companies they may not know what to say. No conversion house offers "conversionless conversion." Only the New VS allows you to simply load and run. Of all the alternatives, only the New VS runs the VS Operating System and all VS software with no modifications whatsoever.
Key questions to ask a conversion vendor
(Or click you browser's BACK button to return)
|
|
There are some serious, responsible conversion firms out there who will take you all the way through to a functioning application on a new platform.
So what's wrong with that?
Nothing, if you don't mind losing many of the features that made the VS such a pleasure to program and to use... and spending a lot of money for the privilege of losing them. These folks usually have little or no VS background and don't understand why we like the VS so much. They therefore readily sacrifice strict VS data and source code compatibility, certain Wang file I/O modes, the workstation Help key, Procedure Language, the Volume/Library/File architecture, rollback recovery transaction capability, the familiar VS utilities, VS Intertask Messaging, the VSSUBS, etc. Like the hit-and-run conversion firms, these people think you should "get with the program" and learn to live with Unix or NT.
Although a serious conversion firm may stick with you through completion of your project, you may not like the "death of a thousand cuts" that results from piecemeal sacrifice of VS features and functionality. Also, you may not like being left in a new and unfamiliar dialect of COBOL or a hybrid of COBOL and database. Lastly, you will pay a lot of money, unnecessarily.
Fortunately, you can now consider the New VS, which requires no conversion, no retraining... just load and run.
Key questions to ask a conversion vendor
(Or click you browser's BACK button to return)
|
|
There is at least one conversion tool that translates VS COBOL to one or two of the popular COBOLs each time you edit and compile a program. This reportedly allows you to maintain your code in VS COBOL and even to maintain it on a real VS if you like.
If you ever modify the generated unix code you will be stuck with it and your original VS COBOL code will be orphaned. If you take the decision to convert once and for all and forever after maintain your code in the unix COBOL, well, you will have made a one-way trip from which you will never return. If you like MicroFocus COBOL or ACCUCobol, go for it. If you're not a programmer, though, you might try showing the new COBOL to your VS programmer(s) before taking the plunge.
Also, the repetitive conversion approach likely lacks good substitutes for Procedure Language, PUTPARM/GETPARM, R1 argument passing and return, an indexed file system identical to that of the VS, data storage formats identical to those of the VS, InterTask Messaging, rollback recovery transaction processing, the VS utilities, the VSSUBS, etc. It is also extremely unlikely that repetitive conversion products are living, developing software with fulltime maintenance and enhancement staffs.
Finally, repetitive conversion is unlikely ever to be able to handle PACE or VS Assembly Language programs. COBOL ReSource can now run well-behaved VS binary executables.
The New VS, on the other hand, requires no conversion of any kind. It runs all currently supported VS compilers and languages, including PACE and VS Assembler. It runs the VS Operating System. It integrates Lightspeed NVS.
Key questions to ask a conversion vendor
(Or click you browser's BACK button to return)
|
|
There are some firms who specialize in converting VS PACE applications to Oracle or other "mainstream" databases. We haven't seen their work, but let's assume they do it well and completely.
What's wrong with this? Nothing, if you don't mind paying an arm and a leg for Oracle. For the price of an Oracle license you could buy a nice New VS. But with the database approach you'll have to buy both a new platform and a mainstream database license, and also pay for the conversion or the tools.
It's also very unlikely that your converted PACE applications will really look and behave the same as they did in the VS environment. SQL*Forms just isn't the same as PACE AB or HLI. Also, until a very recent version of Oracle, it didn't even support referential integrity rules in the data dictionary, as PACE does. Oracle used to fake referential integrity in the forms triggers. That meant that you either had to buy the CASE tools for Oracle or face the impossible task of manually maintaining referential integrity rules dispersed throughout hundreds or thousands of forms triggers.
What is the alternative? Just buy a New VS, load your files, and run. No conversion of any kind is required.
Key questions to ask a conversion vendor
(Or click you browser's BACK button to return)
|
|
(Only one alternative vendor comes close to offering this, and it involves running your code through a converter each and every time you edit and compile a program. With the New VS your source code will not have to change at all.)
("Integrated" implies support for multiple VS languages. Only the New VS supports all VS languages and tools.)
(In a word: No. Only the New VS offers all the VS programming languages.)
(No. Only the New VS and COBOL ReSource offer this. Only the New VS offers 100% binary volume and file compatibility.)
(It doesn't. No substitute will compare with PACE. Some will try to convince you that conversion of PACE applications to Oracle is a good idea, but serious PACE users who have been following Oracle closely still find that Oracle has not yet risen to the level that Wang PACE achieved twenty years ago. Oracle keeps getting closer, but still no cigar.)
(No, only the New VS and COBOL ReSource have VS-style soft recoverable files. Only the New VS seamlessly runs DMS, XDMS and seamlessly supports DMS/TX files with Before Image Journalling and After Image Journalling.)
(No. Only the New VS supports Lightpseed, and it does it seamlessly. Lightspeed NVS is the defacto standard for PC/VS connectivity today.)
(No. Only the New VS offers a seamless Virtual PIB that guarantees precisely the same stream of printer output that you presently get from your Wang PIBs.)
(Yes, almost certainly, and that will disrupt the continuity of application and tool knowledge and experience your organization presently enjoys. With the New VS no retraining is needed.)
(At least to some degree, yes, and possibly to a large degree. With the New VS no retraining is needed.)
(Oh yes, you'd better believe they will! But with the New VS, system administration remains the same, with the addition of a small number of new VS utilities.)
(Haha! Heehee! This one should be good! With the New VS there is no conversion whatsoever.)
(HAHAHA! Expect five figures for small applications and six to seven figures for large applications, plus time, plus inevitable differences from your present system, plus retraining, plus risk... But the New VS will cost you more or less what an upgrade to a later model of VS would cost, with no conversion whatsoever.)
(Sometimes this is really scary. But with the New VS no new software packages are needed on your client PCs.)
(Almost certainly not. But with the New VS nothing changes on your client PCs.)
(In many cases, yes. But with the New VS there are no per seat charges of any kind, nor are there per-seat charges for Lightspeed NVS, the de facto standard for VS/PC connectivity.)
(You really don't want to know, but you have to know. But with the New VS the answer is "zero.")
(This could be really painful. But with the New VS, development tools are the same as on the legacy VS and have no per-seat fees.)
(We know of one VS site whose programming and operations staff swelled from 4+2 to 21+5 when they replaced a smoothly operating cluster of two VS12000 systems with one of the largest AS/400 systems made and expensive third party software that failed to do what the original system had done. We can't tell you how to get an honest answer to this question from a conversion vendor but you might find out by calling some of their other customers. The New VS requires no changes in staffing.)
(Or click you browser's BACK button to return)
|
|
Some conversion firms propagate significant misinformation. They claim that their product is better than some other "emulation" product because it is "native" and faster.
The problem with that is that until recently there has been no VS emulation product in the marketplace. The "emulation" label is usually aimed at COBOL ReSource, which is actually a fully native unix product that ran circles around both IBM and MicroFocus COBOLs when it was first released (the study was conducted by HP). Only recently has VS emulation been developed, and it was done only to support applications written in VS Assembler because such applications had no other good way to leave the VS.
The COBOL 85 compiler in COBOL ReSource works just like it does on the VS: it compiles COBOL to native assembly language for the platform on which it is running, then invokes the native assembler and linker to emit executable machine code. It does not employ pseudocode or emulation.
The PDMS file system used by COBOL ReSource is a fully native unix file system that supports VS-style Indexed and Alt-Indexed files that are completely compatible with corresponding VS files. It is also the only unix-based indexed file system we know of that can actually support file sharing and record locks for over 1,000 users.
The VS look and feel that COBOL ReSource provides has nothing to do with emulation. All the COBOL ReSource components are written in native languages, mostly C, and provide the VS look and feel with no runtime penalty.
On the other hand, the New VS uses a hardware abstraction layer to actually run VS software, including the VS Operating System. When the conversion firms catch wind of this they will probably try to stick the "emulation" label on the New VS, too. But what's the point? Major systems such as IBM AS/400 and IBM S/390 (now zSeries) now commonly use hardware abstraction layers. If you can get 100% binary compatibility that lets you load and run your VS applications at performance levels up to and beyond the VS18950, why would you care how it's done?
(Or click you browser's BACK button to return)
|
|
Yes, there really is a New VS. It offers you these benefits:
(Or click you browser's BACK button to return)
|
|
Ah, COBOL ReSource! It is the product that gives you these key benefits:
Go to the COBOL ReSource Website
(Or click you browser's BACK button to return)
|
|
Good luck. If your application is that small, knock yourself out, because it's probably impossible to justify spending any real money to do anything else. Be sure you know what you're doing, though, because there may be more going on in that VS than you realize.
In any case you may need to extract data from the VS. We can help you do that.
(Click you browser's BACK button to return)
|
|
Good. Things could be worse. Your concerns about the VS could be based on one or more of the following (click whichever apply, use your Back button to come back to this list):
(Or click you browser's BACK button to return)
|
|
If your VS still has a full production complement of users, the load on it may have grown to the point at which the CPU can't comfortably carry the load. In a few cases the CPU may not be the bottleneck, but in most it is. There still may be things you can do, such as:
If the population of users on your VS has fallen off, you may not be experiencing performance problems but you are probably paying to maintain a VS much larger than you need.
In either case the price/performance is probably not what you'd like. The answer may be to move your applications, unchanged, to a more cost effective platform such as the New VS or COBOL ReSource.
Learn more about COBOL ReSource
(Or click you browser's BACK button to return)
|
|
Only you can judge whether you are receiving the service and support you expect. Getronics has committed to supporting the legacy VS for some years to come and we take them at their word.
You can, though, move to a modern, fully maintainable platform such as the New VS or by means of COBOL ReSource, thus assuring yourself of maintainability and scalability on very standard server hardware. On the other hand, the New VS is 100% binary compatible with the legacy VS and requires no conversion whatsoever, while COBOL ReSource offers native RISC speeds on HP and IBM unix platforms, with some conversion required.
Learn more about COBOL ReSource
(Or click you browser's BACK button to return)
|
|
VS operating costs, including maintenance, are often perceived to be high for two reasons:
First, the large models (300, 7000-18000) represent mostly 1980s engineering, except that new processor boards have been introduced as recently as 1999, while small models (VS5000/6000) represent late 1980s to early 1990s engineering except that they, too, have received new processor board offerings as recently as 2000.
Older engineering usually means larger size, greater electrical consumption and heat generation, and rising costs of maintenance as parts and skills become scarce.
Second, the performance the VS delivers has fallen behind competing platforms.
Either of these reasons can make the operating cost of the VS seem high for what it delivers, and both together can make it seem very high indeed.
The plain fact is, though, that organizations using the VS as an enterprise or other critical processor can usually easily afford the cost of operating the VS. What most of them would like, though, is greater maintainability and scalability, product stability, and smaller footprint.
The answer may be to move your applications, unchanged, to a more stable and effective platform such as the New VS or to a platform supported by COBOL ReSource. The New VS offers 100% binary compatibility with the legacy VS while COBOL ReSource offers a way to move Wang VS COBOL applications to high-speed RISC/Unix platforms.
Learn more about COBOL ReSource
(Or click you browser's BACK button to return)
|
|
The people are out there. If you can't attract or retain them it may say more about your organization's salaries and policies than about the availability of people with VS expertise. I know of VS sites that have stable COBOL programming staffs. I know of a site that uses VS Assembly language exclusively and has no trouble maintaining its staff, attracting IBM mainframe programmers or even training non-programmers to become VS Assembly language programmers.
The IT world today is swept by and controlled by what I can only describe as fashion trends. One year client/server will save the world. Another year it's data warehousing. Another year it's Java. If you think it's difficult to find VS programmers, try finding the half-dozen shifting and changing skill sets you'll need to build and maintain an application in today's bizarre, confused IT world. And by the time you've built it, half of the tools and skills you used will have gone out of fashion and become obsolete. Then try maintaining your new application.
Meanwhile, in the background, the majority of the world's serious data processing continues to be done by COBOL programs. VS systems continue to provide robust database applications through PACE and a wide range of traditional applications through COBOL 74, COBOL 85, BASIC and even PL/I, RPG and C.
COBOL is not going away. Not today, not tomorrow, and possibly not ever.
The New VS may be an attractive option for you to consider. It preserves everything good you have liked about the VS, but in a modern PC server platform running Linux. The New VS runs the VS Operating System and all VS software with no modifications or conversions whatsoever.
(Or click you browser's BACK button to return)
|
|
In this case you have a real problem. If the management suits are pursuing an irrational goal to "get rid of the Wang," it could well be a result of the ribbing they get from other clueless suits at the health club or out on the golf links. It's difficult to fight that.
If, though, upper management is laboring under old or incorrect information, there may be a chance to salvage the situation. The New VS addresses the principal valid concerns that management may have, while preserving the often huge investment in existing VS applications.
The New VS:
Click here to see why conversion is a really, really bad idea.
The New VS may be an attractive option for you to consider. It preserves everything good you have liked about the VS, but in a modern PC server platform running Linux. The New VS runs the VS Operating System and all VS software with no modifications or conversions whatsoever.
(Or click you browser's BACK button to return)
|
|
Your organization selected the Wang VS at some time in the past because it offered an exquisite combination of price/performance, reliability and ease of use, and delivered commercial grade data processing manageable by extraordinarily small staffs. Times and technologies change, though, and in your present technology lineup, the Wang VS may seem a bit out of place. Probably, but not necessarily.
The VS is still quite alive, although in much smaller numbers than the many tens of thousands at its high water mark in the late 1980s. If you wish to keep your VS running, you can, and probably will continue to be able to for several more years. If you'd like to keep your VS running but it isn't performing up to par or seems too expensive to maintain, you may benefit by looking into upgrade/downgrade options involving newer, faster, smaller, more reliable VS equipment. Learn more about the VS here.
If, however, you are not comfortable staying with the legacy VS hardware or find that the upgrade/downgrade options do not seem to be cost effective for you, then you should consider moving your VS software, assuming it is good and serves your purposes, to a more modern platform such as the New VS or an IBM or HP unix box.
The only product that can provide you with 100% VS binary compatibility on standard server hardware is the New VS.
On the other hand, the premier product for moving VS applications to native unix without regard to binary compatibility is COBOL ReSource.
(Or click you browser's BACK button to return)
|
|
COBOL ReSource is a tradename of Getronics, Inc., formerly Wang Global, Inc., formerly Wang Laboratories, Inc.
![[home]](homebtn2.gif){kind=small}
Up to The Unofficial Wang VS Information Center
(If you came here from there, use your browser's BACK button instead)
![[envelope]](mailme.gif){kind=small}