President's Perspective

Examine OS/2 Application Alternatives

The useful life of an application varies considerably. Applications that survive longer than others generally were developed with a multi-faceted plan. Ideally, the application designers were well balanced in consideration of key success factors while also setting the correct priorities. An application destined for acceptance, success and longevity generally is developed with the following key elements in mind:

1. Line of business/initiative needs, functions, and enablement are perceived and designed correctly in advance of the initial application launch.

2. Operational performance is at the desired level after launch, and the application can scale successfully (by design) as workloads increase over time.

3. Application architecture is in harmony with corporate standards, with skills in place to support the technology realms (operating system, language base, middleware componentry) upon which the application is based.

4. The application design lends itself for ongoing enhancements and customization as the business requirements evolve. The organization has a process in place to work with line of business in fielding ongoing appropriate application enhancement requests and managing to them.

When application developers and the given organization embrace the aforementioned four general success factors, usually the application is well accepted, meets the need of the business, and has a longer useful life. Some additional granular considerations impact application success and lifeline.

When looking back at legacy applications that have been around for an appreciable amount of time, sometimes “luck” plays a part… that is, the initial application launch and development were in the right time or cycle relative to a few other factors. As an example, some of these additional elements might include the manufacturer's product life cycle plans known or, worse, unknown... like the operating system, the database component, the hardware platform, and the upgradeability of various realms moving into a future era of advanced functions. An operating system might carry the same name for several decades but looking into the future, when advanced functions and enablement are planned, the migration path may not be reasonably manageable. In other cases, the application can evolve gently and in concert with unfolding enhancements the manufacturer of the operating system or given middleware component releases.

In a manner of speaking, one can make their own luck by performing ongoing research and reviewing manufacturer and vendor plans for future product life cycle and support intentions. The better this effort is (in determining future vendor intentions and commitment to the platform) the more secure the application designers and users should be. Furthermore, the better the track record the manufacturer or vendor has in hitting forecasted milestones in feature enablement, new levels of performance, and the more detailed the projected plans are... the more assurance the given organization has in basing an application design on a specific mixture of technology realms. Application developers and users should set forth an appreciable effort in requiring various vendors to reveal/present their roadmaps with respect to planned features, function, performance, dependencies and support. Budgeting the time for briefings, education, and similar undertakings is essential.

In cases where custom code enhancements are extensive, and the degree of customization has no equal in reflecting upon new generation packaged (canned) solutions available in the marketplace, a business dilemma often develops. To clarify, some legacy applications may reflect years of extensive customization highly tuned for precise requirements that fit uniquely well to the given business model or initiative(s) supported. When the age of such an application corresponds to a withdrawal of a technology element or platform (operating system, hardware platform, middleware component) that prompts the need to either replace the application with a new one, or develop a new application... at times it also might make sense to consider migration of the legacy application.

If the given legacy application is a vertical industry realm commodity function set typically replaced by easily defined/accessed off-the-shelf packages available in the marketplace, an organization can have a simple decision to make.

Migration (versus package replacement or rewrite) makes sense when a combination of advantages combine to make that path attractive. Usually and foremost, the migration path is attractive based upon highly customized code content that still has value. Furthermore, either through use of tools or natural “pathing” realities, it can at times makes sense to migrate. What I mean to infer in natural pathing realities is that the most natural target migration direction or platform (in specific cases) is rather obvious based upon industry proven track record, or there are enough similarities between the original application OS/code base and the given target, then migration with tools and other means yields a significant advantage over manual rewrite (whereby the advantage set is in minimization of risk, lower cost versus manual rewrite, and the custom code elements of the older original legacy application can be transferred to the new application target realm in an architecturally harmonious manner).

One example of a natural pathing opportunity is when the original code base is in C or C++ and the business logic portion of the desired custom code investment the business wants to preserve will largely also remain in C/C++ in the target solution realm. Furthermore, in the same example, any desire to take advantage of web enablement can be accommodated logically with respect to scope of effort and financial justification and in harmony with the target's total solution design. The more a subset of the original legacy application can be preserved as a chunk that migrates over, the less user training has to occur, usually the lower cost, reduced risk, etc.

