Table of Contents
Codebase sharing
As a modernization project point of contact and user of AWS Blu Insights, you can follow this process to get the codebase from your customer:
- Customer requests access to AWS Blu Insights.
- Once access requested, the customer should notice you (and provide their email address used to register), so that you can request the activation of their account.
- Invite the customer to prepare their legacy source code. Information regarding the legacy artefacts format is available below.
- Customer uploads source code to AWS Blu Insights:
i) creates a secured Shared Space
ii) uploads the application source code (compressed into a .zip or .7z archive)
iii) Invites you to the Shared Space
Source Code
We list in this page a few guidelines and expectations regarding the assessment baseline.
Artefacts of the codebase
- The code baseline is made of elements called artefacts
- An artefact is a single file corresponding to a single piece of the application, i.e.:
- A single program
- A single control card
- A single copybook
- A single database schema
- Etc.
Versions wise
- Artefacts versions are the ones used to build the application version in production
Content wise
- All artefacts contributing to the build or the run of the application in production
- Scheduler configuration (e.g. OPC, SCL, etc.)
- Scripts (e.g. JCL, REXX, etc.)
- Batch scripts (e.g. CMD, BAT)
- Screens (e.g BMS maps, PROCS).
- Programs (e.g. COBOL, PL/1, Assembler, Easytrieve, SAS) and copybooks and any of their dependencies
- Schema and metadata (e.g. LISTCAT) of the persistence (e.g. DB2 DDLs, IMS (MFS, PSB, DBD), VSAM and GDG formats)
- Parameter and configuration files (such as control cards – CTL or the CICS system definition – CSD file) used to determine execution flow and resolve dynamic calls
- All existing documentation: naming convention, architecture document, interfaces description, etc.
Format wise
- All code and database description artefacts must be in a textual format (or in a special format for 2 cases below).
Special Formats
AWS Blu Insights can extract a suitable codebase from special formats, such as:
Test Data
Depending on the project (customer requirements, legacy technologies, etc.), different types of test cases can be required.
Screen Test Cases
- Video recording of all the screens positive and negative cases
- 1 video with a positive case and 1 video with negative cases, per each test case
- Video duration should be limited to ~10 minutes per screen
- Database extractions related to the Screen
- At start of the recording
- At the immediate end of the recording
See Test Capture & Replay for TN3270 and TN5250 to see how AWS Blu Insights can automate the definition of these test cases.
Batch Test Cases
- Inputs for the job execution (configuration, parameters, files…)
- Outputs generated by the job (files, reports…)
- Execution log of a single batch job or step (including its duration)
- Database extractions related to the batch before and after execution
Backend Test Cases
- Execution log of a back-end service (including response time)
- Database extractions related to the backend service before and immediately after execution
- Recording of backend input and output messages {(Input Message 1, Output Message 1) … (Input Message n, Output Message n)}
Database Test Cases
Database extractions for the Tables in related to the POC migration
- One with a large volume of data
- One with a smaller volume (fewer records per table) of data per table than a production set data
For Project migration, all the used Tables will be extracted.
Test Data Format
- All artefacts are in native format and native encoding (no charset or encoding is changed): no listing or printing format
- Export/dump of artefact is done using legacy native tools from the legacy platform
- No charset or encoding transformation (e.g. EBCDIC encoding is kept)
- Transfer/offload is binary (not ASCII)