Skip to main content

Generate IBM i Build Rules

The Generate IBM i Build Rules tool analyzes IBM i objects—*PGM, *SRVPGM, *FILE (PF, LF, DSPF, PRTF), and *BNDDIR—and produces Rules.mk files, plus any required binding directory (.bnddir) source files, for codermake. Use it to bootstrap a repository's build configuration from existing objects, or to regenerate rules after adding new programs.

No source code is downloaded—only build rules. If you need the sources too, use Import IBM i Sources separately.

Prerequisites

  • An administrator has enabled IBM i Source Import on one of the environment's repositories (see Environments). The target repository must also have a Git provider configured so existing Rules.mk files can be fetched for merging and source files can be validated.
  • Your role includes the IBM i Import permission (included in the Environment Admin role).
  • The IBM i system has its SSH daemon running. The tool connects directly over SSH from the CoderFlow server to run object analysis.
  • Valid IBM i host, user profile, and password credentials. Credentials are held in server memory for the session only.
  • The user profile has authority to install the objx tool the first time you connect. On first use the tool creates a library (default PLOBJX) via CRTLIB, uploads a save file to that library over SFTP, and restores the tool's programs with RSTOBJ. Subsequent sessions reuse the existing library. The profile therefore needs CRTLIB (or a pre-created library named in the advanced objx Tool Library field with *CHANGE authority) and RSTOBJ authority. If your profile can't create libraries, ask an administrator to create an empty library for the tool and grant you *CHANGE authority on it.
  • The user profile has authority to discover and analyze the objects you want to build rules for—*USE on the libraries being browsed and *OBJOPR on the objects, plus read authority on the source members the analyzer resolves. Objects the profile can't read are reported as errors in the review step and skipped.

Launching the Tool

From the main task launcher, open the actions menu and choose Generate IBM i Build Rules.... Visibility is gated by the same conditions as Import Sources.

Workflow

Four steps: Connect, Select, Analyze, Review.

1. Connect

Enter host, user, and password. The Advanced section exposes the objx Tool Library (default PLOBJX). If you previously saved a custom library list for this host, it's applied automatically on connect.

2. Select Objects

Libraries in your IBM i library list appear as expandable rows. Expanding a library fetches its objects page-by-page with filters for name pattern and object type (*ALL, *PGM, *SRVPGM, *FILE, *BNDDIR). IBM-supplied Q* libraries are omitted.

Selection is additive across filter passes—check-all adds every object matching the current filter to the selection, so you can build it up over multiple passes (A* → check, B* → check, result is A∪B). Changing a filter never clears selections.

The card header shows cumulative controls:

  • Library List — customize the user portion of the library list for this session. The list is validated against the IBM i before it takes effect and is saved on the server per host.
  • Options — analysis and rule generation options (see below), plus the shared Source Type Mappings editor.
  • Save / Load — save the current selection under a name and load it later. Saved selections live per environment; objects that no longer exist at load time are silently skipped.
  • Branch — when the repo allows branch selection, this chooses which branch existing Rules.mk files are merged from and which branch the resulting task runs on.

The global count N objects selected sums across libraries.

Options

  • Require sources for files (on by default) — when off, *FILE objects with no source are allowed instead of blocking rule generation.
  • Allow missing file dependencies (off by default) — downgrades missing file-dependency errors to warnings.
  • Search for object sources (off by default) — lets objx search the system for source members rather than only using locations stored on the object.
  • Generate rules for cross-library dependencies (on by default) — controls how object dependencies that cross library boundaries are handled. When on, every cross-library dep is fully resolved: rules for the dep go into its own library's Rules.mk, and the parent rule references it via a library-qualified order-only prereq (e.g. util/usrv.srvpgm). When off, cross-library object deps are dropped unless the dep itself is part of your selection — a directly-selected cross-library object still gets its rules and prereqs generated. Source prerequisites are always included regardless of this option.

3. Analyze

Progress streams live with per-object status (OK, warning, error). The tool runs objx in batches to collect object metadata, emits Rules.mk for each affected library, and validates that every source referenced by a generated rule actually exists on the target repository and branch (via the Git provider).

Rule generation errors are non-blocking: affected targets are skipped and the remaining rules are still generated.

4. Review & Generate

A summary shows objects analyzed, rules emitted, failed, and skipped counts, and the list of libraries covered. Errors and warnings are listed in collapsible sections. The download icon exports a .tar.gz archive of the analysis artifacts for inspection.

Click Generate Build Rules to create a task. The generated Rules.mk files (and any .bnddir files) are injected into the repository inside the task container under {library}/ directories; analysis artifacts are also placed at /tmp/ibmi-import/ for the agent and for later inspection. An AI agent writes a summary and commit message. From there, use the standard approval flow to commit and push.

Notes on the Resulting Task

Build rules tasks behave like Import Sources tasks:

  • Not resubmittable — the injected files are specific to this analysis session.
  • Sync to IBM i surfaces (Approve dialog section and task page button) are hidden. The output is Git-side build configuration, not edits to push back to IBM i.
  • Otherwise, review, approve, and push through the normal task UI.