Analysis with respect to seeking the best decision path between package replacement, manual rewrite, and migration of the legacy application is inevitable when discriminating organizations are applying a healthy review effort, looking at all options. One good thought is to project what would be ideal, using a clean sheet of paper in formulating what the ideal application architecture and functionality would look like. Then detailing the realities of replicating some of the desired functionality already in place in the legacy application that must be in the new target solution, determining the development costs/methodologies, timelines, risks, strategic partners, and other aspects. In cases where there is not a significant amount of custom code that the functionality needs to be preserved, this tends to greatly reduce the attractiveness of migration. Where custom code content is high, unique and of significant present value, and when the target total solution architecture desired can be accomplished in a migration methodology, that option can become the most attractive.

Conversely, legacy application replacement with a packaged solution can make the most sense, but customization is inevitable in most cases. Analysis of off-the-shelf packaged solutions is tedious and risky. Demonstrations alone do not yield a complete review. Ascertaining what a package really brings to the table is rarely fully known until after investment and implementation. Organizations are best served in reviewing the pros and cons of all paths: manual rewrite, package replacement with customization, or migration.

Whether the decision is migration or manual rewrite, some organizations are tempted to take a significant part of the development effort upon themselves. If the organization has a successful history/track record in developing, testing and deploying applications that hit the mark, on budget, and on time... this is great, although very rare. Talent and skills in some organizations might be able to design/model and perceive logical architecture and align to corporate standards and formulate to what can be supported internally. But will this talent be given the focus, time and isolation from other duties to promote likelihood of success? Does the visionary talent have the experience in coding efficiency, testing and execution of a design? The answers to these questions determine whether alliances and partnerships are enlisted to take on migration or development projects. In most cases, aligning with qualified migration or development firms is the best course.

The best migration solutions involve preservation of highly customized code while incorporating new technology that crisply leverages advanced functions in the newer operating system offerings and middleware components that bring resource utilization, performance, scalability, web enablement into the total solution form that can be supported and will scale and evolve in a financially responsible way. Best practices associated with decisions to migrate instead of total package replacement or manual rewrite typically reflect a hybrid approach, whereby the end result preserves meaningful legacy custom code with existing and compelling present value, while the resultant new generation application also reflects new era technology and enablement that mirrors key elements of what an ideal manual rewrite product might have offered... at lower cost, reduced risk, and in a predictable launch time frame.

As the sun sets on OS/2, it rises on application renewal

While you were ringing in the New Year, OS/2 headed off into the sunset to begin its retirement. IBM announced last year that as of December 31, 2006 standard product support for OS/2 would no longer be available. (Click here for the specifics of that announcement.)

Many of our readers may be thinking, "OS/2, isn't that the operating system used by banks to run ATMs?" Yes, it is. But for the past 20 years, OS/2 has also been the desktop operating system of choice for thousands of companies spanning the size and industry spectra. In many cases, the business value of the OS/2 applications companies have invested in can and should be preserved.

The trifecta of options

Most applications have lifecycles of five to ten years, though it's possible for them to survive longer if the business they support is relatively static. But while the application could, in theory, continue to work well throughout its lifecycle, the underlying technology usually becomes obsolete or inefficient. (Think about the disk drives storing your data today versus those doing the job ten years ago.)

When the pain of obsolete technology is felt and lack of operating system support drives an organization toward renewing an application, one of three approaches can be taken:

How to rate the options: from a business, IT, and project perspective

As with any decision that affects the entire corporation, renewing an application can be seen from three different points of view: long-term impact to the business, immediate and future IT investment, and cost/risk of the project itself. The table below shows how each option rates on a "Best to Worst" continuum from each of these three perspectives.

Port option by perspective

The first thing you'll notice as you scan down the "Port" column is the number of blue circles that indicate where porting is the most desirable option.

While the decision to port is generally seen as tactical from the business perspective, it is lowest on the strategic value scale. However, porting your OS/2 application immediately addresses platform issues and does so with minimal impact to users (user interface being the only thing that changes).

From the IT perspective, the Port and Rewrite options earn the best ratings in the areas of application stability, risk management, and ownership — since the application is yours, you remain in control. These important factors are generally considered the "wildcards" when you take the Buy option since the vendor is in control.

In terms of the number of hardware platform choices, the Rewrite option is the only one to claim the highest rating since the application itself could potentially limit the choices when porting, while vendor support limits the choices when buying a software package.

