The API's you are looking at are for Client Access programs?
You need to look at the header files provided with Client Access toolkit as the code would be compiled outside of the IBM I (you also need the DLLs etc that come with the toolkit to be installed)? If you want to do something on the IBM i with that data afterwards you can use the native APIs.
So you would add via the client access process and then read via the above API's.
I have not used the Client Access API's on Windows or Linux so I have nothing to share on that front.
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? 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??
From: C400-L <c400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Patrik Schindler
Sent: December 14, 2021 4:38 AM
To: Bare Metal Programming IBM i (AS/400 and iSeries) <c400-l@xxxxxxxxxxxxxxxxxx>
Subject: [C400-L] Using Data Queues in C, with V4
I'm preparing to (hopefully) get some stuff done in the upcoming holidays. :-)
Some background information for the curious ones:
One of that stuff is a metering project. I have meters for (parts of) my house's power consumption, generating a pulse on output pins after a fixed amount of energy (Watts per hour) have passed. The meter is connected to a small appliance with 12 independent input pins. This generates an UDP packet to a configurable IP address containing the current state of the inputs encoded as bits in a word (16 Bits). For every pulse, two packets are generated: One for the input being set high, and one for being set low after a very short time. By measuring the time between two 0->1 pulses per input, I can calculate the average power consumption in Watts between two pulses. This code is done, and already works well on a x86 Linux server at my home, but I want to give my 150 more meaningful work and thus port that stuff to OS/400. :-)
The frequency of 0->1 pulses can easily reach 2..3 per second, which means that Wattage calculation and (temporary) saving of the values needs to be done with very high efficiency/the least amount of work, given the challengingly limited CPU horse power of the 150. Because any delay (or variation of delay) in calculation means falsified Watt values being calculated, this task should be very small and run with the highest scheduling priority possible. I'll take care of that with a separate SBS (for an ASJ), JOBD and CLS objects.
I have tested a port of that C application to OS/400, just printing calculated watt values to stdout. Comparing the output from Linux and OS/400 in the 5250 session, they are mostly the same with only tiny deviations.
To keep the amount of work for saving values low, I want to write those values to a data queue, from within that C application, and run a low priority copy application from time to time, to move the data queue contents to the final PF for further handling.
I found an example on the IBM web page:
Unfortunately, there is no include file <iostream>, nor "cwbdq.h" in V4R5. So the shown cwbDQ_* API calls for handling data queues are unavailable.
- Does anybody know of a *working* example for handling data queues from C in V4?
- What would be a useful "trigger" to make the mentioned copy-task run? This question isn't necessarily related to C, though. But given the context I'm providing, it makes sense to ask it here, too.
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,
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
As an Amazon Associate we earn from qualifying purchases.