If you are working with the IBM Bob IDE to build or maintain your RPGLE programs, CL commands, or SQLRPGLE procedures, you will want to follow these best practices. They will help you get the most from the tool and keep your development smooth and efficient on the IBM i operating system.
I have taken the official guidance and turned it into practical advice that fits the way we work every day on IBM i. Whether you are writing a new free-format RPG IV service program, updating a CLLE utility, or tuning an embedded SQL procedure, these tips will hopefully save you time and reduce frustration.
Understanding and Using Modes
Bob works best when you pick the right mode for the job. Think of modes as different hats the AI wears depending on what you need right now.
Here are the built-in modes and when they make sense for IBM i work:
Mode | Purpose | When to use it on IBM i |
|---|---|---|
Code | Writing and changing code | Fixing bugs in RPGLE, adding subprocedures, or cleaning up SQLRPGLE statements |
Advanced | Complex tasks with full tools | When you need extra power for database changes or multi-file refactors |
Plan | Planning and designing | Before you start a new program or redesign a subfile screen |
Ask | Getting information | Quick questions about IBM i APIs, RPG opcodes, or CL command syntax |
Orchestrator | Coordinating big projects | Large modernization jobs that touch RPG, CL, DDS, and SQL all at once |
My recommended workflow
Start a new feature or program in Plan mode. Let Bob give you a clear step-by-step design for your RPGLE module or CL wrapper. Read it carefully and make sure it matches what you need on the IBM i side.
When you are happy with the plan, switch to Code mode to write the actual source.
Use Ask mode anytime you just need an explanation or a quick syntax check.
Switch to Advanced only when the job gets big and you need Bob to juggle multiple files or run extra tools.
You can also create your own custom modes. For example, make one called “RPG Security Review” that only checks for proper authority checks and parameter validation in your RPGLE code. Share custom modes with the team so everyone follows the same standards.
Points to Remember with BOB
Always plan before you code
Never jump straight into writing RPGLE or CL without a plan. Fire up Plan mode and ask Bob to break the requirement down into manageable pieces: data structures, procedures, error handling, and performance notes. This stops you from creating broken code that you later have to rip out.
Use checkpoints like a safety net
Every time Bob makes changes to your source members, it automatically saves a checkpoint. This is pure gold when you are experimenting with new SQLRPGLE techniques or refactoring old fixed-format RPG III code. If the output is not quite right, scroll back in the chat, find the checkpoint, and hit “Restore Files and Task”. Your workspace goes back to the previous good state instantly. Much better than trying to fix bad AI output with more instructions.
Keep an eye on usage and costs
Check the Bobalytics panel regularly. It shows how many Bobcoins you are using while generating RPGLE code or CL scripts. Smart usage keeps your project on budget.
Integrate with version control
Commit often. Small, clear commits with messages like “Add new customer lookup procedure in CUST001R” are your friend. Push to your Git repo regularly. Branches are perfect for trying out a risky modernization of an old CL program. Git is your ultimate undo button on IBM i.
Write clear prompts
The better your prompt, the better Bob’s RPGLE or CL code will be. Be specific. Instead of “make this better”, say “Rewrite this fixed-format RPG III subroutine as free-format RPGLE with proper error handling and embedded SQL”. Give examples of the style you want. Use the Enhance Prompt button; it adds useful context automatically.
Use context mentions
Do not copy and paste huge chunks of code. Just type @ followed by the path to your source member or folder. Examples:
- @someprogram.pgm.rpgle
- @/projects/myapp/dds for all display file specs
You can also mention @problems to pull in any compiler errors or @terminal to show recent IBM i command output. Highlight a section of code and press the shortcut to drop it straight into the chat. Much faster than manual copy-paste.
Keep the context window clean
Start fresh chats for each new task. Do not feed Bob your entire application at once. Give him only the files he needs for the current job. Break big changes into small, focused steps. Your SQLRPGLE procedures will come out cleaner that way.
Security and Control
Set your approval level
Decide how much trust you want to give Bob. Start with manual approval while you are learning. Later you can auto-approve safe actions like generating new RPGLE subprocedures while still requiring confirmation for changes to production CL programs.
Create a .bobignore file
Put a .bobignore file in the root of your project. Use the same syntax as .gitignore. Tell Bob to ignore temporary build objects, sensitive configuration files, or large save files. This protects your IBM i source and stops Bob from touching things it should not.
Set up rules
Create rules in the .bob folder to enforce your shop standards. You can make mode-specific rules that force proper naming conventions for RPGLE procedures, require header comments in every CL program, or make sure every SQLRPGLE uses qualified object names. Rules keep the whole team consistent.
Follow these best practices and you will find IBM Bob becomes a real productivity booster instead of just another tool. Your RPG, CL, and SQLRPGLE code will be cleaner, your projects will move faster, and you will spend less time fighting the IDE and more time delivering solid IBM i solutions.