The option to Port shines from the project perspective as every factor is on the desirable end of the continuum:

• Implementation costs, provided there are limits on the complexity of the underlying technology change

• User cost — very little project assistance is required

• Data conversion cost — almost none!

• Time to implement — determined only by the technology replacement.

While porting does naturally carry some costs with it (e.g. new operating system support, replacement of obsolete peripherals, upgraded software licenses, cost of the port itself), they don't compare with the cost of building in-house skills to manage an application written under a sunsetting operating system.

Rewrite option by perspective

The visual impact from a quick glance down the "Rewrite" column is quite different: several blue circles indicating  "Best" ratings from a business perspective, but a lot of "Worst" ratings in the areas of user impact, IT investment, and project cost.

The decision to rewrite is generally characterized as a strategic one in that future requirements can be addressed in the new application, and there is  opportunity to build competitive advantage into the design.

Ah, but strategic value, design flexibility and control come at a price! Because application functionality changes alongside the user interface, there are known (and sometimes hidden) user retraining costs. From the IT perspective, operating costs and skills demands could be quite high, depending on the degree of functional change.

However, where the costs are immediately felt are from a project perspective. As the table above shows, implementation, user, and data conversion costs are all high giving Rewrite the "Worst" ratings from this perspective since there is much work to be done in defining requirements, approving designs, and testing.

And, as expected, the time to implement is a full development cycle (which varies by business and application) and the risk is borne entirely by the organization — not at least partly by the vendor, as is the case when you buy a new application.

Buy option by perspective

In general, the Buy option seems to "split the difference" between the other two. Buying a new application will land you mostly somewhere in the middle of the overall cost/risk continuum (hence all of the blue semi-circles in the table above).

From the business perspective, Buy earns a "Fair" rating in strategic value and ability to meet future requirements because of the compromises associated with buying software off-the-shelf. However, it rates "Worst" on user impact since interface, functionality and business process all must change.

The Buy option has several factors which are inversely related to those of the other two options from the IT perspective. Operating costs and skills requirements could be high since maintenance costs and customization support must be paid to the vendor. On the ownership scale, it can only rate "Fair" since the vendor owns the software even if the organization owns the customization effort.

From the project perspective, much of the costs are dependent upon the level and degree of customization. User costs rated "Worst" because everything that must be done when rewriting software (defining requirements, approving designs, and testing) must also be done when purchasing new software. The areas where the Buy option is more attractive than the Rewrite option is time to implement and risk — both are at least partially in the vendor's domain.

Your "best" option?

As you can see from the table above, there are many factors to consider once a decision has been made to renew or replace an OS/2 application. Every organization will put different emphasis on each of those factors as they consider their Port, Rewrite and Buy options. And, of course, every organization and their OS/2 applications are very different. While there is no clear winner from an objective standpoint, the uniqueness of an individual company and it's OS/2 application may easily determine the best option. If not, an assessment from a technology consultant like Datatrend will help you get on the right path.

... on the best option for renewing your OS/2 application.

Application porting "for real"

The methodology - where it all begins

You wouldn't hit the highway without a map, try to repair your car's engine without a manufacturer's diagram, or build a house without a blueprint... You get where this is going? Any successful project from driving across the country to porting your application requires a plan and good documentation.

Having a methodology, even a very basic one, is key to preparation for a predictable outcome.

The good news is that such a methodology for application porting exists and has been applied in the "real world" to assist customers who have ported their OS/2 applications as described in the next section of this article. The simplified model, as shown at left, has four phases beginning with:

Assessment: Here we are not referring to a full-scale technology assessment as we wrote about in the last issue of this newsletter, rather a smaller contextual assessment of the application in its "as is" and "to be" environments (hardware and operation system). The output of this stage is an assessment report which addresses problems/issues to solve as well as application sizing considerations. A brief list of tasks in this stage includes:
- determine context and scope of application
- examine application architecture, interfaces, databases
- examine source code and compiler differences, scan for OS/2 API
- identify OS/2 coding issues (semaphores, shared memory).

Design: In this stage, the project plan, test strategy, any non-functional requirements (e.g. performance of the new platform), and a schedule for porting are finalized. At the end of this stage, a solution outline is produced describing how the problems/issues identified during the assessment stage will be solved.

