amqsact, where did my output go?

amqsact is the IBM supplied sample for viewing Application Activity Trace (AAT) data.  I was using it recently on Linux and ran into an odd situation that I thought would be helpful to blog about. 

In my Linux scenario, I wanted to use amqsact to read AAT data where the records had a channel of CLIENT.TO.SERVER and write the output to /tmp/amqsact.out.  I constructed my amqsact command as follows.  In this example, the amqsact command will connect to a queue manager called QM1, only read Application Activity Trace records that are for a channel named CLIENT.TO.SERVER, and wait an hour (3600 seconds) for no AAT messages before ending.

> amqsact -m QM1 -c CLIENT.TO.SERVER -w 3600 > /tmp/amqsact.out

I ran the above command, used another shell to invoke amqsputc to generate a PUT for this CLIENT.TO.SERVER channel, and then sent a CTRL-C interrupt to my amqsact command to end it.  When I went to the /tmp/amqsact.out file, it was zero bytes and empty.  Where did my amqsact output go?

I found an article on the internet that helps explain what happened:

https://eklitzke.org/stdout-buffering

The amqsact command I was running was sending stdout to a file called /tmp/amqsact.out.  According to the above doc, when you run a Unix shell command this way, stdout has no TTY (terminal) which results in full buffering.  Full buffering is a large user space buffer (e.g. 4096 bytes) that glibc will use to store data that needs to get written out to a file.  The data does not actually get written out to the file until this buffer is filled and glibc does a system call write to the kernel.  In my amqsact case, not enough data had been written to the glibc stdout buffer to fill it and cause a write to the /tmp/amqsact.out file.  When I sent the CTRL-C interrupt to the amqsact command, the process shut down immediately which resulted in no flush of the glibc buffer for stdout to the file.  This resulted in my output file having no data and looking like amqsact had not read any application activity trace data, which was not the case.

As a usage note, if I had let the amqsact command eventually finish, the process would have then written out the partially filled glibc buffer with the stdout data to the /tmp/amqsact.out file.  However, not wanting to wait an hour for the amqsact command to end, I sent the CTRL-C interrupt to the amqsact command which caused the observed behavior.

To remedy the situation, I changed the command to the following.  The stdbuf -oL command causes line buffering to be used for the stdout of the amqsact command.  With line buffering in use, glibc will write out the buffer to the output file whenever a line has been written to the buffer.  When I ran amqsact with this approach, the output data was all there in my /tmp/amqsact.out file after I sent a CTRL-C interrupt to my amqsact command.

> stdbuf -oL amqsact -m QM1 -c CLIENT.TO.SERVER -w 3600 > /tmp/amqsact.out

Anyway, hopefully you find this information helpful for using amasact on Linux, or also helpful for understanding how line and full buffering can change for the stdout of a shell command when there is or is not a terminal for stdout.