IBM i Access API for C++ lets you run server commands for example (DSPSYSSTS Displaying system status):
cwbSV_ErrHandle msgHandle; //Error Handle
cwbSV_CreateErrHandle(&msgHandle); //Create Error Handle
int code = cwbRC_RunCmd(SystemData::hxSystem, "DSPSYSSTS", msgHandle); //Run command
//Command ran successfully
if(code == CBW_OK){
int code = cwbSV_GetErrText(msgHandle, returnTxt, 1024, NULL);
//code value is CWBSV_NO_ERROR_MESSAGES
}
I can retrieve error messages thrown by the server after command run. But how can I retrieve the command output? If I run a "DSP" (Display) command, I'm obviously wanting to get the output display.
DSP type commands by definition send their output to the 5250 data stream which is then interpreted by a 5250 emulator in order to properly paint a display. It's not at all like stdout, which means that intercepting output meant for a display will require a fair amount of work.
The traditional answer is to use an API which returns the information in a form intended to be read by a program. In the case of system status, that's probably the Retrieve System Status (QWCRSSTS) API. One way to make this easy on yourself is to write a stored procedure and call that instead of directly invoking the API from the client.
Another alternative is to DSPSYSSTS OUTPUT(*PRINT), then read the spooled file. It'll be easier to parse than the raw 5250 output but it can and does change between releases so the API is a more consistent interface.
If you really want to screen scrape the output from DSPSYSSTS, you'll need to learn about the 5250 protocol, which is complex enough that I don't think it can be explained in a forum like this. On the other hand, Albert York has written a program called TNAPI which might fit your needs.
Use Scott Klement explaning to translate Retrieve System Status (QWCRSSTS) API into C++ code. This way you dont need rpg at all.
Related
I have two loggers in my program. One that I made inside a gui, and one that is super complicated but very well designed and prints to the console. I am trying to get the output from the nice console logger to the rendered one. I have tried everything under the sun to get this to work but I can't seem to figure it out (due to my lack of understanding of the code from the other logger(spdlog).) My conclusion is that taking the logs directly from what is printed is the best way to do this but I can't find online anyone asking how to do this. I have seen a few questions but they just post code as an answer and don't really explain what is going on. My question: Is there a way to grab printed statements from the console and what are the performance issues/complications that come with doing something like this.
For example, if i do std::cout << "hello!" << std::endl; or some printf statement, I want to be able to further down in the code be able to grab "hello!"
My conclusion is that taking the logs directly from what is printed is the best way to do this but I can't find online anyone asking how to do this.
Consoles nowadays are terminal emulators. The original terminals' output went to printers and couldn't be (easily) read back.
Application's stdout and stderr (console) streams are write-only. Moreover, in Windows and Unix/Linux you can pipe your program's (console) output (either or both stderr and stdout) into another application with | (pipe) that creates a pipe IPC between stdout of your application and stdin of another one. That IPC pipe is write-only, your application cannot possibly read back from it.
You may be able to get access to the contents of the frame buffer of Windows cmd.exe that controls its Windows console window, but that won't be the verbatim byte-exact copy of data you wrote into stdout because of the escape sequences interpreted by Windows console.
If stdout is redirected into a file you can re-open that file for reading, but there is no portable way to re-open that file.
In other words, there is no portable way to read console output back.
I have tried everything under the sun to get this to work but I can't seem to figure it out (due to my lack of understanding of the code from the other logger(spdlog).
I bet you haven't tried reading spdlog documentation, in particular logger with multi sinks. A sink is an output abstraction, which implementation can write into a file, memory or both. What you need is attach your own sink to spdlog that prints into your UI.
Derive your sink from base_sink and implement abstract member functions:
virtual void sink_it_(const details::log_msg &msg) = 0; to print into the UI, and,
virtual void flush_() = 0; to do nothing.
Then attach one object of your sink class to that spdlog.
I have created a program that extracts data from a racing game and sends it to a speed gauge cluster. I call it the transfer program.
I need a simple user-friendly User Interface to start the transfer program, set some variables and choose a COM Port. At the moment I'm trying to do it with a C++ Windows Forms Application in a CLR Project on Microsoft Visual Studio 2015. When I tried to do it directly (creating the UI in the same project as the transfer program) I just get too many errors that I have no idea where they come from or why they are there.
So I've decided maybe I could try creating some sort of launcher, i.e. a completely different program that is only the UI to start the transfer program and send a few user-set variables to it on startup as well as choose a COM Port to communicate on.
Any idea on how to start on this? How do I execute the transfer program from the Launcher? How do I send variables and data to it?
Thank you very much!
There are basically two ways to pass information to your transfer program.
For simple use cases, just pass the values along on the command line. If you're still using the CLR, this is done using System.Diagnostics.Process. A nice example can be found in this answer: https://stackoverflow.com/a/33633148/127826
Use a shared configuration file. So the user interface loads the values from the config and also saves the file before executing the transfer program. The transfer program then reads the same configuration file to get the values it needs.
The second approach is far more flexible and is what I would use.
I am working on a windows sever program using c++, when the program started it stays for several days and output important logs to the default windows console.
now I want to add some control function to the console, like I cound enter something like query or stop, and the program ouput the variable number or stop accept requests. So there is the problem, I got two output stream(log and query response) and one input stream both mixed in one single console.
How do I seperate the three different stream in one single console? Maybe I cound write my own console to replace the default windows console?
I believe this is a very normal need and a lot of server application has implemented this but I could not find any source code...
I know I could use ncurses, but I think ncurses seems too low level for this. Any suggestion will be apprecitated.
There is a program in java (Minecraft) and for the server part of it, it opens up in a terminal and prompts the user for commands, as well as give feedback for loading progress and other stuff. How can I make a c++ "wrapper" to automatically send commands to the terminal, and receive the response?
I could automate commands such as say and kick with GUI elements. I am running a mac with OSX Lion.
It presumably reads and writes stdin/stdout. You should look up executing a binary (in this case java.exe) in c++ and how to read and write to it. Alternatively, you could write a wrapper in Java that gives you control without having to parse the text output.
The answer to this question would depend on the operating system as different systems use different approach how to deal with the standard input and output channels. On a UNIX system you'd create a pipe(2) (or two if you want to capture standard output and standard error separately), fork(2) the "server", use close(2) and dup(2) to put the various file descriptors into place, and then execve(2) the actual program. After this you can read/write to various descriptors.
I have a project that I thought was going to be relatively easy, but is turning out to be more of a pain that I had hoped. First, most of the code I'm interacting with is legacy code that I don't have control over, so I can't do big paradigm changes.
Here's a simplified explanation of what I need to do: Say I have a large number of simple programs that read from stdin and write to stdout. (These I can't touch). Basically, input to stdin is a command like "Set temperature to 100" or something like that. And the output is an event "Temperature has been set to 100" or "Temperature has fallen below setpoint".
What I'd like to do is write an application that can start a bunch of these simple programs, watch for events and then send commands to them as necessary. My initial plan was to something like popen, but I need a bidrectional popen to get both read and write pipes. I hacked something together that I call popen2 where I pass it the command to run and two FILE* that get filled with the read and write stream. Then all I need to do is write a simple loop that reads from each of the stdouts from each of the processes, does the logic that it needs and then writes commands back to the proper process.
Here's some pseudocode
FILE *p1read, *p1write;
FILE *p2read, *p2write;
FILE *p3read, *p3write;
//start each command, attach to stdin and stdout
popen2("process1",&p1read,&p1write);
popen2("process2",&p2read,&p2write);
popen2("process3",&p3read,&p3write);
while (1)
{
//read status from each process
char status1[1024];
char status2[1024];
char status3[1024];
fread(status1,1024,p1read);
fread(status2,1024,p2read);
fread(status3,1024,p3read);
char command1[1024];
char command2[1024];
char command3[1024];
//do some logic here
//write command back to each process
fwrite(command1,p1write);
fwrite(command2,p2write);
fwrite(command3,p3write);
}
The real program is more complicated where it peeks in the stream to see if anything is waiting, if not, it will skip that process, likewise if it doesn't need to send a command to a certain process it doesn't. But this code gives the basic idea.
Now this works great on my UNIX box and even pretty good on a Windows XP box with cygwin. However, now I need to get it to work on Win32 natively.
The hard part is that my popen2 uses fork() and execl() to start the process and assign the streams to stdin and stdout of the child processes. Is there a clean way I can do this in windows? Basically, I'd like to create a popen2 that works in windows the same way as my unix version. This way the only windows specific code would be in that function and I could get away with everything else working the same way.
Any Ideas?
Thanks!
On Windows, you invoke CreatePipe first (similar to pipe(2)), then CreateProcess. The trick here is that CreateProcess has a parameter where you can pass stdin, stdout, stderr of the newly-created process.
Notice that when you use stdio, you need to do fdopen to create the file object afterwards, which expects file numbers. In the Microsoft CRT, file numbers are different from OS file handles. So to return the other end of CreatePipe to the caller, you first need _open_osfhandle to get a CRT file number, and then fdopen on that.
If you want to see working code, check out _PyPopen in
http://svn.python.org/view/python/trunk/Modules/posixmodule.c?view=markup
I think you've made a very good start to your problem by using the popen2() function to abstract away the cross-platform issues. I was expecting to come and suggest 'sockets', but I'm sure that's not relevant after reading the question. You could use sockets instead of pipes - it would be hidden in the popen2() function.
I am 99% sure you can implement the required functionality on Windows, using Windows APIs. What I cannot do is point you to the right functions reliably. However, you should be aware the Microsoft has most of the POSIX-like API calls available, but the name is prefixed with '_'. There are also native API calls that achieve the effects of fork and exec.
Your comments suggest that you are aware of issues with availability of data and possible deadlocks - be cautious.