Code and Unit Test: The output of this stage is the ported application code and, as expected, this is the longest stage of the porting process. Detailed documentation, test scripts and test unit results are also published.

Integration Test: During this final stage, the data is converted/loaded and any user interface issues are ironed out. When it's completed, the tested application code is ready for implementation.

Datatrend and others currently guiding their customers through the porting process are finding several recurring factors unique to the OS/2 environment which may require some "customized extensions" to the basic model:

• age of the application — more time and effort spent in code and unit test

• lack of in-house OS/2 skills — more time and effort in design

• addition of technology not supported on OS/2 — more time and effort spent in assessment.

Since porting an application is truly a one-time project, outsourcing is the path many organizations are currently taking, beginning with the porting "pioneers". Who wants to spend money and time training a migration team on obsolete technology?

Case studies: Porting "pioneers"

Due to the longevity of OS/2, the porting process began years ago for larger organizations — as this article is being written, many smaller companies are now embarking on their OS/2 migration journeys. See the table below for a quick summary of two large-scale porting projects and where they stand today. (Surprising side note: neither one is a bank!)

Challenges: Part of any migration

The chart above highlights some of the challenges faced by two companies before they began the porting process (perhaps "catalysts" is a more fitting term). Once you are in the middle of an application migration process, another set of challenges presents itself — code-specific items that require manual mitigation:

• Compiler dialects

• Hardware-dependent constructs (e.g. word length)

• Platform run-time, build tool dependencies

• System calls/return values, error codes

• Database, network, messaging middleware

• Namespaces, include files, shared libraries

• UI portability

• Data types, threads, semaphores

• Signals, Named Pipes, DLL's/Shared Objects.

Specific to an OS/2 port are code structure challenges of API calls, the handling of which requires one of three approaches: substitution only, substitute with small modification, and complete redesign and rewrite. Once you take into account the operating system you're porting to, it's a little like peeling an onion in that you may encounter yet another layer of challenges. For those interested in what that "sub-layer" looks like when going from OS/2 to Linux, click here.

... on how to begin the process of porting your OS/2 application.

The many shades of OS/2's colorful history

As some of our readers know, the development, marketing, and usage of OS/2 has had a long (in computer terms) and colorful history. We will review a bit of it here in the interest of understanding how it all started and where it all headed.

In the beginning...

Back in April 1987, the first release of OS/2 was announced as a text-mode only operating system. In November of the following year, the illustrious Bill Gates stated that "over the next 10 years, millions of programmers and users will utilize this system". That was three years after IBM and Microsoft signed the OS/2 Joint Development Agreement and just two years before the partnership between the two computer giants began to unravel.

Gates' sweeping prediction of OS/2 usage did not come true (which goes to show even he can get it wrong). Between the release of Windows 3.0 and OS/2 1.3, Windows began rapidly overtaking OS/2 as the leading PC operating system when Microsoft initiated the practice of bundling it with most newly-manufactured computers.

Best "childhood" memories

Nonetheless, several gems glittered in the dull luster of that first OS/2 release, including a rich API for controlling video display and the Ctrl-Esc hotkey combination for switching tasks among multiple sessions. The next release, which came out in 1988, contained a number of features which were the basis of Gates' prediction and the collective agreement in the IT community that OS/2 was/could be/would be the system of the future:

• Database extensions including Query Manager and SQL

• The GUI Presentation Manager whose proportional fonts were the precursor of the Windows look and feel.

• HPFS (High Performance File System) which allowed for long filenames.

• TCP/IP and Ethernet support.

  Team OS/2 A grass roots effort that really worked! In the early 90s, IBM needed a new approach to establishing OS/2 as the industry standard desktop operating system — and it came from the bottom up, so to speak. In February of 1992, IBM employee David Whittle started an internal OS/2 discussion group called TEAMOS2 FORUM on IBM's worldwide network (at the time, more wide-reaching than the Internet). Thousands of IBMers across the globe and the organizational structure contributed their ideas on-line, a positive counter to IBM's top-down marketing practices of the day. Whittle then extended the reach of the group on CompuServe, Prodigy, bulletin boards and newsgroups. He also proposed the formation of an IBM Grass Roots Marketing Department. Once Team OS/2 went "external" that Spring, the usage and acceptance of OS/2 began to spread exponentially. By 1994, Team OS/2 boasted over ten thousand members and IBM acknowledged publicly that without it, there would not have been a 4th generation of the "Warp" operating system.

