| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1228.1 | Futures are generally not discussed... | BOUVS::OAKEY | Assume is *my* favorite acronym | Wed Feb 10 1993 20:25 | 14 |
| � <<< Note 1228.0 by OSLACT::OLAV "Do it in parallel!" >>>
� -< Rdb on Windows NT? >-
�Almost all the serious database vendors have announced plans for a Windows NT
�product to the public (with dates). I have tried to get some information for Rdb
�with no luck. What are the plans?
Olav,
You won't get futures in a public conference such as this. I'd suggest
that you contact Andy Schneider, the DEC Rdb Product Manager for specific
details. I believe that we have announced an intent to port to Windows NT
and OSF/1.
|
| 1228.2 | | GNROSE::HAGGERTY | GIA EIS/SWS, Acton MA USA | Thu Feb 11 1993 22:41 | 3 |
| or talk to your local I.M. Partner who attended the Symposium - there
were _some_ dates given out.
|
| 1228.3 | | NOVA::FEENAN | Jay Feenan Rdb/xxx Engineering | Thu Feb 11 1993 22:57 | 3 |
| We have announced that we will be porting to NT. Dates have not been announced.
-Jay
|
| 1228.4 | | CSC32::S_MAUFE | this space for rent | Wed Nov 03 1993 17:59 | 5 |
|
customer just asked, will we put Rdb on Windows NT *AXP* or *INTEL*
first? And what delay between the two?
thanks ! Simon
|
| 1228.5 | AXP first | NOVA::BERENSON | | Fri Nov 05 1993 03:00 | 8 |
| > customer just asked, will we put Rdb on Windows NT *AXP* or *INTEL*
> first? And what delay between the two?
AXP. Probably a 6-month delay to get to Intel since we need to rewrite
the internal code generator to have a "generic" mode that is interpretive
rather than a fully optimizing processor-specific code generator.
Hal
|
| 1228.6 | | CSC32::S_MAUFE | this space for rent | Fri Nov 05 1993 17:05 | 4 |
|
thanks Hal!
Simon
|
| 1228.7 | Bliss on Intel ?! | MSDOA::SECRIST | Future ain't what it used to be ! | Wed Nov 17 1993 22:17 | 9 |
|
; AXP. Probably a 6-month delay to get to Intel since we need to rewrite
; the internal code generator to have a "generic" mode that is interpretive
; rather than a fully optimizing processor-specific code generator.
Does this mean we're doing the front/back ends to put Bliss on Intel ?
Regards,
rcs
|
| 1228.8 | | CSC32::S_MAUFE | this space for rent | Thu Nov 18 1993 17:47 | 7 |
|
also, are we aiming for file level compatibility between the flavours
of rdb? My customer was thinking of masteting CDROMs on the VMS, then
weekly emailing the CDROMs to NT clients in the field. I said "uhhhmmm,
he'd better talk to his salesrep" 8-)
Simon
|
| 1228.9 | Well, the future is C | NOVA::BERENSON | | Fri Nov 19 1993 15:41 | 16 |
| re .7: Yes, I believe the BLISS group is doing this for internal
engineering use only. Of course Rdb is also slowly moving to C, a
process that will dramatically accelerate over the coming year.
re .8: I don't consider that a goal of the Rdb project. If other people
solved all the file system problems, it would not be too difficult to add
a special read-only on-disk structure to Rdb that could be generic across
all platforms and be held constant (or upward compatible) over time.
That is, you'd create a standard database and then run a utility which
converted it to this new interchange/archive format. The resulting files
would be burned into the CDROM. By the way, the Rdb on-disk structure is
identical for ALPHA and VAX (unlike ORACLE or other vendors) so you can
use the same database in a mixed architecture VMScluster. I don't know
if the Alpha OSF/1 and NT versions will use the same structure.
Hal
|