You open a portfolio spreadsheet that lists forty applications. You open your production library. It holds four thousand programs. Nobody on the IT staff can say which programs belong to which application.
The printed documentation is years out of date. The system runs the entire business. You cannot shut it down. You cannot easily upgrade it without knowing the internal mechanics. You need an application portfolio assessment to map the environment. You schedule meetings to ask the department heads what the system does. The department heads point back to the servers. The original developers retired a decade ago.
The business rules live inside the compiled objects. A spreadsheet survey asks people what an application does. The source code already says what an application does.
What a standard application portfolio assessment collects
A standard application portfolio assessment relies on interviews and scoring grids. A consultant hands a questionnaire to your business users. The users rank an application on a scale from one to ten for business value. They rank it again for technical fit. The consultant plots the answers on a quadrant. They place high value applications in the upper right corner. They place legacy systems in the lower left. This visual exercise produces a colorful chart. The chart lacks technical depth.
This method stalls on IBM i systems. The business users know the green screens they touch. They enter orders on a specific display file. They do not know the batch processes that run at midnight to update the general ledger. They do not see the interfaces that feed data to external partners. The scoring grid relies on human memory. Human memory fades over twenty or thirty years.
Your RPG developers answer technical questionnaires from their own experience. They estimate the complexity of the order processing module. They guess how many programs handle inventory valuation. The spreadsheet captures opinions. Opinions hide technical debt. Opinions miss the orphaned programs that run every day. A technical debt assessment of your RPG source replaces those opinions with counted items.
An external event often forces the issue. IBM i 7.4 reaches IBM end of support on 30 September 2026. IBM i 7.3 reached end of support on 30 September 2023. No date is announced for 7.5 or 7.6. You have to move the systems forward. To get an accurate picture of your estate, you must start from the source libraries. The source code provides ground truth.
What the source code adds to the portfolio
Reading the source code changes the portfolio conversation. The source code contains facts that no interview uncovers. A code reading tool traces those dependencies across your entire environment.
The operating system provides basic tools. You use DSPPGMREF to start the file inventory. DSPPGMREF reports which files a program references, at the file level. It captures references at compile time. It provides a baseline count for database tables. The file count influences the migration cost. This built-in command stops at the file level.
A true code reading tool traces all dependencies. You see call graph edges between applications. An order entry program calls a tax calculation routine. The inventory allocation module calls that same tax routine. You see exactly where the applications intersect. The code dependencies expose shared files. Two separate applications write to the same physical file. You cannot migrate one application and ignore the other. The database file links them together forever.
The compile instructions list the shared copy members. Copy members pull source from other libraries into a program at compile time. One changed copy member alters every program that pulls it in, across applications. A human developer cannot track every copy member usage from memory. The machine processes the compile instructions and builds the map.
The highest value discovery is the list of programs nothing calls. Every IBM i estate accumulates dead code. Developers write temporary fixes. They leave the old version in production. Removing dead code reduces the scope of your modernization project. Removing dead code saves money. A standard assessment ignores the orphans. A source code analysis identifies them immediately.
Making your application portfolio assessment decisions
Every application in your estate requires a decision. You can keep it as is. You can clean it to free-format RPG. You can convert it to a new language. You can retire it completely. A safe decision requires proof from the source code.
| Portfolio Decision | Required Proof from Source Code | What Happens Without Proof |
|---|---|---|
| Keep as is | Every dependency resolves and the business logic is documented. | A hardware upgrade breaks an undocumented dependency. |
| Clean to free-format | The source matches the object and compiles cleanly. | The modernization team wastes months chasing phantom compile errors. |
| Convert to a new language | The code contains no unresolved copy members and no missing call targets. | The conversion tool generates broken logic in the target language. |
| Retire | Zero programs call the application entry points and zero files accept its output. | A critical batch job fails at quarter end. |
The decision to clean to free-format RPG requires a perfect match between source and object. You cannot recompile a program if the source code is missing. The decision to convert to Python requires a complete map of all dependencies. The conversion tool generates broken logic in the target language if it encounters a missing copy member. An unresolved copy member is one the reading tool could not find. If the tool cannot find the copy member, the automated conversion fails. The decision to keep an application requires a full dependency map. You must know what the application touches before you can secure it.
How to score an application from checkable facts
You score an application objectively once you have the facts. You discard the survey scores. You replace them with numbers you can verify. The first metric is the program count that is actually called. You ignore the total object count in the library. Temporary objects and abandoned backups skew the total count. You count the active nodes in the call graph. This active count defines the true size of the application.
The second metric is the count of unresolved copy members. A high number indicates a fragmented development history. A zero means the application is ready for analysis. Our post on application dependency mapping for copy members covers how those gaps get resolved.
The third metric compares the source to the compiled object. The source must match the compiled object exactly. Developers sometimes lose the source code after a successful compile. A quick fix goes into production without a source control commit. The object runs perfectly for twenty years. The source member sits in a development library and lacks the final logic. You cannot convert an application if the production source is missing.
The fourth metric measures developer readability. You evaluate how many current developers can read the specific RPG dialect. Some programs use fixed-format RPG III syntax from forty years ago. Your current team might only know modern free-format RPG. Our IBM i modernization assessment page covers how we score an estate. This approach anchors your application portfolio assessment in reality.
First pass returns and the exception process
An automated read of the source code produces the baseline inventory. The first pass maps the obvious connections. It generates a plain-English description of each program from the ingested source. It returns the warning list and the list of programs nothing calls.
We use AS/Forward to perform this read. AS/Forward is software that reads IBM i RPG source. It reads six RPG dialects through a proprietary ingestion layer. It builds an interconnection graph across every program, file, copy member and display file. AS/Forward flags unresolved copy members and missing dependencies as warnings. It shows a readiness status per program.
AS/Forward scopes a change in a migration view. You pick a specific field or object. The migration view lists what else moves with it. You see every affected program before you write a line of new code. This view eliminates the guesswork from database changes.
Golden Path Digital tested the ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories. AS/Forward carries one US patent pending. It converts to any target language the client picks. Python and free-format RPG are two examples. It runs against Claude, OpenAI, Gemini or local models on the customer’s own hardware.
The first pass processes the standard code patterns. Every codebase contains exceptions. Your team should expect to spend time reviewing the warnings. Runtime-built call targets require human analysis. A program name assembled from a parameter does not appear in any static cross-reference. The tool flags the dynamic call. A developer must read the plain-English description to understand how the parameter populates.
Security issues emerge as exceptions. CL programs that drive FTP transfers often hold a user ID and password as literal text. A program compiled with USRPRF(*OWNER) adopts its owner’s authority while it runs. This adoption creates a vulnerability if the owner has high privileges. The AS/Forward page covers the product itself. The review process determines your final timeline. Resolving exceptions clears the path for the modernization work.
What the application portfolio assessment cannot decide
The source code provides the mechanics of your system. It maps the dependencies and calculates the program sizes. The automated read generates plain-English descriptions of the logic. You get the facts from the assessment.
The assessment cannot explain why a business rule exists. A program applies a discount to orders from one vendor. The code logic applies the discount. The source text lacks the context to explain if the vendor agreement is still active. A human being must confirm the business policy. A modernization project requires policy decisions.
The assessment cannot determine what the business wants next. You might want a web interface for your warehouse staff. You might need API access for a partner network. The business goals belong to your leadership team. The technical assessment shows you exactly where you are starting. You map the route to the destination. Golden Path Digital provides custom software development to build the new features once the legacy logic is understood.
Start your modernization assessment today
You have forty applications and four thousand programs. You need to know what they do. You need to identify the dead code. You need a complete map of your copy members and shared files. You need an application portfolio assessment based on checkable facts.
Call Golden Path Digital at 501-232-7188. Ask us to perform the IBM i modernization assessment. We ingest your production source libraries and hand back the program count. We provide the dependency graph. We deliver the plain-English descriptions. We supply the warning list and the list of programs nothing calls. Understanding comes first. The target decision belongs to you.
If your security policy keeps source inside your network, we install AS/Forward air-gapped on your own hardware and it reads the source there. Nothing leaves. Or send a message through our contact page.