From Here to Modernity

Five Brave RPG Programmers Move from PDM/SEU to WDSc

April 2006April 2006April 2006

Main Next Month »

April 23, 2006

Varieties of IO Strategies

For many, the idea of modernization includes at least two things: 1) moving from green screen to GUI, and 2) developing a layered application architecture where business logic is separated from user interface logic, on the one hand, and IO access logic on the other. A post at the end of the prior thread of this blog asked about four different IO strategies which were under consideration,

and I think this topic of various IO strategies serves as a good excuse to start a new thread.

Greg posted these questions:

Here's some simple changes that have been suggested to me. I'd like to know which of these you'd choose:

For a critical table, important to the business, do you

1. remove F specs and replace IO w/ SQL in each PGM or module

2. move IO to a SRVPGM and have a procedure return the record format

3. move IO to a SRVPGM and have several procedures which return various data structures

4. move IO to a SRVPGM and have field getters and setters

Doesn't a company risk having its database design go stale by coupling hundreds of programs to its tables and making change expensive?

Posted by on April 23, 2006 at 5:19 PM | Comments (109)

April 12, 2006

What Does Modernization Mean to You?

Words can mean different things to different people, and the phrase "application modernization" is no exception. To some the phrase may elicit positive connotations, whereas to others it may be a source of irritation. For some it may convey responsible management of software assets, where others might hear in the words a veiled criticism of mature applications simply because they are not young and new. What does modernization mean to you?

To a cynic, modernization might mean that someone is trying to sell you something you do not need -- a software tool or consulting services -- or developers are trying to gain job security through busywork.

For others, modernization might mean giving applications a new look and feel and some additional capabilities. The emphasis might be on making applications look more modern while providing the same essential services to the business and its partners.

For still others, the focus may be not on appearance but on new capabilities, greater flexibility and adaptability, and more efficient integration with other applications.

Those who have legacy systems which have proven their value may see modernization as "revitalization" (as Rajiv put it) -- bringing new life into mature systems to enhance their power and prolong their useful life.

Perhaps some see modernization as just referring to the common practice of keeping code and applications up-to-date and in good working (and maintainable) condition. Software is subject to frequent modifications -- some minor, some major -- and over time this accumulation of changes can reduce the initial elegance. Then a reworking is in order to restore elegance (and enhanced maintainability) to the code.

For the community of RPG developers, modernization might mean how developers respond to IBM's changes to the language. Those who have known and used RPG for decades have witnessed many transformations in its capabilities. RPG IV ushered in a revolution which is still in the making, and free form carries it further. Changes in the language have also made it possible to code differently and structure applications with greater modularity, making layered applications more feasible in the RPG world.

So what does "application modernization" mean to you? Does it merely refer to responsible maintenance practices, or are there periods in a technology's history when more significant transformations urge themselves upon us?

Posted by on April 12, 2006 at 9:59 PM | Comments (49)

April 10, 2006

The Challege of Modernization

Many RPG applications in the iSeries world were initially designed and written in the 1980s or 1990s and then carried forward to the present day. They may have been originally developed on the System/34 or System/36, in RPG II or RPG III, and then gradually and continuously modified as they evolved from their initial environment through the System/38 and/or AS/400 to the iSeries (soon to be System i) and RPG IV. Most of these heavily-modified systems still retain their original architecture and green screen user interface, and are comprised of programs which still reflect older programming practices. There is a growing sense among managers of iSeries IT departments and RPG developers that for these applications to have a sustainable and useful future, they must be modernized. Failure to modernize may hasten their obsolescence and replacement.

I hesitate to criticize old applications just for being old and showing their age, but progress in the IT world occurs for a reason. Many new practices and capabilities are simply better than the old. Applications which have proven their worth deserve to be retained through modernization. If they are allowed to grow stale they are likely to be abandoned and replaced.

I work for a company that is forthrightly addressing the challenges of modernization. Glazers is the nation's second-largest liquor distributorship with annual revenues of about 2.5 billion dollars. Based in Dallas, Texas, our primary systems are RPG applications running on a network of over 30 iSeries computers distributed throughout the twelve states where we do business. Most of our applications have had a long history, and although they have been continuously modified to adapt to new business needs, they largely reflect an architecture and program composition of an earlier period. Because they are custom systems which serve our business well, they deserve to be maintained and modernized in order to continue their service to our business. Replacing them would likely be more costly and disruptive than modernizing them.

To help manage and guide what will surely be a long and gradual modernization effort, our Applications Manager established a New Development Forum consisting of many of our analysts and developers. I was appointed to facilitate this forum. We began last summer and the forum will last as long as it is needed. The purpose of the forum is to provide a framework for identifying modernization needs and options, and to bring the varied and rich expertise of our staff to the clarification and evaluation of these needs and options. Ideas, actions and decisions of the forum have already begun to influence our professional practices and sense of direction.

This blog is about an approach to addressing the challenge of application modernization. It is not concerned with the details of Glazers' applications or technical decisions; it is intended instead to share with the iSeries community a process for moving forward with systems from the past, reshaping them for a future. It can also serve as a forum for discussing common modernization challenges and options. It is hoped that others will also share their ways of dealing with this difficult challenge of modernization.

Posted by on April 10, 2006 at 7:41 AM | Comments (9)

Bill Blalock
August 2008
Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Blog Policy

Our blogs are editorial content of System iNetwork. We welcome your comments and opinions and encourage lively debate on the issues, and we reserve the right to edit all postings for clarity, length, civility of tone, and appropriateness to the topic under discussion. Comments consisting of product or job solicitations and other spam, profanity, and extreme rudeness will be deleted. We also reserve the right to publish excerpts from the blogs in our e-mail newsletters and print magazine.

ProVIP Sponsors