INFO-VAX	Sun, 09 Nov 2008	Volume 2008 : Issue 606

   Contents:
Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command
Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command
Re: Banana Republic (was Re: OpenVMS Book Wins award)
Re: OVMS Integrity BASIC LTU Getting only 1 user at cost of  $2400.00???
Re: Variable record format but used with fixed lenght data ?
Re: Variable record format but used with fixed lenght data ?

----------------------------------------------------------------------

Date: Sat, 08 Nov 2008 14:11:50 -0500
From: JF Mezei <jfmezei.spamnot@vaxination.ca>
Subject: Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command
Message-ID: <0007bc82$0$32289$c3e8da3@news.astraweb.com>

Question:

If I MOUNT/FOREIGN/SYSTEM a disk.

Is that ANY locking done for the disk when more than one user tries to
access it at the same time ? (I realise that file or record based
locking is not relevant in a foreign disk, but what about block or disk
based locking (aka: if use 1 opens a channel to the disk read/write,
can user 2 also do the same ?)

------------------------------

Date: Sun, 9 Nov 2008 02:54:08 +0000 (UTC)
From: moroney@world.std.spaamtrap.com (Michael Moroney)
Subject: Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command
Message-ID: <gf5jcg$37u$2@pcls4.std.com>

moroney@world.std.spaamtrap.com (Michael Moroney) writes:

>>Is this a bug or have I got it the wrong way round in my head?

>Interesting.  I just tried that and it worked. V8.3. It definitely did not
>allow both /SYSTEM and /FOREIGN before.  So the question is whether this
>was a deliberate change or an unintended consequence of something else (a
>bug).

I was corrected on this via email, apparently you could do 
$ MOUNT/SYSTEM/FOREIGN since the '90s or maybe earlier.  The oldest system 
I have access to is V7.3 which allows it.

------------------------------

Date: Sun, 9 Nov 2008 08:10:02 +0800
From: "Richard Maher" <maher_rj@hotspamnotmail.com>
Subject: Re: Banana Republic (was Re: OpenVMS Book Wins award)
Message-ID: <gf563i$rbg$1@news-01.bur.connect.com.au>

Hi Mark,

Thanks for the reply. (Sorry for the delay)

> I noted the post on Adobe policy files.

I think the HTML5 people ignore policy-files at their peril. (Not that they
seem to care as their world is all HTTP-shaped with no end of lovely
"headers")

> [Orbited]  Without some sort of access
> control it functions as an open relay - carte blanche.

I haven't used it but I believe they have some sort of white-list.

> Both are broad, evolving concepts and implementations.

Unlike TCP/IP and/or UDP Sockets with Java that have been around since year
dot. (Ok, sandboxed or signed up until now)

> FYIW; I have an (as-yet) unpublished Web application displaying
> elementary graphs of $GETRMI (monitor) data.  It uses a Comet-style
> <IFRAME> and streaming long-poll.  When system data changes it generates
> a <script>ed function call into browser JavaScript that supplies data
> values which the application JavaScript then graphs or displays.  One
> buffered I/O of a few tens to a few hundreds of bytes (depending on what
> data have changed) per sample period.  Negligible CPU ticks.  Not
> full-duplex but not synchronous-poll either.

Look, polling is anathema to me but when it comes to System Stats or
RMU/SHOW STATS etc, I don't have that much of a problem with it. I mean to
try to fire off an event every time something happens on a system or a
database might generate a bit of a flood. And each users might like to set
their own "sample" (or poll) interval?

Anyway, I understand it's "How your example works" rather than "What it's
doing" that's important. Sounds interesting, I look forward to seeing it.

Though, one thing I have been curious about with Comet (and possibly your
example) is what is the server thread/process doing while it's waiting for
(say Stock Price for FMG to change or to move past some limit(s)) Is this
thread/process serving *all* clients or is there a 1:1 relationship? How is
the connection-state and context maintained between the producing-service(s)
and the consuming client? Is the thread/process unavailable for servicing
other requests while it's streaming its long-poll (or words to that effect
:-)

> If you mean, provide asynchronous (event triggered), binary (non-HTTP)
> comms using these ports then yes.  Of course there is no reason why the
> services requested over these ports cannot further proxy the binary to
> TCP anything-configured.  IMO the bottom line is (again) access-control.
>   Whether this is the lone advantage is moot.

But I thought this is what the mail from Shannon of the WHATWG (in my
earlier post) describes as problematic?  - I'm confused.

