At The Shell Prompt
The following text illustrates the network transparency of the QNX operating system from the perspective of the shell prompt by showing some of the possibilities of how the sample programs could be run. Consider running the programs as follows by first typing
holder &at the shell prompt in order to run the holder program in background mode. The & causes the program to be run in the background. You would then run the sender program by typing its name and one of the arguments that it will accept at the shell prompt. For example:
sender t="This is a text string"would result in the sender task sending the text string in a message to the holder task which would store it in a buffer. Typing:
sender -queryat the shell prompt would result in a message being sent to the holder task to request it to reply with the text message that it has stored in its buffer. Typing
sender -killat the shell prompt would result in a message being sent to the holder task requesting that it commit suicide. All the examples so far would cause both programs to run on the same computer that the user was currently logged in to. Under the QNX operating system, you can run your programs anywhere on the network, limited only by your access permissions which are set by the system administrator. Consider the following example: Assume that you are sitting at node 5 on a QNX network. If you type the following at the shell prompt:
[2] holder & [3] sender t="This is a text string"the holder program would be loaded from your current node (5) and run on node 2. Likewise, the sender program would also be loaded from your current node, but it would run on node 3. The screen output from sender would be redirected from node 3 and would print on your own screen at node 5. If you wanted to run a program on a given node and have it's stdin, stdout, and stderr be associated with particular device (terminal, or screen) on that node you could type:
ontty [3]$tty4 sender t="This is a string"This would load the program from your current node and run it on node 3. The stdin, stderr and stdout associated with that task would be directed to $tty4 (which may happen to be a virtual screen or a terminal). It is also possible to pipe or redirect input and output by using the familiar >, >>, <, << and | characters.
