HDTenEightyP/NetNews huggingface dataset:
From: edwards@world.std.com (Jonathan Edwards)
Subject: Re: distributed transactions
Organization: The World Public Access UNIX, Brookline, MA
Date: Sat, 22 Aug 1992 04:05:46 GMT

In article <173oogINNmrp@agate.berkeley.edu> mao@triplerock.CS.Berkeley.EDU (Mike Olson) writes:
>
>you're correct in your assertion that strong consistency in the face
>of catastrophic failures is very difficult to guarantee.  skeen's work
>makes it possible for some nodes, under some conditions, to continue
>to make progress when machines crash or communications fail, but it
>doesn't solve the whole problem.  other approaches are to relax your
>consistency requirements, or to have humans outside the loop grant
>permission to acquire locks and update tables during communications
>failures.
>
>the added complexity of three-phase commit, coupled with the fact that
>a clever adversary can force blockage anyway, have meant that it hasn't
>gotten a lot of attention by commercial vendors.  in real life, what
>people do is spend a lot of money on redundant, highly reliable
>communications systems.  when something crashes, some expensive employees 
>get it working again fast.

And so we come full circle through a theoretical detour to my original
issue. The way to build a reliable distributed system in practice is:

1) partition the design into separate autonomous databases that interact
via a reliable message-transfer protocol. This partitioning is naturally
done along organizational or legal boundaries, so human responsibility
correlates with system availability i.e., your ass is covered if the other
guy's system is down. By interacting via messages, there are discrete quanta
of responsibility that flow between systems in atomic steps.
Distributed transactions should never cross autonomous systems, except perhaps
to run the message transfers.

2) Reliability is acheived through redundant hardware and recoverable
databases. Recovery from 'disasters' is done by geographically seperated
hardware which is kept as a 'hot standby' with a synchronously updated
database. This is optimally done via a copy of the journal stream,
which contains all necessary data without the redundancy of the disk write
stream. General purpose replicated data with multi-phase protocols and
fancy voting and broadcast algorithms seems way too complex and
inefficient (but maybe it will improve).
My original post was a query to find out if any commercial databases
were capable of robust hot standby. So far, NOT. So far, there doesn't
even seem much acknowledgement that this is a correct approach
to the problem.




Newsgroups: comp.databases
From: al@cvgis.prime.com (Al Parker)
Subject: Embedded SQL ANSI Std - Help
Organization: Computervision GIS (Toronto)
X-Newsreader: Tin 1.1 PL4
Date: Thu, 13 Aug 1992 21:07:50 GMT

[ Article crossposted from comp.std.misc ]
[ Author was  ]
[ Posted on Thu, 13 Aug 1992 21:06:10 GMT ]

Greetings,
I am dealing with various RDBMS packages and am finding that there
seems to be considerable latitude in their implementation of
embedded SQL.
Is this because the standard was not official before the
implementations were put out ?

At any rate, I would like a copy of the ANSI standard which governs
embedded SQL. If this is ONLINE somewhere can someone point me to the
source ?