> > If Sockets can't traverse public proxy-servers with existing HTTP then
> > option 1 is no longer on the table as far as I can see?
>
> This one has lost me but I'll have a go at two of the possible intents:
>
> 1) If you mean Web Sockets can't through existing HTTP proxy then the
> answer seems to me that they are designed to do just that.  Web Sockets
> behind proxy servers know it and appropriately CONNECT to tunnel.

I thought that's what Shannon was saying was problematic as they do go
through, but all roads lead to 443?

Cheers Richard Maher

"Mark Daniel" <mark.daniel@vsm.com.au> wrote in message
news:0118206d$0$20660$c3e8da3@news.astraweb.com...
> Richard Maher wrote:
> > Hi Mark,
> >
> > Thanks for the reply.
> >
> >> I bought it through Barnes and Noble in late May '08 for US$36.00 plus
> >> US$13.00 P&P, and I think my credit card statement said something like
> >> AU$52.00 so it was right at the 'peak'.  Why the AU$ currently should
be
> >> at US$0.65 now escapes me - perhaps that's one reason I'm still working
> >> for wages.
> >
> > I looked seriously at Perth Mint gold in August (when the bank deposit
> > guarantee was sweet FA) and Foreign Currency accounts aren't as common
here
> > as they are in the UK. Either way I would (and have) lost big time - but
> > haven't we all :-(
> >
> >> That any network connectivity has some sandboxing doesn't exactly
> >> surprise me.
> >
> > Me either! I'm a big fan of the same-origin, or codebase, policy for
Applets
> > but these guys just want to keep pushing the envelope.
>
> I noted the post on Adobe policy files.
>
> >> A network conduit (like SSH or HTTP CONNECT) is carte
> >> blanche for whatever the agent wishes to transfer.  No constraint would
> >> be considered negligence.
> >
> > Yeah, but here I bow
>
> ;-)
>
> > to your much greater experience and ask "What the hell
> > can a *Socket not HTTP* proxy-server do for me?".
>
> Isn't a(n IP) socket proxy that doesn't explicitly talk HTTP during
> setup a one-to-one NAT router?  And if accepting external connection
> requests, a static port mapping NAT router, into/through the DMZ and
> onto internal services?  And so forth through the NAT variants.
>
> > Look I wanted a HTTP
> > CONNECT handshake to give me a Tunnel for my Socket over a httpS
connection
> > to an arbitray TCP/IP server, but it doesn't look doable; please advise.
>
> I can but reframe my previous comment; unconstrained connectivity from
> browser based applications is surely like signing a full book of blank
> cheques.
>
> > I also view with interest what the Comet guys are doing with Orbited
(see
> > www.cometdaily.com for some background) as they don't seem to be bound
by
> > (or have already solved) these proxy-server restrictions.
>
> AIUI; Orbited is a service used to accept Web-style socket connection
> requests from browsers, establish Comet-style, bidirectional
> communication with the browser, then proxy (or forward, or gateway, or
> <whatever-you-feel-comfortable-describing-it-as>) that communication via
> a TCP socket to the requested end-point.  Without some sort of access
> control it functions as an open relay - carte blanche.  With access
> control it's a lot like most CONNECT proxy, or at least CONNECT
> reverse-proxy.  Of course it's a bit more than that (but isn't
> everything!)  Until Web Sockets become commonplace it uses a number of
> approaches to *emulate* asynchronous comms with current browsers.
>
> AIUI; Comet is a broad term used to described leveraging HTTP
> server-push of unsolicited/unpolled/asynchronous data to the browser,
> using existing HTTP technologies, most commonly, though not restricted
> to, streaming of a series individual response data 'inside' a persisting
>   HTTP connection, currently via 'long polling' and XMLhttpRequest() or
> <script> tag instances.  It's a compromise hack.  Not perfect but it
> works.  Of course it's more than this (but then isn't everything!)
> Undoubtably it will(/is) develop(ing) to encompass Web Sockets, etc.
>
> Both are broad, evolving concepts and implementations.
>
> FYIW; I have an (as-yet) unpublished Web application displaying
> elementary graphs of $GETRMI (monitor) data.  It uses a Comet-style
> <IFRAME> and streaming long-poll.  When system data changes it generates
> a <script>ed function call into browser JavaScript that supplies data
> values which the application JavaScript then graphs or displays.  One
> buffered I/O of a few tens to a few hundreds of bytes (depending on what
> data have changed) per sample period.  Negligible CPU ticks.  Not
> full-duplex but not synchronous-poll either.
>
> >> I'm guessing you mention this because the suggestion below that
> >>
> >>    "that the time could be better spent providing guidelines for
> >>     communication via an asynchronous CGI [originally I read GUI :-]
> >>     interface."
> >>
> >> sounds remarkably like Tier3 :-)
> >
> > Damn, I'm as transparent and one-domensional as usual :-)
>  >
> > The way I see it is we have two camps (and I'm happy to live with the
> > pluralism and think there's enough room for everyone).
> >
> > 1) The WebSockets http/html5 guys who have the distinct (and only)
advantage
> > of being able to tunnel out of 80/443 as HTTP
>
> If you mean, provide asynchronous (event triggered), binary (non-HTTP)
> comms using these ports then yes.  Of course there is no reason why the
> services requested over these ports cannot further proxy the binary to
> TCP anything-configured.  IMO the bottom line is (again) access-control.
>   Whether this is the lone advantage is moot.
>
> Of course Web Sockets require specialised server (and proxy server) as
> well as client (browser) support.
>
> The WASD mudmap includes Web Sockets server support (either 10.0 in
> mid-'09, or 10.1 in mid-'10).  Perhaps once HTML5 moves from draft :-}
>
> > 2) The New Order of full-blown, connection-oriented, full-duplex,
binary,
> > Socket Interaction
>
> No doubt this will be remarkably versatile in the absence of sandboxing,
> with many-and-varied conduits established between user's browsers and
> all manner of 'services'.
>
> > If Sockets can't traverse public proxy-servers with existing HTTP then
> > option 1 is no longer on the table as far as I can see?
>
> This one has lost me but I'll have a go at two of the possible intents:
>
> 1) If you mean Web Sockets can't through existing HTTP proxy then the
> answer seems to me that they are designed to do just that.  Web Sockets
> behind proxy servers know it and appropriately CONNECT to tunnel.
>
> 2) If you mean TCP sockets can't then no, unless they speak the
> application-level protocol required by the proxy (which would make them
> Web Sockets for all intents and purposes :-)
>
> > Anyway, please let me ask the question of why anyone would want to use a
> > proxy-server for Socket communication?
> >
> > . Socket Cacheing - No Thanks
>
> Difficult to cache without meta-data.
>
> > . Limited client IP addresses - IPV6
>
> Still a ways off.  And there's always the private/public address thingy.
>
> > . Anonymity - Not always a good thing
>
> Internal opacity usually is a good thing.
>
> > . Firewall - Open up connections to/from valid hosts/ports
>
> Access control usually is a good thing.
>
> > . Monitoring/filtering - Requirements spec for binary data
>
> Many organisations have a legal requirement to audit their activities.
> Certainly mine does.
>
> BFN, Mark.
>
> > Cheers Richard Maher
> >
> > "Mark Daniel" <mark.daniel@vsm.com.au> wrote in message
> > news:011308d4$0$20645$c3e8da3@news.astraweb.com...
> >> Richard Maher wrote:
> >>> Hi Mark,
> >>>
> >>>> (I purchased it when AU$ was almost at US$ parity :-)
> >>> Aaah, it seems like only weeks ago :-(
> >> I bought it through Barnes and Noble in late May '08 for US$36.00 plus
> >> US$13.00 P&P, and I think my credit card statement said something like
> >> AU$52.00 so it was right at the 'peak'.  Why the AU$ currently should
be
> >> at US$0.65 now escapes me - perhaps that's one reason I'm still working
> >> for wages.
> >>
> >> It was a good 'background' read but not directly applicable to my
> >> daytime duty statement these days.  I had not (as I indicated to Roland
> >> I might) gotten around to a public review (that would have required a
> >> second read).  Willem Grooters provided one I'd generally endorse.
> >>
> >> At around the same time I purchased Heller's, "Catch 22" (shipped to
one
> >> of my daughters), Earl's, "Digital Equipment Corporation (MA) (Images
> >> of  America)", and Schein's, "DEC Is Dead, Long Live DEC"; all good
> >> reads and all for different reasons.  With the exchange rate more like
> >> 2:3 I might have to think think more carefully.  (The Earl soft-cover
is
> >> a particularly easy but also interesting 'read' I'd recommend to all
> >> interested in DEC :-)
> >>
> >>> Cheers Richard Maher
> >>>
> >>> PS. Just in case you don't subscribe to the WHATWG mailing list, do
you
> > have
> >>> any interest in, or opinions on the following: -
> >> No I don't and indirectly I guess I do.
> >>
> >> That any network connectivity has some sandboxing doesn't exactly
> >> surprise me.  A network conduit (like SSH or HTTP CONNECT) is carte
> >> blanche for whatever the agent wishes to transfer.  No constraint would
> >> be considered negligence.
> >>
> >> I'm guessing you mention this because the suggestion below that
> >>
> >>    "that the time could be better spent providing guidelines for
> >>     communication via an asynchronous CGI [originally I read GUI :-]
> >>     interface."
> >>
> >> sounds remarkably like Tier3 :-)
> >>
> >> I agree; why would anyone spend time abstracting interfaces if a
> >> monolithic solution is all that is currently required?  Of course this
> >> is an entirely fresh (if not novel) discussion point ...
> >>
> >>> ----- Original Message ----- 
> >>> From: "Shannon"
> >>> To: "WHAT working group" >
> >>> Sent: Tuesday, October 14, 2008 7:22 AM
> >>> Subject: [whatwg] WebSocket and proxies
> >>>
> >>>
> >>>> In the process of testing my WebSocket proposal I discovered the
> > CONNECT
> >>>> method has a major restriction. Most proxies disable CONNECT to
> > anything
> >>>> but port 443.
> >>>>
> >>>> The following is from "Squid and the Blowfish":
> >>>> ------------------
> >>>> It is very important that you stop CONNECT type requests to non-SSL
> >>>> ports. The CONNECT method allows data transfer in any direction at
any
> >>>> time, regardless of the transport protocol used. As a consequence, a
> >>>> malicious user could telnet(1) to a (very) badly configured proxy,
> > enter
> >>>> something like:
> >>>> ... snip example ...
> >>>> and end up connected to the remote server, as if the connection was
> >>>> originated by the proxy.
> >>>> -------------------
> >>>>
> >>>> I verified that Squid and all public proxies I tried disable CONNECT
by
> >>>> default to non-SSL ports. It's unlikely many internet hosts will have
> >>>> 443 available for WebSockets if they also run a webserver. It could
be
> >>>> done with virtual IPs or dedicated hosts but this imposes complex
> >>>> requirements and costs over alternatives like CGI.
> >>>>
> >>>> The availability and capabilities of the OPTIONS and GET protocols
also
> >>>> varied from proxy to proxy. The IETF draft related to TLS
> >>>> (http://tools.ietf.org/html/draft-ietf-tls-http-upgrade-05) has this
to
> >>> say:
> >>>> -------------------
> >>>> 3.2 Mandatory Upgrade
> >>>>
> >>>>    If an unsecured response would be unacceptable, a client MUST send
> >>>>    an OPTIONS request first to complete the switch to TLS/1.0 (if
> >>>>    possible).
> >>>>
> >>>>           OPTIONS * HTTP/1.1
> >>>>           Host: example.bank.com
> >>>>           Upgrade: TLS/1.0
> >>>>           Connection: Upgrade
> >>>> -------------------
> >>>>
> >>>> So according to this draft spec OPTIONS is the only way to do a
> >>>> *mandatory* upgrade of our connection. Once again this failed in
> > testing
> >>>> -------------------
> >>>> => OPTIONS * HTTP/1.1
> >>>> => Proxy-Connection: keep-alive
> >>>> => Connection: Upgrade
> >>>> => Upgrade: WebSocket/1.0
> >>>> => Host: warriorhut.org:8000
> >>>> =>
> >>>> <= HTTP/1.0 400 Bad Request
> >>>> <= Server: squid/3.0.STABLE8
> >>>> --------------------
> >>>>
> >>>> Other proxies gave different errors or simply returned nothing. The
> >>>> problem may be related to the Upgrade and Connection headers rather
> > than
> >>>> OPTIONS, since I had similar issues using Connection: Upgrade with
GET.
> >>>>
> >>>> I had the most success using GET without a Connection: Upgrade
header.
> >>>> It seems that the proxy thinks the header is directed at it so it
does
> >>>> not pass it on to the remote host. In many cases it will abort the
> >>>> connection. Using the Upgrade: header without Connection allows the
> >>>> Upgrade header through to the actual websocket service.
> >>>>
> >>>> It seems to me that whatever we try in many cases the connection will
> > be
> >>>> silently dropped by the proxy and the reasons will be unclear due to
> > the
> >>>> lack of error handling. There seems to be a wide variation in proxy
> >>>> behaviour for uncommon operations. I suppose proxy developers could
fix
> >>>> these issues but whether a significant rollout could be achieved
before
> >>>> HTML5 is released is questionable.
> >>>>
> >>>> Given that an asynchronous connection cannot be cached the only
reasons
> >>>> remaining for going through a proxy are anonymity and firewall
> >>>> traversal. Automatically bypassing the users proxy configuration to
> >>>> solve the issues above has the potential to break both of these. It
> >>>> would be a significant breach of trust for a UA to bypass the users
> >>>> proxy and some networks only allow connections via a proxy (for
> > security
> >>>> and monitoring).
> >>>>
> >>>> It seems that we're stuck between a rock and hard place here. In
light
> >>>> of this I reiterate my earlier suggestion that the time could be
better
> >>>> spent providing guidelines for communication via an asynchronous CGI
> >>>> interface. This would allow reuse of existing port 80 and 443 web
> >>>> services which would resolve the cross-domain issues (the CGI can
relay
> >>>> the actual service via a backend connection) and most of the proxy
> >>>> issues above (since proxy GET and CONNECT are more reliable on these
> >>> ports).
> >>>> Shannon
> >>>>
> >>> "Mark Daniel" <mark.daniel@vsm.com.au> wrote in message
> >>> news:01110d0c$0$20616$c3e8da3@news.astraweb.com...
> >>>> yyyc186 wrote:
> >>>>> The Minimum You Need to Know About Service Orieted Architecture by
> >>>>> Roland Hughes
> >>>>>
> >>>>> Award-Winner in the Business: Technology/Computers/Internet category
> >>>>> of the National Best Books 2008 Awards, sponsored by USA Book News
> >>>> Congratulations Roland!
> >>>>
> >>>> (I purchased it when AU$ was almost at US$ parity :-)
> >>>>
> >>>>> You can find this book in Island Computer's Web store.
> >
> >

------------------------------

Date: Sat, 08 Nov 2008 14:16:15 -0500
From: JF Mezei <jfmezei.spamnot@vaxination.ca>
Subject: Re: OVMS Integrity BASIC LTU Getting only 1 user at cost of  $2400.00???
Message-ID: <0007bd8b$0$32289$c3e8da3@news.astraweb.com>

yyyc186 wrote:

> Are the language maintainers even in this country anymore?  Last I
> heard, HP no longer meets ITAR requirements for U.S. citizens working
> on their products.
> 

Well, John Reagan can still type in intelligible english without a thick
indian accent, so I assume he has not been moved to India or replaced by
some indian worker assuming the "John Reagan" name on public forums :-)

