Field Resize

You need to increase the size of a field? The product or the invoice number? This is a common request that can occur for any applications, including IBM i application.

Identification of all files and tables

Powerful and flexible filter
Finding exactly all files that contain the field you want to resize is fundamental. On the IBMi system the names of the field you want to identify can be cryptic, the type and size of all of its declinations are not always constant. The field's text and columns headings or alias descriptions are also from great help to include or exclude candidates within the list. Our tool integrates a native and flexible filter to manipulate any research in order to get the exact list of file that contains any iteration of the field you need to resize.

Identification of all propagations

Programs & Stored Procedures
Programs and Stored Procedures (SP) can use a file with different methods:- Record level Access (RLA) - for programs- Static SQL access- Dynamic SQL accessAll those methods are identified by the tool part of our service. Within a program, the propagation of a database field can be very extensive; it can go to a variable that then goes to another var, to a DS or parm or display or printer-field and continue to any combinations of those elements and so on.Our tool can trace all those extensions and identify each interested lines in the code.

Impact analysis

Understanding the impact of the change is necessary to setup the effort task, especially for the testing preparation.

Validation of all recompilations

Recognising all pgm that need to be recompiled and checking the validity of each compilation is a mandatory exercice in a app-field-resize project, before and especially after the app-field-resize change. This feature is integrated in our package.

Integration of all testing scenarios

End to end testing with empowered code coverage
For a field resize project the testing represents 40 to 50% of the all budget. Having a strong testing framework that can enable an end to end testing and particularly identify that the code changed has been going through the code coverage in the testing is a high asset to reduce the risk of failure for the project. Our ReplicTest tool is accompanying the app-field-resizes project for this purpose.

CONTACT US

Get in Touch!

FAQ

How difficult it is to process a field resize in a legacy application?

Resizing fields in an IBM i legacy application may vary in difficulty depending on several factors, such as the programming language used, the application architecture, and the complexity of the application itself. Here are some factors to consider regarding field resizing:

Language and technology: If the application is written with database access exclusively or in majority with SQL accesses the resizing fields task may be relatively advantaged. The impact will start from the propagation of the interested SQL columns to RPG variables (or Cobol etc.) and so on. Everytime a variable or a data-structure that is independently defined with a strict size is a container of the field to be resized it will need to be redefined. Those variables or DS will also need to be traced for there own propagation to get further variable(s) that would possibly need to be redefined as well, and so on.
Data dependencies: Field resizing becomes more complicated if the field is referenced extensively throughout the application or if it is part of complex data structures. In such cases, resizing the field may require updates to multiple programs, files, and data structures, which increases the complexity and effort involved.
Impact analysis: Before resizing a field, it’s essential to conduct a thorough impact analysis to identify any potential consequences. This involves identifying all areas of the application that use or are affected by the field and determining the extent of the required changes. This analysis helps estimate the effort required and potential risks associated with the resizing process.
Regression testing: Resizing a field in a legacy application may necessitate thorough regression testing to ensure that the changes do not introduce unexpected issues or data inconsistencies. This testing should cover all affected areas of the application to validate the correct functioning of the resized field.
Database considerations: Resizing a field in the database files associated with the application may require additional considerations, such as data migration, files reorganization, or files-level locks during the resizing process. These factors can impact the overall difficulty and duration of the resizing effort.

Overall, the difficulty of resizing fields in an IBM i legacy application can range from relatively straightforward to complex, depending on the factors mentioned above. It’s recommended to approach field resizing with careful planning, impact analysis, and thorough testing to minimize potential risks and ensure successful implementation.

What are the factors to consider to analyse the impact of a field resize in a IBM i legacy application?

When analyzing the impact of a field resize in an IBM i legacy application, it’s crucial to consider the following items:

Application Code: Assess how extensively the field is used within the application code. Determine if the field is directly referenced or if it is used indirectly through other variables or data structures. Identify all programs, modules, and procedures that will require modification due to the field resize.
Data Structures: Examine the data structures that contain the field being resized. Determine if there are any dependencies or cascading effects on other fields or data structures within the application. Updating the field size might require modifications to the data definition and usage throughout the application.
User Interfaces: Evaluate any user interfaces (screens, forms, reports) displaying the resized field. Consider the impact on the user experience, layout, alignment, and any associated business rules or calculations that rely on the field. Ensure the interface can accommodate the new field size without visual or functional issues.
Data Storage: Evaluate the impact on the database file(s) that contain the field being resized. Determine if the field size change will affect the storage requirements, indexing, or data integrity. Determine if any data conversion or migration is necessary to handle the new field size.
Interfacing Systems: Identify any systems or applications that interface with the IBM i legacy application. Analyze how the field resize will affect data exchange, API calls, or data integrations. Ensure these systems are compatible with the changes and make any necessary adjustments.
Reporting and Analytics: Consider the impact on any existing reports, queries, or analytics that utilize the field being resized. Analyze the impact on data extraction, manipulation, calculations, and presentation in these reporting mechanisms.
Testing and Quality Assurance: Plan comprehensive testing to ensure the resized field functions correctly and doesn’t introduce any unintended side effects. Include regression testing to validate that existing functionality remains intact after the field resize.
Documentation and Communication: Update relevant documentation, including data dictionaries, system specifications, user guides, and developer documentation, to reflect the field resize. Communicate the changes to all stakeholders, including users, administrators, and support teams.

By considering these points, you can perform a thorough impact analysis and minimize risks while resizing a field in an IBM i legacy application.