Skip to main content

Receive Data from Data Queue in SQL - IBM i

Receive Data from Data Queue

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

There are multiple APIs to work with Data Queues. These have been very much helpful to Send and/or Receive the Data from Data Queues by calling these APIs. 

Working with Data Queues has been made easier with SQL Procedures/Functions. In this post, we will see how to receive the data from Data Queues using SQL table function 'RECEIVE_DATA_QUEUE'. This would work similar to 'QRCVDTAQ' API.

Let's see how to receive data from a Standard Data Queue with no Key data. 

RECEIVE_DATA_QUEUE

In the above SQL, 

  • Line - 1: Column 'MESSAGE_DATA' would receive the data from Data Queue in Character format. 
  • Line - 2: Column 'MESSAGE_DATA_UTF8' would receive the data from Data Queue in UTF8 format.
  • Line - 3: Column 'MESSAGE_DATA_BINARY' would receive the data from Data Queue in Binary format. 
  • Line - 5: Parameter 'DATA_QUEUE', Name of the Data Queue to receive the data.
  • Line - 6: Parameter 'DATA_QUEUE_LIBRARY', Name of the Library Data Queue is present in. *LIBL and *CURLIB can be used instead based on where the Data Queue is present.
We don't need to explicitly mention the parameter names while running the SQL statement and can pass the parameters similar to the usual CALL statement.

RECEIVE_DATA_QUEUE

Data is received as below and the message is cleared from Data Queue. 

RECEIVE_DATA_QUEUE

Above query would remove the message from Data Queue as soon as the data is received. There is another parameter where we can specify if the message needs to be removed from the Data Queue or not. 

RECEIVE_DATA_QUEUE

  • Line - 7: Parameter 'REMOVE' can be used to specify if the message needs to be removed. 'NO' would not remove the message from DTAQ and 'YES' would remove the message from DTAQ.
For Keyed Data Queue, Key data and Key order are the mandatory parameters. 

RECEIVE_DATA_QUEUE

In the above SQL, 
  • Line - 2: column 'KEY_DATA' would receive the key data of the message received from Data Queue. 
  • Line - 7: Parameter 'KEY_DATA', Key data of the message that would need to be received from Data Queue. 
  • Line - 8: Parameter 'KEY_ORDER', Comparison criteria to be specified. Receive Data Queue procedure would compare the Key data passed with the Key data in the message. Below are the possible values for this parameter.
EQAll messages with Key equal to Key data are to be returned.
GEAll messages with Key greater than or equal to Key data are to be returned.
GTAll messages with Key greater than Key data are to be returned.
LEAll messages with Key less than or equal to Key data are to be returned.
LTAll messages with Key less than Key data are to be returned.
NEAll messages with Key not equal to Key data are to be returned.

One other important parameter to consider is 'Wait time'. This is applicable for both Keyed and Non-Keyed data queues.

RECEIVE_DATA_QUEUE

  • Line - 9: Parameter 'WAIT_TIME' is used to specify how much time to wait for if there is no message to receive from Data Queue. Valid values are from -99,999 to 99,999.
    • Any negative value would make the procedure to wait forever for the message to receive.
    • Zero would continue the processing immediately.
    • Any positive value would make the procedure wait for the number of seconds passed in this parameter. 


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

Comments

Post a Comment

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
4 comments
Read more

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
Post a Comment
Read more

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
2 comments
Read more