
{PURPOSE:
{
{ IIP$VTP_PUT_NEXT conceptually replaces AMP$PUT_NEXT and AMP$PUT_PARTIAL.  It
{ bypasses the Interactive FAP associated with the AMP$ interfaces and calls
{ NAM/VE directly.  The application is responsible for device dependencies.
{
{ IIP$VTP_PUT_NEXT sends a message to the network.  The parameters
{ resemble AMP$PUT_NEXT, but there are essential behavioral differences:
{
{ 1. AMP$PUT_NEXT sends text, while IIP$VTP_PUT_NEXT sends a VTP message.
{ Note that text messages can be folded into the VTP protocol with the
{ appropriate header, IIT$VT_OUTPUT_INFORMATION.
{
{ 2. AMP$PUT_NEXT works with AMP$GET_NEXT to keep track of connection
{ attributes for various instances of open, and to download any changes
{ as needed.  IIP$VTP_PUT_NEXT is intended to be used with IIP$VTP_GET_NEXT,
{ and there is no concept of even saving connection attributes per instance
{ of open.  The application is responsible to know when connection attributes
{ should be downloaded, and can do so only thru IIP$VTP_PUT_NEXT with the right
{ VTP message; ie, you cannot use IFP$STORE_TERM_CONN_ATTRIBUTES.
{
{ 3. AMP$PUT_NEXT attempts to compact text messages into a large buffer,
{ to reduce the number of actual VTP messages to the network.  IIP$VTP_PUT_NEXT
{ always calls the network, thus it is up to the application to perform
{ any buffering for best performance.   THIS IS VERY IMPORTANT!
{
{ 4. AMP$PUT_NEXT and AMP$GET_NEXT work together to manage the "partial"
{ bit to help the network know when to perform delayed echoing if the
{ "solicited" input/output mode is in effect.  IIP$VTP_GET_NEXT always sends
{ a fake output message to suppress the "partial" bit;  however, IIP$VTP_PUT_NEXT
{ assumes that the application will correctly set the "partial" bit for any
{ textual messages.
{
{ 5. With the AMP$ routines, the file identifier must be for a terminal file.
{ With the these routines, it must be that of a network file.  For the ordinary
{ one-job/one-terminal architecture, filename $LOCAL.$TERMINAL will suffice.
{ IIP$VTP_OPEN_NETWORK will take care of this for you.
{
{ To output text, generate a working_storage_area and working_storage_length
{ which starts with the IIT$VT_OUTPUT_INFORMATION record and is followed by
{ the actual text, with the length being equal to the size of the output
{ information record plus the actual number of bytes of text.  Set the output
{ information record as follows:
{
{   output_information.message_type := iic$vt_output_data_message;
{   output_information.fill_0 := 0;
{   output_information.reserved_1 := 0;
{   output_information.reserved_2 := 0;
{   output_information.formatting_mode := 0;  { this is transparent output
{   output_information.secured.suppress_end_line_positioning := FALSE;
{   output_information.secured.suppress_echoplexing := FALSE;
{   output_information.partial := TRUE;
{
{ Note that the formatting_mode of zero provides transparent output, for which
{ the network adds no carriage return or line feed; only those bytes generated
{ into the application's buffer will be sent.  A formatting mode of one will
{ generate normal output, for which CR/LF are generated wherever the output
{ buffer contains an Ascii unit separator code (hex 1F).
{
{ To output any application-to-TIP messages read the VTP ERS document to
{ determine the desired message formats.
{
{       IIP$VTP_PUT_NEXT (FILE_IDENTIFIER,
{         WORKING_STORAGE_AREA, WORKING_STORAGE_LENGTH, STATUS)
{
{ FILE_IDENTIFIER: (input) This parameter specifies the file access
{       identifier established when the file was opened.
{
{ WORKING_STORAGE_AREA: (input) This parameter specifies the address of the
{       record to be output.
{
{ WORKING_STORAGE_LENGTH: (input) This parameter specifies the length of the}
{       record to be output.}
{
{ STATUS: (output) This parameter specifies the request status.
{
