Why is COBOL modification so common for PSPA?

Many clients want to avoid modifying COBOL at all costs But, many reasons lead to the need for modification.

Array Sizing is a common problem especially on implementations with complex configuration.

Sustaining Support – no changes to apply new technology, fluid for example, in PUM.

Issues / Bugs – can’t always wait for a fix.

Stale Product – slow pace of PUM issue resolutions, slow pace of problems reported, concerns about change impact on customers.

Fit Gap Solutions into End to End Process – most efficient development, small COBOL change vs. large extension development…not to mention adverse impact on user experience.

User Exits – clear indication that original intention was to use COBOL to bridge gaps. Even if its not a perfect solution.

Performance Tuning

Finish what original developers started.

A lot of times there is a very compelling arguement or justification for choosing COBOL modification over other alternatives.

A clear challenge is availablity of knowledgable COBOL resources…that understand PeopleTools COBOL, PeopleSoft patterns and standards, the application COBOL program flow and structure, enough about the functional process and configuration to follow the coding and identify how and where to make changes. Sometime lack of resources is a show stopper, and that’s one of the reason the enhancement lab was created, to find a way to share this kind of knowledge and development across multiple organizations. But that doesn’t take away from the fact it’s one of the most powerful ways to improve fit and user experience. And hopefully this knowledge base can help developers start to gain confidence with COBOL modifications for PSPA.

In real life, the best user experiences are systems that have embraced COBOL modification. The most robust examples may have touched nearly half of the Pension applications COBOL programs.

Example bad…excessively complex custom App Engine processes that need to run before and/or after the delivered processes, some or all of which could have been implemented via COBOL changes. Good example, complex FAE earnings cap rules applied to rolling 12 month periods and including projections, with great visibility into the rules applied in an expanded result set for both consolidated earnings and final average earnings.

Some Gaps would be complete showstoppers without the ability to modify COBOL.

There has historically been a lot of concern about the impact COBOL modifications have at upgrade or PUM updates and the impact on receiving support from Oracle. All I can say is get over it. Before sustaining support, the COBOL changes coming from Oracle rarely overlapped with client COBOL Modifications, except when they finally fixed a problem the client reported or when the changes for Pension Protection Act were finally delivered after they became effective. Since sustaining support mode began soon after 9.2 was released, there has been one and only one small change, not always COBOL, per quarterly PUM release and it became even rarer to encounter conflicting changes. I would argue that Oracle is not really providing effective support for Pension COBOL so I would take the time spent reporting and replicating and waiting for response with Oracle and focus on learning how to fix or modify the code on your own. If you’re worried about Oracle one day refactoring or significantly changing or adding to the application COBOL, I would say I have tried everything in my power to encourage that, without success. This includes sharing enhancement ideas with product manager long before setting out to develop them in the PSPA Tech Enhancement Lab.

Based on service levels observed while in sustaining support mode, I’m guessing I’m not alone in seeing clients have given up on looking to Oracle for support. It often feels like a very big effort, or long wait, is required. The best bet is to figure it out, fix it in a way that works for all users, and then let them know the details provided you feel it is a simple, obvious, and safe solution that they will implement. I have had luck with this approach for getting changes into a PUM. But many problems require a lot of explanation to replicate or too many lines of code changed for me to make the effort.

I’ll leave you with a story of an interaction I had with Oracle recently about an obscure functionality that no client of mine has ever used. It was clearly not working at all, and one could safely conclude that no client anywhere was successfully using the feature. I gained great insight into Oracle’s support mindset when they were very anxious about fixing the feature because it might adversely impact existing customers. Seemed like they were afraid to touch the product. I guess that explains why their issue choices for each PUM are the safest changes they can find to make and never include an improvement beyond a simple bug fix.

My Upgrade/PUM experience has been only a small fraction of the overall effort is spent reviewing and merging COBOL, even on those implementation with dozens of changed modules. Much more time is spent resolving environment and PeopleTools changes.

Cloud hosted implementations make the turn around on COBOL compiles laborious and slow. Something that may discourage making COBOL mods for these clients. A workaround may be to have a local VM environment for testing compiles before migrating to the cloud.

What is your stance on modifying COBOL? Are you reporting issues to Oracle, or just living with them, or resolving them yourself? Let me know in the comments.