Using Data Queues in Modern Apps
•Descargar como PPT, PDF•
4 recomendaciones•6,413 vistas
Data Queues provide a speedy, versatile, and functional program-to program communication method and also provide a perfect coupling and transaction layer in modern application design models, aiming at separating the data processing and business logic from the presentation layer, and thus achieving independence between the back-end and the front-end of the application.
![RPG & Beyond 2009 : Using Data Queues in Modern Applications ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Using Data Queues in Modern Apps
Similar a Using Data Queues in Modern Apps (20)
Using Data Queues in Modern Apps
- 1. Using Data Queues in Modern Applications Presented by Carsten Flensburg RPG & Beyond Web Conference 2009
Notas del editor
- Welcome to this webcast discussing the employement of data queues in modern applications!
- Over the years I’ve seen data queues being used for a variety of mission critical and performance sensitive applications. Examples of such applications include OTC (On Truck Computer) distribution and billing systems, credit card transaction and monitoring systems, travel reservation systems as well as a number of full scale web business applications. Although I during this time have run into minor issues and challenges using data queues, I’m generally very impressed with the speed, robustness and functionality offered by data queues. Adding to this that the asynchronous program-to-program communication method offered by data queues also very well support contemporary application development and design models is yet another quality distinguishing data queues. When using data queues in application development you’ll sometimes encounter situations calling for the assistance of a data queue CL command in order to quickly progress the task at hand. The i5/OS operating system however only include the very basic CL commands and I’ve therefore developed my own, additional set of data queue CL commands which I will also be presenting today along with links to other on-line data queue resources.
- I’ll briefly talk about the other queue object on the i5/OS, known as a User queue and having a symbolic object name of *USRQ a little later - and also point you to articles and programming examples covering user queues. Standard data queues are data queues residing on the local system as opposed to DDM (Distributed Data Management) data queues pointing to data queues residing on other (remote) systems. The *DDM attribute refers to the original implementation of remote data queues which was established by the DDM architecture and a SNA/APPC (Systems Network Architecture/Advanced Program-to-Program Communication) infrastructure including configuration attributes such as Remote location , APPC device description , Local location , Mode and Remote network identifier and which involved all the challenges of making such a setup work. Luckily, today another, simpler approach of defining the remote location by means of the Relational Data Base (RDB) infrastructure is available – more details to follow. Note that data queue entries are sometimes referred to as messages , but for the context of this presentation I’ll simply be using the term entry . As for the significant data queue Sequence attribute the following brief explanation is intended to serve as a general guideline when defining data queues: A First-in-first-out (FIFO) sequenced data queue ensure that entries are received in the same order as they were added. This is for example useful for an application inbound transaction data queue, causing all transactions to be served in the order they arrive. A Last-in-first-out (LIFO) sequenced data queue ensure that entries are received in the opposite order as they were added. This could be useful to establish a stack type of object, for example preserving the call level order of entries in a system data queue. As call levels are added and current application or runtime values are overwritten, these are saved in the LIFO data queue and retrieved and applied on return from higher call levels. A keyed data queue supports a variety of design objectives such as ensuring that specific data queue entry processing programs receive only the entries that they are supposed to handle - or that a client submitting a data queue entry to a server will receive only the response for which it is specifically waiting.
- By local data queue I’m referring to a data queue of TYPE(*STD) as opposed to a remote data queue of TYPE(*DDM). The Maximum entry length simply defines the longest entry that it will be possible to add to the data queue. You are allowed to add shorter entries, but note that the space occupied by the entry will always be the size specified for this attribute. A value in the range of 1 to 64512 bytes is supported. The Key length of course applies to keyed data queues only and specifies required key size for entries added to the data queue. Note that the key value itself is regarded as a binary value when processed by the data queue, there’s no notion of character set or decimal precision. A value in the range of 1 to 256 bytes is supported. If you choose to Include sender ID , all data queue entries received from the data queue will include a separate data structure containing information about the job adding the entry to the data queue. This information contains the qualified job name plus the current user profile. The Force to auxiliary storage attribute specifies whether entries added to or received from the data queue are immediately forced to auxiliary storage. This ensures that the changes are not lost if a system failure occurs, but of course also adds a price tag in the form of additional system overhead. The Maximum number of entries attribute defines the maximum size that the data queue will be allowed to occupy and consequently also controls how many entries it is possible to add to the message queue at any time. In high volume transaction applications you could very quickly reach the point where it is no longer possible to add entries to a data queue, if the job(s) processing the entries for some reason come to a halt. This point may also be reached if the processing jobs’ are falling behind due to lack of scalability in an application. The Initial number of entries specifies how much space is initially allocated for the data queue. Once this limit is reached the data queue will have to be extended to allow further entries to be added, an operation causing delay and the use of system resources. Since data queues are allowed to grow up to a size of 2 gigabytes it is quite useful easily being able to reclaim this storage. The Automatic reclaim parameter controlling whether the storage allocated to the data queue is released whenever the entry count goes from one to zero. At that point the value *YES indicates that the storage allocated should be reset to reflect the value specified for the Initial number of entries attribute.
- And here it’s the other way round: By remote data queue I’m referring to a data queue of TYPE(*DDM) – as opposed to a local data queue of type (*STD). The Remote Data Queue specifies the name of the existing data queue on the remote system and this is the target of the data queue operation performed against a remote data queue and the actual physical location of data queue entries. The Remote location attribute identifies the system where the remote data queue resides. Setting this attribute to the *RDB special value you only have to also specify the Relational database attribute to complete the data queue description as far as connectivity is concerned. Choosing the SNA/APPC option you’ll further have to specify the correct APPC Local location , Mode as well as Remote Network Identifier attributes for the configuration to be operational. At the end of this presentation I’ve included links to IBM Technical Documents describing in detail how to configure both SNA/APPC and RDB/TCPIP. I clearly recommend the latter option because IBM plans to discontinue SNA at some point in the future and the RDB configuration is much simpler to perform. More about the RDB approach in a minute. As for the application design perspective DDM data queues offer a convenient way to let two applications on different System i servers communicate with each other. One scenario could be two companies that want to integrate their business applications due to a business merger effort. Another scenario could be the desire to integrate a business application running on one server with a new finance application running on yet another server. And a third example could be a web front-end application needing real-time access to a back-end business application running on a central server behind the company firewall.
- If there’s no RDB entry for the system you want to connect to, use the Add Relational Database Directory Entry (ADDRDBDIRE) command to add it. Follow the help text of the ADDRDBDIRE command or the IBM Technical Document (link at the end of this presentation) to create the RDB directory entry. I keep the names of the local and remote data queues the same while the libraries of the respective data queues might vary from system to system. In the following example, the RDB server name is CPHDB01, and the data queue name is WEBINBDQ in library QGPL on both systems: CRTDTAQ DTAQ(QGPL/WEBINBDQ) TYPE(*DDM) RMTDTAQ(QGPL/WEBINBDQ) RMTLOCNAME(*RDB) RDB(CPHDB01) TEXT('Web application inbound data queue') To avoid the user profile and password synchronization requirement you can use a Server Authentication Entry to store the remote user profile name and password. In the following example, I use the data queue application user profile WEBAPP as the local user profile and the RDB Entry name as the server name to achieve a successful connection with the remote user profile CPHWEBUSR: ADDSVRAUTE USRPRF(WEBAPP) SERVER(CPHDB01) USRID(CPHWEBUSR) PASSWORD(remote password). Before adding server authentication entries on your system, please refer to "Source System Security in a TCP/IP Network — Server Authentication" (link at the end of this presentation), which includes a thorough discussion of the Retain Server Security (QRETSVRSEC) system value. The WEBINDBDQ data queue must exist in library QGPL on the remote system and the connection to the remote system be operational. Otherwise, the Send Data Queue (QSNDDTAQ) API call adding the data queue entry immediately will return an exception specifically indicating the cause of failure. Performing the same drill for the WEBOUTDQ data queue on the two systems should lead to the existence of an inbound data queue and an outbound data queue on both systems. I usually keep the local data queue on the system on which the data queue entries are being processed. So I put data queue entries on a DDM data queue, and I get data queue entries from a local data queue. That way, when sending the data queue entry, I immediately know whether the communication was successful, and I also consistently know where to perform recovery and error processing.
- The Create Data Queue (CRTDTAQ) command creates a data queue description. The Delete Data Queue (DLTDTAQ) command deletes a data queue and implicitly all entries within it. The Work with Data Queue (WRKDTAQ) command displays a panel listing all selected data queues. From the panel you can run the CRTDTAQ, DLTDTAQ as well as Change Object Description (CHGOBJD) command. The Clear Data Queue (QCLRDTAQ) API clears all or, if the data queue is keyed, a selected range of entries from a data queue. The Receive Data Queue (QRCVDTAQ) API receives a single entry from the specified data queue. The Retrieve Data Queue Description (QMHQRDQD) API retrieves information about a data queue. The Retrieve Data Queue Message (QMHRDQM) API retrieves one or more entries from a data queue without removing the retrieved entries. The Send to a Data Queue (QSNDDTAQ) API sends data to the specified data queue. The Change Data Queue (QMHQCDQ) API allows you to change selected data queue attributes. Introduced with release 6.1 It is also worth noting that you can journal local data queues. Issuing the Start Journaling Object (STRJRNOBJ) command against a data queue causes all actions, including entry data being added or removed, against the data queue to be logged to the journal specified. The End Journal Object (ENDJRNOBJ) command terminates the journal logging against the data queue. As mentioned earlier the offering of native Data Queue CL commands available is far from impressive. Developing, testing and debugging data queue applications quickly prompts the need of CL commands offering functionality similar to what is provided by the listed APIs. In an attempt to fill that gap I’ve created 6 additional CL commands allowing you to display and copy data queue description, send, display and clear data queue entries as well as an enhanced work with data queue command providing an interface to all relevant data queue commands. More about this later. When designing and building applications relying on the use of data queues, the core data queue functionality is mainly delivered by the Send to a Data Queue and the Receive Data Queue APIs, respectively – so let us have a closer look at that dynamic duo.
- For those of you being used to API programming it’s obvious that the QSNDDTAQ and QRCVDTAQ APIs do not follow the regular API convention for declaring API parameters. Seeing parameters of type packed decimal is not an everyday experience in an API programmer’s life and in this case points back to these APIs history as belonging to the first set of APIs made available by IBM all the way back in the days of the System/38. In fact you’ll find early documentation of the small group of historic APIs in the System/38 Environment Programming manual, Version 3; page 38, at the following location: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books/sc413735.pdf#page=38 QSNDDTAQ error handling: The general API error data structure parameter is missing, so in order to catch exceptions following a call to the QSNDDTAQ API you have to resort to the appropriate facilities provided by your programming language. For RPG/IV that usually resolves into an CALLP(E) opcode extender or a MONITOR group, but other options are also available as documented and discussed by the ILE RPG Programmer's Guide section on Handling Exceptions: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/books/c092507602.htm The Asynchronous request parameter defines whether a send data queue request to a DDM data queue is processed asynchrounously. This parameter consequently only applies to DDM data queues. The eight parameter Data is from a journal entry applies to a scenario where the data queue object itself is journaled. Check out the QSNDDTAQ API documentation for more information.
- If optional parameter group 1 is employed you must ensure that a program variable is specified for parameter 10, Sender information , even if parameter 9, Length of sender information , specifies a length of zero. Failing to do so will cause the call to QRCVDTAQ to return the exception message CPF24B4, Severe error while addressing parameter list. Another caveat is based on a data queue object cache maintained by the operating system: Internally, when a job uses the QSNDDTAQ, QRCVDTAQ, QMHQRDQD, or the QMHRDQM API, a cache is created to allow faster access to the data queue. An entry in the cache means a user is authorized to the data queue. An entry is added to the cache when a user calling one of the APIs has the required authority to the data queue. An entry is also added to the cache when QSNDDTAQ is called to handle a journal entry for a data queue created with the sender ID attribute set to *YES, and the user requesting the send function has the required authority to the current profile name in the sender ID information of the journal entry. The data in the cache is used until the job ends, so if you need to immediately change a user's authority to one of these objects, you may need to end that user's jobs. The cache also implies that if you rename or move a data queue which already has been accessed by a program, the program will continue to address the original data queue, irrespective of an identical named data queue being placed in the same library. Check out the API data queue library documentation for the mentioned APIs for more details.
- The data queue entry retrieval performed by the QMHRDQM API is non-destructive. That implies that all entries retrieved remain in the data queue. This behavior makes the QMHRDQM API an ideal candidate to perform data queue monitoring duties. This allows you for example to detect if entries with a specific key value are not being processed or are queueing up and then perform the necessary recovery action of either reporting the problem or starting the appropriate server job.
- The Receive Data Queue (QRCVDTAQ) API receives data (i.e. an entry) from the specified data queue. When more than one program has a receive pending on a data queue at one time, a data entry sent to the data queue is received by only one of the programs. The program with the highest run priority receives the entry. The next entry sent to the queue is given to the job with the next highest priority. This is very practical in a testing or debugging scenario. By changing the job run priority of your job running the program that calls the QRCVDTAQ API to a value lower (higher priority) than other jobs accessing the same data queue, you ensure that your job will receive the next data queue entry arriving at the data queue. Whenever the last entry on the queue is received, the storage allocated to the data queue will be reduced to the storage needed for the initial number of entries defined for the data queue, given that the data queue was created with the AUTORCL keyword on the Create Data Queue (CRTDTAQ) command set to *YES. Distributed data management (DDM) data queues are supported using this API. This means that you can use this API to receive a message from a data queue that exists on a remote IBM System i. However, using this API to receive messages without removing them from the data queue is not supported for DDM data queues.
- The Send Data Queue (QSNDDTAQ) API sends data (i.e. an entry) to the specified data queue. Note that the storage allocated for each entry will be the value specified for the maximum entry length on the Create Data Queue (CRTDTAQ) command, irrespective of the value specified for the data length on the QSNDDTAQ call. Distributed data management (DDM) data queues are supported using this API. This implies that you can use the QSNDDTAQ API to send data to a data queue that exists on a remote IBM System i. The Clear Data Queue (QCLRDTAQ) API clears all data from the specified data queue, or clears messages that match the key specification from a keyed data queue. If the data queue was created with the AUTORCL keyword on the Create Data Queue (CRTDTAQ) command set to *YES, the clear operation will cause storage allocated to the data queue will be reduced to the storage needed for the initial number of entries defined for the data queue. Distributed data management (DDM) data queues are supported using this API. This means that you can use this API to clear a data queue that exists on a remote iSeries. Clearing messages by key is however not supported for DDM data queues.
- The Retrieve Data Queue Description (QMHQRDQD) API retrieves the description and attributes of a data queue. Examples include the number of entries currently on the data queue, the text description of the data queue, whether the queue includes sender ID information, and whether the data queue is keyed. The attributes of a distributed data management (DDM) data queue can be retrieved with this API. The Retrieve Data Queue Message (QMHRDQM) API retrieves one or more messages from a data queue, thereby enabling the retrieval of multiple messages per call. The message selection information parameter allows you to have some control over which messages are returned and allows you to specifically retrieve one of the following: The first or last message of a data queue All messages of a data queue Selected messages from a keyed data queue The QMHRDQM API is similar in function to the QRCVDTAQ API. However, the QRCVDTAQ API can remove the received message from the data queue; QMHRDQM API does not remove received messages. Distributed data management (DDM) data queues are not supported using this API.
- The QMHQCDQ API introduced with release 6.1 allows you to alter a data queue objects auto reclaim storage attribute as well as a new lock enforcement attribute controlling whether object locks issued against the data queue should be enforced or not. Here’s a brief example demonstrating how to set up the call to the QMHQCDQ API: **-- Global constants: D AUT_RCL c 100 D ENF_DTQ_LCK c 200 /Free RqsChg.VarLenRcd(1).ChgKey = AUT_RCL; RqsChg.VarLenRcd(1).ValLen = %Size( VarLenRcd.NewVal ); RqsChg.VarLenRcd(1).NewVal = '1'; RqsChg.VarLenRcd(2).ChgKey = ENF_DTQ_LCK; RqsChg.VarLenRcd(2).ValLen = %Size( VarLenRcd.NewVal ); RqsChg.VarLenRcd(2).NewVal = '1'; ChgDtaQ( PxDtaQue_q : RqsChg : ERRC0100 ); /End-Free
- The Sender information data structure used when calling the QRCVDTAQ API with optional parameter group 1. A total length of 44 bytes in its current incarnation.
- The Retrieve Data Queue Description (QMHQRDQD) APIs return data structure format for local data queues – RDQD0100.
- The Retrieve Data Queue Description (QMHQRDQD) APIs return data structure format for remote data queues – RDQD0200.
- The Retrieve Data Queue Message (QMHRDQM) API offers two message selection formats: The RDQS0100 format to select messages when using non-keyed data queues. The RDQS0200 format to select messages when using keyed data queues.
- In the following I’m going to demonstrate how to use data queues to establish a communication layer between two programs, and in that context discuss some of the problems and considerations involved in designing and developing data queue applications. Using DDM data queues, the programs communicating through data queues can reside on different servers if required. They can even be on different platforms. For example, both Visual Basic and Java offer programmable interfaces to data queues. Look up the links at the end of this article for more information about DDM data queues as well as VB and Java data queue support.
- The receiving program will already have been activated at the point at which it is waiting on the data queue for messages to arrive. The call level has been established, initiation activities performed, and the data queue has been located and authority has been verified. More than on e process or job can be waiting on the same inbound data queue, so that as many messages can be processed in parallel, as server jobs have been submitted. The sending job includes a reply key to uniquely identify the request, and that key is used when the request processor returns the reply message to an outbound keyed data queue. Specifying that reply key on the receive data queue API call ensures that the receiving job gets the correct reply from the outbound data queue. Using a keyed inbound data queue, you can have different server jobs waiting against the same data queue for different types of request to process. One client could issue three different request messages, have them processed in parallel by three different server jobs, and then continue processing when all reply messages have been returned. One request could also be distributed to different applications or servers by sending the same request to different data queues and then having the reply messages consolidated into a single reply upon return. I should add to point number one that if you are chasing the last milliseconds, only user queues are more efficient in performing queue services than data queues. This speed, however, has its price in that user queues are a bit more complex and difficult to program. At the end of this presentation I provide a link to an article that explains and demonstrates how to program user queues – just in case you're interested in pursuing or evaluating that option.
- Message Format: What kind of formatting should be applied to the message? Message Extensibility: How should we handle changes in or additions to the message format? Message Size Limit: Some message types are by nature limitless in size. For example, when embedded lists or textual descriptions are involved, it might be impossible or senseless to define the maximum message length to cover the longest imaginable message length. Error and Event Communication: How should error and informational messages be communicated within the data protocol, to ensure a correct and helpful dialogue with the application user? Language Support: Do you need to support more than one language within the data protocol? Exception Tolerance: It is very important to include in your application design an exception trap mechanism that catches — and communicates back — unforeseen errors. Debug Facility and Application Monitoring: How do you provide for daily monitoring of the application and investigation of problems and errors?
- If you stick with data structures, your design should allow for varying-length subfields, to avoid space constraint problems. To achieve this objective, keep a fixed-length part of the data structure, which includes offset and length fields defining the location and length of the varying-length subfields. This concept is similar to what is used by many of the APIs that return information in a receiver variable defined by a data structure.
- The Data protocol identifies the exchange format in general and the same value is used for all types of data exchange within the application. If the same data queue is used for different servers this value determines the server to which the request is routed. The Transaction ID uniquely identifies each inbound transaction and also ties the request and the reply message together. The Request ID defines the type of request that is performed by the client and in turn routes the request to the appropriate server function in charge of handling this type of request. The Message format specifies the layout and content of the message exchanged and allows you to vary both elements for the same request ID, depending on the actual circumstances and change in requirements.
- The request message uses the number-of-list-entries field to indicate how many list entries are needed to build one page, and it uses the list-offset field to define where the list should start. If the latter field is empty, the list begins with the first entry. The response message uses the number-of-list-entries field to indicate how many entries are returned, and it uses the list-offset field to indicate whether there are more entries to request. If this field is empty, the list is complete; otherwise, the value is to be used in the subsequent request message to retrieve the next page, thereby ensuring that this page begins at the correct list position. Whereas these methods of preserving information between client and server job are stateless by nature, other methods involve establishing this persistence by means of a stateful message dialogue, typically by assigning and exchanging a session ID or session handle. The session ID is then used to identify the storage location needed to preserve the persistent information. This could be a record in a file, a data area, a user space, a user index, or something similar. If such a design is chosen, it is important to include a mechanism in the protocol to signal when the use of the session ID has completed, so that the associated allocated storage can be released — and the session ID safely reused.
- In general, it is much easier and straight forward to add support for error and event communication as well as language considerations up front, as opposed to establishing such mechanisms further down the road. Again the time spent early in the project getting the application design and the individual components right before embarking on the implementation path clearly offers a substantial pay-back.
- A useful approach to covering this angle is to develop a general model for the catching, registration and communication of this type of event for your application in its entirety. Once the model is devised and facilitated it’s simple to apply to your modules and programs as you move along, and ensures and supports a consistent and well documented behavior of your application. This also makes investigation and debugging of incidents at a later point in time much easier and faster to perform.
- To sum up all these considerations, let me continue with the practical implementation in a sample application context. In a real-life business application, the data exchange would include customer, product, pricing, availability, order, accounting, payment, and many other types of information and transactions, but to avoid the problem of generating test data, for this purpose I've simply chosen to use some information already available on your system to demonstrate a data queue–driven application: The TCP/IP server start information in the system file QATOCSTART. Your part of this demonstration is therefore to envision all the types of information being distributed and exchanged in real business applications of similar design and architecture. For this purpose, I've created the Display TCP/IP Servers (DSPTCPSVR) command, which displays a list of all or a subset of the TCP/IP servers available on your system. Using the display option in the list panel, you can further display all the selected server's start attributes from the QATOCSTART file.
- Using the QATOCSTART file layout, I then continue the design efforts by deciding which file fields to include in the TCP/IP server list. The server name, being the primary key as well, is a good start. The server type and autostart information completes the list. The remaining fields are then included in the full server attribute message.
- The next step is to decide what information my request and response message headers should include and, as part of that consideration, how the server list data exchange should work.
- Given the limited number of file records and the limited amount of server information, simply returning all server information in the list would be no problem. The reason for not doing that is of course the intention of demonstrating how to build the two different types of data exchange. To complete the picture, I have also created the following two examples of log files to capture errors and events as well as the transaction dialogue:
- Now it's time to have a look at the data queue setup. For this application, there is a separate data queue for inbound and outbound transactions, respectively. Separating the data flows makes great sense for a number of reasons, including the above mentioned.
- Both commands are part of the CL program to build the sample data queue application found following the link below: http://www.pentontech.com/IBMContent/Documents/article/54098_170_DataQueue5.zip
- Here’s a list of all sources involved in this data queue sample application. To create all the above objects, copy all sources to their respective source files in your library, then compile and run CBX169M. Compilation instructions are found in the source headers as well.
- To get a closer look at the transaction dialogue and how the various parts of the sample application play together, you could also step through the programs as they run in a source debug session. This concludes the program-to-program data queue communication sample application. Besides program-to-program communication, data queues are also employed by the IBM System i operating system for system-to-program communication. I’ve gathered a list of such uses as well as links to programming examples demonstrating how to take advantage of this facility.
- Data Queue CL commands source file specifications: CBX165 -- Display Data Queue Description - CPP CBX165H -- Display Data Queue Description - Help CBX165P -- Display Data Queue Description - Panel Group CBX165V -- Display Data Queue Description - VCP CBX165X -- Display Data Queue Description CBX1652H -- Clear Data Queue - Help CBX1652X -- Clear Data Queue CBX1653H -- Send Data Queue Entry - Help CBX1653X -- Send Data Queue Entry CBX165M -- Data Queue Commands - Build commands CBX166 -- Copy Data Queue Description - CPP CBX166H -- Copy Data Queue Description - Help CBX166O -- Copy Data Queue Description - POP CBX166V -- Copy Data Queue Description - VCP CBX166X -- Copy Data Queue Description CBX166M -- Copy Data Queue Description - Build command CBX167 -- Display Data Queue Entries - CPP CBX167E -- Display Data Queue Entries - UIM General Exit Program CBX167H -- Display Data Queue Entries - Help CBX167L -- Display Data Queue Entries - UIM List Exit Program CBX167P -- Display Data Queue Entries - Panel Group CBX167V -- Display Data Queue Entries - VCP CBX167X -- Display Data Queue Entries CBX167M -- Display Data Queue Entries - Build command CBX168 -- Work with Data Queues - CCP CBX168E -- Work with Data Queues - UIM Exit Program CBX168H -- Work with Data Queues - Help CBX168P -- Work with Data Queues - Panel Group CBX168V -- Work with Data Queues - VCP CBX168X -- Work with Data Queues CBX168M -- Work with Data Queues - Build command
- Running the command WRKDTAQ2 DTAQ(*ALL/Q*) shows the above list panel on my system. For each listed data queue you have the option of running the SNDDTAQE, CPYDTAQD, DLTDTAQ, DSPDTAQD, DSPDTAQE, CHGOBJD and CLRDTAQ commands.
- IBM documentation for data queue support: Use Data Queues: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/qcomm.htm Examples: Using Data Queues or User Queues: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apiref/ExTaskDataque.htm ICFF & Display File — Example Using a Data Queue: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/apis/apiexusque.htm Data Queue Support for Spooled Files: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzalu/rzaludataq.htm Job Notification Exit Point: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/apis/xjobntfy.htm
- Programming examples of data queue usage: Mystifying Timeout Messages — Tech Corner, July 1996: http://www.systeminetwork.com/article.cfm?id=1539 INVITE a Timeout — Tech Corner, May 1996: http://www.systeminetwork.com/article.cfm?id=1592 Automatic Spool Rerouting — March 31, 2004: http://www.systeminetwork.com/article.cfm?id=18333 Automatic Notification When Spool Files Created — March 17, 2004: http://www.systeminetwork.com/article.cfm?id=18244 Realtime Job Monitor — August 19, 2004: http://www.systeminetwork.com/article.cfm?id=19252 Synchronizing Passwords Between Systems — July 21, 2004: http://www.systeminetwork.com/article.cfm?id=18986