1) Kermit download of SEED format data works if you have a dialup session, but not from wtihin a telnet session. Supposedly, the tmp files created when you do a kermit download are cleaned up by the system -- IS THIS CORRECT?

While dialed in, using a kermit transfer, tmp files are overwritten, not deleted. Hypothetically a large request could take up a significant amount of disk space, however it would have to be a big request.

While telneted in, using a kermit transfer (which doesn't work right anyway) files are NOT deleted or overwritten. Disk space could be eaten up quickly in this case.

2) Under ultrashear, one can use the finger server to obtain uuencoded seed format data. I am not sure if we have this enabled at any of our stations. CAN ANYONE SHED ANY LIGHT ON THIS ONE?

Finger is enabled at only GTSN stations. At first I had thought finger was a "one-liner" in terms of data retreival, however this is only the case if uuencoded, SAC ascii or STP format is requested. These formats would than requiring the use of a session log or of script (sort of a Unix session log). If archived miniseed is used, one still must ftp in, get the file, and then delete it.

A similar protocol, called "tentacle", is a mix between finger and telnet because it requires a password to get in and can put some arguements on the same line for a retrieve. The one advantage I understand so far is that several commands could be stated on one command line, otherwise it doesn't seem any better than logging in as seed or vbb. As a minimum to get data a few lines are required.

1. account and password
2. who you are
3. the retrieval command and info (type of retrieval, channel, times)
4. command to start the protocol 5. logout

3) Under shear or ultrashear, one can request creation of a seed format file, then ftp to the station, download the file, and delete the file. One must delete these files from the system manually.

Under ultrashear one must delete the seed format file. I dialed and created some archived mini-seed files at a shear station and they appear to stick around. So the same may be true with stations running shear software.

4) Under ultrashear, one can request uuencoded transfer of seed format data. This will scroll the uuencoded data on the screen, similar to asking for SAC ASCII format transfer. One captures the screen output to a file and uudecodes the file.

Checked this and it works fine.

5) When a user asks for data in any format other than SEED, the Quanterra patches the time series together, glossing over any timing glitches (e.g. two data chunks separated by a gap are simply glued together, or possibly zero-filled on newer systems). Supposedly warnings about any timing problems encountered when fulfilling the user's request are written to a log. CAN ANYONE HELP CLARIFY THIS?

When data with time gaps is decompressed (from steim1 or steim2) and converted to the chosen data format, the decompression algorithm will send an error message (to standard out) that basically says there is a time descrepency between records.