As to whether Mr Reagan is the only one left to maintain all of the
compilers on VMS (except for PL1), that is another question.

------------------------------

Date: Sat, 8 Nov 2008 16:23:19 -0800 (PST)
From: yyyc186 <yyyc186@hughes.net>
Subject: Re: Variable record format but used with fixed lenght data ?
Message-ID: <2b1bead3-0f44-4f47-a031-2774db3f399c@o4g2000pra.googlegroups.com>

On Nov 8, 10:58=A0am, Jan-Erik S=F6derholm <jan-erik.soderh...@telia.com>
wrote:
> Could/can it join RMS and Rdb in the same
> SQL SELECT statement ?
>

You wouldn't use SQL, you would be using the Quiz reporting module or
the Quick entry screens or the QTP bulk transaction module.

I have personally written reports with it which pulled data from RDB,
Oracle, and RMS.

The product used to be really cheap.  I haven't priced it since IBM
took it over.  PowerHouse is simply one of those tools every shop
should have laying around.

------------------------------

Date: Sun, 09 Nov 2008 01:40:31 GMT
From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?=
Subject: Re: Variable record format but used with fixed lenght data ?
Message-ID: <jcrRk.3944$U5.25289@newsb.telia.net>

yyyc186 wrote:
> On Nov 8, 10:58 am, Jan-Erik Söderholm <jan-erik.soderh...@telia.com>
> wrote:
>> Could/can it join RMS and Rdb in the same
>> SQL SELECT statement ?
>>
> 
> You wouldn't use SQL, you would be using the Quiz reporting module or
> the Quick entry screens or the QTP bulk transaction module.

OK, so it sounds as the join is done in the PowerHouse
application, not in the database utself (such as in Rdb
Database Integrator, wich can join from Rdb and any
Transparent Gateway) which I belive could get slihtly
better performance.

> 
> I have personally written reports with it which pulled data from RDB,
> Oracle, and RMS.
> 
> The product used to be really cheap.  I haven't priced it since IBM
> took it over.  PowerHouse is simply one of those tools every shop
> should have laying around.

Well, I'm quite comfortable with the price of
the DBI-kit from Oracle also... :-) :-)

------------------------------

End of INFO-VAX 2008.606
************************