NAME    [Toc]    [Back]

     rmtops - access tape drives on remote machines

LIBRARY    [Toc]    [Back]

     Remote Magnetic Tape Library (librmt, -lrmt)

SYNOPSIS    [Toc]    [Back]

     #include <rmt.h>
     #include <sys/stat.h>

     int
     isrmt(int fd);

     int
     rmtaccess(char *file, int mode);

     int
     rmtclose(int fd);

     int
     rmtcreat(char *file, int mode);

     int
     rmtdup(int fd);

     int
     rmtfcntl(int fd, int cmd, int arg);

     int
     rmtfstat(int fd, struct stat *buf);

     int
     rmtioctl(int fd, int request, char *argp);

     int
     rmtisatty(int fd);

     long
     rmtlseek(int fd, long offset, int whence);

     int
     rmtlstat(char *file, struct stat *buf);

     int
     rmtopen(char *file, int flags, int mode);

     int
     rmtread(int fd, char *buf, int nbytes);

     int
     rmtstat(char *file, struct stat *buf);

     int
     rmtwrite(int fd, char *buf, int nbytes);

DESCRIPTION    [Toc]    [Back]

     The rmtops library provides a simple means of transparently accessing
     tape drives on remote machines via rsh(1) and rmt(8).  These routines are
     used like their corresponding system calls, but allow the user to open up
     a tape drive on a remote system on which he or she has an account and the
     appropriate remote permissions.

     A remote tape drive file name has the form

          [user@]hostname:/dev/???

     where system is the remote system, /dev/??? is the particular drive on
     the remote system (raw, blocked, rewinding, non-rewinding, etc.), and the
     optional user is the login name to be used on the remote system, if different
 from the current user's login name.

     For transparency, the user should include the file <rmt.h>, which has the
     following defines in it:

     #define access  rmtaccess
     #define close   rmtclose
     #define creat   rmtcreat
     #define dup     rmtdup
     #define fcntl   rmtfcntl
     #define fstat   rmtfstat
     #define ioctl   rmtioctl
     #define isatty  rmtisatty
     #define lseek   rmtlseek
     #define lstat   rmtlstat
     #define open    rmtopen
     #define read    rmtread
     #define stat    rmtstat
     #define write   rmtwrite

     This allows the programmer to use open(2), close(2), read(2), write(2),
     etc. in their normal fashion, with the rmtops routines taking care of
     differentiating between local and remote files.  This file should be
     included before including the file <sys/stat.h>, since it redefines the
     identifier ``stat'' which is used to declare objects of type struct stat.

     The routines differentiate between local and remote file descriptors by
     adding a bias (currently 128) to the file descriptor of the pipe.  The
     programmer, if he or she must know if a file is remote, should use
     isrmt().

ENVIRONMENT    [Toc]    [Back]

     The RCMD_CMD environment variable can be set to the name or pathname of a
     program to use, instead of /usr/bin/rsh, and must have the same calling
     conventions as rsh(1).

FILES    [Toc]    [Back]

     /usr/lib/librmt.a  remote tape library

DIAGNOSTICS    [Toc]    [Back]

     Several of these routines will return -1 and set errno to EOPNOTSUPP, if
     they are given a remote file name or a file descriptor on an open remote
     file (e.g., rmtdup()).

SEE ALSO    [Toc]    [Back]

     rcp(1), rsh(1), rmt(8), and the appropriate system calls in section 2.

AUTHORS    [Toc]    [Back]

     Jeff Lee wrote the original routines for accessing tape drives via
     rmt(8).

     Fred Fish redid them into a general purpose library.

     Arnold Robbins added the ability to specify a user name on the remote
     system, the <rmt.h> include file, this man page, cleaned up the library a
     little, and made the appropriate changes for 4.3BSD.

     Dan Kegel contributed the code to use the rexec(3) library routine.

BUGS    [Toc]    [Back]

     There is no way to use remote tape drives with stdio(3), short of recompiling
 it entirely to use these routines.

     The rmt(8) protocol is not very capable.  In particular, it relies on
     TCP/IP sockets for error free transmission, and does no data validation
     of its own.

BSD                            October 16, 2001                            BSD