IDMS Migrations FAQ
Q: How many years of experience do you have with IDMS migrations?
A: We started the development of IDMS migration tools in 2002 and we executed our first IDMS migration project 2004.
Q: Can you provide IDMS Project references?
A: Yes, including the following organisations:
|
Name |
Project specifics |
Data Points |
| LCM ANMC– largest Health Insurer in Belgium | MF/IDMS to COBOL Oracle Unix | 4000 users |
| Swets in the Netherlands and present in 20 countries around the globe |
MF/IDMS to COBOL DB2 Linux | 800 users |
| City of Brussels in Belgium | MF/IDMS to COBOL Oracle Windows | 200 users |
| Ministry of Finance in France | MF/IDMS to MF/COBOL CICS Oracle | 14000 users |
| Bank in Spain (under NDA) with 200 regional offices |
MF/IDMS to MF/COBOL CICS DB2 | 1200 users |
| Division of Rabo Bank (global bank) in the Netherlands |
MF/IDMS DB to SQL Server Windows | 250 GB data |
| Tax Authorities of the State of New Mexico in USA |
MF/IDMS DB to SQL server Windows | 50 GB data |
| Unigarant Insurance in the Netherlands | MF/IDMS DB to Oracle Windows | 250 GB data |
Q: What type of project plan will be provided and how detailed are the task descriptions?
A: Once the Pre-Migration Analysis has identified and defined the work and tasks involved, we deliver two documents:
- A project plan (in MS Project format) listing the tasks and the associated dependencies, for both ourselves and the customer.
- An accompanying document that explains all tasks in following terms:
- The work that needs to be performed
- The responsibilities
- When and where the task must be executed
- Deliverables that result from the task
- The acceptance method or criteria for the deliverables, if any
Q: What types of deliverables will be defined?
A: We distinguish between three types of deliverables:
-
Software components:
- Data migration programs (generated by us)
- Data verification programs (generated by us)
- Runtime and maintenance software
-
Conversion results:
- RDBMS scripts for the creation and loading of the target RBDMS
- Converted (COBOL, ADS, assembler, …) code & (JCL, REXX, …) scripts
- Converted screens
-
Training & Expertise:
- Training on the use of Anubex software
- Training on new or changed syntax in converted programs and scripts
- Advice and support for the replacement of utilities or third-party software
- Advice and support for the choice (and evaluation) of target technologies
Q: What type of documentation will be provided during the project?
A: Anubex provides documents (and training) relating to:
- All syntax introduced by Anubex (e.g. COBOL DML statement reference)
- All functionality provided by Anubex software (e.g. IDMS framework reference)
Anubex do not provide documentation regarding third-party software (e.g. IBM MQ documentation), nor third-party technologies or programming languages (e.g. Java documentation).
Q: Do you have a methodology for handling application change during the project
A: Yes, it is known as SOAR – Snapshot Oriented Automated Reduction.
The main characteristics of SOAR are:
- Migration tools are improved and adapted to a project’s specific requirements in an iterative process.
- The migration process runs on a snapshot, i.e. the complete picture of the source application’s artifacts at a specific point in time.
- Normal maintenance operations can continue, in parallel with the migration operations.
- Migration operations can be performed off-site.
- Code freeze and DB structure freeze is limited to a very short time period (typically 4 weeks max).
Please refer to the white paper on SOAR for further information
Q: What percentage of program conversion is automated?
A: All COBOL and ADS code is converted automatically by the Anubex conversion tools. There are some rare situations where it becomes necessary to perform manual adjustments, but it is typically limited to less than 1% of the code. This is occasionally due to a gap in the conversion tool, e.g. an example of statement syntax not yet fully supported, or for performance tuning reasons. Another scenario where manual intervention can be required is if a migration project involves only a subset of a group of applications that interact with each other on the source platform. Assembler programs are converted manually
Q: What degree of customization is possible during conversion of the code?
A: Our COBOL conversion acts as a preprocessor-alike tool: it leaves all non-IDMS syntax unaltered (i.e. preserving whitespace and layout). It only replaces or inserts new COBOL syntax as replacement for IDMS DML. The only customization that is currently possible, are naming conventions for paragraphs and variables that are generated inside the converted program.
IN the case of ADS dialogs, a complete new COBOL program is generated, based on a COBOL ‘dialog’ template. This template can be customized at will, as long as it keeps the relevant hook-points.
Q: How is IDMS data access converted and what are the trade-offs between IO modules and embedded SQL?
A: Data access can be handled in two ways:
- Data access statements are automatically converted to IO module calls. These IO modules encapsulate embedded SQL for talking to the target RDBMS. They also take care of currency and cursor-management tasks.
- Data access statements are converted directly to embedded SQL, whilst cursor and currency management code is added to each of the converted programs.
The trade-offs:
|
|
Advantages |
Disadvantages |
|
IO Modules |
|
|
|
ESQL |
|
|
More detailed information can be made available on this topic upon application: Please contact us.
Q: How can Anubex guarantee that code performance will be equal or better than current performance?
A: We have never experienced problems with the performance of the migrated code. This is largely due to the capabilities of modern hardware and compilers. We do, however, sometimes need to enable compiler performance switches.
From our experience, performance tuning generally correlates to database access efficiency. Database optimization on tablespaces, indexes etc. will normally resolve any database access performance issues. Another technique is to restrict the volume of data retrieved. Our IO modules have an entry point, specifically for this purpose. However, using this entry point and analyzing the extra criteria to filter the data does introduce the need for additional, manual effort.
Q: How are assembler programs handled?
A: Assemblers will be re-created as COBOL (or C) programs: this is manual work and can only be performed after gaining a thorough understanding of the assemblers’ functionality and use. Customer input is required, in order to achieve this.
Q: What special handling is required for programs that are currently AMODE 24?
A: None, except for assembler programs, the conversion of which is a manual process in any case.
Q: What constitutes manual work and why is it neccessary?
A: Manual work represents adaptations made to delivered or converted artifacts, which initially need to be completed by a person, as opposed to being executed automatically by software.
Reasons for introducing manual work include:
- Functional changes requested by a customer
e.g. the list of hardcoded users names in a login program needs to be changed. - Changes forced by a new software environment that cannot be detected by static source code analysis
e.g. conditions in code that rely on the EBCDIC codepage order need to be changed on an ASCII-platform. - Gaps in the current functionality of migration tools.
e.g. conversion of statement X is yet to be supported, of which there are only one or two isolated cases of its use within the application and the required enhancement of the tools would impose an impractical delay upon the progress of the project in hand.
Q: Are risks introduced through the introduction of manual processes and how are they mitigated?
A: Risks are commonly associated with manual work, due to the very fact that it is not automated, i.e. manual work is prone to inadvertent error or omission. However, Anubex has a strict methodology for handling manual work, a methodology that is enforced by automated mechanisms within Anubex' Migratonomy product, which effectively eliminates the risk associated with manual processes. The key elements of Microtonomy’s functionality are:
- Automated detection that a particular migration artifact has had manual work applied from a previous SOAR cycle
- Automated 'manual-work merge' steps that either re-apply previously performed manual work on newly converted artifacts or notifies the migration expert that manual intervention is needed, where the detection routine encounters a conflict condition that precludes an automated merge.
Q: Can you provide samples of migrated COBOL programs?
A: We will be pleased to provide examples of migrated COBOL programs upon application. Please contact us.
Q: Can you provide samples of migrated ADS dialogs/programs?
A: We will be pleased to provide examples of migrated ADS dialogs/programs upon application. Please contact us.
Q: Do you offer a migration to CICS BMS maps?
A: We do not currently offer a migration of maps to CICS BMS. In brief, use of BMS with a runtime library introduces additional and undesirable points of maintenance, and an associated risk of inconsistency. Use of BMS without a runtime library would significantly increase of the volume of code in the converted programs. BMS also introduces further limitations. Please see below for a more detailed analysis of this topic.
Our current offering is based upon:
- WYSISYG editing of screens, including the IDMS OLM map specific properties
- Generation of a COBOL data structure that contains the positioning and properties of the screen, labels and fields
- A UI-runtime library that uses the info from the COBOL data structure to provide the same behavior as the IDMS runtime.
IDMS OLM map specific properties that are not directly supported by BMS include:
- Data binding based on record name and record element name
- Properties related to pageable maps (wait, nowait, return, browse, update, …)
- Error messages, edit tables, edit modules and code tables associated with fields
- Help texts associated with fields and maps
- Underscore when blank, display when zero
- Automatic editing
- IDMS-specific picture (e.g. pictures containing the ‘:’ character)
- Map-level properties for incorrect and correct fields – to be used during a validation cycle
Using BMS maps with a UI-runtime library
The UI-runtime library needs to know the IDMS OLM map specific properties to provide the same behavior as the IDMS runtime. These IDMS OLM map specific properties would have to be maintained in a different place to the BMS map source – in a COBOL copybook, for example. This means there are two points of maintenance for the same artifact. Additionally, the UI-runtime library must know the position of the fields on the screen, to calculate the number of detail occurrences on pageable maps, for example. The developer must therefore also include this information in the COBOL copybook. This must match the positioning information of the BMS map, which potentially introduces a risk of inconsistency. In short, the maintenance of BMS maps (using SDF2, for example) would be primarily for positioning the fields and labels on the screen, and this information would need to be duplicated in the data structure that is used by the UI-runtime library.
Using BMS maps without a UI-runtime library
The IDMS UI runtime provides IDMS specific screen behavior such as:
- Validation cycles
- Map paging sessions
- Temporary/permanent map property changes
- Complex inquire map statements
- IDMS-specific editing and de-editing of fields
- Edit tables
- Edit modules
- Code titles
- Help data
- Parameter substitution in error messages
- Justification of data in fields, mandatory fields
When using a BMS map without any runtime, (parts of) this logic would have to be inserted in each migrated program, which would result in an enormous increase in the number of lines of code to be maintained.
Further information
If you require additional information please contact us with your questions.
Recently Added
References
From small companies to multinationals, from health insurers to airlines, all Anubex customers save time and money by modernizing their applications with the right set of migration tools.