T.R | Title | User | Personal Name | Date | Lines |
---|
1386.1 | problems to unpack gemar201 | VNABRW::KRONSTEINER | | Wed Nov 17 1993 09:06 | 13 |
| peter,
got gemar201 from your account last week but I had no chance to unpack
the File. I started the filetransfer with kermit and whack
sucessfully but unpacking resulted in something like "bad table on
***.rsc".
I would like to try gemar on an tk50 with SCSI-controller, (DEC-stuff-
controller is seen as adaptec).
Thank You in advance for any help
Regards
Armin
|
1386.2 | Use LHARC 2.31 for unpacking | EDDF10::ECKEL | No sports. | Thu Nov 18 1993 02:56 | 10 |
| Hello Armin,
did you also get lharc231.lzh? The archives in my account are all
packed with the latest version of lharc, which is in a self extracting
archive. Some other colleagues used it for unpacking CoNnect and
everything worked OK, so you should have no difficulties.
If it doesn't work, please call me at DTN 861-3687.
Regards, Peter.
|
1386.3 | Difference between v2.0 and 2.1? | FAILTE::ROBSONB | | Mon Jan 10 1994 06:26 | 12 |
|
I have GEMAR v2.0 (dated, I think, October 1993). Are there any
major differences between v2.0 and 2.01? I notice that while v2.0
comes with English RSC file and docs, the full manual has not yet
been translated into English. Does v2.01 now include an English
translation of the manual?
TIA,
Best Regards,
Brian
|
1386.4 | Contact the author. | EDDF10::ECKEL | No sports. | Mon Jan 10 1994 08:49 | 11 |
| Hello Brian,
as I don't know the current status of the GEMAR distribution I'd
suggest you contact the author, Steffen Engel, via MausNet under the
internet address "[email protected]" (hopefully correct).
Please don't send mails larger than 48kB to the MausNet.
Regards,
Peter.
|
1386.5 | Thanks for info. | FAILTE::ROBSONB | | Tue Jan 11 1994 08:46 | 13 |
|
Thanks Peter,
I've taken a note for future reference, but in the meantime
was just wondering if the complete manual had been translated
in v2.01.
I don't have a tape streamer, but on having seen how powerfull
and comprehensive GEMAR looks to be IMHO, I would really like to
get one for backups.
Thanks and Best Regards,
Brian
|
1386.6 | if you can get a streamer, do it! | UFHIS::BFALKENSTEIN | | Tue Jan 18 1994 10:28 | 12 |
|
I really can recomend GEMAR in conjunction with a SCSI-streamer. It
just perfectly suits my needs for backup: over the weekend I do a
complete backup (150 MB in about 30 minutes) and every day there is
my daily backup for about 2 minutes. For these two tasks I wrote a
script which I put on my desktop. Simply doubleclicking the icon starts
the process, and when finished the program automatically returns to the
desktop.
Bernd
|
1386.7 | GEMAR v2.01 for Falcon | FAILTE::ROBSONB | | Thu Jan 20 1994 06:19 | 10 |
|
Thanks for the recommendation Bernd, - yes, I'm convinced this for
me too is the way to go for backups.
BTW, I read a very recent post on usenet from the author of GEMAR,
saying that v2.01 is required for use with the Falcon and fixes a
minor bug with Falcon SCSI code; appart from that, I understand the
package is the same as v2.0
Best Regards,
Brian
|
1386.8 | Works with TZ86 too... | FAILTE::ROBSONB | | Mon Jan 24 1994 05:48 | 20 |
|
I arranged to borrow a SCSI tape drive this weekend, and tried
it with GEMAR and the LINK. It was a TZ86, and although more
experimentation would be required to find the optimum values for
streaming, I backed up 443MB in 1 hr 50 minutes with
Backup Buffer 110kB
Max Read 100k
Data Rate 1000kB/s
I understand from the documentation that the supplied XFS driver
enables the tape drive to be accessed as a 'virtual drive' - this
could also be a very usefull feature.
The TZ86 needs to be returned, so unfortunately I won't be able
to experiment further with parameters, but on actually seeing GEMAR
working, I'm more convinced than ever that a tape streamer is now
top priority for next add-on :-)
Best Regards,
Brian
|
1386.9 | ST(e)/TT & MultiTOS? | UFHIS::BFALKENSTEIN | | Tue Jan 25 1994 08:46 | 9 |
|
re. -1
Brian, do you use MultiTOS? Because XFS-drivers only work with
MultiTOS...
Bernd
|
1386.10 | No MultiTOS, but XFS not needed for backups... | FAILTE::ROBSONB | | Tue Jan 25 1994 09:45 | 20 |
|
Hi Bernd,
I don't have MultiTOS with which to run the XFS drivers,
but I thought the part in the docs. which indicate that the tape
drive could be accessed via. the XFS driver as a 'Read Only'
virtual drive, was an interesting feature. (Is this correct?)
(I found that the XFS driver/MultiTos did not need to be installed for
backups, and it was only necessary to enter the SCSI ID of the
drive (and select 'Inquiry') in the Streamer Options dialogue
box, and when 'load tape' was selected from the menu, the tape streamer
icon became active, displaying 'DEC' in the icon label).
Best Regards,
Brian :-)
|
1386.11 | Works with TK50Z too.... | FAILTE::ROBSONB | | Mon Feb 28 1994 05:20 | 25 |
|
I tried GEMAR with a TK50Z, and the following parameters gave good
streaming results:
In 'Streamer Commands' submenu: X Test Unit Ready
X Mode Sense
X Mode Select
Wait Before SCSI 1 tick
Wait After SCSI 1 tick
Backup Parameters submenu: X Time Before SCSI
Backup Buffer 7kB
Maximum Read 69kB
Data Rate 45kB/s
I found the above worked well in keeping the tape streaming and the
top 'buffer rate' bar in the display full, with a cached 4MB 16MHz ST.
I also found that the Backup parameter figures are critical in that
a shift of 1kB either way makes a very significant difference.
Best Regards,
Brian
|
1386.12 | Thanks. | EDDF10::ECKEL | No sports. | Mon Feb 28 1994 05:39 | 17 |
| Thanks Brian,
I've forwarded your parameters to Steffen.
Indeed these parameters are *very* critical. When I found the numbers
in .0, it was the result of several hours of work and testing.
When you are trying to find the correct parameters, it is sensible to
test on a partition containing lots of small files. This is the case
when mis-tuned parameters will show up first, because the file system
takes a lot of time for directory searches and the disk drive has to move
heads very often, so it is most difficult for the software to keep the
buffer full.
Regards,
Peter.
|
1386.13 | When the Backup requests a second Tape ! | VNABRW::KRONSTEINER | | Thu Mar 03 1994 04:12 | 11 |
| Thank's got the TZK50 streaming with this parameters.
But Ifound a problem when the Backup needs a second Tape. Everything
seems ok. but I cant restore it. It seems that the first Index is
unreadable. Its possible to read the last Index on the second Tape but
there is no acces to Files on the first Tape.
Do I have fingertroubles ?
What are Your eperiences ?
Regards
Armin
|
1386.14 | Contact the author. | EDDF10::ECKEL | No sports. | Thu Mar 03 1994 06:48 | 22 |
| Hello Armin,
you could get GEMAR using a second tape? In this case the TZK50 must be
different to the TZ30 in more places than I thought. I can't even backup
to multiple volumes.
The reason is that the TZ30 seems to go into unit attention state when
it recognises that a tape change occurred. And it seems to provide more
than one status information to the SCSI initiator, which is where the
software suspects a fatal error and stops operation.
Steffen already knows about the problem, but he is rather busy at the
moment so that he has not too much time to work on it. Your error seems
to be a different one, so you should send a bug report to him. His
internet address is [email protected], plase don't ever send more
than 48 kB of mail to this address.
Feel free to contact me via mail if you have further questions.
Regards,
Peter.
|
1386.15 | GEMAR v2.2 and TK50Z | FAILTE::ROBSONB | | Wed Mar 16 1994 06:36 | 10 |
|
I now have GEMAR v2.2, but find that the parameters noted earlier
for the TK50Z do not seem to work so well with this new version
(the tape now stops and restarts quite frequently).
I plan to play with the parameters further and report here re.
results.
Best Regards,
Brian
|
1386.16 | | EDDF10::ECKEL | No sports. | Wed Mar 16 1994 08:24 | 9 |
| Brian,
I forwarded your info to Steffen. I hope this is no general effect of
the changes made to GEMAR, because otherwise *all* parameter sets have
to be reworked ...
Regards,
Peter.
|
1386.17 | Perhaps not a general effect... | FAILTE::ROBSONB | | Wed Mar 16 1994 09:34 | 19 |
| Hi Peter,
I mentioned the TK50Z parameters to Steffen too (I am now a
registered user :-) but I believe he thought that the backup buffer
sounded to be rather on the low side, but if it worked for me with
my configuration then O.K. I agreed with Steffen though that perhaps
more experimentation would be of value (although the parameters were
arrived at after quite a long time), but I don't believe the results
with v2.2 is a general effect of the changes made.
Perhaps the new coding is more efficient, and a change of 1k either
way made a significant difference before - I believe a little tweaking
with the new version is probably all that is required. I'll update
as soon as possible with the results for TK50Z, but I would assume that
the parameters included in the PAR folder for other types of drives
would probably still be O.K.?
Best Regards,
Brian
|
1386.18 | TK50Z seems to need 'Time Before SCSI'... | FAILTE::ROBSONB | | Mon Mar 28 1994 11:53 | 53 |
|
After many hours of experimentation with the parameters, I find that
with my setup (16MHz, 4MB, ICD 'Link' and ICD Pro Driver/Cache) larger
buffer sizes cause the top bar to alternately empty and refill, and
I have reverted back to a small buffer of only 8k. I find also that
the 'Time Before SCSI' parameter must be selected in my setup,
otherwise the TK50Z seems to 'hog' the SCSI bus and the disk drive
doesn't appear to be reading frequently enough to keep the buffer
filled up.
The small buffer in my setup is a little confusing as I understand
from Steffen that if the value of 'maximum read' is higher than the
buffer size, then the buffer value is over-ridden by 'max-read'.
It seems to work for me however, perhaps my disk-cache is contributing
to the overall buffer.
The parameters which work for me with the TK50Z are very similar
to those previously, and I get good results with the following:
Backup Buffer 8KB
Max Read 20KB
Data Rate 46KB
Wait Before SCSI 1 tick
Wait After SCSI 0 tick
Select X Time Before SCSI
X Verbose
X Immediate
X Test Unit Ready
X Mode Sense
X Mode Select
X Load/Unload Tape
The 'Time Before SCSI' settings seem to keep the TK50Z and the disk
drive both busy at the same time, and although the TK50Z paused five
or six times during test backups of partitions containing a wide
variety of different file sizes, the top bar does not empty.
I think that it is possible that the tape may perhaps be pausing
on these few occasions to do an error correction or retry - I have
found that some cartridges do this more so than others, and the
cartridges which I have are well used and quite old.
The above works O.K. for me and was arrived at after many hours of
experimentation, and I think that the most significant change from
previous parameters is that the 'Time Before SCSI' figures have been
reduced.
Best Regards,
Brian :-)
|
1386.19 | Possible Restore problem with multiple tapes... | FAILTE::ROBSONB | | Thu Mar 31 1994 10:13 | 14 |
|
I too have found the same problem as Armin reported in .13,
when backing up files from a 330MB partition.
I found that GEMAR asked for a new cartridge after the first and
second were full, and although the primary index had been written
to the first tape during the backup, and the main Index to the
third (final) tape, GEMAR could not seem to find the index from
either tape during a restore, so that a restore was not possible.
I have reported this to Steffen as a possible bug, but in the
meantime everything is O.K. with backups to a single TK50Z cartridge.
Best Regards,
Brian :-)
|
1386.20 | Not thought to be a bug.. | UIST::ROBSONB | | Fri Apr 08 1994 06:02 | 20 |
|
I have a reply from Steffen, advising that this is not thought to be
a bug. With backups which run to more than one cartridge, the 'last'
cartridge, which contains the main index file, should be inserted for
reading regarding a restore, and 'Gemar' apparantly does a 'space
forward' from the beginning of the cartridge until it encounters the
main index file at the end, and then reads the index.
I tried increasing the 'space' timeout value as advised, but this
does not make any difference, and appears to have been large enough
already (I think it was 1200 seconds, which should be more than
enough).
I think possibly it may be something to do with the large block size
on the partition I was backing up (the drive is 330MB, and I have this
set up as one partition, block size 8192, I think) and plan to
experiment further in the meantime.
Armin, what is the block size on the partition you backed up?
Best Regards,
Brian
|
1386.21 | Space-Time Out Value 2400s for TK50Z | FAILTE::ROBSONB | | Mon Apr 11 1994 11:18 | 22 |
|
I found out during the weekend that the 'block-size' in -1. has
nothing to do with the problem - silly me :-)
It seems that the TK50Z takes 30 minutes to find the index file
written at the end of a three-cartridge set , so the Space-Timeout
value needs to be somewhere around 2400s (40 minutes).
I had tried this value earlier, but had aborted after 25 minutes -
if I had waited another 5 minutes, I would have seen that the index
was read O.K.
I don't know why the TK50Z takes so long to find and read the index
in this situation (the backups was from a 330MB partition, with
536 folders containing 3932 files in 253MB) but I found that file
restores were O.K.
I find that Image backups are much quicker, although I have not
yet tried an Image restore.
I also find that the TK50Z finds and reads the Index file on a
single cartridge backup relatively quickly.
Best Regards,
Brian
|
1386.22 | Serpentine Recording | MUNSBE::BFALKENSTEIN | | Tue Apr 12 1994 05:56 | 16 |
|
re. -18
Brian, the drive has to stop once in a while to switch to reverse
direction when it reached the end of one track. The TK50Z does
Serpentine Recording with only one track, so this is normal even
when the buffer display shows full.
Bernd
P.S. sorry for not receiving any replies to your internet-mails to my
home account. The MausNet encountered a problem with personal mails
after they installed version "d" of the software ;-(
Receiving is ok, but no PM leaves the gateway...
|
1386.23 | normal behaviour | FAILTE::ROBSONB | | Tue Apr 12 1994 13:28 | 7 |
|
re. -1,
Thanks Bernd, I hadn't thought of that :-)
Brian
|
1386.24 | Falcon/TZ30 problems... | FAILTE::ROBSONB | | Mon May 23 1994 06:13 | 21 |
|
I borrowed a TZ30 over the weekend to see how it would perform
compared to the TK50Z, and while the TK50Z has been giving good
results on my Falcon, I found I couldn't get the TZ30 to work
very well at all.
With Gemar v2.20, I found that the drive was seen O.K. but
the 'load tape' command would bring up a 'command timeout' alert,
and hang the machine if I tried it again. Deselecting 'mode select'
and 'mode sense' in the streamer parameter dialogue box and selecting
only 'test unit ready' enabled the tape to respond to the 'load tape'
command, but on commencing a write to tape following reading of the
drive index file, an error 'error writing TAR header' and 'incorrect
SCSI command' appeared, with an alert box requesting an 'abort' action.
I am wondering if perhaps the TZ30 is broken (the TK50Z works O.K.)
I would be interested in hearing if anyone else has seen this, and if
there are any specific switch/jumper settings on the TZ30 which should
be taken into account.
Thanks and Best Regards,
Brian
|
1386.25 | Falcon/TZ30 | FAILTE::ROBSONB | | Tue May 31 1994 05:37 | 7 |
|
I found that the TZ30 works O.K. with my STFM, so perhaps there
is a problem with the Falcon/TZ30 combination.
Best Regards,
Brian
|
1386.26 | GEMAR restore problems | MSBCS::WALLACE_R | | Tue Oct 25 1994 13:41 | 39 |
| Well I finally got a chance to play with a tape drive and GEMAR. WOW! What a
big difference over backing up to floppies!
I did run into a few glitches though, and was wondering if anyone else has
seen these problems and/or knows how to fix them? All these comments are based
on using GEMAR V2.20 available on the net.
When writing the index at the end of a backup, GEMAR access's the floppy drive
(drive A:). Does anyone know why it access drive A:? It doesn't create any
(visible) files on the floppy, just lights the light and you can hear the head
move.
When GEMAR does a restore it creates the files on the hard drive with the
CURRENT date and NOT the original date of the backed up files. It does store
the correct date on the tape, it just doesn't use that date when doing a
restore. I looked all over trying to find a menu option to change this
behavior, with no success.
Another restore problem is that it doesn't correctly handle folder names with
embedded colons. ie: When restoring a folder name of /TOOLS/A:CALC/, GEMAR
created /TOOLS on the hard drive and then created /CALC on the floppy drive A:.
Of course it got an error when it tried to restore the first file to
/TOOLS/A:CALC/ as the folder was non existent.
Does anyone know the difference between using the RESTORE item in the main
menu and the RESTORE item in the window menu? One of the readme files
indicates there is a difference but refers you to the manual (which has not
been translated to English) to find out the difference.
GEMAR was not able to read a tar tape created on Ultrix. I think when I asked
for an index it just came up empty, I can't remember for sure. I'm still
looking at this problem. Perhaps its a problem with compression enabled on one
machine and not the other. Ultrix tar WAS able to read a GEMAR created tape,
it created a folder for the drive letter and all of the files were in
uppercase, but other than that it worked great.
Thanks,
Ray
|
1386.27 | | EDDF10::ECKEL | No sports. | Thu Oct 27 1994 05:51 | 49 |
| Hello Ray,
Maybe I can shed some light on some of your points. Anyway, I forwarded
your mail to Steffen Engel for the rest of your questions.
> When writing the index at the end of a backup, GEMAR access's the
> floppy drive (drive A:). Does anyone know why it access drive A:?
I also use the 2.20 version, and I never had this effect. So probably
there is either a bug or you misconfigured something. Did you start
GEMAR from floppy? It writes a log file and a directory of indices
after finishing backups, the latter is in order to recognize if the
first index is correct without reading the second index at the end of
the tape. If you started from floppy, it will create the files there.
> Another restore problem is that it doesn't correctly handle folder
> names with embedded colons. ie: When restoring a folder name of
> /TOOLS/A:CALC/, GEMAR created /TOOLS on the hard drive and then created
> /CALC on the floppy drive A:.
How did you create that folder? Folder names with colons are not
supported by TOS or MagiC!, so I'm not very surprised that a TOS
program can't handle them properly.
> Does anyone know the difference between using the RESTORE item in
> the main menu and the RESTORE item in the window menu? One of the
> readme files indicates there is a difference but refers you to the
> manual (which has not been translated to English) to find out the
> difference.
I don't have the manual here at the moment, but I will take a look and
tell you if I don't forget.
GEMAR was not able to read a tar tape created on Ultrix. [...] Ultrix
tar WAS able to read a GEMAR created tape, [...]
That's the way it's supposed to work.
After version 2.12, GEMAR has dropped support for reading TAR tapes and
just writes TAR compatible headers. Steffen told me that TAR support
was too complicated to maintain within GEMAR, because there is a large
variety of TAR formats around (Unix, sigh). If you are using
MinT/MultiTOS, it is possible to obtain a TAR file system extension,
since I don't, I do not know exactly where to find it and how it works.
Regards,
Peter.
|
1386.28 | Reply from Steffen... | FAILTE::ROBSONB | | Sun Nov 06 1994 12:15 | 87 |
|
Hello Ray, Peter,
I also took the opportunity to put Ray's questions to the
author - I hope I am not overstepping any response Peter has
planned, but if I may, here is Steffens reply. I have been off-line
for a while due to a serious fault in my telephone line, and while
the reply was received just before my phone line went down, I am
only now in a position to post it, with apologies for any delay...
BR>behalf of a friend at work
That's ok, I'll do my very best.
BR>GEMAR access's the floppy drive (drive A:).
Hm, never heard of, never seen. Maybe there is 'A:' in the PATH-
Environment. When finishing the Backup, GEMAR searches for an existing
GEMAR.KEY and GEMAR.LOG with shel_find. If they do not exist, they are
created in GEMAR's home directory.
Due to the shel_find-operation of the AES all Paths given in PATH are
searched for these files, so maybe there is A: in PATH.
BR>When GEMAR does a restore it creates the files on the hard drive
with
BR>the CURRENT date and NOT the original date of the backed up files.
Very strange, because on my system the date is set to the original
date.
Maybe there is any AUTO-program changing the behaviour of the GEMDOS
call
Fdatime.
You can check for the existance of the call with SYSMON.
Which version of TOS do you use?
BR>Another restore problem is that it doesn't correctly handle folder
BR>names with embedded colons.
A colon is a forbidden character in file names, so this is no bug, it's
a
feature.
BR>Does anyone know the difference between using the RESTORE item in
the
BR>main menu and the RESTORE item in the window menu?
I call it local and global restore. If you use the local restore (in
the
window menu), only those files are restored, which are in the open
window
and deeper.
For example:
in a backup there is the folder C:\TEST1\ with the files FILE1 FILE2
...
FILE10 and a folder C:\TEST2\ with the files FILE11 ... FILE20
Open the path for C:\ and select all. Then open the folder TEST1 and do
a global and local restore with the destination path to C:\CLIPBRD\
The global restore will give:
C:\CLIPBRD\
TEST1\
FILE1
FILE2
...
FILE10
TEST2\
FILE11
...
FILE20
The local restore will give
C:\CLIPBRD\
FILE1
...
FILE10
because the opened window is C:\TEST1\
BR>GEMAR was not able to read a tar tape created on Ultrix.
GEMAR can' read a TAR index it only write TAR compatible archives.. For
reading TAR-archives you must use the devicedriver under MiNT and a
normal TAR.TTP
Best Regards,
Brian
|
1386.29 | Thanks for contacting the author | MSBCS::WALLACE_R | | Mon Nov 07 1994 17:44 | 22 |
| Thanks a lot for getting this feedback from the author.
The difference between the two restores sounds real usefull.
I'll take a look at my path and my auto folder to see if I can find the cause
of the floppy access and the date problem.
Atari docs do state that using a colon in a file or directory name is illegal,
however TOS and the desktop (TOS 1.2) allow the creation of directories with
an embeded colon and since the name of program is A:CALC the vendor (it's a
commercial spreadsheet) decided to put the program and its files in a
directory of the same name. It's simple enough to change the directory name,
so no real problem. Note that GEMAR is the only program I've run across which
has a problem with this.
I've got a couple of other ST tar programs that I'm going to try out,
hopefully one of them will be able to read the Ultrix tar tapes. It would be
much nicer than using floppies to move large amounts of files back and forth.
Thanks,
Ray
|
1386.30 | odd filenames, indeed... | MUNSBE::BFALKENSTEIN | | Fri Nov 18 1994 08:59 | 11 |
|
Ray, I can't believe that in TOS version 1.2 you can use semicolons and
colons in a file- or directory name. This would be against all rules of
the 8.3-structure (which is still a heritage from C/PM and DOS). I
don't have 1.2 anymore, but 2.06 and MagiC definitely don't allow this.
Hm, this is really very interesting.Could it be that there are
differences in the country versions of TOS (e.g. GY vs. UK)?
Bernd
|