Migration design
Migrating OpenVMS systems requires a thorough understanding of how the whole system behaves. Migration between two OpenVMS platforms requires a detailed understanding of the differences in platform behaviour to optimise performance and availability.
There is far more to focus on than the application code base. This is just one of many areas for consideration as part of a complete systems migration to a new platform. Your applications need to run on a supported hardware and operating system platform that can evolve with your business in the future.
Critical aspects of the design for an alternative system architecture include: performance, availability, scalability, data replication, multi-site operation, network connectivity, data interchange, databases and operational manageability.
Migrating from your current platform
- Take advantage of new features and new ways to do things.
- In some cases there may be no direct equivalents of the way things are currently implemented.
- Direct "bug for bug" port or re-implement your application ?
- Allowing for expansion & growth
- Adaptability & flexibility
- Overall system design issues
Typical application issues that need to be considered:
- Equivalent system routines for OpenVMS features and capabilities
- Compiler availability and compatibility between platforms
- Command language scripts
- Batch / scheduler environment on other platforms
- OpenVMS specific constructs without direct equivalents on other platforms (e.g.: clustering, shadowing)
- Data storage mechanisms (e.g.: RMS indexed files, RDB databases)
- Implicit assumptions of architecture types and architecture specific features
- Synchronisation and serialisation of access to data structures
- Floating Point data formats
- IO device support for specific interfaces
- Software installation and configuration
- Startup, shutdown, monitoring, etc.
Typical system-wide issues that need to be considered
- Availability (uptime, disaster recovery etc.) and multi-site operation
- Performance (bandwidth, latency etc.)
- Multiprocessing requirements, parallelism and scalability
- Storage subsystems, fibrechannel SAN fabrics, storage array capabilities, etc.
- Data replication, archive and backup
- Network interconnects, VLANs, LAN failover / NIC teaming, etc.
- Separation of production, test and development environments
- Testing, test data feeds, results comparison, etc.
- Transition with minimal disruption