The early 90s were something of an awkward adolescence for OS/2, as it continued to do battle with its older "sibling" (Windows) who insisted on stealing the limelight. So in 1992, the two joined forces and version OS/2 2.0 was released with limited compatibility with Windows 3.0 (no device drivers or Windows apps) by adapting the code to run inside a virtual DOS machine.

The one stand-out feature of version 2.0 was the Workplace Shell, a fully object-oriented GUI — radically different from the previous interface in that the user could manage programs, files, and devices by manipulating objects on the screen.

OS/2 grows up (and old) at Warp speed

Several years later, IBM decided the OS/2 product image needed refreshing. So to highlight the updated performance, IBM borrowed its internal Star Wars product naming scheme and announced OS/2 version 3.0 or "OS/2 Warp" in 1994. (Anyone recall Patrick Stewart signing up to be Master of Ceremonies at the launch?)

OS/2 Warp offered a host of benefits over the previous version including a basic office suite, broader hardware support, greater multimedia capabilities, and Internet-compatible networking.

In 1996, Warp 4 added Java and speech recognition software. At the time, a server edition of Warp 4 was also released which bundled IBM's LAN Server product with the operating system.

Unfortunately, the Warp product line did little to increase IBM's market share of desktop operating systems. Warp 4 was the last widely-distributed version of OS/2 and soon after its release IBM announced the end of marketing to individual users.

The not-so-golden years

Since the mid-90s, OS/2 has continued its stronghold in certain industries like banking, where thousands of ATMs run OS/2 with a customized user interface. However, these individual niches were not enough to justify continued marketing and sales investments, so IBM announced that as of December 23, 2005, it would no longer be selling OS/2 licenses. Logically, once a software product is no longer in circulation, it's simply a matter of time before the product will no longer be supported. That announcement came last year when IBM notified customers that as of December 31, 2006 standard OS/2 product support will be withdrawn.

Will OS/2 come out of retirement? Not likely, even though some 13,000 OS/2 devotees have signed a petition asking IBM to open source the code. So while IBM is ready to move on, it appears like some loyal OS/2 users are not. Take heart OS/2 fans, with every major technology and application change comes tremendous opportunity!

TechTip: Tips for IBM Users – Redbooks of Value

By Mark Waldrep, President, Datatrend Technologies

IBM Redbooks are developed by the IBM International Technical Support Organization (ITSO). Redbooks provide guidance, installation and implementation experiences, typical solution scenarios, and step-by-step "how-to" guidelines. They often include sample code and other support materials. This library of publications is a very valuable resource!

Below you will find a couple Redbooks that we recommend. Or you can visit this site to search for a different topic: www.redbooks.ibm.com

Database Performance Tuning on AIX

While there are many different types of application realms, it is important to note that the IBM Redbooks that are available which pertain to AIX performance tuning generally correlate to areas of specific application or “solution stack” types. With Relational Database Management Systems (RDBMS) usually being a significant factor in building the profit line of a company, we are supplying a link that can be accessed to download a comprehensive set of performance tuning tips when using the RDBMS of choice under IBM AIX...

Click here to view the Redbook: Database Performance Tuning On AIX

OS/2 to Linux Client Transition

Relating to OS/2 Migration, it is important to note that the industry movement is, in the majority, focused on three OS/2 target tracks - Linux, IBM AIX (or other UNIX), and Windows. The technical scope/effort in migrating to Linux or AIX/UNIX is similar; but quite different in moving to Windows. Clients concerned about using Windows for mission-critical applications, which must be secure, or who are not generally comfortable with Windows, usually move to Linux or AIX/UNIX. Those with a high confidence level and an established Windows practice typically consider moving in that direction. For more information...

Click here to view the Redbook: OS2 to Linux Client Transition

Contact us | Visit Datatrend website

All trademarks, registered trademarks and service marks are the property of their respective owners.
IBM, the IBM logo and other referenced IBM products and services are trademarks
or registered trademarks of the International Business Machines Corporation in the United States,
other countries, or both. All rights reserved. Windows is property of Microsoft Corporation.

Linux is a registered trademark of Linux Torvalds.

Brought to you by Datatrend Technologies Inc.

6815 Meadowridge Court, Alpharetta, GA 30005