dewey@execu.UUCP (Dewey Henize) (08/05/88)
Hi all, We may be looking at getting in some new machines here to replace or augment our Pr1me machines that we've had for a long, LONG time. However, in addition to all the software conversion you would expect, we have a real problem with tapes! As a software company, we have always strived to produce distribution tapes in the 'native' form of the various customers we have - and this has included machines like IBM with os's like MVS. This can produce some tape blocks of quite sizable length. On the Pr1mes, you pay Pr1me very large sums of money and they make mods to the operating system that almost work so you can write the tapes. The question is, though, are we going to run into this same level of incompatability with various *nix machines? (I'm asking about pyramid, but info on DEC, HP, or Sun would be helpful too, especially if the answer is something like 'all ya gotta do is'. If you have general info that might be of interest, please followup to comp.sys.pyramid, if you just have (just have? Ha!) some technical info that isn't likely to be exciting to anyone by me, please respond via email. Thanks in much advance, Dewey -- =============================================================================== | execu!dewey Dewey Henize @ Execucom Systems Corp 512/346-3008 | | You don't think my employer APPROVES of these ideas, do you?? Sheesh! | ===============================================================================
era@scdpyr.ucar.edu (Ed Arnold) (08/05/88)
In article <254@execu.UUCP> dewey@execu.UUCP (Dewey Henize) writes: > As a software company, we have always strived to produce distribution >tapes in the 'native' form of the various customers we have - and this has >included machines like IBM with os's like MVS. This can produce some tape >blocks of quite sizable length. On the Pr1mes, you pay Pr1me very large >sums of money and they make mods to the operating system that almost work >so you can write the tapes. The question is, though, are we going to run >into this same level of incompatability with various *nix machines? (I'm >asking about pyramid, but info on DEC, HP, or Sun would be helpful too, Dewey - There have been several items in the sun-spots mailing list (comp.sys.sun) recently about this. Look at issues between v6n150 and v6n160, approx. There are several contacts you can make thru the list, who are writing IBM compatible tapes on Suns and appear to know the ins and outs. -------- Ed Arnold * NCAR (Nat'l Center for Atmospheric Research) * Mesa Lab PO Box 3000 * Boulder, CO 80307-3000 * 303-497-1253 era@ncar.ucar.edu [128.117.64.4] * {ames,gatech,noao,...}!ncar!era
csg@pyramid.pyramid.com (Carl S. Gutekunst) (08/05/88)
In article <254@execu.UUCP> dewey@execu.UUCP (Dewey Henize) writes: >The question is, though, are we going to run into this same level of [tape] >incompatability with various *nix machines? Generally, one of the beauties of Unix tape handling is its incredible sim- plicity. And, the biggest headache is its incredible simplicity.... A Unix raw tape device is very much a "you asked for it, you got it" device. You can write anything you want, byte-for-byte, in any size block, up to the limit of the buffers on the tape controller. Inter-record gaps get written after each write(2) call, and an EOF mark gets writen when the file is closed (if you had it open for write). You just can't get simpler than this. The other edge of the sword is that if you want to do anything "standard," like an ANSI format tape or plain ol' 80-block-40, you have to write an application to do it for you. The operating system won't help. The Unix dd(1) utility is supposed to assist in this sort of thing, although I've found that for any given new tape format, I have to write a C program to manipulate it. Someday someone write a really good tape handler for UNIX, and get rich.... Differences are found in the controller's buffer size, which determines the maximum record size. You need at least 10K for the tar(1) utility to work, and the smallest I've seen on any Unix system is 20K. Pyramids allow up to 30K with the old IOC tape controller, and 64K with the TPE. Suns write up to 61K blocks on their Archive 1/4" tape; I dunno about their 1/2" 9-track interface. The other difference is how the physical end-of-tape is handled. Most UNIX systems botch this horribly, something like writing a record across the gap (good) but not allowing you to read it (bad). If this is important, ask your salescritter. (I am told Pyramid does this "right," meaning the same as most commercial DP machines, but I don't recall what "right" is. I do know that multi-volume cpio works flawlessly, which is not true on many other Unix boxes I have used.) <csg>