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 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-23 14:50 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkhb28$5la$3@dont-email.me> |
| In reply to | #58857 |
VAXman- @SendSpamHere.ORG wrote: > In article <nkh313$ekh$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-23 18:06, VAXman-@SendSpamHere.ORG wrote: >>> In article <nkgspt$rm$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> This whole thread came about because some people pointed out that exact >>>> file sizes, to the byte, sometimes were wanted. And then it's been a >>>> thread of "why?". And when I give an example of why, it becomes a thread >>>> of "why?". >>>> >>>> Yes, I know VMS couldn't care less. RSX also couldn't care less. Me, >>>> writing an http server (as well as an ftp server), do care. And doing >>>> these things, which many people consider to be pretty basic tools that >>>> all systems should have, is a pain because the file system do not have >>>> this information. >>>> >>>> Yes, there are solutions. They are costly. Could there possibly be a >>>> point in adding this information, if it can be done at a low cost? >>>> >>>> You are just putting your head in the sand and saying that since it's >>>> not there, we don't need it. >>> Why pay for it when you don't need it? Pay for it when you do! >> Which, for a web server, is every time a document is requested, which >> might mean a dozen requests for a single page. And that is just one >> example. And for a 10M document, calculating the size every time is >> pretty costly... Reading through 10M to find the size, and then read >> through it again, to deliver it. Color me not-excited. > > Again, that's not a VMS problem; it's your/the protocol. Perhaps, instead > of about it complaining here, you should complain to the IETF. ;) Agreed. > VMS moved files over the network without having to know the precise number > of bytes it has to move before doing so, so there could and there should > and there are alternative ways this can be accomplished without knowing a > count beforehand. What about a protocol that allows data to be sent without a byte count up front, terminated by some termination flag, and then the byte count so the receiver can check for a good transmission? Should work.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-23 21:24 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkhd0k$2us$2@Iltempo.Update.UU.SE> |
| In reply to | #58861 |
On 2016-06-23 20:50, David Froble wrote: > VAXman- @SendSpamHere.ORG wrote: >> In article <nkh313$ekh$1@Iltempo.Update.UU.SE>, Johnny Billquist >> <bqt@softjar.se> writes: >>> On 2016-06-23 18:06, VAXman-@SendSpamHere.ORG wrote: >>>> In article <nkgspt$rm$2@Iltempo.Update.UU.SE>, Johnny Billquist >>>> <bqt@softjar.se> writes: >>>>> This whole thread came about because some people pointed out that >>>>> exact >>>>> file sizes, to the byte, sometimes were wanted. And then it's been a >>>>> thread of "why?". And when I give an example of why, it becomes a >>>>> thread >>>>> of "why?". >>>>> >>>>> Yes, I know VMS couldn't care less. RSX also couldn't care less. Me, >>>>> writing an http server (as well as an ftp server), do care. And doing >>>>> these things, which many people consider to be pretty basic tools that >>>>> all systems should have, is a pain because the file system do not have >>>>> this information. >>>>> >>>>> Yes, there are solutions. They are costly. Could there possibly be a >>>>> point in adding this information, if it can be done at a low cost? >>>>> >>>>> You are just putting your head in the sand and saying that since it's >>>>> not there, we don't need it. >>>> Why pay for it when you don't need it? Pay for it when you do! >>> Which, for a web server, is every time a document is requested, which >>> might mean a dozen requests for a single page. And that is just one >>> example. And for a 10M document, calculating the size every time is >>> pretty costly... Reading through 10M to find the size, and then read >>> through it again, to deliver it. Color me not-excited. >> >> Again, that's not a VMS problem; it's your/the protocol. Perhaps, >> instead >> of about it complaining here, you should complain to the IETF. ;) > > Agreed. > >> VMS moved files over the network without having to know the precise >> number >> of bytes it has to move before doing so, so there could and there >> should and there are alternative ways this can be accomplished without >> knowing a >> count beforehand. > > What about a protocol that allows data to be sent without a byte count > up front, terminated by some termination flag, and then the byte count > so the receiver can check for a good transmission? Should work. There are plenty of ways to design protocols. Doing the size after the file will not allow you to have any understanding of how much space should be reserved for the file, nor get any idea of how far you are from completion. But that should not stop you. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-23 19:34 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B0ED.278215B5@SendSpamHere.ORG> |
| In reply to | #58861 |
In article <nkhd0k$2us$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-23 20:50, David Froble wrote: >> VAXman- @SendSpamHere.ORG wrote: >>> In article <nkh313$ekh$1@Iltempo.Update.UU.SE>, Johnny Billquist >>> <bqt@softjar.se> writes: >>>> On 2016-06-23 18:06, VAXman-@SendSpamHere.ORG wrote: >>>>> In article <nkgspt$rm$2@Iltempo.Update.UU.SE>, Johnny Billquist >>>>> <bqt@softjar.se> writes: >>>>>> This whole thread came about because some people pointed out that >>>>>> exact >>>>>> file sizes, to the byte, sometimes were wanted. And then it's been a >>>>>> thread of "why?". And when I give an example of why, it becomes a >>>>>> thread >>>>>> of "why?". >>>>>> >>>>>> Yes, I know VMS couldn't care less. RSX also couldn't care less. Me, >>>>>> writing an http server (as well as an ftp server), do care. And doing >>>>>> these things, which many people consider to be pretty basic tools that >>>>>> all systems should have, is a pain because the file system do not have >>>>>> this information. >>>>>> >>>>>> Yes, there are solutions. They are costly. Could there possibly be a >>>>>> point in adding this information, if it can be done at a low cost? >>>>>> >>>>>> You are just putting your head in the sand and saying that since it's >>>>>> not there, we don't need it. >>>>> Why pay for it when you don't need it? Pay for it when you do! >>>> Which, for a web server, is every time a document is requested, which >>>> might mean a dozen requests for a single page. And that is just one >>>> example. And for a 10M document, calculating the size every time is >>>> pretty costly... Reading through 10M to find the size, and then read >>>> through it again, to deliver it. Color me not-excited. >>> >>> Again, that's not a VMS problem; it's your/the protocol. Perhaps, >>> instead >>> of about it complaining here, you should complain to the IETF. ;) >> >> Agreed. >> >>> VMS moved files over the network without having to know the precise >>> number >>> of bytes it has to move before doing so, so there could and there >>> should and there are alternative ways this can be accomplished without >>> knowing a >>> count beforehand. >> >> What about a protocol that allows data to be sent without a byte count >> up front, terminated by some termination flag, and then the byte count >> so the receiver can check for a good transmission? Should work. > >There are plenty of ways to design protocols. >Doing the size after the file will not allow you to have any >understanding of how much space should be reserved for the file, nor get >any idea of how far you are from completion. >But that should not stop you. So I can get a silly progression bar graphic or, like on linux, file transfer time left is 8 mins... 7 mins.. 9 mins... ... 10 secs... 5 secs... 14 secs... 2 sec., nearly complete... transfer complete. Anyway, there are web servers for VMS and several other TCP/IP protocols for VMS. You may need to ask those who have successfully implemented those how to approach your issue if you don't want to use the RFM=STM approach. I really don't see why you think that's wrong. *ix text files are streams with <CR>s and <LF>s, and binary files are, IIRC, sent in multiples of a block of some size (512). -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-23 22:02 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkhf9i$7s3$1@Iltempo.Update.UU.SE> |
| In reply to | #58872 |
On 2016-06-23 21:34, VAXman-@SendSpamHere.ORG wrote: > In article <nkhd0k$2us$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> There are plenty of ways to design protocols. >> Doing the size after the file will not allow you to have any >> understanding of how much space should be reserved for the file, nor get >> any idea of how far you are from completion. >> But that should not stop you. > > So I can get a silly progression bar graphic or, like on linux, file transfer > time left is 8 mins... 7 mins.. 9 mins... ... 10 secs... 5 secs... 14 secs... > 2 sec., nearly complete... transfer complete. I was merely pointing out why protocols have been designed the way that they pass the size before the data. You might not enjoy the results, and you are free to design your own protocols. It don't change the existing protocols, and it will not make other people change how they design protocols, since some of them really think there is a benefit in this. > Anyway, there are web servers for VMS and several other TCP/IP protocols for > VMS. You may need to ask those who have successfully implemented those how to > approach your issue if you don't want to use the RFM=STM approach. I really > don't see why you think that's wrong. *ix text files are streams with <CR>s > and <LF>s, and binary files are, IIRC, sent in multiples of a block of some > size (512). Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are no blocks, nothing is sent in any multiple of blocks. (And besides, text files in Unix do not have CF and LF in them. They just have LF. Which is why I was complaining about Unix ftp implementations, which often lies about file size, and sometimes cheat when transferring in text mode. These protocols were not designed by Unix people...) Johnny
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-24 08:52 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <yE7BjmIxxkSS@eisner.encompasserve.org> |
| In reply to | #58876 |
In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: > > Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are > no blocks, nothing is sent in any multiple of blocks. > (And besides, text files in Unix do not have CF and LF in them. They > just have LF. Which is why I was complaining about Unix ftp > implementations, which often lies about file size, and sometimes cheat > when transferring in text mode. These protocols were not designed by > Unix people...) So hwo does UNIX solve it? By lieing about it? Does that work anyhow? If so, then why can't VMS lie about it? Or do both UNIX and VMS have to read the file twice to get it right?
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-24 16:54 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B1A0.05EC55FB@SendSpamHere.ORG> |
| In reply to | #58886 |
In article <yE7BjmIxxkSS@eisner.encompasserve.org>, koehler@eisner.nospam.decuserve.org (Bob Koehler) writes: >In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> >> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >> no blocks, nothing is sent in any multiple of blocks. >> (And besides, text files in Unix do not have CF and LF in them. They >> just have LF. Which is why I was complaining about Unix ftp >> implementations, which often lies about file size, and sometimes cheat >> when transferring in text mode. These protocols were not designed by >> Unix people...) > > So hwo does UNIX solve it? By lieing about it? Does that work > anyhow? If so, then why can't VMS lie about it? Or do both UNIX > and VMS have to read the file twice to get it right? Maybe you'll get an answer but I'd suggest you don't hold your breath. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-24 13:41 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkjrcr$4ra$1@dont-email.me> |
| In reply to | #58887 |
On 2016-06-24 16:54:35 +0000, VAXman- @SendSpamHere.ORG said: > In article <yE7BjmIxxkSS@eisner.encompasserve.org>, > koehler@eisner.nospam.decuserve.org (Bob Koehler) writes: >> In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist >> <bqt@softjar.se> writes: >>> >>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >>> no blocks, nothing is sent in any multiple of blocks. (And besides, >>> text files in Unix do not have CF and LF in them. They just have LF. >>> Which is why I was complaining about Unix ftp implementations, which >>> often lies about file size, and sometimes cheat when transferring in >>> text mode. These protocols were not designed by Unix people...) >> >> So hwo does UNIX solve it? By lieing about it? Does that work anyhow? >> If so, then why can't VMS lie about it? Or do both UNIX and VMS have >> to read the file twice to get it right? > > Maybe you'll get an answer but I'd suggest you don't hold your breath. Unix returns the file size in bytes. As for TCP presenting a stream and not datagrams, more than a few neophyte developers have been derailed by that detail. There's no one-to-one mapping of write I/O size to read I/O size with TCP. One TCP write can produce one read, or potentially as many single byte read I/O requests as bytes were written. For file transfers, the app developer chooses how much data to toss over the connection. That might be records from a file or records synthesized by the network server for a network protocol, or whatever hunk of data the developer thought was appropriate. Particularly with 64-bit addressing and a flat address space, it wouldn't surprise me to see a few just read and write the whole file. For those on systems that don't have to use socket I/O, they'll call the file transfer framework or whatever the local analog; libssh underneath ssh has a callable interface. Though AFAICT, there's no libssh available with the HPE ssh bits. There is a libcurl port around for OpenVMS. OpenVMS itself never sprouted a local callable copy akin to macOS and copyfile(3) — beyond callable convert which can usually get you there, and probably callable backup, or probably the FTSV/FTSO spool layered product bits for those that have access to that — though there was some work on providing that. Having a simple call that gets you the user file size would be handy, at least for stream files and analogous. Getting the user data size of a NoSQL, or metadata-enriched RMS file formats, or a relational database file, is rather less useful, so that'd best be the size of the whole wad that needs to be transferred. Whether that's blocks or not matters little. But then this whole block size stuff will get even more interesting if/when VSI adds support for native access to the two and four kibibyte sector sizes that are now available. EFI sees those differences as do a few other giblets, but most users haven't had to deal with that yet. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-24 18:27 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B1AC.FFD7B360@SendSpamHere.ORG> |
| In reply to | #58888 |
In article <nkjrcr$4ra$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes: >On 2016-06-24 16:54:35 +0000, VAXman- @SendSpamHere.ORG said: > >> In article <yE7BjmIxxkSS@eisner.encompasserve.org>, >> koehler@eisner.nospam.decuserve.org (Bob Koehler) writes: >>> In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist >>> <bqt@softjar.se> writes: >>>> >>>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >>>> no blocks, nothing is sent in any multiple of blocks. (And besides, >>>> text files in Unix do not have CF and LF in them. They just have LF. >>>> Which is why I was complaining about Unix ftp implementations, which >>>> often lies about file size, and sometimes cheat when transferring in >>>> text mode. These protocols were not designed by Unix people...) >>> >>> So hwo does UNIX solve it? By lieing about it? Does that work anyhow? >>> If so, then why can't VMS lie about it? Or do both UNIX and VMS have >>> to read the file twice to get it right? >> >> Maybe you'll get an answer but I'd suggest you don't hold your breath. > >Unix returns the file size in bytes. > >As for TCP presenting a stream and not datagrams, more than a few >neophyte developers have been derailed by that detail. There's no >one-to-one mapping of write I/O size to read I/O size with TCP. One >TCP write can produce one read, or potentially as many single byte read >I/O requests as bytes were written. > >For file transfers, the app developer chooses how much data to toss >over the connection. That might be records from a file or records >synthesized by the network server for a network protocol, or whatever >hunk of data the developer thought was appropriate. Particularly with >64-bit addressing and a flat address space, it wouldn't surprise me to >see a few just read and write the whole file. > >For those on systems that don't have to use socket I/O, they'll call >the file transfer framework or whatever the local analog; libssh >underneath ssh has a callable interface. Though AFAICT, there's no >libssh available with the HPE ssh bits. There is a libcurl port around >for OpenVMS. OpenVMS itself never sprouted a local callable copy akin >to macOS and copyfile(3) — beyond callable convert which can usually >get you there, and probably callable backup, or probably the FTSV/FTSO >spool layered product bits for those that have access to that — though >there was some work on providing that. > >Having a simple call that gets you the user file size would be handy, >at least for stream files and analogous. Getting the user data size >of a NoSQL, or metadata-enriched RMS file formats, or a relational >database file, is rather less useful, so that'd best be the size of the >whole wad that needs to be transferred. Whether that's blocks or not >matters little. > >But then this whole block size stuff will get even more interesting >if/when VSI adds support for native access to the two and four kibibyte >sector sizes that are now available. EFI sees those differences as do >a few other giblets, but most users haven't had to deal with that yet. You don't need to explain that to me. I've been trying to get Johnny to realize that there are numerous ways to represent records in a VMS file. In *ix files (text files) there's a <LF> at the end of a string of bytes. VMS can support that and, if he were to use that for his files, he'd be able to get the sought after byte size. I don't see why there's such an inability to comprehend it. Variable length file have a 2-byte length count prefixing each record -- akin to having a total file byte count for his purposes. However, that length is figured into the total file byte count and that's NOT appropriate for a protocol that's sending <byte><byte><byte><byte>...<byte><byte><LF>. Selecting a file format that reflects the data will get him his byte count assuming a <byte><byte><byte><byte>...<byte><byte><LF> transfer protocol. Ignoring that will only cause him to acquire the proper and true file size, but it will be an incorrect size for his protocol transfers. I haven't looked at the code for c$stat() on VMS, which can return a file byte count, to see if there's logic inherent in that code to a return file size biased to a *ix stream LF file. I'd wager it's the <end_of_file_block -1>*512+<end_of_file_byte> computation I've been discussing because that'd be just too much to handle if the file was binary. C$stat() shouldn't be making assumptions about the file content. Anyway, this whole thread has gone on all too long. Sometimes, no matter how bright the light, the blind still refuse to see it. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 14:40 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkr6sn$put$1@Iltempo.Update.UU.SE> |
| In reply to | #58889 |
On 2016-06-24 20:27, VAXman-@SendSpamHere.ORG wrote: > In article <nkjrcr$4ra$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes: >> On 2016-06-24 16:54:35 +0000, VAXman- @SendSpamHere.ORG said: >> >>> In article <yE7BjmIxxkSS@eisner.encompasserve.org>, >>> koehler@eisner.nospam.decuserve.org (Bob Koehler) writes: >>>> In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist >>>> <bqt@softjar.se> writes: >>>>> >>>>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >>>>> no blocks, nothing is sent in any multiple of blocks. (And besides, >>>>> text files in Unix do not have CF and LF in them. They just have LF. >>>>> Which is why I was complaining about Unix ftp implementations, which >>>>> often lies about file size, and sometimes cheat when transferring in >>>>> text mode. These protocols were not designed by Unix people...) >>>> >>>> So hwo does UNIX solve it? By lieing about it? Does that work anyhow? >>>> If so, then why can't VMS lie about it? Or do both UNIX and VMS have >>>> to read the file twice to get it right? >>> >>> Maybe you'll get an answer but I'd suggest you don't hold your breath. >> >> Unix returns the file size in bytes. >> >> As for TCP presenting a stream and not datagrams, more than a few >> neophyte developers have been derailed by that detail. There's no >> one-to-one mapping of write I/O size to read I/O size with TCP. One >> TCP write can produce one read, or potentially as many single byte read >> I/O requests as bytes were written. >> >> For file transfers, the app developer chooses how much data to toss >> over the connection. That might be records from a file or records >> synthesized by the network server for a network protocol, or whatever >> hunk of data the developer thought was appropriate. Particularly with >> 64-bit addressing and a flat address space, it wouldn't surprise me to >> see a few just read and write the whole file. >> >> For those on systems that don't have to use socket I/O, they'll call >> the file transfer framework or whatever the local analog; libssh >> underneath ssh has a callable interface. Though AFAICT, there's no >> libssh available with the HPE ssh bits. There is a libcurl port around >> for OpenVMS. OpenVMS itself never sprouted a local callable copy akin >> to macOS and copyfile(3) — beyond callable convert which can usually >> get you there, and probably callable backup, or probably the FTSV/FTSO >> spool layered product bits for those that have access to that — though >> there was some work on providing that. >> >> Having a simple call that gets you the user file size would be handy, >> at least for stream files and analogous. Getting the user data size >> of a NoSQL, or metadata-enriched RMS file formats, or a relational >> database file, is rather less useful, so that'd best be the size of the >> whole wad that needs to be transferred. Whether that's blocks or not >> matters little. >> >> But then this whole block size stuff will get even more interesting >> if/when VSI adds support for native access to the two and four kibibyte >> sector sizes that are now available. EFI sees those differences as do >> a few other giblets, but most users haven't had to deal with that yet. > > You don't need to explain that to me. > > I've been trying to get Johnny to realize that there are numerous ways to > represent records in a VMS file. And you don't have to explain that to me. I know way more of the internals of these things than I should have to. While not specifically RMS-32, I've modified RMS-11, ODS-1 and FCS enough to last me a lifetime, and it's really no different than RMS-32. And just because there are numerous ways to store a file do not mean that I should support only one of them. > In *ix files (text files) there's a <LF> > at the end of a string of bytes. VMS can support that and, if he were to > use that for his files, he'd be able to get the sought after byte size. I > don't see why there's such an inability to comprehend it. What I can't comprehend is your inability to understand the problem, or that having one more piece of metadata actually could help for a rather common case. We've been running this thread way longer than I ever though was needed. Who cares that VMS can store files in a compatible way with Unix. That is not the answer. You still have various files, in various formats on VMS. How it looks under Unix have no bearing. > Variable length > file have a 2-byte length count prefixing each record -- akin to having a > total file byte count for his purposes. However, that length is figured > into the total file byte count and that's NOT appropriate for a protocol > that's sending <byte><byte><byte><byte>...<byte><byte><LF>. Selecting a > file format that reflects the data will get him his byte count assuming a > <byte><byte><byte><byte>...<byte><byte><LF> transfer protocol. Ignoring > that will only cause him to acquire the proper and true file size, but it > will be an incorrect size for his protocol transfers. You are making the assumption that the files will be created specifically for the need and purpose, which is a broken assumption. A web server is expected to serve content that already exist. And if that is created by a text editor (not uncommon), it will normally be in the standard format for a text file, which on VMS would be variable sized sequential records with implied CRLF. This is the most common type of files you will be serving. Going on rambling about how it will be easy to figure out the length of a stream-LF file could be more irrelevant. However, I'm glad you at least acknowledge that getting the plain content size of a sequential record file in VMS is not possible without actually reading through the file. Because this is the problem, and this is what you need to do today. > I haven't looked at the code for c$stat() on VMS, which can return a file > byte count, to see if there's logic inherent in that code to a return file > size biased to a *ix stream LF file. I'd wager it's the <end_of_file_block > -1>*512+<end_of_file_byte> computation I've been discussing because that'd > be just too much to handle if the file was binary. C$stat() shouldn't be > making assumptions about the file content. > > Anyway, this whole thread has gone on all too long. Sometimes, no matter > how bright the light, the blind still refuse to see it. Couldn't agree more. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-27 13:33 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B3DF.61631EB0@SendSpamHere.ORG> |
| In reply to | #58976 |
In article <nkr6sn$put$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-24 20:27, VAXman-@SendSpamHere.ORG wrote: >> In article <nkjrcr$4ra$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes: >>> On 2016-06-24 16:54:35 +0000, VAXman- @SendSpamHere.ORG said: >>> >>>> In article <yE7BjmIxxkSS@eisner.encompasserve.org>, >>>> koehler@eisner.nospam.decuserve.org (Bob Koehler) writes: >>>>> In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist >>>>> <bqt@softjar.se> writes: >>>>>> >>>>>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >>>>>> no blocks, nothing is sent in any multiple of blocks. (And besides, >>>>>> text files in Unix do not have CF and LF in them. They just have LF. >>>>>> Which is why I was complaining about Unix ftp implementations, which >>>>>> often lies about file size, and sometimes cheat when transferring in >>>>>> text mode. These protocols were not designed by Unix people...) >>>>> >>>>> So hwo does UNIX solve it? By lieing about it? Does that work anyhow? >>>>> If so, then why can't VMS lie about it? Or do both UNIX and VMS have >>>>> to read the file twice to get it right? >>>> >>>> Maybe you'll get an answer but I'd suggest you don't hold your breath. >>> >>> Unix returns the file size in bytes. >>> >>> As for TCP presenting a stream and not datagrams, more than a few >>> neophyte developers have been derailed by that detail. There's no >>> one-to-one mapping of write I/O size to read I/O size with TCP. One >>> TCP write can produce one read, or potentially as many single byte read >>> I/O requests as bytes were written. >>> >>> For file transfers, the app developer chooses how much data to toss >>> over the connection. That might be records from a file or records >>> synthesized by the network server for a network protocol, or whatever >>> hunk of data the developer thought was appropriate. Particularly with >>> 64-bit addressing and a flat address space, it wouldn't surprise me to >>> see a few just read and write the whole file. >>> >>> For those on systems that don't have to use socket I/O, they'll call >>> the file transfer framework or whatever the local analog; libssh >>> underneath ssh has a callable interface. Though AFAICT, there's no >>> libssh available with the HPE ssh bits. There is a libcurl port around >>> for OpenVMS. OpenVMS itself never sprouted a local callable copy akin >>> to macOS and copyfile(3) — beyond callable convert which can usually >>> get you there, and probably callable backup, or probably the FTSV/FTSO >>> spool layered product bits for those that have access to that — though >>> there was some work on providing that. >>> >>> Having a simple call that gets you the user file size would be handy, >>> at least for stream files and analogous. Getting the user data size >>> of a NoSQL, or metadata-enriched RMS file formats, or a relational >>> database file, is rather less useful, so that'd best be the size of the >>> whole wad that needs to be transferred. Whether that's blocks or not >>> matters little. >>> >>> But then this whole block size stuff will get even more interesting >>> if/when VSI adds support for native access to the two and four kibibyte >>> sector sizes that are now available. EFI sees those differences as do >>> a few other giblets, but most users haven't had to deal with that yet. >> >> You don't need to explain that to me. >> >> I've been trying to get Johnny to realize that there are numerous ways to >> represent records in a VMS file. > >And you don't have to explain that to me. I know way more of the >internals of these things than I should have to. While not specifically >RMS-32, I've modified RMS-11, ODS-1 and FCS enough to last me a >lifetime, and it's really no different than RMS-32. ... and I know way more of the RMS internals that two lifetimes -- so what? >And just because there are numerous ways to store a file do not mean >that I should support only one of them. > >> In *ix files (text files) there's a <LF> >> at the end of a string of bytes. VMS can support that and, if he were to >> use that for his files, he'd be able to get the sought after byte size. I >> don't see why there's such an inability to comprehend it. > >What I can't comprehend is your inability to understand the problem, or >that having one more piece of metadata actually could help for a rather >common case. We've been running this thread way longer than I ever >though was needed. > >Who cares that VMS can store files in a compatible way with Unix. That >is not the answer. You still have various files, in various formats on >VMS. How it looks under Unix have no bearing. But it does because that's the size of the data you want to present to it! >> Variable length >> file have a 2-byte length count prefixing each record -- akin to having a >> total file byte count for his purposes. However, that length is figured >> into the total file byte count and that's NOT appropriate for a protocol >> that's sending <byte><byte><byte><byte>...<byte><byte><LF>. Selecting a >> file format that reflects the data will get him his byte count assuming a >> <byte><byte><byte><byte>...<byte><byte><LF> transfer protocol. Ignoring >> that will only cause him to acquire the proper and true file size, but it >> will be an incorrect size for his protocol transfers. > >You are making the assumption that the files will be created >specifically for the need and purpose, which is a broken assumption. A >web server is expected to serve content that already exist. And if that >is created by a text editor (not uncommon), it will normally be in the >standard format for a text file, which on VMS would be variable sized >sequential records with implied CRLF. EDT and TPU will edit that file just fine if it's RFM=STM or RFM=STMLF. ;) So, you have a file that was created with a VMS editor. Let's, for argument here, say that's VFC. You want to send that file in HTTP with a byte count that properly accounts for <record's data>+<LF> for each record; yet, you do NOT know how each record has been stored. That's impossible! If you can do that, please let me know how as I might like to apply that logic to winning the Powerball. Short of reading the file, in the case of a VFC, to know the size of EACH record, there's no way to accurately define the file size in a format that you expect for it to be transferred. You can't be that obtuse! >This is the most common type of files you will be serving. Going on >rambling about how it will be easy to figure out the length of a >stream-LF file could be more irrelevant. > >However, I'm glad you at least acknowledge that getting the plain >content size of a sequential record file in VMS is not possible without >actually reading through the file. Because this is the problem, and this >is what you need to do today. I *never* acknowledged that! The file's content size is available without having to read through the file; however, there are several record formats available to save that file; thus, the size will be different. Now, if YOU believe that a record is <byte><byte><byte>...<byte><byte><LF>, I might NOT and their record formats affirm that. What you want is the byte count size that's based upon what or how you will normalize the data in its transfer. That would be misleading to those of us looking at that the file as it's stored on the media. There is VMS CONVERT which can modify the record format; each target format can add or subtract to and from the size of the input. Which is correct? You haven't YET said which one. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 16:14 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkrcbu$9bt$1@Iltempo.Update.UU.SE> |
| In reply to | #58986 |
On 2016-06-27 15:33, VAXman-@SendSpamHere.ORG wrote: > In article <nkr6sn$put$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-24 20:27, VAXman-@SendSpamHere.ORG wrote: >>> I've been trying to get Johnny to realize that there are numerous ways to >>> represent records in a VMS file. >> >> And you don't have to explain that to me. I know way more of the >> internals of these things than I should have to. While not specifically >> RMS-32, I've modified RMS-11, ODS-1 and FCS enough to last me a >> lifetime, and it's really no different than RMS-32. > > ... and I know way more of the RMS internals that two lifetimes -- so what? Right. So let's stop this pissing game. Just as I know that you know these things, stop trying to assume that I don't. >>> In *ix files (text files) there's a <LF> >>> at the end of a string of bytes. VMS can support that and, if he were to >>> use that for his files, he'd be able to get the sought after byte size. I >>> don't see why there's such an inability to comprehend it. >> >> What I can't comprehend is your inability to understand the problem, or >> that having one more piece of metadata actually could help for a rather >> common case. We've been running this thread way longer than I ever >> though was needed. >> >> Who cares that VMS can store files in a compatible way with Unix. That >> is not the answer. You still have various files, in various formats on >> VMS. How it looks under Unix have no bearing. > > But it does because that's the size of the data you want to present to it! What is "it" here? I've been pointing out in a number of posts now that sometimes having the file size in bytes is useful. And the examples I've used have been some internet protocols. So all that's been in my argument is: VMS, all kind of files. And internet protocols, as specified by some RFCs. No Unix within sight. >> You are making the assumption that the files will be created >> specifically for the need and purpose, which is a broken assumption. A >> web server is expected to serve content that already exist. And if that >> is created by a text editor (not uncommon), it will normally be in the >> standard format for a text file, which on VMS would be variable sized >> sequential records with implied CRLF. > > EDT and TPU will edit that file just fine if it's RFM=STM or RFM=STMLF. ;) Just because it can does not mean that all your files will be. > So, you have a file that was created with a VMS editor. Let's, for argument > here, say that's VFC. You want to send that file in HTTP with a byte count > that properly accounts for <record's data>+<LF> for each record; yet, you do > NOT know how each record has been stored. That's impossible! If you can do > that, please let me know how as I might like to apply that logic to winning > the Powerball. Short of reading the file, in the case of a VFC, to know the > size of EACH record, there's no way to accurately define the file size in a > format that you expect for it to be transferred. You can't be that obtuse! Nitpick: The correct format is <record's data>+CR+LF. And... uh... If the file is in VFC, then you have the information on how each record is stored. Which part is it that you miss here? We know the storage format on disk. We would like to know the number of bytes this would be represented as, talking about just the file content, without any metadata. If we were to imagine how a system would implement this, the obvious answer is that as each record is written, the byte size added to the file would be the length of the record, plus two bytes for the implied CR+LF. This is not rocket science. And if you have a file with variable length records without the implied CR+LF, then the size added would become just the length of each record written. The actual space needed on disk is obviously different than this number, for a bunch of reasons and cases. But that's irrelevant. If you were to read the file, these are the number of bytes you would get (assuming you add your CR+LFs as assumed, at the end of each record, if the file attributes said so). >> This is the most common type of files you will be serving. Going on >> rambling about how it will be easy to figure out the length of a >> stream-LF file could be more irrelevant. >> >> However, I'm glad you at least acknowledge that getting the plain >> content size of a sequential record file in VMS is not possible without >> actually reading through the file. Because this is the problem, and this >> is what you need to do today. > > I *never* acknowledged that! The file's content size is available without > having to read through the file; however, there are several record formats > available to save that file; thus, the size will be different. Now, if YOU > believe that a record is <byte><byte><byte>...<byte><byte><LF>, I might NOT > and their record formats affirm that. Sigh. So now you are again claiming that the size of the user data of a sequential record file in VMS, with implied CRLF attributes can be calculated somehow? Please tell me how you do that. > What you want is the byte count size that's based upon what or how you will > normalize the data in its transfer. That would be misleading to those of us > looking at that the file as it's stored on the media. There is VMS CONVERT > which can modify the record format; each target format can add or subtract > to and from the size of the input. Which is correct? You haven't YET said > which one. Please read this reply twice before answering. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 16:50 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkrefd$ems$1@Iltempo.Update.UU.SE> |
| In reply to | #58991 |
On 2016-06-27 16:14, Johnny Billquist wrote: > On 2016-06-27 15:33, VAXman-@SendSpamHere.ORG wrote: >> In article <nkr6sn$put$1@Iltempo.Update.UU.SE>, Johnny Billquist >> <bqt@softjar.se> writes: >>> On 2016-06-24 20:27, VAXman-@SendSpamHere.ORG wrote: >>>> I've been trying to get Johnny to realize that there are numerous >>>> ways to >>>> represent records in a VMS file. >>> >>> And you don't have to explain that to me. I know way more of the >>> internals of these things than I should have to. While not specifically >>> RMS-32, I've modified RMS-11, ODS-1 and FCS enough to last me a >>> lifetime, and it's really no different than RMS-32. >> >> ... and I know way more of the RMS internals that two lifetimes -- so >> what? > > Right. So let's stop this pissing game. > Just as I know that you know these things, stop trying to assume that I > don't. > >>>> In *ix files (text files) there's a <LF> >>>> at the end of a string of bytes. VMS can support that and, if he >>>> were to >>>> use that for his files, he'd be able to get the sought after byte >>>> size. I >>>> don't see why there's such an inability to comprehend it. >>> >>> What I can't comprehend is your inability to understand the problem, or >>> that having one more piece of metadata actually could help for a rather >>> common case. We've been running this thread way longer than I ever >>> though was needed. >>> >>> Who cares that VMS can store files in a compatible way with Unix. That >>> is not the answer. You still have various files, in various formats on >>> VMS. How it looks under Unix have no bearing. >> >> But it does because that's the size of the data you want to present to >> it! > > What is "it" here? I've been pointing out in a number of posts now that > sometimes having the file size in bytes is useful. And the examples I've > used have been some internet protocols. > > So all that's been in my argument is: VMS, all kind of files. And > internet protocols, as specified by some RFCs. No Unix within sight. > >>> You are making the assumption that the files will be created >>> specifically for the need and purpose, which is a broken assumption. A >>> web server is expected to serve content that already exist. And if that >>> is created by a text editor (not uncommon), it will normally be in the >>> standard format for a text file, which on VMS would be variable sized >>> sequential records with implied CRLF. >> >> EDT and TPU will edit that file just fine if it's RFM=STM or >> RFM=STMLF. ;) > > Just because it can does not mean that all your files will be. > >> So, you have a file that was created with a VMS editor. Let's, for >> argument >> here, say that's VFC. You want to send that file in HTTP with a byte >> count >> that properly accounts for <record's data>+<LF> for each record; yet, >> you do >> NOT know how each record has been stored. That's impossible! If you >> can do >> that, please let me know how as I might like to apply that logic to >> winning >> the Powerball. Short of reading the file, in the case of a VFC, to >> know the >> size of EACH record, there's no way to accurately define the file size >> in a >> format that you expect for it to be transferred. You can't be that >> obtuse! > > Nitpick: The correct format is <record's data>+CR+LF. > > And... uh... If the file is in VFC, then you have the information on how > each record is stored. Which part is it that you miss here? We know the > storage format on disk. We would like to know the number of bytes this > would be represented as, talking about just the file content, without > any metadata. > > If we were to imagine how a system would implement this, the obvious > answer is that as each record is written, the byte size added to the > file would be the length of the record, plus two bytes for the implied > CR+LF. > This is not rocket science. > > And if you have a file with variable length records without the implied > CR+LF, then the size added would become just the length of each record > written. The actual space needed on disk is obviously different than > this number, for a bunch of reasons and cases. But that's irrelevant. If > you were to read the file, these are the number of bytes you would get > (assuming you add your CR+LFs as assumed, at the end of each record, if > the file attributes said so). An alternative solution, which I think would actually be even more useful, would be to keep track of just the number of bytes actually written. So the implied CRLF per record would be ignored. However, in addition to counting the bytes in each $PUT, you also have a counter for the number of records in the file. If someone then wants the size, assuming you add a CRLF for each record (if say, you have implied CRLF as an attribute on the file), then you take the number of actual bytes written, and you add 2*<number of records> to this. Easy, more generic, and if someone would like to know the number of records for some other use, then that information would also be available. Pretty cheap, and giving you more things you can do based on the metadata. Now, would this really be that bad? Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-27 20:02 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B415.B860E31F@SendSpamHere.ORG> |
| In reply to | #58995 |
In article <nkrefd$ems$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-27 16:14, Johnny Billquist wrote: >> On 2016-06-27 15:33, VAXman-@SendSpamHere.ORG wrote: >>> In article <nkr6sn$put$1@Iltempo.Update.UU.SE>, Johnny Billquist >>> <bqt@softjar.se> writes: >>>> On 2016-06-24 20:27, VAXman-@SendSpamHere.ORG wrote: >>>>> I've been trying to get Johnny to realize that there are numerous >>>>> ways to >>>>> represent records in a VMS file. >>>> >>>> And you don't have to explain that to me. I know way more of the >>>> internals of these things than I should have to. While not specifically >>>> RMS-32, I've modified RMS-11, ODS-1 and FCS enough to last me a >>>> lifetime, and it's really no different than RMS-32. >>> >>> ... and I know way more of the RMS internals that two lifetimes -- so >>> what? >> >> Right. So let's stop this pissing game. >> Just as I know that you know these things, stop trying to assume that I >> don't. >> >>>>> In *ix files (text files) there's a <LF> >>>>> at the end of a string of bytes. VMS can support that and, if he >>>>> were to >>>>> use that for his files, he'd be able to get the sought after byte >>>>> size. I >>>>> don't see why there's such an inability to comprehend it. >>>> >>>> What I can't comprehend is your inability to understand the problem, or >>>> that having one more piece of metadata actually could help for a rather >>>> common case. We've been running this thread way longer than I ever >>>> though was needed. >>>> >>>> Who cares that VMS can store files in a compatible way with Unix. That >>>> is not the answer. You still have various files, in various formats on >>>> VMS. How it looks under Unix have no bearing. >>> >>> But it does because that's the size of the data you want to present to >>> it! >> >> What is "it" here? I've been pointing out in a number of posts now that >> sometimes having the file size in bytes is useful. And the examples I've >> used have been some internet protocols. >> >> So all that's been in my argument is: VMS, all kind of files. And >> internet protocols, as specified by some RFCs. No Unix within sight. >> >>>> You are making the assumption that the files will be created >>>> specifically for the need and purpose, which is a broken assumption. A >>>> web server is expected to serve content that already exist. And if that >>>> is created by a text editor (not uncommon), it will normally be in the >>>> standard format for a text file, which on VMS would be variable sized >>>> sequential records with implied CRLF. >>> >>> EDT and TPU will edit that file just fine if it's RFM=STM or >>> RFM=STMLF. ;) >> >> Just because it can does not mean that all your files will be. >> >>> So, you have a file that was created with a VMS editor. Let's, for >>> argument >>> here, say that's VFC. You want to send that file in HTTP with a byte >>> count >>> that properly accounts for <record's data>+<LF> for each record; yet, >>> you do >>> NOT know how each record has been stored. That's impossible! If you >>> can do >>> that, please let me know how as I might like to apply that logic to >>> winning >>> the Powerball. Short of reading the file, in the case of a VFC, to >>> know the >>> size of EACH record, there's no way to accurately define the file size >>> in a >>> format that you expect for it to be transferred. You can't be that >>> obtuse! >> >> Nitpick: The correct format is <record's data>+CR+LF. >> >> And... uh... If the file is in VFC, then you have the information on how >> each record is stored. Which part is it that you miss here? We know the >> storage format on disk. We would like to know the number of bytes this >> would be represented as, talking about just the file content, without >> any metadata. >> >> If we were to imagine how a system would implement this, the obvious >> answer is that as each record is written, the byte size added to the >> file would be the length of the record, plus two bytes for the implied >> CR+LF. >> This is not rocket science. >> >> And if you have a file with variable length records without the implied >> CR+LF, then the size added would become just the length of each record >> written. The actual space needed on disk is obviously different than >> this number, for a bunch of reasons and cases. But that's irrelevant. If >> you were to read the file, these are the number of bytes you would get >> (assuming you add your CR+LFs as assumed, at the end of each record, if >> the file attributes said so). > >An alternative solution, which I think would actually be even more >useful, would be to keep track of just the number of bytes actually >written. So the implied CRLF per record would be ignored. >However, in addition to counting the bytes in each $PUT, you also have a >counter for the number of records in the file. >If someone then wants the size, assuming you add a CRLF for each record >(if say, you have implied CRLF as an attribute on the file), then you >take the number of actual bytes written, and you add 2*<number of >records> to this. >Easy, more generic, and if someone would like to know the number of >records for some other use, then that information would also be available. >Pretty cheap, and giving you more things you can do based on the metadata. > >Now, would this really be that bad? That *would* give you a more accurate figure for *your* purposes. Of course, you may also have to include $DELETE and $UPDATE (depending upon organization of the file(s)) to be accurate. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 22:35 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nks2n5$3gn$2@Iltempo.Update.UU.SE> |
| In reply to | #59016 |
On 2016-06-27 22:02, VAXman-@SendSpamHere.ORG wrote: > In article <nkrefd$ems$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> An alternative solution, which I think would actually be even more >> useful, would be to keep track of just the number of bytes actually >> written. So the implied CRLF per record would be ignored. >> However, in addition to counting the bytes in each $PUT, you also have a >> counter for the number of records in the file. >> If someone then wants the size, assuming you add a CRLF for each record >> (if say, you have implied CRLF as an attribute on the file), then you >> take the number of actual bytes written, and you add 2*<number of >> records> to this. >> Easy, more generic, and if someone would like to know the number of >> records for some other use, then that information would also be available. >> Pretty cheap, and giving you more things you can do based on the metadata. >> >> Now, would this really be that bad? > > That *would* give you a more accurate figure for *your* purposes. Of course, > you may also have to include $DELETE and $UPDATE (depending upon organization > of the file(s)) to be accurate. Certainly. I could also argue that anyone else who actually is asking for the file size in bytes are probably asking for this same information. But if that is incorrect I'm very interested in hearing what they actually are looking for. As we stated elsewhere, this is only really meaningful for sequential files, so $DELETE and $UPDATE is not really relevant. But I could try and work out if such a number could be used in a meaningful way on such files as well. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 14:26 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkr62a$neg$1@Iltempo.Update.UU.SE> |
| In reply to | #58887 |
On 2016-06-24 18:54, VAXman-@SendSpamHere.ORG wrote: > In article <yE7BjmIxxkSS@eisner.encompasserve.org>, koehler@eisner.nospam.decuserve.org (Bob Koehler) writes: >> In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> >>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >>> no blocks, nothing is sent in any multiple of blocks. >>> (And besides, text files in Unix do not have CF and LF in them. They >>> just have LF. Which is why I was complaining about Unix ftp >>> implementations, which often lies about file size, and sometimes cheat >>> when transferring in text mode. These protocols were not designed by >>> Unix people...) >> >> So hwo does UNIX solve it? By lieing about it? Does that work >> anyhow? If so, then why can't VMS lie about it? Or do both UNIX >> and VMS have to read the file twice to get it right? > > Maybe you'll get an answer but I'd suggest you don't hold your breath. Yeah, since I only read this today, holding the breath would have turned him blue... But an answer was given. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 14:15 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkr5cb$lui$1@Iltempo.Update.UU.SE> |
| In reply to | #58886 |
On 2016-06-24 14:52, Bob Koehler wrote: > In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> >> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >> no blocks, nothing is sent in any multiple of blocks. >> (And besides, text files in Unix do not have CF and LF in them. They >> just have LF. Which is why I was complaining about Unix ftp >> implementations, which often lies about file size, and sometimes cheat >> when transferring in text mode. These protocols were not designed by >> Unix people...) > > So hwo does UNIX solve it? By lieing about it? Does that work > anyhow? If so, then why can't VMS lie about it? Or do both UNIX > and VMS have to read the file twice to get it right? With HTTP Unix just stat() the file, and return the size as reported, and everything is correct. Some ftp implementations lie, in that they do a stat() and return that size, and at transfer they still send more data than the size reported, if in text mode. Which is not a problem between Unix systems, since they never use text mode normally. Unix to Unix normally is done in binary all the time, for which the size is correct. So it becomes a potential issue if transferring between Unix and non-Unix systems, at which point text transfer might work wrong. However, with ftp, size information is not mandatory in the first place, and is normally not used for the actual transfer, so you can often get away with lying about the size, but it does break the standard. (ftp also usually always close the connection on transfer end, so size is not used to see if the full file is transferred. A side effect from the fact than ftp use a separate channel for data transfer compared to commands. http uses the same channel for both, which makes it so much more sensitive.) But in reality, if Unix has to transfer a file in text mode using internet standards, and needs to report size, you'll have to read the file twice on Unix as well. But only for text transfers. Johnny
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-27 09:35 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <hUeVLoh3krUw@eisner.encompasserve.org> |
| In reply to | #58974 |
In article <nkr5cb$lui$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: > On 2016-06-24 14:52, Bob Koehler wrote: >> In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> >>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >>> no blocks, nothing is sent in any multiple of blocks. >>> (And besides, text files in Unix do not have CF and LF in them. They >>> just have LF. Which is why I was complaining about Unix ftp >>> implementations, which often lies about file size, and sometimes cheat >>> when transferring in text mode. These protocols were not designed by >>> Unix people...) >> >> So hwo does UNIX solve it? By lieing about it? Does that work >> anyhow? If so, then why can't VMS lie about it? Or do both UNIX >> and VMS have to read the file twice to get it right? > > With HTTP Unix just stat() the file, and return the size as reported, > and everything is correct. Not if the protocol is depending on CRLF.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 16:15 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkrceu$9bt$2@Iltempo.Update.UU.SE> |
| In reply to | #58987 |
On 2016-06-27 15:35, Bob Koehler wrote: > In article <nkr5cb$lui$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-24 14:52, Bob Koehler wrote: >>> In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> >>>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >>>> no blocks, nothing is sent in any multiple of blocks. >>>> (And besides, text files in Unix do not have CF and LF in them. They >>>> just have LF. Which is why I was complaining about Unix ftp >>>> implementations, which often lies about file size, and sometimes cheat >>>> when transferring in text mode. These protocols were not designed by >>>> Unix people...) >>> >>> So hwo does UNIX solve it? By lieing about it? Does that work >>> anyhow? If so, then why can't VMS lie about it? Or do both UNIX >>> and VMS have to read the file twice to get it right? >> >> With HTTP Unix just stat() the file, and return the size as reported, >> and everything is correct. > > Not if the protocol is depending on CRLF. Well, I suspect you mean if Unix have a file in the native text format, and is expected to serve it as a text with CRLF line endings. In that case yeah, then stat() will not suffice. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-27 15:23 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B3EE.D6623DC2@SendSpamHere.ORG> |
| In reply to | #58992 |
In article <nkrceu$9bt$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-27 15:35, Bob Koehler wrote: >> In article <nkr5cb$lui$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-24 14:52, Bob Koehler wrote: >>>> In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>> >>>>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >>>>> no blocks, nothing is sent in any multiple of blocks. >>>>> (And besides, text files in Unix do not have CF and LF in them. They >>>>> just have LF. Which is why I was complaining about Unix ftp >>>>> implementations, which often lies about file size, and sometimes cheat >>>>> when transferring in text mode. These protocols were not designed by >>>>> Unix people...) >>>> >>>> So hwo does UNIX solve it? By lieing about it? Does that work >>>> anyhow? If so, then why can't VMS lie about it? Or do both UNIX >>>> and VMS have to read the file twice to get it right? >>> >>> With HTTP Unix just stat() the file, and return the size as reported, >>> and everything is correct. >> >> Not if the protocol is depending on CRLF. > >Well, I suspect you mean if Unix have a file in the native text format, >and is expected to serve it as a text with CRLF line endings. In that >case yeah, then stat() will not suffice. What do you do in that case? And, one could argue that the <LF> is akin the VMS record's metadata. Now, if you're adding the <CR><LF> (2 bytes) you might have your file size if the file is VMS variable length. ;) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 17:42 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkrhga$lkq$2@Iltempo.Update.UU.SE> |
| In reply to | #59002 |
On 2016-06-27 17:23, VAXman-@SendSpamHere.ORG wrote: > In article <nkrceu$9bt$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-27 15:35, Bob Koehler wrote: >>> In article <nkr5cb$lui$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-24 14:52, Bob Koehler wrote: >>>>> In article <nkhf9i$7s3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>> >>>>>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are >>>>>> no blocks, nothing is sent in any multiple of blocks. >>>>>> (And besides, text files in Unix do not have CF and LF in them. They >>>>>> just have LF. Which is why I was complaining about Unix ftp >>>>>> implementations, which often lies about file size, and sometimes cheat >>>>>> when transferring in text mode. These protocols were not designed by >>>>>> Unix people...) >>>>> >>>>> So hwo does UNIX solve it? By lieing about it? Does that work >>>>> anyhow? If so, then why can't VMS lie about it? Or do both UNIX >>>>> and VMS have to read the file twice to get it right? >>>> >>>> With HTTP Unix just stat() the file, and return the size as reported, >>>> and everything is correct. >>> >>> Not if the protocol is depending on CRLF. >> >> Well, I suspect you mean if Unix have a file in the native text format, >> and is expected to serve it as a text with CRLF line endings. In that >> case yeah, then stat() will not suffice. > > What do you do in that case? And, one could argue that the <LF> is akin > the VMS record's metadata. Now, if you're adding the <CR><LF> (2 bytes) > you might have your file size if the file is VMS variable length. ;) In a Unix system? You will have to read the file to figure out what the size is. There is no other way. Not that you often hit that situation, as most larger files transferred will not be in a native Unix text format, and be required to be translated into the network standard text format (which is not the same as the Unix format). How much do you really want to go into how and what Unix does, and how network protocols work here? Isn't this rather irrelevant to the question of getting a file size in bytes in VMS? Johnny
[toc] | [prev] | [next] | [standalone]
Page 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
Back to top | Article view | comp.os.vms
csiph-web