Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.vms > #58251 > unrolled thread
| Started by | helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) |
|---|---|
| First post | 2016-06-12 19:04 +0000 |
| Last post | 2016-06-17 10:39 +0200 |
| Articles | 20 on this page of 338 — 25 participants |
Back to article view | Back to comp.os.vms
FREESPADRIFT helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-12 19:04 +0000
Re: FREESPADRIFT Johnny Billquist <bqt@softjar.se> - 2016-06-12 21:17 +0200
Re: FREESPADRIFT Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 20:01 +0000
Re: FREESPADRIFT helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-12 20:23 +0000
Re: FREESPADRIFT Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 20:36 +0000
Re: FREESPADRIFT helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-14 09:02 +0000
Re: FREESPADRIFT helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-12 20:22 +0000
Re: FREESPADRIFT Johnny Billquist <bqt@softjar.se> - 2016-06-13 11:45 +0200
Re: FREESPADRIFT "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-12 16:08 -0400
Re: FREESPADRIFT brendan welch <w1lpg@uml.edu> - 2016-06-12 17:20 -0400
Re: FREESPADRIFT koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 09:20 -0400
Re: FREESPADRIFT lawrencedo99@gmail.com - 2016-06-14 18:42 -0700
Re: FREESPADRIFT moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-16 18:24 +0000
Re: FREESPADRIFT "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-16 15:15 -0400
Re: FREESPADRIFT lawrencedo99@gmail.com - 2016-06-16 16:01 -0700
Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-16 19:56 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-16 17:23 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-16 21:16 -0500
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-16 20:11 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-17 10:26 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-17 15:28 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-18 00:39 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Michael Moroney <moroney@TheWorld.com> - 2016-06-17 22:41 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-17 23:14 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-17 20:10 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-06-18 10:54 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 02:19 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-06-18 13:51 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-18 14:31 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 15:24 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-18 22:57 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 20:02 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-19 01:46 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 10:56 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 11:32 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 12:42 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 15:00 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 15:12 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-19 22:45 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:29 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 18:50 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-18 14:48 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-18 21:19 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:35 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 11:26 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-19 22:55 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 17:38 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-21 14:53 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-21 16:18 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-21 18:27 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 18:40 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 18:34 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-21 17:07 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 12:19 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 12:36 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 16:47 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 16:06 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 18:33 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-23 14:46 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:16 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-26 19:33 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:01 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:23 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:29 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:42 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:58 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 21:40 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:03 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 15:19 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 17:39 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 16:55 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 19:36 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 19:43 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 20:20 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 22:33 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-28 09:02 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:48 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:59 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:06 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 17:05 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-23 14:50 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:24 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:34 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 22:02 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-24 08:52 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-24 16:54 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-24 13:41 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-24 18:27 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 14:40 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 13:33 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:14 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:50 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 20:02 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 22:35 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 14:26 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 14:15 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-27 09:35 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:15 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 15:23 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 17:42 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 16:56 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 19:41 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 15:09 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 21:41 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 14:43 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 22:18 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 15:08 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 14:53 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 17:17 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:16 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:31 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:22 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:27 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:55 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-23 22:15 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-24 10:50 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-24 11:19 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 15:12 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 21:17 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 15:19 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 15:08 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 17:34 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-27 13:40 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 20:21 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 20:28 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 22:38 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 21:29 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 23:40 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 22:39 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:32 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-29 12:15 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 14:54 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-29 13:45 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 15:58 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-29 14:07 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 16:56 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-07-11 09:34 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-07-11 11:31 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-11 20:48 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-07-11 15:49 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-12 13:03 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-11 20:47 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-29 11:01 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 12:48 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 15:12 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 15:15 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 17:56 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 18:01 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 17:00 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 21:02 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 19:38 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-01 14:19 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-07-01 12:58 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-01 17:42 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 17:03 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-30 15:17 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 20:02 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-29 10:51 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) johnwallace4@yahoo.co.uk - 2016-06-27 21:09 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-27 23:39 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:54 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 18:44 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 10:47 -0400
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-19 19:47 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Paul Sture <nospam@sture.ch> - 2016-06-20 07:38 +0200
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-19 22:46 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Paul Sture <nospam@sture.ch> - 2016-06-20 11:41 +0200
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-20 03:13 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 09:13 -0400
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-20 16:55 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-21 10:18 -0400
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-21 07:29 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Paul Sture <nospam@sture.ch> - 2016-06-20 17:38 +0200
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-20 17:01 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 08:34 -0400
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-20 07:40 -0500
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 17:29 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-22 00:27 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-22 09:43 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-22 12:36 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 12:27 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 12:49 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-24 03:03 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 15:29 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-27 15:51 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:56 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-29 02:41 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 11:54 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-29 03:04 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 12:57 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-30 00:15 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 14:51 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-30 15:37 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-01 14:14 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-07-02 17:38 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-07-04 15:04 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-05 15:02 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-05 15:09 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-04 12:30 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 09:45 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-06-18 20:07 +0200
RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-18 18:41 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 18:50 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:48 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 19:56 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 23:04 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 09:04 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 12:20 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 14:18 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 15:03 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 15:49 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 11:46 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-19 23:26 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 09:07 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) John Reagan <xyzzy1959@gmail.com> - 2016-06-20 06:47 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 09:54 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) hb <end.of@inter.net> - 2016-06-20 17:37 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) John Reagan <xyzzy1959@gmail.com> - 2016-06-20 10:47 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) hb <end.of@inter.net> - 2016-06-20 21:28 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) John Reagan <xyzzy1959@gmail.com> - 2016-06-20 13:27 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-20 10:19 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-20 14:39 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 11:14 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-20 12:30 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-20 20:39 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-20 22:10 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-20 22:15 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-21 00:57 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Steven Schweda <sms.antinode@gmail.com> - 2016-06-20 19:42 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-20 23:06 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-20 12:27 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 14:52 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-21 09:52 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-21 07:16 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was John Reagan <xyzzy1959@gmail.com> - 2016-06-21 07:44 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-21 15:02 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-21 15:04 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-22 12:10 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-22 09:53 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Paul Sture <nospam@sture.ch> - 2016-06-22 20:25 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-22 16:18 -0400
System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-23 07:49 +0000
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-23 12:26 -0400
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Johnny Billquist <bqt@softjar.se> - 2016-06-23 18:44 +0200
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-23 12:43 -0500
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-23 14:40 -0400
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-26 19:29 -0700
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-27 13:03 +0000
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-27 09:09 -0400
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-27 14:54 +0000
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-23 18:59 +0000
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-23 17:04 -0400
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Chris Scheers <chris@applied-synergy.com> - 2016-06-24 14:54 -0500
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-23 07:41 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-22 12:45 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Paul Anderson <paul.anderson@vmssoftware.com> - 2016-06-22 17:03 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-22 19:10 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "-------------------------Michael W. Farrell" <mfarrell001@verizon.net> - 2016-06-23 01:10 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-22 16:16 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-22 22:04 -0500
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-23 07:52 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-23 09:02 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-23 12:16 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Johnny Billquist <bqt@softjar.se> - 2016-06-21 17:58 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-21 13:05 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-22 12:27 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-22 12:46 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Paul Sture <nospam@sture.ch> - 2016-06-22 20:42 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-22 10:15 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-21 15:04 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-22 14:11 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-22 19:50 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-22 17:57 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-23 08:35 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was hb <end.of@inter.net> - 2016-06-23 15:18 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-23 09:46 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was hb <end.of@inter.net> - 2016-06-23 16:10 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-24 03:56 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-25 14:47 -0400
MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 19:44 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-26 02:16 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Paul Sture <nospam@sture.ch> - 2016-06-26 10:26 +0200
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 10:23 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 22:30 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-26 11:20 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-26 12:43 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 10:34 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:10 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-27 00:46 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-28 03:16 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-26 19:41 -0700
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-27 17:39 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-27 15:44 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 10:09 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 22:23 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 10:07 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-26 11:30 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:30 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-23 08:59 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Johnny Billquist <bqt@softjar.se> - 2016-06-23 16:40 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-24 03:05 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-22 15:00 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-23 01:40 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-23 00:18 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-23 10:10 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-23 01:50 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-23 11:03 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-22 19:57 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-23 09:00 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-24 03:54 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-24 21:24 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-25 12:43 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-25 12:52 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-25 21:37 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-26 02:07 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:47 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-19 14:40 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-19 20:14 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-20 19:19 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-06-19 21:29 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 15:02 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) John Reagan <xyzzy1959@gmail.com> - 2016-06-18 13:59 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 19:12 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:57 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 12:03 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-19 23:35 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 18:01 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-18 12:52 -0500
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-07-04 15:05 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-07-04 19:11 +0200
Re: FREESPADRIFT moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-17 02:57 +0000
Re: FREESPADRIFT Paul Sture <nospam@sture.ch> - 2016-06-17 07:24 +0200
Re: FREESPADRIFT David Froble <davef@tsoft-inc.com> - 2016-06-17 02:28 -0400
Re: FREESPADRIFT Paul Sture <nospam@sture.ch> - 2016-06-17 16:56 +0200
Re: FREESPADRIFT David Froble <davef@tsoft-inc.com> - 2016-06-17 13:22 -0400
Re: FREESPADRIFT Paul Sture <nospam@sture.ch> - 2016-06-17 20:53 +0200
Re: FREESPADRIFT "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-17 15:22 -0400
Re: FREESPADRIFT Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-17 10:39 +0200
Page 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-26 02:16 -0400 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nknrvv$mc$3@dont-email.me> |
| In reply to | #58923 |
Simon Clubley wrote: > On 2016-06-25, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote: >> OpenVMS has not integrated the MOUNT command or the mount system >> service with mount points or links. >> > > The MOUNT command as currently implemented (and the underlying > monolithic mass of filesystem code in the kernel) is not exactly > VMS's best selling point. > >> OpenVMS lacks a volume manager. >> >> OpenVMS support for storage device management and storage device >> swapping is limited at best. >> > > OTOH, you can do things with volumes in VMS clusters, especially when > things go wrong, that you can't do elsewhere. > > The terms "volume manager" and "storage device management" cover a wide > range of areas. So that I understand you, what _exactly_ are you looking > for (with examples if possible) with the last two items ? > >> The configuration and related commands are manual, file-based and the >> associated commands and syntax and configuration required (for >> configuring USB devices, for instance) tends toward arcane and manual. >> >> Then there's that MOUNT — which is useful for other purposes in the I/O >> system — is currently tied to disk and tape storage, and to specific >> disk formats. That design and that limit is not a surprise, but more >> than a little of the underlying flexibility around ACP handling (yes, >> ACPs are undocumented) was lost to developers here. But I digress. >> > > IMHO, I agree with you on this one. Based on what general knowledge > I know of how it's implemented internally (I've never seen the VMS > source code), MOUNT internals are a disaster area if you ever wanted > to implement general mount support in VMS for a variety of filesystems > in the way that it's possible in Linux (for example). > > You should be able to write (for example) a FAT32 filesystem driver > from public documentation and use a MOUNT command to mount it in the > same way as you can with an ODS-2 volume. Why do you think that MOUNT should be able to handle some format that it doesn't know about? Perhaps if you wish to implement a FAT32 filesystem driver, then you should also implement the method(s) for mounting the filesystem.
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2016-06-26 10:26 +0200 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <r6g44d-vr11.ln1@news.chingola.ch> |
| In reply to | #58927 |
On 2016-06-26, David Froble <davef@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> On 2016-06-25, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>> OpenVMS has not integrated the MOUNT command or the mount system
>>> service with mount points or links.
>>>
>>
>> The MOUNT command as currently implemented (and the underlying
>> monolithic mass of filesystem code in the kernel) is not exactly
>> VMS's best selling point.
>>
>>> OpenVMS lacks a volume manager.
>>>
>>> OpenVMS support for storage device management and storage device
>>> swapping is limited at best.
>>>
>>
>> OTOH, you can do things with volumes in VMS clusters, especially when
>> things go wrong, that you can't do elsewhere.
>>
>> The terms "volume manager" and "storage device management" cover a wide
>> range of areas. So that I understand you, what _exactly_ are you looking
>> for (with examples if possible) with the last two items ?
>>
>>> The configuration and related commands are manual, file-based and the
>>> associated commands and syntax and configuration required (for
>>> configuring USB devices, for instance) tends toward arcane and manual.
>>>
>>> Then there's that MOUNT — which is useful for other purposes in the I/O
>>> system — is currently tied to disk and tape storage, and to specific
>>> disk formats. That design and that limit is not a surprise, but more
>>> than a little of the underlying flexibility around ACP handling (yes,
>>> ACPs are undocumented) was lost to developers here. But I digress.
>>>
>>
>> IMHO, I agree with you on this one. Based on what general knowledge
>> I know of how it's implemented internally (I've never seen the VMS
>> source code), MOUNT internals are a disaster area if you ever wanted
>> to implement general mount support in VMS for a variety of filesystems
>> in the way that it's possible in Linux (for example).
>>
>> You should be able to write (for example) a FAT32 filesystem driver
>> from public documentation and use a MOUNT command to mount it in the
>> same way as you can with an ODS-2 volume.
>
> Why do you think that MOUNT should be able to handle some format that
> it doesn't know about?
> >
> Perhaps if you wish to implement a FAT32 filesystem driver, then you
> should also implement the method(s) for mounting the filesystem.
I think that what Hoff and Simon are complaining about is that the
programming interface to MOUNT is inflexible and undocumented.
$ HELP MOUNT /MEDIA
/MEDIA_FORMAT
/MEDIA_FORMAT=CDROM
Mounts a volume assuming the media to be ISO 9660 (or High
Sierra) formatted.
The /MEDIA_FORMAT=CDROM qualifier instructs the mount subsystem
to attempt to mount a volume assuming the media to be ISO 9660
(or High Sierra) formatted.
That's a pretty specific case for CD-ROMs, further complicated by:
Because it is possible to record parts of a CD-ROM in Files-
11 ODS-2 and other parts in ISO 9660 format, this qualifier
can be used to specify a CD-ROM mount (ISO 9660 or High
Sierra).
--
There are two hard things in computer science, and they are cache invalidation,
naming, and off-by-one errors.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-26 10:23 -0400 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkooge$quj$1@dont-email.me> |
| In reply to | #58928 |
On 2016-06-26 08:26:35 +0000, Paul Sture said: > I think that what Hoff and Simon are complaining about is that the > programming interface to MOUNT is inflexible and undocumented. Ayup, at least for me. And volume management is more than a little limited in general, too. > $ HELP MOUNT /MEDIA > > /MEDIA_FORMAT > > /MEDIA_FORMAT=CDROM That in-retrospect-wonderfully-misnamed keyword overrides the default format search order and the built-in format-sniffing carnal knowledge within MOUNT. it's only useful for dual-format disks containing both an ODS-2 or ODS-5 file system, and a file system related to ISO-9660, as those would otherwise always mount the ODS-2 or ODS-5 file system and ignore the ISO-9660 file system or related variant. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2016-06-26 22:30 +0000 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkpl2e$65t$2@dont-email.me> |
| In reply to | #58935 |
On 2016-06-26, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote: > On 2016-06-26 08:26:35 +0000, Paul Sture said: > >> I think that what Hoff and Simon are complaining about is that the >> programming interface to MOUNT is inflexible and undocumented. > > Ayup, at least for me. And volume management is more than a little > limited in general, too. > And for me as well. MOUNT should be little more than a CLI wrapper around a $MOUNT system service and that $MOUNT system service should provide generic mount services only and should ask filesystem specific drivers/modules about anything that's filesystem specific. BTW, all this (and a lot more) would be required as a pre-requisite to properly supporting end-user written filesystem drivers in VMS. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-26 11:20 -0400 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkorsb$7cg$1@dont-email.me> |
| In reply to | #58928 |
Paul Sture wrote: > I think that what Hoff and Simon are complaining about is that the > programming interface to MOUNT is inflexible and undocumented. Well, that is a general problem with VMS. I agree that better documentation, and better capability for modifications, would be a good thing. In more than one area.
[toc] | [prev] | [next] | [standalone]
| From | moroney@world.std.spaamtrap.com (Michael Moroney) |
|---|---|
| Date | 2016-06-26 12:43 +0000 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkoilg$jfa$1@pcls7.std.com> |
| In reply to | #58927 |
David Froble <davef@tsoft-inc.com> writes: >> You should be able to write (for example) a FAT32 filesystem driver >> from public documentation and use a MOUNT command to mount it in the >> same way as you can with an ODS-2 volume. >Why do you think that MOUNT should be able to handle some format that it >doesn't know about? >Perhaps if you wish to implement a FAT32 filesystem driver, then you >should also implement the method(s) for mounting the filesystem. File system support (other than relatively trivial transfer programs) in VMS need some knowledge by MOUNT for it to even know what to do about a foreign format. For the theoretical FAT32 filesystem, you'd need a /FAT32 paramater to tell MOUNT this is a FAT32 filesystem, for it to validate the filesystem and launch an ACP to deal with the file system. A while back, I did write enough code to recognize FAT filesystems, to "MOUNT" it (a standalone program does this, not VMS $ MOUNT) and to fire off an ACP. The disk shows up as MOUNTed on VMS and trying to do anything to it does properly poke the ACP, so a $ DIRECTORY DKxx: correctly dies with the expected error. The ACP actually doesn't know how to do anything at all except to DISMOUNT it, and I probably won't be able to learn enough to make it do anything useful. And they pay me to do different things, not this, this was just toy code. Nob
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-26 10:34 -0400 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkop55$tb4$1@dont-email.me> |
| In reply to | #58932 |
On 2016-06-26 12:43:28 +0000, Michael Moroney said: > File system support (other than relatively trivial transfer programs) > in VMS need some knowledge by MOUNT for it to even know what to do > about a foreign format. For the theoretical FAT32 filesystem, you'd > need a /FAT32 paramater to tell MOUNT this is a FAT32 filesystem, for > it to validate the filesystem and launch an ACP to deal with the file > system. Wouldn't be the first time that dynamically-activated extensions or callouts were used within OpenVMS or layered products, or ACPs for that matter, and MOUNT does still has a largely-now-runt ACP-related qualifier. (But this also leads to discussions around code signing and related, though those areas of security haven't become visible to most OpenVMS users. Yet.) -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2016-06-26 23:10 +0000 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkpnc9$dr3$1@dont-email.me> |
| In reply to | #58936 |
On 2016-06-26, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote: > On 2016-06-26 12:43:28 +0000, Michael Moroney said: > >> File system support (other than relatively trivial transfer programs) >> in VMS need some knowledge by MOUNT for it to even know what to do >> about a foreign format. For the theoretical FAT32 filesystem, you'd >> need a /FAT32 paramater to tell MOUNT this is a FAT32 filesystem, for >> it to validate the filesystem and launch an ACP to deal with the file >> system. IMHO, MOUNT should not be validating that filesystem; it should be asking a previously registered FAT32 filesystem driver if the volume in question contains a valid FAT32 filesystem. > > Wouldn't be the first time that dynamically-activated extensions or > callouts were used within OpenVMS or layered products, or ACPs for that > matter, and MOUNT does still has a largely-now-runt ACP-related > qualifier. > It would be a lot better if you could load and remove filesystems at kernel level instead (in the same way that you can currently load a device driver at runtime [but not remove it :-(]) and have the ODS-2/5 support just be yet another filesystem driver. And yes, I know in reality that's going to be NuVMS territory only. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-27 00:46 -0400 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkqb2r$rme$1@dont-email.me> |
| In reply to | #58953 |
Simon Clubley wrote: > On 2016-06-26, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote: >> On 2016-06-26 12:43:28 +0000, Michael Moroney said: >> >>> File system support (other than relatively trivial transfer programs) >>> in VMS need some knowledge by MOUNT for it to even know what to do >>> about a foreign format. For the theoretical FAT32 filesystem, you'd >>> need a /FAT32 paramater to tell MOUNT this is a FAT32 filesystem, for >>> it to validate the filesystem and launch an ACP to deal with the file >>> system. > > IMHO, MOUNT should not be validating that filesystem; it should be asking > a previously registered FAT32 filesystem driver if the volume in question > contains a valid FAT32 filesystem. > >> Wouldn't be the first time that dynamically-activated extensions or >> callouts were used within OpenVMS or layered products, or ACPs for that >> matter, and MOUNT does still has a largely-now-runt ACP-related >> qualifier. >> > > It would be a lot better if you could load and remove filesystems at > kernel level instead (in the same way that you can currently load a > device driver at runtime [but not remove it :-(]) and have the ODS-2/5 > support just be yet another filesystem driver. > > And yes, I know in reality that's going to be NuVMS territory only. > > Simon. > Not so fast .... If VSI is developing a new file system, and the road map says they are, they are also going to run into this problem. So they will: 1) Add another file system where required 2) Do the design and work to allow what you're asking
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2016-06-28 03:16 +0000 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nksq6h$rsk$2@dont-email.me> |
| In reply to | #58964 |
On 2016-06-27, David Froble <davef@tsoft-inc.com> wrote: > Simon Clubley wrote: >> >> It would be a lot better if you could load and remove filesystems at >> kernel level instead (in the same way that you can currently load a >> device driver at runtime [but not remove it :-(]) and have the ODS-2/5 >> support just be yet another filesystem driver. >> >> And yes, I know in reality that's going to be NuVMS territory only. >> > > Not so fast .... > > If VSI is developing a new file system, and the road map says they are, they are > also going to run into this problem. So they will: > > 1) Add another file system where required > It will probably be a monolithic mass of code added on top of the existing monolithic mass of code but it would be _very_ nice to be proved wrong here. > 2) Do the design and work to allow what you're asking Or MOUNT will just get yet more special case and filesystem specific code on top of the current special case and filesystem specific code. There are a number of things that VMS, even today, is very good at when compared to the opposition. Handling filesystems in a general way is not one of them however. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-26 19:41 -0700 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <fba86d13-9fd4-4fed-bf4d-0b4b83d2fc76@googlegroups.com> |
| In reply to | #58932 |
On Monday, June 27, 2016 at 12:44:13 AM UTC+12, Michael Moroney wrote: > For the theoretical FAT32 filesystem, you'd need a /FAT32 > paramater to tell MOUNT this is a FAT32 filesystem, for it to validate the > filesystem and launch an ACP to deal with the file system. Actually, most of the time in Linux, I don’t need to worry about this. It is capable of automatically sniffing the filesystem format as part of the mount process.
[toc] | [prev] | [next] | [standalone]
| From | moroney@world.std.spaamtrap.com (Michael Moroney) |
|---|---|
| Date | 2016-06-27 17:39 +0000 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkrodb$3c7$1@pcls7.std.com> |
| In reply to | #58961 |
lawrencedo99@gmail.com writes: >On Monday, June 27, 2016 at 12:44:13 AM UTC+12, Michael Moroney wrote: >> For the theoretical FAT32 filesystem, you'd need a /FAT32 >> paramater to tell MOUNT this is a FAT32 filesystem, for it to validate the >> filesystem and launch an ACP to deal with the file system. >Actually, most of the time in Linux, I don't need to worry about this. >It is capable of automatically sniffing the filesystem format as part of >the mount process. I accidentally produced something that would confound this. I put an ODS-5 VMS filesystem on a thumb drive. Later I stuck the drive in a PC and formatted it. The PC then saw it as an (empty) FAT-32 drive. I don't think I put anything on the drive from the PC. Later I put it back into a VMS system intending to init it with a VMS file system again but I $ MOUNTED it with no problem. All the necessary VMS bits to mount it were still there. I did an $ ANALYZE/DISK expecting something to be corrupted, yet it passed. The VMS file system structure was still there. Back to the PC and it was still FAT... What should a file system agnostic MOUNT do with this? I should try to see if I can recreate it and see what is in block 0/the GPT blocks ...
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-27 15:44 -0400 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkrvmf$d40$1@dont-email.me> |
| In reply to | #59009 |
On 2016-06-27 17:39:55 +0000, Michael Moroney said: > I accidentally produced something that would confound this. I put an > ODS-5 VMS filesystem on a thumb drive. Later I stuck the drive in a PC > and formatted it. The PC then saw it as an (empty) FAT-32 drive. I > don't think I put anything on the drive from the PC. Later I put it > back into a VMS system intending to init it with a VMS file system > again but I $ MOUNTED it with no problem. All the necessary VMS bits > to mount it were still there. I did an $ ANALYZE/DISK expecting > something to be corrupted, yet it passed. The VMS file system > structure was still there. Back to the PC and it was still FAT... The FAT and ODS-5 structures overlap, so that disk was honked, and the tools involved were clearly not detecting the honkage; the inconsistencies. > What should a file system agnostic MOUNT do with this? I should try to > see if I can recreate it and see what is in block 0/the GPT blocks ... Better detect a corrupt file system? But for dual-format-capable file systems such as ODS-2 or ODS-5 and ISO-9660 systems, a switch or qualifier is necessary to mount a file system further down the search order from what's initially found, when the file systems are dual-format. This qualifier already exists in OpenVMS. There'll be yet added work here, if (when?) OpenVMS supports GPT disks and disk partitioning, too. The sys$setboot tool can sniff some of the basic file system structures. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-26 10:09 -0400 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkonnn$o8p$1@dont-email.me> |
| In reply to | #58927 |
On 2016-06-26 06:16:31 +0000, David Froble said: > Why do you think that MOUNT should be able to handle some format that > it doesn't know about? > > Perhaps if you wish to implement a FAT32 filesystem driver, then you > should also implement the method(s) for mounting the filesystem. Don't ever wonder how the command interface complexity and the glue code and the management effort increases, either. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2016-06-26 22:23 +0000 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkpkk9$65t$1@dont-email.me> |
| In reply to | #58927 |
On 2016-06-26, David Froble <davef@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>>
>> IMHO, I agree with you on this one. Based on what general knowledge
>> I know of how it's implemented internally (I've never seen the VMS
>> source code), MOUNT internals are a disaster area if you ever wanted
>> to implement general mount support in VMS for a variety of filesystems
>> in the way that it's possible in Linux (for example).
>>
>> You should be able to write (for example) a FAT32 filesystem driver
>> from public documentation and use a MOUNT command to mount it in the
>> same way as you can with an ODS-2 volume.
>
> Why do you think that MOUNT should be able to handle some format that it doesn't
> know about?
>
The MOUNT command should know exactly nothing about the internals of
the filesystem on _any_ volume it is being asked to mount; it should
restrict itself to providing the general mount infrastructue.
In a modular system, filesystem specific knowledge should be held
within the filesystem driver only and MOUNT should restrict itself
to asking the driver for {X} filesystem (via a standard interface)
if the driver recognises the filesystem on volume {Y}.
{Y} does not have to be a physical disk/tape/whatever BTW; it could
be a purely software/virtual construct in a modular system.
> Perhaps if you wish to implement a FAT32 filesystem driver, then you should also
> implement the method(s) for mounting the filesystem.
And that's exactly what happens in a modular system; MOUNT would
provide general mounting services only. If you didn't want MOUNT
to ask each registered filesystem in turn about the volume MOUNT
was being asked to mount, then the only additional MOUNT qualifier
you would need would be /FILESYSTEM={whatever} where {whatever}
would be the registered name of the filesystem driver.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-26 10:07 -0400 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkonj3$nmm$1@dont-email.me> |
| In reply to | #58923 |
On 2016-06-25 19:44:38 +0000, Simon Clubley said: > On 2016-06-25, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote: > >> OpenVMS lacks a volume manager. >> >> OpenVMS support for storage device management and storage device >> swapping is limited at best. > > OTOH, you can do things with volumes in VMS clusters, especially when > things go wrong, that you can't do elsewhere. One of the few (only?) distinctive features of OpenVMS and clustering remaining is multi-host RAID-1, and the DVE/DDS support. Most of the other capabilities of clustering that an application might seek to use can be implemented — variously through entirely different means, but with similar results — on other platforms. > The terms "volume manager" and "storage device management" cover a wide > range of areas. So that I understand you, what _exactly_ are you > looking for (with examples if possible) with the last two items ? I was answering a question. OpenVMS volume management is crayon-grade. It certainly works, but it's manual. What would I prefer to see? I'd prefer to see volumes become far less interesting to applications with the integration of the mount point support, the ability to automatically mount or re-mount volumes in cluster and NFS configurations (and the integrated SMB and WebDAV clients, if those ever arrive) as the hosts come and go (what some of us use MSCPMOUNT for), and I'd prefer the ability to notify on storage- and volume-level errors (error handling and notifications are another area of OpenVMS that was quite good to start, but that has subsequently degraded into a free-for-all of a zillion different tool- and app-specific solutions), the ability to automatically detect WWIDs and to manage the FC scanning without all the manual schtick currently required — not modifying or mounting detected volumes, but avoiding the WWIDMGR dance and the absurdly manual FC SAN configuration and management where that can be automated and integrated and preferably avoiding the need for the rd_devid (xec) and management_in (xa3) commands if possible, better automation of the DVE/DDS volume growth operation, rid of the manual editing of the sys$config and sys$user_config,and it'd be nice to have USB sector-addressable storage volumes automatically detected and made available. Volume-level encryption and the related key management, too. Background scrubbing, for those that cling to rotating rust. Managing snapshots and local and off-site backups. Storage allocation and storage migration support too, and preferably transparent — but some apps are going to squabble or are going to need to change. Among other details. Just having a MOUNT-integrated database with a list of which volumes are in use or are scratch, and which projects and users are on what volume, and the interface to the central password and certificate store, would be nice, too. Take a long hard look at the storage-related DCL glue code in SYSTARTUP_VMS and SYCONFIG and SYSHUTDWN and SYSHUTDWN_0010 and MSCPMOUNT and elsewhere, and start to work to remove it. In short, take what your average system manager has to do to manage your average moderate-to-large non-static storage configuration and across the current suite of disparate tools involved (BACKUP or other backup tool, SHOW ERROR and ELV, MOUNT, etc), and better automate it. Yes, some of you are working at sites with servers and volumes and configurations that seldom change or that never change. With SYSTARTUP_VMS and SYSHUTDWN and such having reached a state of utter perfection. Good on you. Good job. Seriously. Volume management features and better storage automation are probably not for you. But even among some of these sites, I suspect there are features here that you could use, though. Are all of these necessary? Of course not. But consider what features will OpenVMS be competing with and competing against, and what those other platforms will be providing, in five or ten years, too. >> The configuration and related commands are manual, file-based and the >> associated commands and syntax and configuration required (for >> configuring USB devices, for instance) tends toward arcane and manual. >> >> Then there's that MOUNT — which is useful for other purposes in the I/O >> system — is currently tied to disk and tape storage, and to specific >> disk formats. That design and that limit is not a surprise, but more >> than a little of the underlying flexibility around ACP handling (yes, >> ACPs are undocumented) was lost to developers here. But I digress. > > IMHO, I agree with you on this one. Based on what general knowledge I > know of how it's implemented internally (I've never seen the VMS source > code), MOUNT internals are a disaster area if you ever wanted > to implement general mount support in VMS for a variety of filesystems > in the way that it's possible in Linux (for example). The MOUNT code is good code, but the design is old and limited. MOUNT has carnal knowledge of the supported file systems. There's no support for user-mode nor inner-mode file systems; for FUSE or for the ability to add and integrate additional file systems. There's no way to get MOUNT to launch an ACP on a non-storage or storage-but-non-recognized-format device, for that matter. There are examples such as NFS, which didn't have a way to use MOUNT, and various products which use ACPs to "assist" with driver-specific processing. > You should be able to write (for example) a FAT32 filesystem driver > from public documentation and use a MOUNT command to mount it in the > same way as you can with an ODS-2 volume. That's one of many examples of what's missing here. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-26 11:30 -0400 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkosfg$9h0$1@dont-email.me> |
| In reply to | #58933 |
Stephen Hoffman wrote: > On 2016-06-25 19:44:38 +0000, Simon Clubley said: > >> On 2016-06-25, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote: >> >>> OpenVMS lacks a volume manager. >>> >>> OpenVMS support for storage device management and storage device >>> swapping is limited at best. >> >> OTOH, you can do things with volumes in VMS clusters, especially when >> things go wrong, that you can't do elsewhere. > > One of the few (only?) distinctive features of OpenVMS and clustering > remaining is multi-host RAID-1, and the DVE/DDS support. > > Most of the other capabilities of clustering that an application might > seek to use can be implemented — variously through entirely different > means, but with similar results — on other platforms. > >> The terms "volume manager" and "storage device management" cover a >> wide range of areas. So that I understand you, what _exactly_ are you >> looking for (with examples if possible) with the last two items ? > > I was answering a question. > > OpenVMS volume management is crayon-grade. It certainly works, but it's > manual. > > What would I prefer to see? I'd prefer to see volumes become far less > interesting to applications with the integration of the mount point > support, the ability to automatically mount or re-mount volumes in > cluster and NFS configurations (and the integrated SMB and WebDAV > clients, if those ever arrive) as the hosts come and go (what some of us > use MSCPMOUNT for), and I'd prefer the ability to notify on storage- and > volume-level errors (error handling and notifications are another area > of OpenVMS that was quite good to start, but that has subsequently > degraded into a free-for-all of a zillion different tool- and > app-specific solutions), the ability to automatically detect WWIDs and > to manage the FC scanning without all the manual schtick currently > required — not modifying or mounting detected volumes, but avoiding the > WWIDMGR dance and the absurdly manual FC SAN configuration and > management where that can be automated and integrated and preferably > avoiding the need for the rd_devid (xec) and management_in (xa3) > commands if possible, better automation of the DVE/DDS volume growth > operation, rid of the manual editing of the sys$config and > sys$user_config,and it'd be nice to have USB sector-addressable storage > volumes automatically detected and made available. Volume-level > encryption and the related key management, too. Background scrubbing, > for those that cling to rotating rust. Managing snapshots and local > and off-site backups. Storage allocation and storage migration support > too, and preferably transparent — but some apps are going to squabble or > are going to need to change. Among other details. > > Just having a MOUNT-integrated database with a list of which volumes are > in use or are scratch, and which projects and users are on what volume, > and the interface to the central password and certificate store, would > be nice, too. > > Take a long hard look at the storage-related DCL glue code in > SYSTARTUP_VMS and SYCONFIG and SYSHUTDWN and SYSHUTDWN_0010 and > MSCPMOUNT and elsewhere, and start to work to remove it. In short, > take what your average system manager has to do to manage your average > moderate-to-large non-static storage configuration and across the > current suite of disparate tools involved (BACKUP or other backup tool, > SHOW ERROR and ELV, MOUNT, etc), and better automate it. > > Yes, some of you are working at sites with servers and volumes and > configurations that seldom change or that never change. With > SYSTARTUP_VMS and SYSHUTDWN and such having reached a state of utter > perfection. Good on you. Good job. Seriously. Volume management > features and better storage automation are probably not for you. But > even among some of these sites, I suspect there are features here that > you could use, though. > > Are all of these necessary? Of course not. But consider what features > will OpenVMS be competing with and competing against, and what those > other platforms will be providing, in five or ten years, too. > >>> The configuration and related commands are manual, file-based and the >>> associated commands and syntax and configuration required (for >>> configuring USB devices, for instance) tends toward arcane and manual. >>> >>> Then there's that MOUNT — which is useful for other purposes in the >>> I/O system — is currently tied to disk and tape storage, and to >>> specific disk formats. That design and that limit is not a >>> surprise, but more than a little of the underlying flexibility >>> around ACP handling (yes, ACPs are undocumented) was lost to >>> developers here. But I digress. >> >> IMHO, I agree with you on this one. Based on what general knowledge I >> know of how it's implemented internally (I've never seen the VMS >> source code), MOUNT internals are a disaster area if you ever wanted >> to implement general mount support in VMS for a variety of filesystems >> in the way that it's possible in Linux (for example). > > The MOUNT code is good code, but the design is old and limited. MOUNT > has carnal knowledge of the supported file systems. There's no support > for user-mode nor inner-mode file systems; for FUSE or for the ability > to add and integrate additional file systems. There's no way to get > MOUNT to launch an ACP on a non-storage or > storage-but-non-recognized-format device, for that matter. There are > examples such as NFS, which didn't have a way to use MOUNT, and various > products which use ACPs to "assist" with driver-specific processing. > >> You should be able to write (for example) a FAT32 filesystem driver >> from public documentation and use a MOUNT command to mount it in the >> same way as you can with an ODS-2 volume. > > That's one of many examples of what's missing here. > > > I'd think that the whole system of device handling in VMS could use a serious look, and re-design, to incorporate things that have appeared since the original work was done. MOUNT is just a part of this. Now, I know you probably know this, MOUNT /FOREIGN gives an application access to a device. No, it's not the OS that does anything. And yes, you'd want the OS to handle the device, not an application. Probably should not have mentioned this .... :-)
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2016-06-26 23:30 +0000 |
| Subject | Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkpoiq$dr3$2@dont-email.me> |
| In reply to | #58933 |
On 2016-06-26, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote: > On 2016-06-25 19:44:38 +0000, Simon Clubley said: >> The terms "volume manager" and "storage device management" cover a wide >> range of areas. So that I understand you, what _exactly_ are you >> looking for (with examples if possible) with the last two items ? > > I was answering a question. > > OpenVMS volume management is crayon-grade. It certainly works, but > it's manual. > [snip] Thanks for taking the time to write out that list; there's some interesting items in there. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-23 08:59 -0400 |
| Subject | Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <7OJqEPpPfgqo@eisner.encompasserve.org> |
| In reply to | #58790 |
In article <be575c72-8d63-44a2-9aeb-c15bb24c7c59@googlegroups.com>, lawrencedo99@gmail.com writes: > > Then there=E2=80=99s the sheer complexity of a VMS filespec. Does the idea = > of exposing disk device names seem so wise nowadays? Yes, it does. Works just fine. Don't need to hide them like some OS written in the late 1960s. > On POSIX, you have a p= > athspec with components separated by simple slashes, and disk device names = > are completely hidden. There are issues that arize when you can see the device names, and issues that arize when you can't.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-23 16:40 +0200 |
| Subject | Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was |
| Message-ID | <nkgsc9$rm$1@Iltempo.Update.UU.SE> |
| In reply to | #58838 |
On 2016-06-23 14:59, Bob Koehler wrote: > In article <be575c72-8d63-44a2-9aeb-c15bb24c7c59@googlegroups.com>, lawrencedo99@gmail.com writes: >> >> Then there=E2=80=99s the sheer complexity of a VMS filespec. Does the idea = >> of exposing disk device names seem so wise nowadays? > > Yes, it does. Works just fine. Don't need to hide them like some OS > written in the late 1960s. Agreed. There is no real problem with explicitly showing the device, as opposed to hiding it. And yes, VMS is way newer than Unix. :-) >> On POSIX, you have a p= >> athspec with components separated by simple slashes, and disk device names = >> are completely hidden. > > There are issues that arize when you can see the device names, and > issues that arize when you can't. Right. Pro's and cons. I wish more people could remember that. Johnny
[toc] | [prev] | [next] | [standalone]
Page 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
Back to top | Article view | comp.os.vms
csiph-web