12-11-2011 11:19 PM - edited 12-11-2011 11:22 PM
Actually My machine are open vms alpha 4000-700A which is running on open vms 6.2v
but I would like to port to 7.3 OPEN VMS ALPHA..
My queries are
1) Is there any hardware dependency?
2) What are the steps we need to take?
3) where we get install kit?
4) CD-ROM required is there any other way?
Iam really new this upgradation area can you please help from the beggining If i upgrade to 7.3 i need to change source code (vms c) ? I need to upgrade FMS also? how long upgrade will take?
12-12-2011 03:43 AM
12-12-2011 04:04 AM
What you are requesting cannot be answered with any detail without an examination of the code that currently exists on the VAX. If the code is entirely in C, the amount of work may be minimal. There are compiler options that allow the "VAXisms" to be acceptable to the newer compiler and standards. (/Standard=vaxc). There are caveats to that however, which may result in incorrect behavior and slow code.
If there are Macro32 routines involved, there are erquired changes to allow the code to be "compiled" on the Alpha platform. Other changes may be required to insure proper execution and behavior.
In short, a close examination of the code and enviropnment is required in order to properly respond. for proper disclosure: Many of us in this forum provide such services. It is unlikely that assistance through inquiries here in this forum will be sufficient to resolve your porting issues.
The OS is the same so that system calls etc. should not require changes, there are coding practices that may need to be changed.
Feel free to either provide more details here or to contact me directly (via Email) using the addresses posted in my profiles for additional information.
12-12-2011 05:04 AM - edited 12-12-2011 05:08 AM
0: device names will change, but that's about the only thing I can tell you from what you've posted. When you hit one of these name changes, use a logical name.
1: If you are planning on porting this yourself, read the OpenVMS manuals and particularly both the OpenVMS documentation shelf as a refresher and (particularly for this case) the "porting documentation" that's behind that link over in the left navigation of that web site.
2: If the prerequisite layered products or suitable replacements for those products are available, then porting from one dead architecture (VAX) to another dead architecture (Alpha) is often somewhere in the range of unwise, foolhardy, expensive and futile. In terms of complexity, porting from VAX to Alpha is on par with going from VAX to Itanium, in other words. And entry-level used Integrity Itanium boxes and HP software licenses are cheap. Some details on the Itanium port.
3: There are always some hardware dependencies. They can range from minor to intractable. The CD-ROM device and the software load path or the data transfer paths (getting your source code from the VAX to the new box, etc) are generally noise-level details in this process.
4: You will obtain your software licenses and software media and installation from HP or an HP reseller, or from the vendor of the product, same as usual. Some vendors will offer software downloads for licensed users. Some don't.
5: The cheapest approach here (in terms of aggregate purchase costs and porting effort involved) is to move from your old VAX to a VAX emulator, and to continue to do little or nothing (additional) with this old source code.
6: Decide if you're going to stay (on VAX emulation or on VMS on either Alpha or Integrity Itanium), or port to another platform. Consider porting your data to Unix or Linux, or to Windows, and particularly to an analogous commercial package that might provide similar functions as these current applications, if and as available. That'll be more work, but an actively maintained commercial (or potentially open-source) package will typically have better features and capabilities than some home-grown pieces.
And FWIW, it's "upgrade" and not "upgradation". Using the word "upgrade" here is simpler, shorter, and it's an actual English word. But then I suspect this'll go the same way as "function" and "functionality"; the longer and more pompous and made-up word will win.
12-12-2011 07:56 AM
Are you REALLY moving to an Alpha? Are you moving to a different machine other than your current VAX4000? Or are you staying on your existing VAX?
If you really are moving to a different machine, then you need to understand that you are dealing with 2 different architectures. EVERYTHING must change (translators not withstanding). Every bit of software currently running on your VAX VMS 6.2 machine will need to be upgraded to run on an Alpha server.
As Hoff mentioned - Alpha is also a dead architecture. I do hope you've looked into going to Integrity. Assuming there are legitimate reasons that you can not go to Integrity, I do hope you have considered some of the Alpha emulation products in lieu of an aged Alpha server (or for that matter, emulation to relace your aged VAX with modern Proliant hardware).
If this really is a VAX to Alpha migration - The fact that you don't seem to realize what architecture you are on, combined with the nature of the questions you are asking leads me to believe that you would do your company a favor by recommending they seek outside help with this migration. Many of the folks that answer questions in these forums (our company included) offer these services.
Software Concepts International
12-12-2011 10:22 AM
Adding a few commens to the replies above. As noted, Alpha Servers are no longer in production and, while supported, have generally been replaced by Integrity Servers. OpenVMS v7.3 (Alpha) is out of support. Version 7.3-2 will remain in support, however the current version is 8.4. Consider migrating to supported hardware and operating system, or at least 8.3. Another option is to migrate to a VM VAX. Someone familiar with your application will have to reply to any hardware questions. There have been a variety of accessories configured as options to VMS systems.
If your business doesn't have the expertise in your VMS environment, consider retaining a consultant to review, plan and possibly execute a migration. Some very qualified people can be found right here.