Re: How to properly end a C program using stdio with F3

Hello,

it's been a while, but for searchability, I want to provide a definitive answer to my question, after having learned an awful lot. Hopefully, others might benefit!

Am 29.01.2020 um 19:37 schrieb Patrik Schindler <poc@xxxxxxxxxx>:

I can't end this program with F3 in the "fake terminal". The keyboard gets locked (like the AS/400 does when it's busy) and thus doesn't accept any keys. Even pressing reset and immediately F3 yields no program ending: The keyboard gets locked again.

I read the two Unix porting guides:
- UNIX C Applications Porting to AS/400 Companion Guide.pdf
- UNIX C Applications Porting to AS/400.pdf

But I haven't found any mentioning how to handle a similar situation. I also browsed through the ILE C/C++ Programmer's Guide.pdf, with also no helpful findings.

May I kindly ask for advice? Thanks!

There is no way to "properly" end a simple terminal-running application with F3, unless it is allocating a terminal device through the use of a display file. This enables the proper usage of function keys. Interaction by simply running an application on a 5250 command line isn't possible, because OS/400 has no inherent concept of stdin/stdout. There is no "connection" between the application and the terminal itself. Thus the keyboard gets locked until the application voluntarily ends, or is "killed" (SIGKILL?) by forcing a system request and doing an endrqs (option 2 on the sysreq menu).

In addition, if you use sockets and kill the application as described, the socket doesn't get closed immediately. You can't restart your next test iteration because of an "address already in use" error. You need to use NETSTAT *CNN, and manually close that socket with option 4. So much for the brute force aspect.
Running an application for testing purposes directly in a terminal thus isn't really comfy. The correct way to run a background application is to submit it to batch. (Caution! With standard parameters, the job will run in the QBATCH subsystem and tie up your single slot of parallel runnable applications in QBATCH!)

Others have mentioned "*STOP" messages but it's not clear what exactly is meant by that. Confusion arises from mentioning data queues, in-band "data" on a socket to make the application quit, and the web link by Ron Unknown points to an IBM page mentioning UNIX type signals — in this case to prioritize OOB data reception to make the application quit.

I have described a way to use standard UNIX SIGTERM in a convenient way to be used for proper ending of background tasks here:

https://try-as400.pocnet.net/wiki/Properly_ending_a_daemon_written_in_C

This works like a charm, including ENDJOB, and ENDSBS.

:wq! PoC