Skip to main content

View Binding Directory Entries from SQL - IBM i

View Binding Directory Entries

Binding directory is an object that holds the list of modules and/or service programs that may be required for the compilation of ILE programs. 

In other words, Binding directory contains modules and/or service programs whose procedures might be used across different ILE programs and are required for compiling the ILE programs. 

Can these programs be compiled without the use of binding directory? The answer is Yes. If a program is using procedures from one service program (say SRVPGM1), corresponding service program to be added against the parameter BNDSRVPGM when creating the program using CRTPGM. 

So, Why is binding directory needed? In the above scenario, we are only talking about one program using procedure from one service program so it is easy to mention service program name while creating a program. Say if we have many procedures across different service programs (most common), It becomes hard to remember and adding all the service program names while compiling. 

Binding directory provides the option to add all the modules and service programs whose procedures could be used in various programs. And, binding directory name can either be added in the H spec of the RPGLE source or against BNDDIR parameter in the compilation command (CRTPGM, CRTBNDRPG...). 

How do we view the entries in binding directory? Traditionally, DSPBNDDIR (Display Binding Directory) command is used to display the entries in binding directory. 

DSPBNDDIR BNDDIR(<library>/<binding-directory>) 

Same information can now be viewed from the SQL by running a SELECT query on the view BINDING_DIRECTORY_INFO (system name - QSYS2/BNDDIR_INF). 

This view contains the same information as it is displayed using DSPBNDDIR. 
  • BINDING_DIRECTORY_LIBRARY - The library which contains the binding directory.
  • BINDING_DIRECTORY - The binding directory name.
  • ENTRY_LIBRARY - The library containing entry (i.e., service program or module). Can contain the special value *LIBL.
  • ENTRY - The name of the binding directory entry.
  • ENTRY_TYPE - The object type of the binding directory entry. Valid values are *MODULE and *SRVPGM.
  • ENTRY_ACTIVATION - The activation control of the bound service program. Valid values are *DEFER (Activation of the bound service program may be deferred until a function it exports is called) and *IMMED (Activation of the bound service program takes place immediately when the program or service program it is bound to is activated). Contains the null value if ENTRY_TYPE is *MODULE.
  • ENTRY_CREATE_TIMESTAMP - The timestamp when the object was created. Contains the null value if the entry timestamp is not available.
There are two major advantages of using the SQL view (BINDING_DIRECTORY_INFO) over the command DSPBNDDIR. 
  • There is no provision for filter to check for a specific entry in the binding directory in DSPBNDDIR. So one has to page down and find out to see if the specific entry is  present in binding directory. 
  • One has to run command DSPBNDDIR on multiple binding directory to find out all the binding directories in which a specific entry is added. 
Both of these can be easily achieved with the use of SQL view. 

Check for the entries starting with TEST in a specific binding directory. 


Check for the binding directory which has entry TESTSRVPGM and entry library TESTLIB. 


Similarly, we can run the query based on the entry activation, entry create timestamp or any other fields as required.

If you have any Suggestions or Feedback, Please leave a comment below or use Contact Form.


Popular posts from this blog

All about READ in RPGLE & Why we use it with SETLL/SETGT?

READ READ is one of the most used Opcodes in RPGLE. As the name suggests main purpose of this Opcode is to read a record from Database file. What are the different READ Opcodes? To list, Below are the five Opcodes.  READ - Read a Record READC - Read Next Changed Record READE - Read Equal Key Record READP - Read Prior Record READPE - Read Prior Equal Record We will see more about each of these later in this article. Before that, We will see a bit about SETLL/SETGT .  SETLL (Set Lower Limit) SETLL accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Corresponding Record (or Next Record if exact match isn't found).  SETGT (Set Greater Than) SETGT accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Next Record (Greater Than the Key value). Syntax: SETLL SEARCH-ARGUMENTS/KEYFIELDS FILENAME SETGT  SEARCH-ARGUMENTS/KEYFIELDS FILENAME One of the below can be passed as Search Arguments. Key Fiel

What we need to know about CHAIN (RPGLE) & How is it different from READ?

CHAIN READ & CHAIN, These are one of the most used (& useful) Opcodes by any RPG developer. These Opcodes are used to read a record from file. So, What's the difference between CHAIN & READ?   CHAIN operation retrieves a record based on the Key specified. It's more like Retrieving Random record from a Database file based on the Key fields.  READ operation reads the record currently pointed to from a Database file. There are multiple Opcodes that start with READ and all are used to read a record but with slight difference. We will see more about different Opcodes and How they are different from each other (and CHAIN) in another article. Few differences to note.  CHAIN requires Key fields to read a record where as READ would read the record currently pointed to (SETLL or SETGT are used to point a Record).  If there are multiple records with the same Key data, CHAIN would return the same record every time. READE can be used to read all the records with the specified Ke

Extract a portion of a Date/Time/Timestamp in RPGLE - IBM i

%SUBDT Extracting Year, Month, Day, Hour, Minutes, Seconds or Milli seconds of a given Date/Time/Timestamp is required most of the times.  This can be extracted easily by using %SUBDT. BIF name looks more similar to %SUBST which is used to extract a portion of string by passing from and two positions of the original string. Instead, We would need to pass a value (i.e., Date, Time or Timestamp ) and Unit (i.e., *YEARS, *MONTHS, *DAYS, *HOURS, *MINUTES, *SECONDS or *MSECONDS) to %SUBDT.  Valid unit should be passed for the type of the value passed. Below are the valid values for each type. Date - *DAYS, *MONTHS, *YEARS Time - *HOURS, *MINUTES, *SECONDS Timestamp - *DAYS, *MONTHS, *YEARS, *HOURS, *MINUTES, *SECONDS, *MSECONDS Syntax: %SUBDT(value : unit { : digits { : decpos} }) Value and Unit are the mandatory arguments.  Digits and Decimal positions are optional and can only be used with *SECONDS for Timestamp. We can either pass the full form for the unit or use the short form. Below i