I have been experimenting with compressed psuedo floppies on a NFS drive
using D3 on aix. This is where the device cascades automatically from, for
example:

filesave
filesave-1
filesave-2
etc.

I've been trying to figure out if there is a way to use the data files in
a non-aix environment. I moved one of the files over to my dual-boot
laptop, with Mandriva linux and D3/NT on WinXP. I put the file on the
Mandriva side first, and opened it with "ark". It claimed the file was a
unix-compressed file. So far, so good, so I un-compressed the file with
ark, and stored the uncompressed file where I could get to it from WinXP.
I then in WinXP set a D3 tape device to the file with the device manager,
and booted D3. I set-device to the file, and read the tape, getting:

:t-read
Block size: 500

record = 1
000 :0b..."F..2p@......M...!....1f..Qc...D.P.....&E*.. I:
050 :..M.^........@...J....H.*].....P.6-...?.X.j......`:
100 :...K..A...:.(Q.E..5r..R$I.(U.t.....8u..L......+.. .:
150 :..._...L.....3k.......C..M.....9S.......c..M..... .:
200 :>.8."...7v\..n..)W.|..oL.9c..N....._.......2r&... .:
250 :v.4p..Q....^.[._....!.8.b~~..4.P....c..Lp.....w_}.:
300 :y...OL..z....C...`........`..D....3....5.p..9.... 1:
350 :.Xc.2..C.C....9.C.H74........8..`.N8...N...[7. C?.:
400 :.0..78...8.p..Q.tf.5..C.g...C..0g?q...w8`IC...4.. ]:
450 :....D$1..H....w..BD0..c? ...o#.`..0....pr...Bj...~

Oh well! I thought maybe this would work. Has anybody tried any
experimenting along this line, and found anything useful? I periodically
have to move enough data that the 2G file size limit for an uncompressed
psuedo floppy is very incovenient.

Art

Hi Art,

Not sure about AIX but D3 Linux compressed pseudo-floppies ("p" in
/usr/lib/pick/pick0) writes files that can be uncompressed with gunzip.
Depending upon your distro you might have to rename the files to have a
".gz" extension:
$ mv filesave filesave.gz
$ gunzip filesave.gz

As I remember D3 for Linux links "compress" to "gzip" and "uncompress"
to "gunzip" during installation. This may not be the case on AIX. You
might want to try both gunzip and uncompress from the command line.

HTH,
-Tom

EVen so, if there are multiple files involved, you will then need to
"stitch" them together. Art, for the "few" times this happens, you
might consider using a tape (if possible) OR isolating a few largish
files that can be "stolen" to another account & backed up, or simply
T-DUMP myfile (I, then DX before the save (remembering to undo the
'damaged' file pointer so that backups continue to work

On Mon, 27 Mar 2006 19:22:20 -0800, Ross Ferris wrote:

Yeah. I'm doing a combination of the above, and it requires a half-dozen
different tape files, and a combination of account-saves and t-dumps. It
works, but I thought I'd explore the alternatives, if any.

Art

On Mon, 27 Mar 2006 17:11:25 -0800, Tom deL wrote:

My Bad! (Ooops!) I was pointing to the *compressed* file instead of the
*uncompressed* file. (blush) With ark you can specify either unix
compressed or gzip (or many other compression standards). It seems both
unix compressed and gzip work. Now I need to generate a full account-save
instead of the sample file I tested, and see what happens with multiple
cascaded files. BTW, my tape definition line in pick0 (aix) is:

tape /aixbak/filesave 10000000 p lx # tape 14 1000000 p lx

Art

I'd be inclined to replace the 1Gb with 2Gb volumes ... less "stiching"
and fewer cascading files - remember, D3/NT has not notion (that I'm
aware of) of cascading file saves

Funny you should mention that... D3 DOES have cascading tapes.

When I worked on the Series/1 implementation in '83, I came up with the idea
having more than one tape unit available to more than one user at a time.
And the idea of using a non-tape unit to act like a tape. We did machine to
machine file saves via bisync.

When I worked on the RT port, 6 years later, I did it again. When Pick went
to *nix, they carried the idea to the pseudo floppy.

My original idea was to have two sct's and assign one as device 1 and the
other as device 2. When the save filled tape1, it would automatically
switch to tape2 while tape1 and continue saving while tape1 rewound and was
replaced. When tape2 filled up, it would switch back to tape1 and continue.

Personally, I haven't been on a *nix or NT system that had that much data,
but theoretically, it should work for psuedo floppies as well. If the fact
that the floppy is "full" is reported as END OF TAPE condition, then it will
work. If it's reported as any other kind of error, then it wont.

IIRC it was T-CASCADE unit1, unit2, unit3,..unitn {, unit1 to link back}

Most people don't know, as well, that there's a T-COPY to copy from one tape
unit to another. T-COPY unit-in, unit-out, # of files to copy (each tape
mark is a "file")

Mark Brown
"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

I think that D3 does not compress the COMPLETE file. So trying to do a
gunzip or something similar to the complete file may not work.

And worse, if you have cascade pseudofloppies, D3 NT do not know how to
handle them.


My solution:

Take out the D3 NT. Move it to D3 Linux. Buy a licence of VMWARE (or
something similar, i know VMware works OK). Install VMware on NT, then
install a virtual Linux machine and D3 Linux. Configure NFS and the
pseudofloppies as they are in D3 AIX. And work in that environment.


If you do not need NT at all, install Linux directly in a box.

Hope this help

joseba

Hi Joseba,

In Linux at least, it is simply piped through the compress command
(which IIRC is linked to gzip). The resultant file(s) are indeed
available to be uncompressed, I do it regularly.

Did they build D3/NT to use different approaches to tapes??? That seems
very short sighted.

<snip>

That sounds the best. <g>
-Tom

I'd love to. But I'm very partial to Mandriva Linux on my laptop, and
don't want to do Red Hat. So that kind of limits my options.

Art