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 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-26 19:33 -0700 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <3bc47c02-3f19-436f-b806-86f53b85d66e@googlegroups.com> |
| In reply to | #58864 |
On Friday, June 24, 2016 at 7:16:38 AM UTC+12, Johnny Billquist wrote: > For a web server, you *have* to give the size before you start sending > data. Doing it in segments then obviously is not the answer. Yes, you can do it in segments. It’s called “chunked” transfer coding <https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1>.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 16:01 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkrbje$7k8$1@Iltempo.Update.UU.SE> |
| In reply to | #58960 |
On 2016-06-27 04:33, lawrencedo99@gmail.com wrote: > On Friday, June 24, 2016 at 7:16:38 AM UTC+12, Johnny Billquist wrote: >> For a web server, you *have* to give the size before you start sending >> data. Doing it in segments then obviously is not the answer. > > Yes, you can do it in segments. It’s called “chunked” transfer coding <https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1>. I *knew* someone was going to bring this up sooner or later. I tried being careful with my wording, but got tired. :-) Yes, you can use chunked encoding. It will cause your web browser to not present you with a progress bar, and you will not be able to preallocate the file, but yes, it do work. I started with that when I wrote my http server, since that is a mandatory part of HTTP/1.1, but I then realized that, especially for large files, having a progress bar is actually pretty damn useful, so I "had" to implement the file size headers as well. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-23 19:23 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B0EB.B9A9DE66@SendSpamHere.ORG> |
| In reply to | #58860 |
In article <nkhcik$1o0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-23 20:46, David Froble wrote: >> Johnny Billquist wrote: >>> 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. >>> >>> Johnny >>> >> >> Why would you read through it twice? With a few exceptions, read it >> into memory, then transmit it. Something you got to do anyway. Perhaps >> just re-ordering the task. >> >> Too big? Got to ask, what's wrong with doing things in segments? Maybe >> not how the *ix world does things. Who's to say they are always right? > >I think you missed the point. For a web server, you *have* to give the >size before you start sending data. Doing it in segments then obviously >is not the answer. Nor is reordering of anything. Size comes first, data >comes after. Do I have to repeat it again? > >And blaming Unix isn't useful/meaningful either. The protocol is that >way. Deal with it. >And yes, it can be too big to just gob into memory, not to mention that >gobbing many megs of memory for this is a pretty poor design. OK. So your web server sits on VMS. If the file is NOT RFM=STM, call the callable CONV$ert routine and convert it to RFM=STM. There, done once and then no more! Now, you can have your precious byte-counted file size from <end_of_file_block-1>*512 + <end_of_file_byte>. Both values easily gotten and the math is simple enough that even Bernie *should* be able do 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-23 21:29 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkhdao$2us$3@Iltempo.Update.UU.SE> |
| In reply to | #58867 |
On 2016-06-23 21:23, VAXman-@SendSpamHere.ORG wrote: > In article <nkhcik$1o0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-23 20:46, David Froble wrote: >>> Johnny Billquist wrote: >>>> 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. >>>> >>>> Johnny >>>> >>> >>> Why would you read through it twice? With a few exceptions, read it >>> into memory, then transmit it. Something you got to do anyway. Perhaps >>> just re-ordering the task. >>> >>> Too big? Got to ask, what's wrong with doing things in segments? Maybe >>> not how the *ix world does things. Who's to say they are always right? >> >> I think you missed the point. For a web server, you *have* to give the >> size before you start sending data. Doing it in segments then obviously >> is not the answer. Nor is reordering of anything. Size comes first, data >> comes after. Do I have to repeat it again? >> >> And blaming Unix isn't useful/meaningful either. The protocol is that >> way. Deal with it. >> And yes, it can be too big to just gob into memory, not to mention that >> gobbing many megs of memory for this is a pretty poor design. > > OK. So your web server sits on VMS. If the file is NOT RFM=STM, call the > callable CONV$ert routine and convert it to RFM=STM. There, done once and > then no more! Now, you can have your precious byte-counted file size from > <end_of_file_block-1>*512 + <end_of_file_byte>. Both values easily gotten > and the math is simple enough that even Bernie *should* be able do it. Apart from the fact that it's reusable, what you just did was read the file twice, to serve it. And now you are creating alternative files for requested files, and need to keep track which ones you have created an alternative for, and substitute one for the other for those cases. I can see how this can become rather exciting over time... Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-23 19:42 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B0EE.4DBEE09A@SendSpamHere.ORG> |
| In reply to | #58867 |
In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-23 21:23, VAXman-@SendSpamHere.ORG wrote: >> In article <nkhcik$1o0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-23 20:46, David Froble wrote: >>>> Johnny Billquist wrote: >>>>> 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. >>>>> >>>>> Johnny >>>>> >>>> >>>> Why would you read through it twice? With a few exceptions, read it >>>> into memory, then transmit it. Something you got to do anyway. Perhaps >>>> just re-ordering the task. >>>> >>>> Too big? Got to ask, what's wrong with doing things in segments? Maybe >>>> not how the *ix world does things. Who's to say they are always right? >>> >>> I think you missed the point. For a web server, you *have* to give the >>> size before you start sending data. Doing it in segments then obviously >>> is not the answer. Nor is reordering of anything. Size comes first, data >>> comes after. Do I have to repeat it again? >>> >>> And blaming Unix isn't useful/meaningful either. The protocol is that >>> way. Deal with it. >>> And yes, it can be too big to just gob into memory, not to mention that >>> gobbing many megs of memory for this is a pretty poor design. >> >> OK. So your web server sits on VMS. If the file is NOT RFM=STM, call the >> callable CONV$ert routine and convert it to RFM=STM. There, done once and >> then no more! Now, you can have your precious byte-counted file size from >> <end_of_file_block-1>*512 + <end_of_file_byte>. Both values easily gotten >> and the math is simple enough that even Bernie *should* be able do it. > >Apart from the fact that it's reusable, what you just did was read the >file twice, to serve it. OK. But only done once. >And now you are creating alternative files for requested files, and need >to keep track which ones you have created an alternative for, and >substitute one for the other for those cases. I can see how this can >become rather exciting over time... Overwrite the existing. It's text and VMS can read it because it'll see the record format. And, again, if you want a *FILE SIZE* that'll satisfy your TCP/IP and *ixy file systems, you're going to have to send the <CR>s and <LF>s. Now, it's possible that you could use the same <end_of_file_block-1>*512 + <end_of_ file_byte> computation, but you don't have anything that indicates a count of records which you might need to use to add 2*record_count to account for the *synthesized* <CR>s and <LF>s in your stream. -- 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 21:58 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkhf0u$71o$2@Iltempo.Update.UU.SE> |
| In reply to | #58873 |
On 2016-06-23 21:42, VAXman-@SendSpamHere.ORG wrote: > In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-23 21:23, VAXman-@SendSpamHere.ORG wrote: >>> In article <nkhcik$1o0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-23 20:46, David Froble wrote: >>>>> Johnny Billquist wrote: >>>>>> 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. >>>>>> >>>>>> Johnny >>>>>> >>>>> >>>>> Why would you read through it twice? With a few exceptions, read it >>>>> into memory, then transmit it. Something you got to do anyway. Perhaps >>>>> just re-ordering the task. >>>>> >>>>> Too big? Got to ask, what's wrong with doing things in segments? Maybe >>>>> not how the *ix world does things. Who's to say they are always right? >>>> >>>> I think you missed the point. For a web server, you *have* to give the >>>> size before you start sending data. Doing it in segments then obviously >>>> is not the answer. Nor is reordering of anything. Size comes first, data >>>> comes after. Do I have to repeat it again? >>>> >>>> And blaming Unix isn't useful/meaningful either. The protocol is that >>>> way. Deal with it. >>>> And yes, it can be too big to just gob into memory, not to mention that >>>> gobbing many megs of memory for this is a pretty poor design. >>> >>> OK. So your web server sits on VMS. If the file is NOT RFM=STM, call the >>> callable CONV$ert routine and convert it to RFM=STM. There, done once and >>> then no more! Now, you can have your precious byte-counted file size from >>> <end_of_file_block-1>*512 + <end_of_file_byte>. Both values easily gotten >>> and the math is simple enough that even Bernie *should* be able do it. >> >> Apart from the fact that it's reusable, what you just did was read the >> file twice, to serve it. > > OK. But only done once. Assuming you then keep track of this converted file, it does not change, and you have the storage, yes... >> And now you are creating alternative files for requested files, and need >> to keep track which ones you have created an alternative for, and >> substitute one for the other for those cases. I can see how this can >> become rather exciting over time... > > Overwrite the existing. It's text and VMS can read it because it'll see the > record format. Whoa! I don't know about you, but personally I would be extremely pissed if a tool that is supposed to only read my file were to modify it. Even if the contents supposedly should appear to look the same afterwards. But you're even making some pretty horrible assumptions here. Assuming that the file even is a text file to start with, for which conversion to a stream, might be assuming too much. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-23 21:40 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B0FE.C42FF119@SendSpamHere.ORG> |
| In reply to | #58873 |
In article <nkhf0u$71o$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-23 21:42, VAXman-@SendSpamHere.ORG wrote: >> In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-23 21:23, VAXman-@SendSpamHere.ORG wrote: >>>> In article <nkhcik$1o0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>> On 2016-06-23 20:46, David Froble wrote: >>>>>> Johnny Billquist wrote: >>>>>>> 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. >>>>>>> >>>>>>> Johnny >>>>>>> >>>>>> >>>>>> Why would you read through it twice? With a few exceptions, read it >>>>>> into memory, then transmit it. Something you got to do anyway. Perhaps >>>>>> just re-ordering the task. >>>>>> >>>>>> Too big? Got to ask, what's wrong with doing things in segments? Maybe >>>>>> not how the *ix world does things. Who's to say they are always right? >>>>> >>>>> I think you missed the point. For a web server, you *have* to give the >>>>> size before you start sending data. Doing it in segments then obviously >>>>> is not the answer. Nor is reordering of anything. Size comes first, data >>>>> comes after. Do I have to repeat it again? >>>>> >>>>> And blaming Unix isn't useful/meaningful either. The protocol is that >>>>> way. Deal with it. >>>>> And yes, it can be too big to just gob into memory, not to mention that >>>>> gobbing many megs of memory for this is a pretty poor design. >>>> >>>> OK. So your web server sits on VMS. If the file is NOT RFM=STM, call the >>>> callable CONV$ert routine and convert it to RFM=STM. There, done once and >>>> then no more! Now, you can have your precious byte-counted file size from >>>> <end_of_file_block-1>*512 + <end_of_file_byte>. Both values easily gotten >>>> and the math is simple enough that even Bernie *should* be able do it. >>> >>> Apart from the fact that it's reusable, what you just did was read the >>> file twice, to serve it. >> >> OK. But only done once. > >Assuming you then keep track of this converted file, it does not change, >and you have the storage, yes... Why would it change? >>> And now you are creating alternative files for requested files, and need >>> to keep track which ones you have created an alternative for, and >>> substitute one for the other for those cases. I can see how this can >>> become rather exciting over time... >> >> Overwrite the existing. It's text and VMS can read it because it'll see the >> record format. > >Whoa! I don't know about you, but personally I would be extremely pissed >if a tool that is supposed to only read my file were to modify it. Even >if the contents supposedly should appear to look the same afterwards. > >But you're even making some pretty horrible assumptions here. Assuming >that the file even is a text file to start with, for which conversion to >a stream, might be assuming too much. If it's not text, then what does it matter? Binary? -- 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:03 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkrbmt$7k8$2@Iltempo.Update.UU.SE> |
| In reply to | #58879 |
On 2016-06-23 23:40, VAXman-@SendSpamHere.ORG wrote: > In article <nkhf0u$71o$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-23 21:42, VAXman-@SendSpamHere.ORG wrote: >>> In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-23 21:23, VAXman-@SendSpamHere.ORG wrote: >>>>> In article <nkhcik$1o0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>> On 2016-06-23 20:46, David Froble wrote: >>>>>>> Johnny Billquist wrote: >>>>>>>> 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. >>>>>>>> >>>>>>>> Johnny >>>>>>>> >>>>>>> >>>>>>> Why would you read through it twice? With a few exceptions, read it >>>>>>> into memory, then transmit it. Something you got to do anyway. Perhaps >>>>>>> just re-ordering the task. >>>>>>> >>>>>>> Too big? Got to ask, what's wrong with doing things in segments? Maybe >>>>>>> not how the *ix world does things. Who's to say they are always right? >>>>>> >>>>>> I think you missed the point. For a web server, you *have* to give the >>>>>> size before you start sending data. Doing it in segments then obviously >>>>>> is not the answer. Nor is reordering of anything. Size comes first, data >>>>>> comes after. Do I have to repeat it again? >>>>>> >>>>>> And blaming Unix isn't useful/meaningful either. The protocol is that >>>>>> way. Deal with it. >>>>>> And yes, it can be too big to just gob into memory, not to mention that >>>>>> gobbing many megs of memory for this is a pretty poor design. >>>>> >>>>> OK. So your web server sits on VMS. If the file is NOT RFM=STM, call the >>>>> callable CONV$ert routine and convert it to RFM=STM. There, done once and >>>>> then no more! Now, you can have your precious byte-counted file size from >>>>> <end_of_file_block-1>*512 + <end_of_file_byte>. Both values easily gotten >>>>> and the math is simple enough that even Bernie *should* be able do it. >>>> >>>> Apart from the fact that it's reusable, what you just did was read the >>>> file twice, to serve it. >>> >>> OK. But only done once. >> >> Assuming you then keep track of this converted file, it does not change, >> and you have the storage, yes... > > Why would it change? Because nothing is set in stone? People use the system, people change content, people transfer files, people do all kind of strange things... Imagine... >>>> And now you are creating alternative files for requested files, and need >>>> to keep track which ones you have created an alternative for, and >>>> substitute one for the other for those cases. I can see how this can >>>> become rather exciting over time... >>> >>> Overwrite the existing. It's text and VMS can read it because it'll see the >>> record format. >> >> Whoa! I don't know about you, but personally I would be extremely pissed >> if a tool that is supposed to only read my file were to modify it. Even >> if the contents supposedly should appear to look the same afterwards. >> >> But you're even making some pretty horrible assumptions here. Assuming >> that the file even is a text file to start with, for which conversion to >> a stream, might be assuming too much. > > If it's not text, then what does it matter? Binary? So you have a sequential file with variable size records, and no file attributes. How do you find the size? Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-27 15:19 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B3EE.2CDE76C6@SendSpamHere.ORG> |
| In reply to | #58879 |
In article <nkrbmt$7k8$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-23 23:40, VAXman-@SendSpamHere.ORG wrote: >> In article <nkhf0u$71o$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-23 21:42, VAXman-@SendSpamHere.ORG wrote: >>>> In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>> On 2016-06-23 21:23, VAXman-@SendSpamHere.ORG wrote: >>>>>> In article <nkhcik$1o0$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>>> On 2016-06-23 20:46, David Froble wrote: >>>>>>>> Johnny Billquist wrote: >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> Johnny >>>>>>>>> >>>>>>>> >>>>>>>> Why would you read through it twice? With a few exceptions, read it >>>>>>>> into memory, then transmit it. Something you got to do anyway. Perhaps >>>>>>>> just re-ordering the task. >>>>>>>> >>>>>>>> Too big? Got to ask, what's wrong with doing things in segments? Maybe >>>>>>>> not how the *ix world does things. Who's to say they are always right? >>>>>>> >>>>>>> I think you missed the point. For a web server, you *have* to give the >>>>>>> size before you start sending data. Doing it in segments then obviously >>>>>>> is not the answer. Nor is reordering of anything. Size comes first, data >>>>>>> comes after. Do I have to repeat it again? >>>>>>> >>>>>>> And blaming Unix isn't useful/meaningful either. The protocol is that >>>>>>> way. Deal with it. >>>>>>> And yes, it can be too big to just gob into memory, not to mention that >>>>>>> gobbing many megs of memory for this is a pretty poor design. >>>>>> >>>>>> OK. So your web server sits on VMS. If the file is NOT RFM=STM, call the >>>>>> callable CONV$ert routine and convert it to RFM=STM. There, done once and >>>>>> then no more! Now, you can have your precious byte-counted file size from >>>>>> <end_of_file_block-1>*512 + <end_of_file_byte>. Both values easily gotten >>>>>> and the math is simple enough that even Bernie *should* be able do it. >>>>> >>>>> Apart from the fact that it's reusable, what you just did was read the >>>>> file twice, to serve it. >>>> >>>> OK. But only done once. >>> >>> Assuming you then keep track of this converted file, it does not change, >>> and you have the storage, yes... >> >> Why would it change? > >Because nothing is set in stone? People use the system, people change >content, people transfer files, people do all kind of strange things... >Imagine... > >>>>> And now you are creating alternative files for requested files, and need >>>>> to keep track which ones you have created an alternative for, and >>>>> substitute one for the other for those cases. I can see how this can >>>>> become rather exciting over time... >>>> >>>> Overwrite the existing. It's text and VMS can read it because it'll see the >>>> record format. >>> >>> Whoa! I don't know about you, but personally I would be extremely pissed >>> if a tool that is supposed to only read my file were to modify it. Even >>> if the contents supposedly should appear to look the same afterwards. >>> >>> But you're even making some pretty horrible assumptions here. Assuming >>> that the file even is a text file to start with, for which conversion to >>> a stream, might be assuming too much. >> >> If it's not text, then what does it matter? Binary? > >So you have a sequential file with variable size records, and no file >attributes. How do you find the size? Why would the file attributes matter? file_size_in_bytes = <end_of_file_block-1>*512 + <end of file byte> ... but it won't mean what you want it to mean. -- 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:39 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkrhao$lkq$1@Iltempo.Update.UU.SE> |
| In reply to | #59001 |
On 2016-06-27 17:19, VAXman-@SendSpamHere.ORG wrote: > In article <nkrbmt$7k8$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-23 23:40, VAXman-@SendSpamHere.ORG wrote: >>> In article <nkhf0u$71o$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-23 21:42, VAXman-@SendSpamHere.ORG wrote: >>>>> In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>> And now you are creating alternative files for requested files, and need >>>>>> to keep track which ones you have created an alternative for, and >>>>>> substitute one for the other for those cases. I can see how this can >>>>>> become rather exciting over time... >>>>> >>>>> Overwrite the existing. It's text and VMS can read it because it'll see the >>>>> record format. >>>> >>>> Whoa! I don't know about you, but personally I would be extremely pissed >>>> if a tool that is supposed to only read my file were to modify it. Even >>>> if the contents supposedly should appear to look the same afterwards. >>>> >>>> But you're even making some pretty horrible assumptions here. Assuming >>>> that the file even is a text file to start with, for which conversion to >>>> a stream, might be assuming too much. >>> >>> If it's not text, then what does it matter? Binary? >> >> So you have a sequential file with variable size records, and no file >> attributes. How do you find the size? > > Why would the file attributes matter? If you get a request for a file, it matters greatly if it has implied CRLF or not. If it does, you should add an explicit CR+LF at each record end, when sending the file. If it does not have this attribute, you should definitely not add a CR+LF at each record end. I did not expect I should have to explain such basic things to you. Were you really serious with this question? > file_size_in_bytes = <end_of_file_block-1>*512 + <end of file byte> > > ... but it won't mean what you want it to mean. That number is certainly a number. It is not a number I ever expect anyone would find useful for anything, so why do you even bring it up? It is not a file size for any meaningful definition of a filesize. Why would you exclude some bytes from the allocated size, but not exclude other bytes? Very discriminatory... Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-27 16:55 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B3FB.ACC455F6@SendSpamHere.ORG> |
| In reply to | #59001 |
In article <nkrhao$lkq$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-27 17:19, VAXman-@SendSpamHere.ORG wrote: >> In article <nkrbmt$7k8$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-23 23:40, VAXman-@SendSpamHere.ORG wrote: >>>> In article <nkhf0u$71o$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>> On 2016-06-23 21:42, VAXman-@SendSpamHere.ORG wrote: >>>>>> In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>>> And now you are creating alternative files for requested files, and need >>>>>>> to keep track which ones you have created an alternative for, and >>>>>>> substitute one for the other for those cases. I can see how this can >>>>>>> become rather exciting over time... >>>>>> >>>>>> Overwrite the existing. It's text and VMS can read it because it'll see the >>>>>> record format. >>>>> >>>>> Whoa! I don't know about you, but personally I would be extremely pissed >>>>> if a tool that is supposed to only read my file were to modify it. Even >>>>> if the contents supposedly should appear to look the same afterwards. >>>>> >>>>> But you're even making some pretty horrible assumptions here. Assuming >>>>> that the file even is a text file to start with, for which conversion to >>>>> a stream, might be assuming too much. >>>> >>>> If it's not text, then what does it matter? Binary? >>> >>> So you have a sequential file with variable size records, and no file >>> attributes. How do you find the size? >> >> Why would the file attributes matter? > >If you get a request for a file, it matters greatly if it has implied >CRLF or not. If it does, you should add an explicit CR+LF at each record >end, when sending the file. If it does not have this attribute, you >should definitely not add a CR+LF at each record end. That'so not a file attribute. >I did not expect I should have to explain such basic things to you. Were >you really serious with this question? > >> file_size_in_bytes = <end_of_file_block-1>*512 + <end of file byte> >> >> ... but it won't mean what you want it to mean. > >That number is certainly a number. It is not a number I ever expect >anyone would find useful for anything, so why do you even bring it up? Because it's THE file size. -- 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 19:36 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkro7d$8k2$1@Iltempo.Update.UU.SE> |
| In reply to | #59006 |
On 2016-06-27 18:55, VAXman-@SendSpamHere.ORG wrote: > In article <nkrhao$lkq$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-27 17:19, VAXman-@SendSpamHere.ORG wrote: >>> In article <nkrbmt$7k8$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-23 23:40, VAXman-@SendSpamHere.ORG wrote: >>>>> In article <nkhf0u$71o$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>> On 2016-06-23 21:42, VAXman-@SendSpamHere.ORG wrote: >>>>>>> In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>>>> And now you are creating alternative files for requested files, and need >>>>>>>> to keep track which ones you have created an alternative for, and >>>>>>>> substitute one for the other for those cases. I can see how this can >>>>>>>> become rather exciting over time... >>>>>>> >>>>>>> Overwrite the existing. It's text and VMS can read it because it'll see the >>>>>>> record format. >>>>>> >>>>>> Whoa! I don't know about you, but personally I would be extremely pissed >>>>>> if a tool that is supposed to only read my file were to modify it. Even >>>>>> if the contents supposedly should appear to look the same afterwards. >>>>>> >>>>>> But you're even making some pretty horrible assumptions here. Assuming >>>>>> that the file even is a text file to start with, for which conversion to >>>>>> a stream, might be assuming too much. >>>>> >>>>> If it's not text, then what does it matter? Binary? >>>> >>>> So you have a sequential file with variable size records, and no file >>>> attributes. How do you find the size? >>> >>> Why would the file attributes matter? >> >> If you get a request for a file, it matters greatly if it has implied >> CRLF or not. If it does, you should add an explicit CR+LF at each record >> end, when sending the file. If it does not have this attribute, you >> should definitely not add a CR+LF at each record end. > > That'so not a file attribute. Ok. So I should have said record attribute. My mistake. >> I did not expect I should have to explain such basic things to you. Were >> you really serious with this question? >> >>> file_size_in_bytes = <end_of_file_block-1>*512 + <end of file byte> >>> >>> ... but it won't mean what you want it to mean. >> >> That number is certainly a number. It is not a number I ever expect >> anyone would find useful for anything, so why do you even bring it up? > > Because it's THE file size. No it is not. It's an arbitrary number you decided to calculate. Why would that be any more valid than just <end-of-file-block>*512. Why do you care about the first free byte information at the end if you don't care about the free bytes in other records? And why just calculating based on the end-of-file-block and not allocated blocks? Johnny
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-27 19:43 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkroj5$8k2$3@Iltempo.Update.UU.SE> |
| In reply to | #59008 |
On 2016-06-27 19:36, Johnny Billquist wrote: > On 2016-06-27 18:55, VAXman-@SendSpamHere.ORG wrote: >> In article <nkrhao$lkq$1@Iltempo.Update.UU.SE>, Johnny Billquist >> <bqt@softjar.se> writes: >>> On 2016-06-27 17:19, VAXman-@SendSpamHere.ORG wrote: >>>> In article <nkrbmt$7k8$2@Iltempo.Update.UU.SE>, Johnny Billquist >>>> <bqt@softjar.se> writes: >>>>> On 2016-06-23 23:40, VAXman-@SendSpamHere.ORG wrote: >>>>>> In article <nkhf0u$71o$2@Iltempo.Update.UU.SE>, Johnny Billquist >>>>>> <bqt@softjar.se> writes: >>>>>>> On 2016-06-23 21:42, VAXman-@SendSpamHere.ORG wrote: >>>>>>>> In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist >>>>>>>> <bqt@softjar.se> writes: >>>>>>>>> And now you are creating alternative files for requested files, >>>>>>>>> and need >>>>>>>>> to keep track which ones you have created an alternative for, and >>>>>>>>> substitute one for the other for those cases. I can see how >>>>>>>>> this can >>>>>>>>> become rather exciting over time... >>>>>>>> >>>>>>>> Overwrite the existing. It's text and VMS can read it because >>>>>>>> it'll see the >>>>>>>> record format. >>>>>>> >>>>>>> Whoa! I don't know about you, but personally I would be extremely >>>>>>> pissed >>>>>>> if a tool that is supposed to only read my file were to modify >>>>>>> it. Even >>>>>>> if the contents supposedly should appear to look the same >>>>>>> afterwards. >>>>>>> >>>>>>> But you're even making some pretty horrible assumptions here. >>>>>>> Assuming >>>>>>> that the file even is a text file to start with, for which >>>>>>> conversion to >>>>>>> a stream, might be assuming too much. >>>>>> >>>>>> If it's not text, then what does it matter? Binary? >>>>> >>>>> So you have a sequential file with variable size records, and no file >>>>> attributes. How do you find the size? >>>> >>>> Why would the file attributes matter? >>> >>> If you get a request for a file, it matters greatly if it has implied >>> CRLF or not. If it does, you should add an explicit CR+LF at each record >>> end, when sending the file. If it does not have this attribute, you >>> should definitely not add a CR+LF at each record end. >> >> That'so not a file attribute. > > Ok. So I should have said record attribute. My mistake. I bet you even knew this... >>> I did not expect I should have to explain such basic things to you. Were >>> you really serious with this question? >>> >>>> file_size_in_bytes = <end_of_file_block-1>*512 + <end of file byte> >>>> >>>> ... but it won't mean what you want it to mean. >>> >>> That number is certainly a number. It is not a number I ever expect >>> anyone would find useful for anything, so why do you even bring it up? >> >> Because it's THE file size. > > No it is not. It's an arbitrary number you decided to calculate. > Why would that be any more valid than just <end-of-file-block>*512. Why > do you care about the first free byte information at the end if you > don't care about the free bytes in other records? Free bytes in other blocks, I should have said. > And why just calculating based on the end-of-file-block and not > allocated blocks? I would argue that this would actually be more useful than your weird file "byte size". Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-27 20:20 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B418.485672A4@SendSpamHere.ORG> |
| In reply to | #59006 |
In article <nkro7d$8k2$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>On 2016-06-27 18:55, VAXman-@SendSpamHere.ORG wrote:
>> In article <nkrhao$lkq$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>> On 2016-06-27 17:19, VAXman-@SendSpamHere.ORG wrote:
>>>> In article <nkrbmt$7k8$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>>>> On 2016-06-23 23:40, VAXman-@SendSpamHere.ORG wrote:
>>>>>> In article <nkhf0u$71o$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>>>>>> On 2016-06-23 21:42, VAXman-@SendSpamHere.ORG wrote:
>>>>>>>> In article <nkhdao$2us$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>>>>>>>> And now you are creating alternative files for requested files, and need
>>>>>>>>> to keep track which ones you have created an alternative for, and
>>>>>>>>> substitute one for the other for those cases. I can see how this can
>>>>>>>>> become rather exciting over time...
>>>>>>>>
>>>>>>>> Overwrite the existing. It's text and VMS can read it because it'll see the
>>>>>>>> record format.
>>>>>>>
>>>>>>> Whoa! I don't know about you, but personally I would be extremely pissed
>>>>>>> if a tool that is supposed to only read my file were to modify it. Even
>>>>>>> if the contents supposedly should appear to look the same afterwards.
>>>>>>>
>>>>>>> But you're even making some pretty horrible assumptions here. Assuming
>>>>>>> that the file even is a text file to start with, for which conversion to
>>>>>>> a stream, might be assuming too much.
>>>>>>
>>>>>> If it's not text, then what does it matter? Binary?
>>>>>
>>>>> So you have a sequential file with variable size records, and no file
>>>>> attributes. How do you find the size?
>>>>
>>>> Why would the file attributes matter?
>>>
>>> If you get a request for a file, it matters greatly if it has implied
>>> CRLF or not. If it does, you should add an explicit CR+LF at each record
>>> end, when sending the file. If it does not have this attribute, you
>>> should definitely not add a CR+LF at each record end.
>>
>> That'so not a file attribute.
>
>Ok. So I should have said record attribute. My mistake.
>
>>> I did not expect I should have to explain such basic things to you. Were
>>> you really serious with this question?
>>>
>>>> file_size_in_bytes = <end_of_file_block-1>*512 + <end of file byte>
>>>>
>>>> ... but it won't mean what you want it to mean.
>>>
>>> That number is certainly a number. It is not a number I ever expect
>>> anyone would find useful for anything, so why do you even bring it up?
>>
>> Because it's THE file size.
>
>No it is not. It's an arbitrary number you decided to calculate.
>Why would that be any more valid than just <end-of-file-block>*512. Why
>do you care about the first free byte information at the end if you
>don't care about the free bytes in other records?
Why does DEC C (DEC, Compaq, HP, VSI)?
[King Arthur] Consult the Book of VMS Source Listings.
[Brother Maynard] C$STD_STAT, chapter two, verses nine through twenty-one.
[Cleric]
if (recattr.fat$l_efblk != 0) {
stat_buf->st_size = ((off64_t)recattr.fat$w_efblkh * 65536
+ (off64_t)recattr.fat$w_efblkl - 1 ) * RMS_BLOCKSIZE
+ recattr.fat$w_ffbyte;
}
else {
stat_buf->st_size = ((off64_t)recattr.fat$w_hiblkh * 65536
+ (off64_t)recattr.fat$w_hiblkl ) * RMS_BLOCKSIZE
+ recattr.fat$w_ffbyte;
}
[Brother Maynard] Amen.
>And why just calculating based on the end-of-file-block and not
>allocated blocks?
The calculation is the bytes written in the file. Allocated blocks you would
not be outputting in your HTTP connection UNLESS they were written to by some
application.
The file size is, primarily, only relative to the size of the file if it is a
sequential file. RELATIVE and, most definitely, INDEXED files mailtain data
that is only for the specialize access each provides (metadata). INDEXED can
have data in the records and keys compressed; thus, all bets are off on using
the file size.
--
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:33 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nks2in$3gn$1@Iltempo.Update.UU.SE> |
| In reply to | #59018 |
On 2016-06-27 22:20, VAXman-@SendSpamHere.ORG wrote:
> In article <nkro7d$8k2$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>> On 2016-06-27 18:55, VAXman-@SendSpamHere.ORG wrote:
>>> In article <nkrhao$lkq$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>>> On 2016-06-27 17:19, VAXman-@SendSpamHere.ORG wrote:
>>>>> file_size_in_bytes = <end_of_file_block-1>*512 + <end of file byte>
>>>>>
>>>>> ... but it won't mean what you want it to mean.
>>>>
>>>> That number is certainly a number. It is not a number I ever expect
>>>> anyone would find useful for anything, so why do you even bring it up?
>>>
>>> Because it's THE file size.
>>
>> No it is not. It's an arbitrary number you decided to calculate.
>> Why would that be any more valid than just <end-of-file-block>*512. Why
>> do you care about the first free byte information at the end if you
>> don't care about the free bytes in other records?
>
> Why does DEC C (DEC, Compaq, HP, VSI)?
I obviously do not have the answer to that one either, but the number is
equally meaningless no matter who wrote the code.
> [King Arthur] Consult the Book of VMS Source Listings.
> [Brother Maynard] C$STD_STAT, chapter two, verses nine through twenty-one.
> [Cleric]
>
> if (recattr.fat$l_efblk != 0) {
> stat_buf->st_size = ((off64_t)recattr.fat$w_efblkh * 65536
> + (off64_t)recattr.fat$w_efblkl - 1 ) * RMS_BLOCKSIZE
> + recattr.fat$w_ffbyte;
> }
> else {
> stat_buf->st_size = ((off64_t)recattr.fat$w_hiblkh * 65536
> + (off64_t)recattr.fat$w_hiblkl ) * RMS_BLOCKSIZE
> + recattr.fat$w_ffbyte;
> }
>
> [Brother Maynard] Amen.
Bonus point for the Python reference.
>> And why just calculating based on the end-of-file-block and not
>> allocated blocks?
>
> The calculation is the bytes written in the file. Allocated blocks you would
> not be outputting in your HTTP connection UNLESS they were written to by some
> application.
No it is not the number of bytes written in the file. As noted before,
the number of bytes written in the file can either be 1) The actual
number of bytes written in the file, which should then exclude padding
bytes at record ends, and padding bytes at block ends, or 2) the number
of bytes constituting the blocks written, since in the end, all writes
are in blocks.
This (your) number is neither.
> The file size is, primarily, only relative to the size of the file if it is a
> sequential file. RELATIVE and, most definitely, INDEXED files mailtain data
> that is only for the specialize access each provides (metadata). INDEXED can
> have data in the records and keys compressed; thus, all bets are off on using
> the file size.
Totally agree that indexed and relative files make no sense in this
context, so I'm leaving them out of it.
But the problem with the number (and code) above, is that it's not
really a number that relates to anything relevant at all.
Johnny
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-28 09:02 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nLW6VDLetIhm@eisner.encompasserve.org> |
| In reply to | #59020 |
In article <nks2in$3gn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: > > No it is not the number of bytes written in the file. As noted before, > the number of bytes written in the file can either be 1) The actual > number of bytes written in the file, which should then exclude padding > bytes at record ends, and padding bytes at block ends, or 2) the number > of bytes constituting the blocks written, since in the end, all writes > are in blocks. If I write "hellow world\n" on UNIX, I get a different number of bytes in the file than if I write it on Windows, even though my application wrote the same thing. So which one is the "number of bytes" _written_ "to the file"?
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-29 10:48 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nl020i$g3n$1@Iltempo.Update.UU.SE> |
| In reply to | #59048 |
On 2016-06-28 15:02, Bob Koehler wrote: > In article <nks2in$3gn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> >> No it is not the number of bytes written in the file. As noted before, >> the number of bytes written in the file can either be 1) The actual >> number of bytes written in the file, which should then exclude padding >> bytes at record ends, and padding bytes at block ends, or 2) the number >> of bytes constituting the blocks written, since in the end, all writes >> are in blocks. > > If I write "hellow world\n" on UNIX, I get a different number of > bytes in the file than if I write it on Windows, even though my > application wrote the same thing. > > So which one is the "number of bytes" _written_ "to the file"? Since the OSes are different, the number of bytes written are different. Why do you expect that you will get the same number of bytes written in both cases? However, reading the file with the proper low level functions (ie not the C stdio format library functions fgets(), which do some even funkier stuff when reading), you would get the same number of bytes read back as was original written to the file, and that would be the same number of bytes as reported by the stat() call. I would suggest reading with something like fgetc() or fread() if you are more impatient. Very consistent, and very correct. In VMS it's neither. (Well, it is consistently wrong, which I guess is consistent... :-) ) Put it in very simple terms. If I have a file, and I do a stat() call, to find out how many bytes there are in the file, I should be able to call fgetc() that many times to get all the bytes in the file. Anything breaking this assumption means the reported size is wrong. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-29 10:59 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nl02lf$gsb$3@Iltempo.Update.UU.SE> |
| In reply to | #59077 |
On 2016-06-29 10:48, Johnny Billquist wrote: > On 2016-06-28 15:02, Bob Koehler wrote: >> In article <nks2in$3gn$1@Iltempo.Update.UU.SE>, Johnny Billquist >> <bqt@softjar.se> writes: >>> >>> No it is not the number of bytes written in the file. As noted before, >>> the number of bytes written in the file can either be 1) The actual >>> number of bytes written in the file, which should then exclude padding >>> bytes at record ends, and padding bytes at block ends, or 2) the number >>> of bytes constituting the blocks written, since in the end, all writes >>> are in blocks. >> >> If I write "hellow world\n" on UNIX, I get a different number of >> bytes in the file than if I write it on Windows, even though my >> application wrote the same thing. >> >> So which one is the "number of bytes" _written_ "to the file"? > > Since the OSes are different, the number of bytes written are different. > Why do you expect that you will get the same number of bytes written in > both cases? > However, reading the file with the proper low level functions (ie not > the C stdio format library functions fgets(), which do some even funkier > stuff when reading), you would get the same number of bytes read back as > was original written to the file, and that would be the same number of > bytes as reported by the stat() call. I would suggest reading with > something like fgetc() or fread() if you are more impatient. > > Very consistent, and very correct. In VMS it's neither. (Well, it is > consistently wrong, which I guess is consistent... :-) ) > > Put it in very simple terms. If I have a file, and I do a stat() call, > to find out how many bytes there are in the file, I should be able to > call fgetc() that many times to get all the bytes in the file. Anything > breaking this assumption means the reported size is wrong. And before anyone comes with a silly argument like having stat() return +inf: reading one byte more than what stat() returned as the size, should return an error. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-23 19:06 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B0E9.50CD26DE@SendSpamHere.ORG> |
| In reply to | #58852 |
In article <nkhaqu$5la$2@dont-email.me>, David Froble <davef@tsoft-inc.com> writes: >Johnny Billquist wrote: >> 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. >> >> Johnny >> > >Why would you read through it twice? With a few exceptions, read it into >memory, then transmit it. Something you got to do anyway. Perhaps just >re-ordering the task. > >Too big? Got to ask, what's wrong with doing things in segments? Maybe not how >the *ix world does things. Who's to say they are always right? The *ix world believe they are always right. -- 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 | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-23 17:05 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B0D8.6BF2E75C@SendSpamHere.ORG> |
| In reply to | #58850 |
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. ;) 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. *IF* you need to transfer your files as you state, then choose your file's record formats appropriately and you should be able to compute the file's byte count from readily available info. ;) But don't force an unnecessary burden on my files because you need some data that's of no consequence to me. HP Alliance One distributes PAKs as a text file that is stream (chock full of <CR>s and <LF>s). I'm supposed to execute this to install the Alliance One PAKs. Some people (on VMS) find this a nuisance because of the <CR>s and <LF>s littering the data (because it's delivered via HTTP from HP's A1 web site) cause DCL to complain. I simply change the file's attributes to RFM=STM and all's well. You, too, could convert your files to RFM=STM and then, your prayers have been answered. What YOU want to transmit via HTTP is all right there in the file and you should be able to compute the file size as well. But, it's so much easier to fault VMS, its file system, and RMS because it's not understood. -- 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]
Page 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
Back to top | Article view | comp.os.vms
csiph-web