icon Top 9 categories map      RocketAware > man pages >

rmt(8)

Tips: Browse or Search all pages for efficient awareness of more than 6000 of the most popular reusable and open source applications, functions, libraries, and FAQs.


The "RKT couplings" below include links to source code, updates, additional information, advice, FAQs, and overviews.


Home

Search all pages


Subjects

By activity
Professions, Sciences, Humanities, Business, ...

User Interface
Text-based, GUI, Audio, Video, Keyboards, Mouse, Images,...

Text Strings
Conversions, tests, processing, manipulation,...

Math
Integer, Floating point, Matrix, Statistics, Boolean, ...

Processing
Algorithms, Memory, Process control, Debugging, ...

Stored Data
Data storage, Integrity, Encryption, Compression, ...

Communications
Networks, protocols, Interprocess, Remote, Client Server, ...

Hard World
Timing, Calendar and Clock, Audio, Video, Printer, Controls...

File System
Management, Filtering, File & Directory access, Viewers, ...

    

RocketLink!--> Man page versions: OpenBSD FreeBSD NetBSD Others



RMT(8)                  OpenBSD System Manager's Manual                 RMT(8)

NAME
     rmt - remote magtape protocol module



SYNOPSIS
     rmt

DESCRIPTION
     Rmt is a program used by the remote dump and restore programs in manipu-
     lating a magnetic tape drive through an interprocess communication con-
     nection.  Rmt is normally started up with an rexec(3) or rcmd(3) call.

     The rmt program accepts requests specific to the manipulation of magnetic
     tapes, performs the commands, then responds with a status indication.
     All responses are in ASCII and in one of two forms.  Successful commands
     have responses of:

           Anumber\n

     Number is an ASCII representation of a decimal number.  Unsuccessful com-
     mands are responded to with:

           Eerror-number\nerror-message\n

     Error-number is one of the possible error numbers described in intro(2)
     and error-message is the corresponding error string as printed from a
     call to perror(3).  The protocol is comprised of the following commands,
     which are sent as indicated - no spaces are supplied between the command
     and its arguments, or between its arguments, and `\n' indicates that a
     newline should be supplied:

     Odevice\nmode\n
             Open the specified device using the indicated mode. Device is a
             full pathname and mode is an ASCII representation of a decimal
             number suitable for passing to open(2).  If a device had already
             been opened, it is closed before a new open is performed.

     Cdevice\n
             Close the currently open device.  The device specified is ig-
             nored.

     Loffset\nwhence\n
             Perform an lseek(2) operation using the specified parameters.
             The response value is that returned from the lseek call.

     Wcount\n
             Write data onto the open device.  Rmt reads count bytes from the
             connection, aborting if a premature end-of-file is encountered.
             The response value is that returned from the write(2) call.

     Rcount\n
             Read count bytes of data from the open device.  If count exceeds
             the size of the data buffer (10 kilobytes), it is truncated to
             the data buffer size.  rmt then performs the requested read(2)
             and responds with Acount-read\n if the read was successful; oth-
             erwise an error in the standard format is returned.  If the read
             was successful, the data read is then sent.

     Ioperation\ncount\n
             Perform a MTIOCOP ioctl(2) command using the specified parame-
             ters.  The parameters are interpreted as the ASCII representa-
             tions of the decimal values to place in the mt_op and mt_count
             fields of the structure used in the ioctl call.  The return value

             is the count parameter when the operation is successful.

     S       Return the status of the open device, as obtained with a MTIOCGET
             ioctl call.  If the operation was successful, an ``ack'' is sent
             with the size of the status buffer, then the status buffer is
             sent (in binary).

     Any other command causes rmt to exit.

DIAGNOSTICS
     All responses are of the form described above.

SEE ALSO
     rcmd(3),  rexec(3),  mtio(4),  rdump(8),  rrestore(8)

BUGS
     People tempted to use this for a remote file access protocol are discour-
     aged.

HISTORY
     The rmt command appeared in 4.2BSD.

4.2 Berkeley Distribution       March 16, 1991                               2

Source: OpenBSD 2.6 man pages. Copyright: Portions are copyrighted by BERKELEY
SOFTWARE DESIGN, INC., The Regents of the University of California, Massachusetts
Institute of Technology, Free Software Foundation, FreeBSD Inc., and others.



(Corrections, notes, and links courtesy of RocketAware.com)


[Detailed Topics]
FreeBSD Sources for rmt(8)
OpenBSD sources for rmt(8)


[Overview Topics]

Up to: File System Operations - Operations for entire file-systems (quotas, configuration, consistency, mount, unmount, et al)
Up to: Hardware Access


RocketLink!--> Man page versions: OpenBSD FreeBSD NetBSD Others






Rapid-Links: Search | About | Comments | Submit Path: RocketAware > man pages > rmt.8/
RocketAware.com is a service of Mib Software
Copyright 1999, Forrest J. Cavalier III. All Rights Reserved.
We welcome submissions and comments