OPNQRYF (Open Query File) Command Description

OPNQRYF Command Overview

Purpose

The Open Query File (OPNQRYF) command is used to open a file that contains records meeting specific query conditions. Once opened, the file behaves like one opened with the OPNDBF command, and programs can access its records through a shared open data path (ODP). When finished, the path and resources are released with the CLOF command.

This command can perform several database operations:

• Join records from multiple files, members, or formats (supports both equal and non-equal joins).
• Compute new values using arithmetic or character expressions.
• Group records by field values and apply aggregate functions (e.g., MIN, AVG).
• Filter records before or after grouping.
• Sort results by one or more key fields.

---

Restrictions

1. Overrides can change file, library, or member names on the FILE parameter, but not on the FORMAT parameter unless FORMAT(*FILE) is specified.
2. OPNQRYF does not share an existing ODP. If a shared ODP already exists with the same file/member, the command fails.
3. Subsequent shared opens must use the same options as the initial OPNQRYF.
4. Some system commands (e.g., DSPPFM, CPYF) do not share ODPs, so OPNQRYF cannot be used with them.
5. BASIC programs cannot use OPNQRYF because they don’t share ODPs.
6. In multithreaded jobs, OPNQRYF is not threadsafe for distributed files using *SNA.
7. Required authorities include:
   • Execute authority for libraries.
   • Operational and data authorities (read, add, update, delete) depending on the file access mode.
   • Operational authority for FORMAT files.
   • Use authority for translation tables on MAPFLD.

---

Key Parameters

FILE

Defines the files, members, and record formats to be processed.

• Supports physical, logical, or DDM files.
• Library qualifiers: *LIBL, *CURLIB, or explicit library name.
• Member options: *FIRST, *LAST, or specific member.
• Record format options: *ONLY or a named format.
• Up to 32 physical file members can be joined in one query.

OPTION

Specifies how the file is opened:

• *INP → Input only
• *OUT → Output
• *UPD → Update
• *DLT → Delete
• *ALL → All operations

FORMAT

Defines the record format for the query results.

• Can be mapped fields or unique field names.
• FORMAT(*FILE) uses the format of the first file listed.

QRYSLT

Sets selection criteria before grouping.

• *ALL → Selects all records.
• Expression → Logical conditions (e.g., CUSNBR<7000 *AND BALDUE>CRLIMIT*0.9).

KEYFLD

Determines record ordering.

• *NONE → No specific order.
• *FILE → Order follows the first file’s access path.
• Qualified field names → Up to 50 fields, with ascending/descending options.

UNIQUEKEY

Controls uniqueness of key fields.

• *NONE → No uniqueness required.
• *ALL → All key fields must be unique.
• Number → Specifies how many key fields must be unique.

JFLD

Defines join conditions between files.

• Specifies pairs of fields for join operations.
• Supports operators like *EQ, *NE, *GT, *LT, *GE, *LE.

JDFTVAL

Controls whether default values are used when join matches are missing.

• *NO → No defaults.
• *YES → Include records with defaults.
• *ONLYDFT → Only include records created with defaults.

JORDER

Specifies join order.

• *ANY → System chooses order for performance.
• *FILE → Order follows FILE parameter.

GRPFLD

Defines grouping fields.

• *NONE → No grouping.
• Qualified field names → Up to 50 fields.

GRPSLT

Applies selection after grouping.

• *ALL → All groups included.
• Expression → Logical conditions using grouping fields or aggregate functions.

MAPFLD

Defines mapped or derived fields.

• *NONE → No mapped fields.
• Named fields → Used in other parameters to reference derived values.

---

MODULE

Understanding ILE Module Objects

What is a Module?

• A module is a non-executable object created by an ILE compiler.
• The system identifies it with the special symbol *MODULE.
• Modules act as building blocks in larger applications, allowing developers to reuse code efficiently.

Why Use Modules?

• They simplify development in large systems by enabling code reuse.
• A module can contain one or more procedures (similar to functions).
• Procedures accept parameters, perform logic, and can return values.
• Modules can be combined into different executable objects, making them versatile components.

Creating Programs and Service Programs

• When you compile source code with an ILE compiler, you get a *MODULE.
• You can then use:
  • CRTPGM → to build a *PGM (program object)
  • CRTSRVPGM → to build a *SRVPGM (service program object)
• During this process, the compiled code is copied from the module into the program or service program.
• Once copied, the module itself is no longer required unless you plan to rebuild the program later.
• Important: You cannot directly call a module; only the routines inside it are callable.

---

Procedures in Modules

• In ILE terminology, routines inside modules are called procedures.
• There are two types:
  • Main procedures – usually named after the module itself.
  • Subprocedures – additional routines defined within the module.
• Both are invoked in the same way, but the naming convention sometimes creates confusion, leading people to think they are calling the module directly.

---

Key Points About Modules

• Modules group related tasks into smaller, manageable units.
• They can be bound into programs or service programs.
• They cannot be invoked with a dynamic CALL. Instead, they are accessed through:
  • CALLB (bound call in RPG)
  • CALLP (prototyped call in RPG)
• NOMAIN modules cannot be called directly; only their subprocedures can be invoked.

---

Types of RPG Modules

1. Cycle-Main Module

• Contains a cycle-main procedure plus optional subprocedures.
• Implements the full RPG cycle logic.
• Can be called via a bound call or a program call.

2. Linear-Main Module

• Contains a linear-main procedure and optional subprocedures.
• The main procedure is explicitly defined with the MAIN keyword.
• Can only be called through a program call (not a bound call).

3. NOMAIN Module

• Defined with the NOMAIN keyword.
• Contains only subprocedures, with no main procedure.
• Cannot serve as the entry point of a program.

---

RPG Module Types Summary

Module Type	Keyword	RPG Cycle Features	Main Procedure	Behavior
Cycle-main	—	Yes	Implicitly defined in source	Runs RPG cycle logic; can be called via bound or program call
Linear-main	MAIN	No	Explicitly defined with MAIN	Entry procedure only via program call
NOMAIN	NOMAIN	No	None	Contains only subprocedures; cannot be program entry

---

Linear-Main Modules Explained

• A linear-main module is created by specifying the MAIN keyword in the control specification.
• It has one or more procedures, with one designated as the entry point.
• Unlike cycle-main modules, it does not include RPG cycle-related specifications.

Rules for Linear-Main Procedures

• The procedure name must match one defined in the source.
• Calls to the linear-main procedure are program calls, not bound calls.
• Recursive calls are treated as dynamic program calls.
• If a prototype is defined, it must include the EXTPGM keyword.
• Exporting the main procedure is not allowed (EXPORT keyword cannot be used).

---

Linear and NOMAIN Modules

• Modules compiled with MAIN or NOMAIN keywords exclude the RPG program cycle.
• Restrictions in the main source section:
  • No primary/secondary file specs
  • No heading/detail/total output specs
  • No executable calculations (including *INZSR)
  • No *ENTRY PLIST
• Allowed elements include:
  • Full-procedural files
  • Input and definition specifications
  • Declarative calculations (DEFINE, KFLD, KLIST, PARM, PLIST)
  • Exception output

⚠️ Note: In linear modules, global files and data areas are not automatically closed or unlocked. Developers must explicitly handle these operations.

---