× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


OK the link I passed in is all of the Native Data Queue APIs that are available and according to the documentation have been available since V1R1.. You should use these in any native programs that you write.

Not sure how the data is collected (passed to the 150 or an internal program is getting the data directly from the appliance??) but these API's are very efficient (I use them for all my data collection processes where I need a quick write and slow read and processing process)

There are some examples around that I have written (Blog or github) but the API's are very easy to use and the documentation is pretty clear. I use keyed data queues a lot but the FIFO queues would be suitable for your purpose here (unless you wanted to differentiate and have stop messages pushed through the queue).

Anyhow, the API's in the manual should suffice for your needs. If you really need a sample look through the examples.


The user queue API may also be of use?


-----Original Message-----
From: C400-L <c400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Patrik Schindler
Sent: December 14, 2021 9:47 AM
To: Bare Metal Programming IBM i (AS/400 and iSeries) <c400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: [C400-L] Using Data Queues in C, with V4

Hello Chris,

glad do hear from you again!

Am 14.12.2021 um 15:27 schrieb Chris Hird <chrish@xxxxxxxxxxxxxxxxxx>:

The API's you are looking at are for Client Access programs?

Hmm. Did I get something wrong? Are cwbDQ_* functions client access specific? If the answer is yes, then: Which functions do I need to work with Data Queues on OS/400 from within C?

An Alternative approach would be to create a Client server process where the external server collecting the data would send the data to the server via IP and then a process on the IBM I would take that data and write to the Data queue for later consumption?

Honestly, I don't want to distribute the functionality over multiple hosts.

The use of an IP based process would be similar to a web server so the number of transactions per second could be pretty large. The source would just have to do a send() and not bother about confirmation of receipt outside of the return from the send function so I would think that would be very efficient?? As long as the recv() is done efficiently I cannot see the target buffers being a problem either??

I already have an IP based process on OS/400. :-) It's just not yet writing the calculated values anywhere but stdout (a scrolling screen in a 5250 session).

I want to save that received-and-calculated data with a good compromise between least overhead, and easy consumption by an "archiver". Thus I thought, a Data Queue might be a good fit.

Maybe the 150 is fast enough to allow me to directly do a _Rwrite to a PF. If I can't find out how to cope with Data Queues, on V4, in C, I probably have no choice to try that out.

:wq! PoC

This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list To post a message email: C400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxxxxxxxx Before posting, please take a moment to review the archives at https://archive.midrange.com/c400-l.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2023 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.