Note: The document accompanying this article is available for download here.

Troubleshooting problems is often a costly component of application maintenance. Consider the case when the user reports an application crash. Exactly what program crashed? Was it the UI logic or business logic embedded in a service program? If it was a service program, what procedure was running? What was the chain of events that led to the problem? Knowing what the call stack looks like can help answer many of these questions, thereby reducing costly investigation time. Since writing “persistent stored modules” (a.k.a., SQL routines) is increasingly popular

Suppose you were to ask me how large an alphanumeric variable should be, and I replied that I didn’t know, nor did I care. Wouldn’t that sound odd? Those of us who have been programming in business languages such as RPG, COBOL, and CL since the French and Indian War always think it’s important to know the size of a variable, otherwise we won’t be able to define it properly in a program. But when you work with pointers, a variable’s defined size doesn’t necessarily matter. Let me show you what I’m talking about.

Consider a command:

CMD        PROMPT('Do something')

While recently reviewing system storage on an IBM i partition, we were shocked to discover that spooled files (SPLFs, pronounced spliffs) took up over 10 percent of our usable system storage. Based on that experience and what my shop learned cleaning it up, here are six techniques for keeping your spooled file storage under control.

The Big Six For Spooled File Storage Management

1. Don’t have FNDBIGSPLF? Get FNDBIGSPLF!!!
2. Check your IBM i cleanup parameters (GO CLEANUP) to delete old job logs and system generated output
3. Check for automatically scheduled jobs that are generating unnecessary spooled files
4. The 2.5 million-page