Skip to main content

Working with Data Queues in SQL - IBM i

Data Queues

Data Queues (DTAQ) has been very useful for communication between different Jobs on IBM i.

There have been various APIs to help working with data queues by calling these from CL or RPGLE programs. 

With the use of SQL Procedures and Functions, this has been made easy to work with Data Queues from SQL without having to write a program to call APIs. 

We can now create data queues, send data to data queue and receive data and more. Let's have a look.

  • Create Data Queue.
  • Retrieve Data Queue info.
  • Send data to Data Queue. 
  • Receive data from Data Queue.
  • Retrieve data from Data Queue.
  • Clear Data Queue.

Create Data Queue:

Create Data Queue (CRTDTAQ) is more of an interactive command and best suited to execute from either command line or CL program. 

Sometimes, we get to create Data Queues in run time. QCMDEXC is extremely useful in such cases. QCMDEXC API is useful for running commands from programs and QCMDEXC procedure is useful for running commands from SQL. 

Data Queue can be created in SQL procedure in run time as below. 

Run CL commands from SQL

Or, even from a single SQL statement. 

Run CL commands in SQL

Read more about running CL commands in SQL

Retrieve Data Queue info:

Checking the attributes of Data Queue becomes essential when investigating problems around data queues. Or, If we just need to know all the Data Queues that are present in a specific library and more. 

Whatever is the requirement, 'DATA_QUEUE_INFO' view becomes handy to retrieve the info quickly through a single SQL statement. 


Send data to Data Queue:

Data can be sent to Data Queue with a single SQL statement without having to write code to call the API (QSNDDTAQ). 

And, data can be sent to Data Queue in different formats (Character, UTF8 and Binary). There are different procedures to send the data to data queue in each format. 

'SEND_DATA_QUEUE' procedure can be used to send the data to Data Queue in character format. 

Send data to Data Queue in SQL

Read more about Sending data to Data Queues in different formats in SQL. 

Receive data from Data Queue: 

Receiving data from Data Queue using 'RECEIVE_DATA_QUEUE' table function returns the data in different formats (Character, UTF8 and Binary). 

This gives the choice to the programmer to get the data directly in the required format. Just simply choose the column you need. 

One other advantage of using this function is, Data can be received without having to delete from the Queue. 

Receive data from Data Queue

Read more about Receiving data from Data Queues and how to Receive without removing the data from the Queue.

Retrieve data from Data Queue:

Checking what data is present in Data Queue becomes essential when investigating problems around data queues. Or, We may just need to retrieve the data from Data Queue without removing from the Queue. 

'DATA_QUEUE_ENTRIES' becomes extremely useful in these cases. Like 'RECEIVE_DATA_QUEUE', This function would return the data in different formats. 

Retrieve data from Data Queue

Read more about Retrieve data from Data Queue and different selection criteria we can apply. 

Clear Data Queue:

Clearing data from Data Queue from SQL has been made easy with procedure 'CLEAR_DATA_QUEUE'. 

Clear data from Data Queue

Read more about Clearing data from Data Queue and how we can clear a set of data. 


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

Comments

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