Thanks in advance, AlP
-- 
-------------------------------------------------------------------------------
Al Parker, P.Eng, Sr Software Engineer - Computervision GIS
al@cvgis.prime.com	(416)508-8020(x881)
These opinions are my own and not those of my compnay.
-- 
-------------------------------------------------------------------------------
Al Parker, P.Eng, Sr Software Engineer - Computervision GIS
al@cvgis.prime.com	(416)508-8020(x881)
These opinions are my own and not those of my compnay.
Newsgroups: comp.databases
From: jono@netcom.com (Jonathan Levine)
Subject: Re: Looking for a database (I'm a nonprogrammer..)
Date: Fri, 14 Aug 92 15:16:43 GMT
Organization: Our Lady of Perpetual Motion
Distribution: na

In article <BsJ3I3.1tx@cs.dal.ca> goldrick@ug.cs.dal.ca (Majeed  Goldrick) writes:
>Greetings,
>
>Thanks to those in Canada who have responded or are going to respond, eh?. It's
>time to "broaden my horizons, I think...
>
>I am looking for a very rudimentary database program with an idiot-proof
>user interface.  The data entry screen(s) should be able to be set up
>much like a printed page - it could be character-based or WYSIWYG 
>(Windows programs are O.K.).  This primary interface form should be able
>to be cross referenced against other forms with related information (I
>guess this is where relational database comes from??).  For example,
>the primary page might be a fact sheet on an individual in a company,
>the secondary sheets might include salary info, notes and comments, etc...
>
>Along with this, it would be nice to have some report-generation capabilities,
>like being able to correlate values in different fields, at least to
>the extent that you could dump the figures to a spreadsheet/graphing
>program.
>

You will probably want to check out Approach for Windows, a Windows-based
relational database that lets you set up forms and reports with no
programming required.  (Some of the stuff you're describing about switching
between forms can be automated with a simple macro facility).

Approach can store data in several major database formats, and can export/import
to Excel and 1-2-3.

For more information, call 1-800-APPROACH (in Canada, 1-800-354-1122).

Jon

P.s. Disclaimer: Yes, I did write some of Approach.


-- 
Jonathan Levine			"Paradise is exactly like 
jono@netcom.COM			 where you are right now,
(    ^^^^^^^^^^ New EMail Path)	 only much, much better."
					-- Laurie Anderson
Newsgroups: comp.databases
From: geppert@ifi.unizh.ch (Andreas Geppert)
Subject: Re: Wanted: suggested reading on object oriented databases
Reply-To: geppert@ifi.unizh.ch
Organization: University of Zurich, Department of Computer Science
Date: Fri, 14 Aug 1992 12:00:04 GMT

I'd propose
   "Object Data Management"
   by R.G.G. Cattell, Addison-Wesley.
Have fun
Andreas

------------------------------------------------------------
Andreas Geppert
Institut fuer Informatik
Universitaet Zuerich            Phone         +41-1-257 4576
Winterthurerstr. 190            Telefax       +41-1-363 0035
CH-8057 Zuerich                 Telex        817 251 unii ch
Switzerland                     E-mail  geppert@ifi.unizh.ch
------------------------------------------------------------

Newsgroups: comp.databases
From: des@helix.nih.gov (David E. Scheim)
Subject: Re: Help me choose: SQL DBMS for DOS
Organization: National Institutes of Health, Bethesda
Date: Wed, 12 Aug 1992 13:03:03 GMT

>I currently run Paradox 3.0 and I am getting increasingly jealous of my
>brother's ease of programming in SQL.  The PAL language just doesn't seem to
>meet my needs (PAL is in Paradox).
>
SQL provides an advantage mainly for a client-server configuration, to
provide a common interface between a back-end DBMS engine and a front-end
tool.  If you're running standalone on a DOS machine, Paradox is one of the
better choices.  I would recommend upgrading to version 4.0 which should be
out this summer.  It's a major upgrade, I understanding with an up to
10-fold speed improvement and much-improved programming tools.  

Newsgroups: comp.databases
From: ak45ldp@Texaco.com (Larry D. Pyeatt)
Subject: Need some advice
Organization: Texaco
Date: Thu, 13 Aug 1992 14:49:11 GMT

Hello, I need some advice on how to set up a data server.  My
area is Neural Networks and I really don't know what is 
available in the way of databases.  So here is a description
of the problem.

We have a flat data file consisting of at least 2000 binary
images.  Several other files are used to group the images
into overlapping sets of "related" images.  What we would
like to do is set this up on a Unix system so that several
people can have simultaneous access to the data.  They will
need to be able to retrieve, edit, delete and create images.
The program will also need high speed sequential access to 
all of the records referenced by a group.  This is to
facilitate automated pattern recognition.  The file currently
contains over 2000 images and is still growing.

The data server should:
support multiple clients,
provide record locking for the image file,
notify all clients when a record or file has been modified.

I have been considering the possibility of writing a simple
daemon to fulfill my requirements, but want to explore any
alternatives first.  I am especially interested in any public
domain or shareware products, but will also consider other
options.

Thanks in advance.

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.
From: tapo@LEON.NRCPS.ARIADNE-T.GR (AUEB)
Newsgroups: comp.databases
Subject: 2 Phase locking simulator needed
Date: 20 Aug 92 13:10:51 GMT
Organization: NETWORK ARIADNE , NCSR DEMOCRITOS


Does anyone know a 2PL simulator (Public available) ?

I desperately need it for an urgent work.

Thanking in advance for any help

Chris Tsiros
tapo@leon.nrcps.ariadne-t.gr
Newsgroups: comp.dcom.isdn
From: rick@digibd.com (Rick Richardson)
Subject: Re: Network Connections over ISDN
Organization: DigiBoard Incorporated, Eden Prairie, MN
Date: Tue, 18 Aug 1992 11:51:35 GMT

lgm@ulysses.att.com (L. G. McKnight) writes:

>I have not tried to use X -windows over ISDN.  Notes on the network
>indicate that X-windows works surprisingly well over a 64 kbit/sec
>B-channel.  I assume that this means that the D-channel would be too slow.

I haven't tried X on the D channel, either. But I've run up a Qume
monochrome serial X terminal at 9600 baud over a serial line.  You
could get away with using an xterm to do some editing, and perhaps
do a little testing of, say, a new app you might be building.
But you wouldn't want to have much more going on than that.  With
D channel packet you might get burned by the PAD latency; I'm not
sure if the Qume does Ack/Nak type of protocol on the serial line.

>>As for 19.2, that's not ever available on the D-channel in 2B+D, not
>>even in theory.

>If we assume that "19.2" refers to the baud rate for an RS-232
>connection -- which is almost certainly the case -- then 19.2 is, in
>fact, available over the 16 kbit/sec D-channel.  The RS-232 signal
>includes a start and a stop bit for each character so there are 10 bits
>per asynchronous ascii character.  The D-channel carries only the 8 data
>bits so an asynchronous 19.2 kbaud signal can be carried in 15.36
>kbits/sec without compression.

Its easier to see this point by converting to CPS.  19,200 async is
1920 char/sec,  16000 sync is 2000 char/sec.

However, after accounting for flags, layer 2 and 3 headers, CRC bytes,
and bit stuffing (about 1 bit stuffed in 32 for binary data), you come
up with about 1+3+4+2+1 = 11 bytes of fixed overhead.  For packet
length of 256, bit stuffing adds about 8 more bytes of overhead. So
you only get 2000 cps * 256/(256+19) = 1860 cps.  For 512 byte packets,
it works out to 2000 * 512/(512+27) = 1898 cps. At 1024, its 1918 cps.

Note that some types of data don't need much bit stuffing, and other
types of data force worst case bit stuffing.  I think that 1 bit in 32
is fair for making comparisons, as it assumes pseudo-random data.

So 1024 byte packets on the D channel are approximately equal to a
19,200 bps async "wire".  Smaller packets are very close to 19.2.
Its so close, its not worth quibbling about.

OOPS -- I forgot to add in the layer 1 overhead - you've got to
wait 8-11 one bits between frames.  Add 1 to 1.5 bytes to the above
numbers and recompute.  It won't make much difference.

-Rick
-- 
Rick Richardson		Email: rick@digibd.com	This space intentionally
Senior Staff Engineer	Fax:   (612) 943-0803	blank until 1996 elections.
DigiBoard, Inc.		Tel:   (612) 943-5383
Eden Prairie, MN	Radio: N0NMY
From: dror@digibd.com (Dror Kessler)
Subject: Re: Network Connections over ISDN
Organization: DigiBoard Incorporated, Eden Prairie, MN
Date: Fri, 14 Aug 1992 14:46:56 GMT

In article <1992Aug12.085917.5543@ericsson.se> etxorst@eos.ericsson.se writes:
>
>In a real-life situation a message of 1024 bytes (the size limit we'd
>arbitrarily picked for our message transfer function) took several
>seconds (often 5 - 10). At 16 kbit/s it should only have needed 0.5 s.
>I think part of the delay may have been due to flow control imposed by
>the CO.
>

Are you reffering to D channel packet (X.25) or Q.931 user-to-user signalling?

Using D channel X.25, I have seen close to 14000 bps of user data. 

Q.931 user-to-user signalling is not intended to move large amounts of
information. The main use would be signalling setup information user-to-user
upon connection establishment. Trying to move data with this facility is
asking for it.

After saying that, I would like to point that data transfer on the D channel is 
becoming less and less interesting. have you ever thought of how much you're 
going to pay for this service LONG DISTANCE. With circuit switched B channel, 
you're paying a rate comparable to analog long distance. Also user-to-user 
signalling can not be guaranteed unless there is end-to-end ISDN (SS7 in US) 
deployment, which is always to be completed in two years.

----------------------------------------------------------------------------
Dror Kessler                                         phone: (612)943-5374
Senior Member of Technical Staff                     fax:   (612)943-0803
DigiBoard
6400 Flying Cloud Drive
Eden Prairie, MN 55344                               e-mail: dror@digibd.com
----------------------------------------------------------------------------


Newsgroups: comp.dcom.isdn
From: fan@socrates.umd.edu (Joseph Fan)
Subject: Re: TCP/IP via ISDN using PC ISDN card and packetdriver
Organization: University of Maryland University College
Date: Tue, 18 Aug 1992 02:08:39 GMT

In article <713961723snx@home.demon.co.uk> cms@home.demon.co.uk (Cliff Stanford) writes:
>In article <1992Aug14.114239.1@ttd.teradyne.com> munro@ttd.teradyne.com writes:
>>
>>Try the ISDN DataVoice S0 PC Card,
>>from:
>>        Gravatom Technology Limited
>
>	1)  The MCA version is broken.  I am waiting for Gravatom to
>let me have an updated version.
>	2)  As far as I know, they do not have a packet driver for the
>card.  The only MsDos software seems to be a file transfer package.
>		Regards,
>			Cliff.
>
>-- 
>Cliff Stanford                              cliff@demon.co.uk
>Demon Internet Services			    cms@home.demon.co.uk
>42 Hendon Lane				    +44 81 349 0063
>London N3 1TT                               +44 860 375870

