Steps to Modernization and Cloud Deployment
You're intrigued about the possibility of running your enterprise mission-critical application in the cloud but don't know how to get started? The Getting Started Guide shows how to develop and maintain these apps using the Heirloom Computing Elastic COBOL Interactive Development Environment (IDE), but what about actually deploying and running apps in the Heirloom Computing Enterprise Legacy Platform-as-a-Service? You might be asking yourself these questions:
- I've got application source, how do I get a running app to the cloud?
- My app has a "batch" component -- where does it run and how does it start?
- My app prints reports that need to be routed to the local user's printer -- how do I connect a printer cable to the cloud?
- I use a 3270 (mainframe) or 5250 (AS400) or ASCII Terminal (UNIX, Linux) screen interface on the "online" components -- how do I connect an ASCII terminal to the cloud?
- COBOL ACCEPT/DISPLAY -- ASCII terminal screens
- CICS SEND MAP applications - 3270 terminal screens
- EXEC HTML applications - Web pages delivered to network-attached browsers
Step 1 - Application Development / Maintenance
Application development for enterprise applications is accomplished from Heirloom Computing Elastic COBOL IDE. Even if the application consists of Java, C, C++ or languages other than COBOL, the IDE is based on Eclipse development environment that supports multiple languages. HCI offers both a downloadable tool and a cloud-based Application Development-as-a-Service solution. Both start with registering for a subscription on www.elasticcobol.com > Portal.
To gain full use of the platform (e.g., CICS, JES, database), sign up for a paid subscription to Elastic COBOL Enterprise Developer. To test your application code with Elastic COBOL, sign up for a Elastic COBOL Developer (Free Edition). Either subscription is valid in the cloud or on-premise. Advantages of on-prem is that you have access to local files and cloud development allows you to get started without any installation or setup required.
See the Elastic COBOL Portal FAQ forum for commonly asked questions about starting and connecting to a cloud instance. When you start a cloud instance with the Power On link (paid subscriptions have a Download link) and then Connect to it to bring up the IDE window using remote desktop protocol allowing the IDE to run in the cloud while its windows are displayed locally.
- Open new COBOL program files and copy/paste from existing source into the window
- Copy directories en-mass from your local system to the cloud
Step 2 - Data Extraction, Translation and Loading
Data Extract Translate and Load refers to the process to move production (or test) data from your current environment to the development or production environment and put it in a format acceptable for your Elastic COBOL application.
When moving between like databases (e.g., Oracle in your existing production UNIX server to an ELPaaS Oracle instance) is fairly straightforward: Use the same techniques as moving data between servers. This might include running database manufacturer supplied tools to export the data to a text or a database-specific export file format. ELPaaS contains the Oracle APEX and SQL Developer instances to run the corresponding import tools.
If moving between EBCDIC and ASCII or Unicode format the text files would be converted when you move them off the original platform.
Elastic COBOL supports a variety of sequential and indexed-sequential file formats:
- Line sequential, variable record length
- Fixed record length sequential
- Micro Focus IDX2 format COBOL files
- AcuCOBOL indexed file format
- Elastic COBOL indexed, relative-record and sequential file format
Step 3 - Application User Interface Mapping
If your application is BMS screen oriented use the techniques described in the Getting Started Guide under CICS Applications for transforming the user interface to a Web interface. For further customization, utilize a custom CSS or home page for each app. Static pages can set up the introduction and links to the applications running under the Java app server (Geronimo) or servlet manager (Tomcat).
For traditional COBOL ACCEPT/DISPLAY applications or Acu Graphic Extension oriented use the techniques described How do Acu GUI apps look in Elastic COBOL.
These applications bring up a Java graphics window which utilizes Microsoft Windows graphics techniques. An ELPaaS (Windows) instance type offers access to these applications usin the same remote desktop protocol as the Eclipse IDE in an ADaaS instance. Virtual terminal remote desktop technologies are available for ELPaaS (Linux) platforms as well. A different windows client (VNC) is required to access these applications.
CICS application transactions and batch applications can also be accessed through WSGI protocol in a technique suited for Web 2.0 AJAX applications. The user interface or batch file input/output is converted to XML and sent over HTTP by use of a servlet or JEE application. See www.wsgi.org for more information.
Step 4 - Cloud Deployment
Applications are deployed from the development environment to the deployment environment from either the IDE's Elastic COBOL Deploy Wizard or the Elastic Transaction Deploy Wizard. Access these from the File > Export... menu command.
Batch applications are deployed to the production environment in pre-packaged JAR files using the first of these wizards. The JAR (containing your application code and Elastic COBOL runtime libraries) into the configured JOBLIB, STEPLIB or the /data or D:\Data directory as configured in the Job Entry Subsystem. JCL programs and scripts can access the JARs from those locations. For testing on the development ADaaS cloud instance, deploy batch jars to the D:\Data directory.
Non-CICS Applications that are Web based (e.g., utilize EXEC HTML) are also deployed to the production environment from the IDE through the Elastic COBOL Deployment Wizard, but are deployed as WAR files. You can deploy these from the ADaaS cloud environment to the production ELPaaS environment by clicking on the Cloud radio button and choosing your started instance.
OLTP (CICS) applications require the JEE server to coordinate transactions and database resources. See the Getting Started Guide for examples with the Geronimo app server. These use the Elastic Transaction Platform Deploy Wizard.
Another step involved in the deployment is establishing a production, rather than test, web environment. The default Web page shown above for a newly started ELPaaS instance would be modified by editing the index.html home page using the File Explorer view. Keep a protected or "administrator view" of your application using the original home page site or something similar to access it through administrator purposes.
Step 5 - Production Operations
Now that the application has been compiled, modernized, deployed into production ELPaaS instances with the prior steps what remains are the steps necessary to carry out various production operations. These might be System Operator duties carried out by IT datacenter personnel in a traditional environment as well as Administrator functions managed by the IT programming or operations people. The ELPaaS Dashboard (on the Web portal) and the Job Entry Subsystem (on the production instance) are used for these activities.
Based on the type of production subscription your ELPaaS instances are backed up daily, weekly, monthly yearly and even hourly if you need it. Retention is up to 10 years. This is similar to a System Operator taking backups of key DASD volumes on a regular basis. Access these snapshots through the Backup Calendar Portlet. Use this portlet to restore a running system to the time the backup was taken. The restored system is given a new Web address that you access in the same way as your main application.
To retrieve report or intermediate application datasets you set up a virtual directory on the Web definition (editing the httpd.conf file in the File Explorer). But for most batch job output reports you would likely use the Scheduler to set up windows when jobs should run:
- Define JES job classes with different resource criteria (maximum CPU seconds, memory, etc.)
- Upload JCL job (or other supported dynamic language script) definitions that are to invoke invoke applications
- Start initiators of those classes at particular times, which would start running jobs for that class or increase the concurrency of background jobs
- Define tasks which start one or more jobs under a particular class through
- Indicate when the batch window should close so as not to affect OLTP applications at other times of day
This has been a review of the steps to modernize, SaaS-enable and cloud-deploy your enterprise application into the Heirloom Computing PaaS specifically designed for the enterprise environment. Although only limited types of applications (COBOL) and batch job scenarios (JCL) have been presented, the platforms created by HCI are of general purpose. "Anything legacy" that runs today in a server environment can take advantage of the ADaaS and ELPaaS capabilities to provide a low-risk, high-reward alternative to traditional enterprise application operation. See other sections of the www.elasticcobol.com or www.elpaas.com Web portals to learn about other modernization options.