Try OST's PC Snet Card, an ISDN BRI card for MS-DOS and UNIX platforms.
OST provides driver and API software for developers to develop their ISDN+X25
applications. In addition, OST developed the application software for the
SNET card to make your SNET PC work as TCP/IP Router(UNIX), TCP/IP NDIS
remote (DOS), NetBIOS Gateway/Remote, or Netware Router/Remote. 

The TCP/IP NDIS Remote works well over FTP's PC/TCP software without any
modification. Kmart has just proved it lately.

OST, S.A. (33) 99.32.50.50 France
OST, Inc. (703) 817-0400 USA
OST, AP (65) 2214233 Singapore
MAXIM (OST UK) (I don't have phone number)

Joseph Fan

fan@socrates.umd.edu		Know your enemy and know yourself. - Sun Tse



Newsgroups: comp.dcom.isdn
From: imhw400@indyvax.iupui.edu
Newsgroups: comp.dcom.isdn
Subject: Re: Network Connections over ISDN
Date: 17 Aug 92 16:18:22 -0500

In article <17079@ulysses.att.com>, lgm@ulysses.att.com (L. G. McKnight) writes:
[much highly useful discussion deleted -- thanks for explaining!]
> A call can be set up to route data to a packet switched network by any
> number of routes.   Currently our CO switch routes D-channel data to
> the packet handler section of the switch.  Higher data rates are
> more economically sent as circuit switched data so our switch does
> not have a link from the B-channel to the packet switched network.

Um, what path do I take if I want to connect a service intended to be used
concurrently by a significant number of subscribers, to the packet handler?  Do
I put in a bucketful of BRIs and waste the B channels, accepting one call on
each D channel?  I think I'd rather have the PH multiplex the packets onto a
single higher-bandwidth channel (a B channel, for example, if the anticipated
concurrent subscriber load is not *too* large).

[more deletia]
> The rates for telephone services in the U.S. are too complex to
> discuss here.  But certainly B-channel connections are not expensive --
> as every modem user knows.  Sending data over B-channels is no more
> expensive than sending VBD using a modem.  D-channel data should be cheaper
> for bursty data over long distances.  If D-channel data is not cheaper
> then data will be sent circuit switched over the B-channel.

No more expensive for the *carriers*.  But take a look at the tariffs that have
been filed, and rejected, and rewritten, if you want to see how expensive it
could have been for the *subscribers*.  I think that engineers need to take a
few moments, now and then, to ring up the sales office and find out what
marketing decisions have done to the desirability of their beautiful creations. 
Some might be shocked.

[still more deletia]
> As I said above, all the long distance switches in the U.S. are digital
> and digital switches are gradually relacing analog switches in the LEC's.
> Digital switches are by their very nature designed to handle data.
> However the telephone companies must make the investment in hardware
> and software to handle ISDN.  If there are only a few users to bear
> the cost then ISDN will be expensive.  But there is nothing intrinsic
> in ISDN to make the service more expensive than the POTS service we
> have now.

Don't get me started on the policy of sell-to-PBX-owners-first/residential-
subscribers-when-we-get-around-to-it.
--
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.
Newsgroups: comp.dcom.isdn
From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: Network Connections over ISDN
Organization: AT&T
Date: Fri, 14 Aug 1992 21:36:21 GMT

In article <oikh4co@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> (Is it fair to claim...)
> that ISDN D-channel might be good for intermittent stuff,
>such as remote interactive access, where the packet charges might be
>less than phone rates, but less good than a $430 v.32bis modem for
>moving bulk data?

I don't think anyone's ever claimed otherwise.  I don't believe Al's claimed
that D-channel packet is great for moving bulk data.  I know that's not the
intent of D-channel packet.  That's what B-channel 64k clear circuit mode is
for...

David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!houxa!deej     Switching & ISDN Implementation
From: nelson@crynwr.com (Russell Nelson)
Newsgroups: comp.dcom.isdn
Subject: BRI is actually 256Kbps
Distribution: world
Date: Fri, 21 Aug 92 13:23:46 GMT
Organization: Crynwr Software

I got to thinking last night -- BRI is actually 256kbps.  That's
because you get 2 connections at 2*64kbps.  The incoming and outgoing
data connections are *both* 64kbps.  So BRI is really 2*2*64kbps.

So when you compare modems to ISDN, remember that because you hear
yourself, you only get 64kbps MAX to use for a modem.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX
Newsgroups: comp.dcom.isdn
From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: Is the hub end of ISDN just N * the user end?
Organization: AT&T
Date: Fri, 21 Aug 1992 14:48:59 GMT

In article <or54mr8@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
>lars@spectrum.CMC.COM (Lars Poulsen) writes:
>+---------------
>| In article <optere0@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes:
>| >Ah, but the IECs (long-distance carriers) are racking up the bucks
>| >selling PRI as LEC bypass service...
>| 
>| How well does the LEC BRI interoperate with the IEC PRI service ?
>+---------------
>
>I am not a PRI customer, so I don't know for sure, but my understanding
>is that they *don't* necessarily interoperate. For example, if you ask
>for clear-channel 64 Kb/s through your PRI link to you IEC, you might not
>be able to complete that call through an LEC BRI link, though you almost
>certainly *will* be able to complete the call through another PRI supplied
>by the same IEC. 

Please note that the main reason for this is the lack of SS7 Network
Interconnect and appropriate service tariffs for digital switched access for
64kb/s data calls, *not* any incompatibility between the ISDN services.  For
example, AT&T offers Accunet(TM) Switched Digital Service over our ISDN PRI
offering.  An ASDS call, at 64, 384, or 1536 kb/s, can complete to another
AT&T network ISDN PRI.  An ASDS call at 56kb/s rate adapted to 64kb/s can
complete to a LEC BRI, if that BRI and the terminal support 56/64kb/s rate
adapted calls; the LEC/IXC interconnection will be via CSDC (in-band
signaled data) trunks.  At such time when SS7-NI is deployed for 64kb/s data
bearer capability and access tariffs are written on both the LEC and IXC
side, there is no technical reason why a 64kb/s call from an IXC PRI should
not be able to complete to a LEC BRI.

>Also, you probably can complete a "switched-56" call
>from an IEC PRI to/from an LEC BRI.

See above.

>+---------------
>| And are they both National ISDN-1 profile ?
>+---------------
>
>I don't think so, at this point. 

National ISDN-1 defines PRI capabilities in a supplier-specific manner (q.v.
Bellcore SR-NWT-001937), so if I wanted to claim the letter of the law, I
could claim compliance with NI-1.  (And my product manager would love me for
it.)  However, it's probably more accurate to say that NI-1 does not address
requirements for consistent provision of PRI capabilities.

>They're either DMS-100 or 5ESS,

Not necessarily.  AT&T's ISDN PRI offering is supported off the 4ESS(TM)
switch.


Note that any opinions contained herein are strictly the property of the
author, and do not necessarily reflect the position of AT&T.


David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!houxa!deej     Switching & ISDN Implementation
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Newsgroups: comp.dcom.isdn
Subject: Re: Is the hub end of ISDN just N * the user end?
Date: 21 Aug 92 03:27:40 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

lars@spectrum.CMC.COM (Lars Poulsen) writes:
+---------------
| In article <optere0@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes:
| >Ah, but the IECs (long-distance carriers) are racking up the bucks
| >selling PRI as LEC bypass service...
| 
| How well does the LEC BRI interoperate with the IEC PRI service ?
+---------------

I am not a PRI customer, so I don't know for sure, but my understanding
is that they *don't* necessarily interoperate. For example, if you ask
for clear-channel 64 Kb/s through your PRI link to you IEC, you might not
be able to complete that call through an LEC BRI link, though you almost
certainly *will* be able to complete the call through another PRI supplied
by the same IEC. Also, you probably can complete a "switched-56" call
from an IEC PRI to/from an LEC BRI.

+---------------
| And are they both National ISDN-1 profile ?
+---------------

I don't think so, at this point. They're either DMS-100 or 5ESS, and which
it is will vary by site. But DMS-100 at one end can interoperate with 5ESS
on the other...


-Rob
Newsgroups: comp.dcom.isdn