|
|
|
|
|
|
| Author |
Message |
Arne Vajhøj
*nix forums addict
Joined: 31 Jul 2005
Posts: 59
|
 Posted: Sun Oct 09, 2005 7:38 pm Post subject:
Re: looking for VMS/Fortran/Rdb/OSU job in northern Europe
|
|
|
vmsfortranrdbosu@gNOmSPAMx.nREMOVEeCAPITAL_LETTERSt wrote:
| Quote: | I have several years' experience with VMS, Fortran (77--95), Rdb and the
OSU HTTP server. I am currently employed at a permanent position where
I use some of these skills (and the others I keep polished elsewhere),
and at some time have been paid to use each of these skills (though not
always all at once).
I am looking for a similar job in Sweden, Norway, Denmark or the
Netherlands. Neither language nor residence/work permits are a problem.
I am looking for a permanent job, the plan being to move house once more
in my life. It doesn't matter much where in these countries the job is,
and travel as part of the job is not a problem.
What is the best way to look for such jobs, for obvious reasons
anonymously at first, in these countries? What fraction of such jobs
are advertised via, say, Monster? Is it worth checking with individual
companies? If so, which ones? What about contacting a headhunter
directly---does anyone have any experience with that and can anyone
recommend any good headhunters?
|
Denmark job sites:
http://www.jobworld.dk/
http://www.jobeasy.dk/
There are extremely few VMS jobs in Denmark today.
Maybe chances in Sweden
Arne |
|
| Back to top |
|
 |
Keith Cayemberg
*nix forums addict
Joined: 26 May 2005
Posts: 80
|
| Posted: Thu Jul 21, 2005 9:30 am Post subject:
Re: Moving Rdb RUJ and log files to alternate location other than SYS$SYSTEM
|
|
|
andrew.rycroft@intrinsitech.com wrote:
| Quote: | Hi,
Currently we are running Oracle/Rdb on OpenVMS. Rdb creates a lot of
RUJ and log files in SYS$SYSTEM. Is there a way to get Oracle Rdb to
create them on a different disk ? Is there a logical for this ?
Thank
Andrew
|
From the "Oracle Rdb7 Guide to Database Performance and Tuning"
(Copyright © 1984, 1996, Oracle Corporation.)
http://download-uk.oracle.com/otn_hosted_doc/rdb/pdf/dbpt.pdf
See especially Appendix A for a list of Rdb Logical Names.
-------------------------------
RDMS$RUJ and RDB_RUJ (from appendix A.97)
You can use the RDMS$RUJ logical name or the RDB_RUJ configuration
parameter to locate the .ruj file on a different disk and directory from
the default directory. This can help to reduce contention in that directory.
Include the RDB_RUJ configuration parameter in the configuration file to
specify the location you want to use, as shown in Example A–36.
Example A–36 Using the RDB_RUJ Configuration Parameter
RDB_RUJ /usr/clients/journal
¨
See Section 3.2.1.7 and Section 8.1.2 for more information.
.. . .
The following guidelines can help you decide where to place the database
files:
• Database root (.rdb), storage area (.rda), and snapshot (.snp) files
In a single-node environment, Oracle Rdb maps the root portion of the
database file, or root header, as a global section of memory. Because
VMScluster configurations do not allow memory to be shared between
nodes, Oracle Rdb in a VMScluster environment maintains copies of the
root header in a page-file section on each node that uses a database.
The root file itself remains on the disk where you created it.
Therefore, this disk must be accessible from all nodes in the VMScluster
system that will access the database. If the root file of a database is
not available to a node, that database cannot be used by that node.
The OpenVMS lock manager ensures that all root file copies are
identical. The root, storage area, and snapshot files must be accessible
from every node that intends to access the database. Oracle Rdb must be
able to create and maintain VMScluster distributed root file access.
• Recovery-unit journal (.ruj) files
Oracle Rdb must be able to complete its automatic recovery procedure
should a node fail. Recovery can complete only if all .ruj files are
accessible from every node that accesses the database. To ensure that
all .ruj files are accessible, follow these rules:
Define the RDMS$RUJ logical name in the system table to refer to a
common directory. Define the RDMS$RUJ logical name for each process to
refer to a common directory. If you permit .ruj files to reside on the
user’s default directory, that directory’s device must be on a
cluster-accessible disk.
• After-image journal (.aij) files
The .aij files must be accessible from every node that accesses the
database. This ensures that all processes that access the database will
be able to write to the .aij files.
To learn about reducing I/O contention in multiuser database access,
read Section 3.2 and Section 8.1.1, which describe disk I/O operations
and the corresponding effects on database performance. Placing the .aij
files on different devices than the database files is one way to
minimize I/O contention on the database disks.
.. . .
Example 6–8 Defining the RDMS$RUJ Logical Name for the Directory for the
..ruj Files
$ DEFINE/SYSTEM RDMS$RUJ RUJ_DISK:[PERS.RUJ]
If you plan to use a systemwide directory for your .ruj files, include
this command in your SYSTARTUP_V5.COM or SYSTARTUP_VMS.COM file.
Define this directory on a device other than the database files. You can
also use the default, SYS$LOGIN, to place .ruj files per process in each
user’s default directory. If you do not define the logical name,
RDMS$RUJ, to refer to a common directory, make sure that all database
users log in to accounts whose default directories are on
cluster-accessible disks.
--------------------------
ALSO...
RDM$BIND_ABS_LOG_FILE and RDB_BIND_ABS_LOG_FILE
You can use the RDM$BIND_ABS_LOG_FILE logical name or the RDB_
BIND_ABS_LOG_FILE configuration parameter to
-----------------------------
RDM$BUGCHECK_DIR and RDB_BUGCHECK_DIR
You can use the RDM$BUGCHECK_DIR logical name or the RDB_BUGCHECK_DIR
configuration parameter to redirect the location of bugcheck files from
the default directory to another location. This can be useful when the
default directory does not have enough space for bugcheck files.
On OpenVMS, when the bugcheck directory is defined, bugcheck dump files
are written to the device and directory pointed to by the
RDM$BUGCHECK_DIR logical name, rather than to the user’s top-level
directory, which is the default behavior on OpenVMS.
When users have reached their disk quotas in their default directory due
to a bugcheck dump, and if the RDM$BUGCHECK_DIR logical name or the
RDB_BUGCHECK_DIR configuration parameter is not specified to another
device, the bugcheck dump overflows to the KOD$TT file. In this case, a
DBR process is created with an output device of KOD$TT. Also, note that
bugcheck dump files are written to the system disk and if the system
disk becomes full, the overflow might also end up in KOD$TT. Generally,
nothing is written to KOD$TT and an examination of the KOD$TT file will
show that it is empty.
DBR bugcheck dump files by default are written to the SYS$SYSTEM
directory; however, when you define the RDM$BUGCHECK_DIR logical name,
DBR bugchecks will also be written to the new location specified by this
logical name. As with any file creation, the user must have read and
write access to the bugcheck directory for the bugcheck dump file to be
written successfully.
--------------------------
User Logfiles usually go to the directory defined in the logical
SYS$SCRATCH. This is by default the same as the SYS$LOGIN directory of
the user.
The variuos Rdb Manuals are available here...
http://www.oracle.com/technology/products/rdb/rdb_doc_index.html
Appendix E of the SQL Reference Manual provide Logical Names used by SQL.
Cheers!
Keith Cayemberg |
|
| Back to top |
|
|
Dr. Dweeb
*nix forums Guru Wannabe
Joined: 23 Jul 2005
Posts: 125
|
| Posted: Fri May 27, 2005 10:47 pm Post subject:
Re: New Cluster Interconnects
|
|
|
Dr. Dweeb wrote:
| Quote: | Keith Parris wrote:
Richard Maher wrote:
1) I saw 10 Gigabit NIC support scheduled for VMS 8.3 (Depending on
which slide you look at it says "Integrity Servers Only"). Now 10x
what a lot of people are using for a cluster-interconnect at the
moment sounds pretty s__t-hot to me! Especially if you're moving big
lock-trees around the cluster. Given that this functionality is less
than a year away, surely some performance figures or at least
anecdotal evidence should be available?
One way to estimate the impact is to see how Gigabit Ethernet
compared with Fast Ethernet. Bandwidth went up by close to 10x;
latency went from about 240 microseconds for a round-trip lock
conversion request with Fast Ethernet to about 200 microseconds on
Gigabit Ethernet, as measured on a typical Alpha box of the recent
past (Wildfire or ES40). So don't expect a 10x latency improvement.
I mean, if I was an Rdb engineer that had used p___-poor DLM
performance as the rationale for sticking all of my R&D eggs in the
stand-alone single-node basket, then I'd be interested in what's
happening with this. Right? "But it's not the bandwidth, it's the
latency that gets ya." Well that brings me to the next slide. . .
Rdb supports Row Cache in Galaxy Shared Memory between multiple
nodes.
2) Next Generation Low-Latency Interconnects Post 8.3 (Integrity
Servers Only)
Am I the only person getting their jollies out of this or what?
Nope. I also find this exciting.
Potential candidate technologies one would naturally want to look at
could include Infiniband and RDMA/iWARP.
Infiniband promises low latency, but hasn't really taken off much in
the industry yet, and hardware is expensive. Some initial proponents
have subsequently backed out (like Intel). A lot of people are
waiting to see how this turns out.
RDMA/iWARP looks to have broad potential industry support, and will
quite possibly be built into commodity Ethernet adapters. Latency
wouldn't be quite as low, but price would be low and
price/performance very good.
Should be interesting. In any case, I'm know VMS Engineering has its
finger on the pulse of the technologies available in the marketplace,
and will provide a quality solution with the best interests of the
customers in mind.
Will there be a special limit on the distances between nodes for
this stuff to work? (Like memory channel) Can you have a Disaster
Tolerant Low Latency Cluster?
Infiniband has some fairly low distance limitations, unless you
include an Infiniband router, and that's for IP traffic.
For anything Ethernet-based I don't expect distance limitations.
Other than how far you can drive light over fiber, there's no
inherent distance limit in Gigabit Ethernet today, for example. But
of course the longer your inter-site distance, the more delay there
is due to the speed of light over the distance, which mitigates
against low latency. ---
Indeed - it is the physical absolute barrier for comminucation of
data or energy over distance, something to do with instantaneous
causal events not being possible and all that (if I recall my physics
of relativity correctly) :-)
Dweeb.
|
But perhaps not http://homepage.sunrise.ch/homepage/schatzer/space-time.html
Dweeb.
| Quote: | Looks likely I'll be doing a hands-on workshop at HP Technology Forum
on Long-Distance OpenVMS Clusters. We'll explore some of the impacts
of long distances on performance in that workshop, for folks who are
interested. |
|
|
| Back to top |
|
|
Dr. Dweeb
*nix forums Guru Wannabe
Joined: 23 Jul 2005
Posts: 125
|
| Posted: Fri May 27, 2005 10:37 pm Post subject:
Re: New Cluster Interconnects
|
|
|
Keith Parris wrote:
| Quote: | Richard Maher wrote:
1) I saw 10 Gigabit NIC support scheduled for VMS 8.3 (Depending on
which slide you look at it says "Integrity Servers Only"). Now 10x
what a lot of people are using for a cluster-interconnect at the
moment sounds pretty s__t-hot to me! Especially if you're moving big
lock-trees around the cluster. Given that this functionality is less
than a year away, surely some performance figures or at least
anecdotal evidence should be available?
One way to estimate the impact is to see how Gigabit Ethernet compared
with Fast Ethernet. Bandwidth went up by close to 10x; latency went
from about 240 microseconds for a round-trip lock conversion request
with Fast Ethernet to about 200 microseconds on Gigabit Ethernet, as
measured on a typical Alpha box of the recent past (Wildfire or
ES40). So don't expect a 10x latency improvement.
I mean, if I was an Rdb engineer that had used p___-poor DLM
performance as the rationale for sticking all of my R&D eggs in the
stand-alone single-node basket, then I'd be interested in what's
happening with this. Right? "But it's not the bandwidth, it's the
latency that gets ya." Well that brings me to the next slide. . .
Rdb supports Row Cache in Galaxy Shared Memory between multiple nodes.
2) Next Generation Low-Latency Interconnects Post 8.3 (Integrity
Servers Only)
Am I the only person getting their jollies out of this or what?
Nope. I also find this exciting.
Potential candidate technologies one would naturally want to look at
could include Infiniband and RDMA/iWARP.
Infiniband promises low latency, but hasn't really taken off much in
the industry yet, and hardware is expensive. Some initial proponents
have subsequently backed out (like Intel). A lot of people are
waiting to see how this turns out.
RDMA/iWARP looks to have broad potential industry support, and will
quite possibly be built into commodity Ethernet adapters. Latency
wouldn't be quite as low, but price would be low and price/performance
very good.
Should be interesting. In any case, I'm know VMS Engineering has its
finger on the pulse of the technologies available in the marketplace,
and will provide a quality solution with the best interests of the
customers in mind.
Will there be a special limit on the distances between nodes for
this stuff to work? (Like memory channel) Can you have a Disaster
Tolerant Low Latency Cluster?
Infiniband has some fairly low distance limitations, unless you
include an Infiniband router, and that's for IP traffic.
For anything Ethernet-based I don't expect distance limitations. Other
than how far you can drive light over fiber, there's no inherent
distance limit in Gigabit Ethernet today, for example. But of course
the longer your inter-site distance, the more delay there is due to
the speed of light over the distance, which mitigates against low
latency. ---
|
Indeed - it is the physical absolute barrier for comminucation of data or
energy over distance, something to do with instantaneous causal events not
being possible and all that (if I recall my physics of relativity correctly)
:-)
Dweeb.
| Quote: | Looks likely I'll be doing a hands-on workshop at HP Technology Forum
on Long-Distance OpenVMS Clusters. We'll explore some of the impacts
of long distances on performance in that workshop, for folks who are
interested. |
|
|
| Back to top |
|
|
prep@prep.synonet.com
*nix forums Guru Wannabe
Joined: 28 Jul 2005
Posts: 190
|
| Posted: Fri May 27, 2005 7:56 pm Post subject:
Re: New Cluster Interconnects
|
|
|
"Bill" <bill@demsky.name> writes:
| Quote: | Low latency is where the performance appears to be, gig ethernet,
and maybe 10g ethernet have too much latency as you scale
|
Almost everyone I've talked to did not know that GBE over copper
runs 4 120Mbaud lines and has to do a line turnaround, unlike
fibre where it is a real full duplex circuit. With a lot of
small packets, throughput tanks and latency blows out.
--
Paul Repacholi 1 Crescent Rd.,
+61 (0 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be. |
|
| Back to top |
|
|
Rich Jordan
*nix forums beginner
Joined: 04 Jul 2005
Posts: 9
|
| Posted: Fri May 27, 2005 7:56 pm Post subject:
Re: New Cluster Interconnects
|
|
|
Richard Maher wrote:
| Quote: | Hi,
I was flicking through the OpenVMS Roadmap presentation yesterday and came
across a couple of very interesting (at least to me) milestones regarding
Cluster Interconnects. Now, I'm pretty useless with hardware, "the laws of
physics capt'n", and not much better as a System Manager so I hope someone
can offer me a lay-man's view of what these developments could mean for VMS
Cluster performance. (In particular the VMS Lock Manager.)
1) I saw 10 Gigabit NIC support scheduled for VMS 8.3 (Depending on which
slide you look at it says "Integrity Servers Only"). Now 10x what a lot of
people are using for a cluster-interconnect at the moment sounds pretty
s**t-hot to me! .
.. |
..
..
| Quote: |
2) Next Generation Low-Latency Interconnects Post 8.3 (Integrity Servers
Only)
.. |
..
..
| Quote: | Am I the only person getting their jollies out of this or what?
Regards Richard (Just off to have a cold shower) Maher
|
I'd be a lot more excited if they weren't artifically limiting it to the
intel based servers. It'll be a long time before those capabilities 'on
integrity' matter to us or any of our customers.
Still, its good news for the long run. |
|
| Back to top |
|
|
Bill
*nix forums Guru Wannabe
Joined: 22 Feb 2005
Posts: 116
|
| Posted: Fri May 27, 2005 7:56 pm Post subject:
Re: New Cluster Interconnects
|
|
|
Low latency is where the performance appears to be, gig ethernet, and maybe
10g ethernet have too much latency as you scale
"Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message
news:d6neb1$rds$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
| Quote: | Hi,
I was flicking through the OpenVMS Roadmap presentation yesterday and came
across a couple of very interesting (at least to me) milestones regarding
Cluster Interconnects. Now, I'm pretty useless with hardware, "the laws of
physics capt'n", and not much better as a System Manager so I hope someone
can offer me a lay-man's view of what these developments could mean for
VMS
Cluster performance. (In particular the VMS Lock Manager.)
1) I saw 10 Gigabit NIC support scheduled for VMS 8.3 (Depending on which
slide you look at it says "Integrity Servers Only"). Now 10x what a lot of
people are using for a cluster-interconnect at the moment sounds pretty
s**t-hot to me! Especially if you're moving big lock-trees around the
cluster. Given that this functionality is less than a year away, surely
some
performance figures or at least anecdotal evidence should be available? I
mean, if I was an Rdb engineer that had used piss-poor DLM performance as
the rationale for sticking all of my R&D eggs in the stand-alone
single-node
basket, then I'd be interested in what's happening with this. Right? "But
it's not the bandwidth, it's the latency that gets ya." Well that brings
me
to the next slide. . .
2) Next Generation Low-Latency Interconnects Post 8.3 (Integrity Servers
Only)
Am I the only person getting their jollies out of this or what?
I forget when Oracle10g was scheduled to arrive but I'd dearly love to
hear
from anyone using Cache Fusion and is looking at this!
Will there be a special limit on the distances between nodes for this
stuff
to work? (Like memory channel) Can you have a Disaster Tolerant Low
Latency
Cluster?
Regards Richard (Just off to have a cold shower) Maher
|
|
|
| Back to top |
|
|
Richard Maher
*nix forums Guru Wannabe
Joined: 15 Jun 2005
Posts: 275
|
| Posted: Fri May 27, 2005 7:56 pm Post subject:
Re: Dec RDB V6.1-14 under VMS 6.2
|
|
|
Hi,
What's the big deal? Surely with those outdated versions and no support
contract, this system can't be doing anything important. Can it? What does
Nightspeed do? Do they have any customers or shareholders that read this
group :-(
Ok, sorry to be a pain and now I'll try to help. But it just drives me nuts
how many other companies out there just like yours (and some of them are
VERY big and profitable) are too cheap to supply the resource levels
required. (And the number of Rdb bodies out on the street.) Insurance eh,
who needs it?
Anyway, you say nothing's changed so without much information to go on, I'll
offer two guesses FWTW
1) You've started to get a lot of deadlocks (any other errors logged to user
screens etc?) maybe a sorted index is looking a bit crappy after years of
neglect. If your error-handling code is rolling back the transaction so as
to recover from the deadlock then maybe the code is incorrectly proceeding
to the otherwise legitimate commit/rollback.
2) Some part of the database has grown and the number of rows has led to an
internal array blowing up and if your transaction handles are in memory
after the array. Is the system written in Pascal, RDML, RDO? Do you declare
your own transaction handles? Sadly, I have seen production systems where
people simply ignore this error  Often, they're using a specific database
handle in one module but accepting the default rdb$dbhandle in the other.
Then they say "That module does what we want let's call that" and they end
up with two attaches to the database each with it's own transaction context.
So a transaction could be started in one attach and you're trying to commit
it in another. Are you using SQL Connections?
Any more information? How many times does RMU say each user is attached to
the database? Is it only one specific module/option?
Regards Richard Maher
"NightspeedIT" <derek.cowdrey@nightspeed.com> wrote in message
news:1116430491.529600.205410@f14g2000cwb.googlegroups.com...
| Quote: | HELP!!!
I am the technical support person for Nightspeed Services Ltd in
Tipton, UK.
We have been using RDB V6.1-14 under VMS 6.2 for several years with a
major hitch but suddenly, two days ago we started to get large numbers
of...
%RDB-E-BAD_TRANS_HANDL, invalid transaction handle
... errors. There have been no changes made to the system as far as I
am aware.
I have very scant knowledge of RDB internals and Oracle don't seem to
interested in helping me (I know we don't have a support contract but I
did offer to pay to speak to someone on the phone!)
Is there anyone out there who might be able to help?
Thanks
Derek Cowdrey
|
|
|
| Back to top |
|
|
Keith Cayemberg
*nix forums addict
Joined: 26 May 2005
Posts: 80
|
| Posted: Fri May 27, 2005 7:56 pm Post subject:
Re: Dec RDB V6.1-14 under VMS 6.2
|
|
|
NightspeedIT wrote:
| Quote: | HELP!!!
I am the technical support person for Nightspeed Services Ltd in
Tipton, UK.
We have been using RDB V6.1-14 under VMS 6.2 for several years with a
major hitch but suddenly, two days ago we started to get large numbers
of...
%RDB-E-BAD_TRANS_HANDL, invalid transaction handle
.... errors. There have been no changes made to the system as far as I
am aware.
I have very scant knowledge of RDB internals and Oracle don't seem to
interested in helping me (I know we don't have a support contract but I
did offer to pay to speak to someone on the phone!)
Is there anyone out there who might be able to help?
Thanks
Derek Cowdrey
|
Hi Derek,
That is still not much information to go on for an analysis. This error
is usually preceded by another error message indicating the real cause
of the problem. The transaction handle error means that the transaction
context has (for some reason) been lost or not correctly established
before attempting to perform an operation requiring that transaction
context. Here is the documentation for this error message...
-------
BAD_TRANS_HANDLE, invalid transaction handle
Explanation: You may have attempted a commit or rollback operation
when no transaction is active. For example, your
program may execute the same set of actions to handle
all fatal errors. If those actions include a rollback
operation, the rollback operation will generate the
BAD_TRANS_HANDLE error after a fatal error occurs on
database attachment or on an attempt to start a
transaction. The BAD_TRANS_HANDLE error occurs because
you cannot end a transaction when no transaction has
been started.
(RCI and RDML users) If you declared a variable as an
explicit transaction handle, you: a) may not have set
the variable to zero before starting the transaction or
b) may have modified the variable after it was set by
the database system.
User Action: Do not execute commit or rollback operations when a
transaction is not active. Alternatively, you may
choose to specifically check for this error after
execution of commit and rollback operations, and branch
to program recovery actions when appropriate.
(RCI and RDML users) If you explicitly declared a
transaction handle variable in your program, set the
variable to zero before referring to it. Make sure
that your program does not write to this variable after
initializing its value.
------------
Maybe you could describe more what was being done, and how, at the time
of the error? Where do you see the error (application screen or log
file)? What tools or languages are being used by the application? You
should probably check for dump or log files at the application
directory, the user directory, the user's SYS$SCRATCH directory or at
the directory pointed to by the logical RDM$BUGCHECK_DIR.
Eventually, a successful analysis may require a qualified person with
access to the code and a system that is producing the error.
I think (especially if you were offering money) you were probably
talking to the wrong people at Oracle. I would suggest contacting one of
the persons listed at the following web page...
http://www.oracle.com/technology/products/rdb/Contacts/index.html
Ingrid Klein should be able to help you get in contact with a qualified
person in Oracle Support.
There are also several Rdb Consultants worldwide who would be happy to
have your business...
achi Informatik Dienstleistungen - Switzerland
http://www.achi.ch/
ACS - operations in nearly 100 countries worldwide
http://www.acs-inc.com/
ALI/Empirical Software - USA
http://www.aliconsultants.com/
Bethinda - Netherlands
http://www.bethinda.nl/en/index.html
BIOS Software GmbH - Germany
http://www.bios-software.de/bios/index.htm
Colin Sewell OpenVMS Consulting Services - Canada
http://www3.telus.net/csewell/
Contemporary Technologies - USA
http://www.contemptech.com/
DCU - Data Collections Unlimited, Inc. - USA
http://www.dcu-inc.com/
Equicon - Germany
http://www.equicon.de/
Evenlogic, Software House, South West London, England
http://www.evenlogic.co.uk/index.html
First DBA Source, Inc. - USA
http://www.firstdbasource.com/
GAP - UK
http://www.gap.co.uk/
http://www.gap.co.uk/oracle_RDB.html
ITurnITy Information Group - Netherlands
http://www.iturnity.com/index_uk.htm
JCC Consulting, Inc. - USA
http://www.jcc.com/
Keane, Inc. - India Subsidiary
http://www.keane.com/about/worldwide/country.php?state=II&country=India
M Squared Consulting, Inc. - USA - ALL-IN-1, TeamLinks, Linkworks,
Pathworks, Rdb - Partner Brief
http://www.openvms.compaq.com/partners/m-squared/index.htm
MainTrend Ltd. - USA and Canada
http://www.maintrend.net/
Meyering Software Productions b.v. - Netherlands
http://www.mspbv.nl/msp_index.htm
Praxa Ltd - Australia
http://www.praxa.com.au/
RKS - Sweden
http://www.rks.se
Salem Automation - USA and Puerto Rico
http://www.winvms.com/about.html
SCI - USA
http://www.sciinc.com/
SEKA-Service-Programing - Germany
http://www.seka.de/e/service/Programing.htm#Programmierung
SIT System- und Informations-Technik GmbH - Germany
http://www.sit-germany.de/indexen.html
Softax - Poland
http://www.softax.pl
STI - Soluções em Tecnologia da Informação - Brazil
http://www.stinfo.com.br/
TE&PJ Contractors - New Zealand
http://www.jerrom.co.nz/
VX Company - Netherlands
http://www.vxcompany.nl/
Yartoo Software - Australia
http://www.yartoo.com.au/
There are probably many others which I don't have listed.
You may also consider joining the JCC Rdb Listserver discussion and
informal support group. Instruction for joining are at...
http://www.jcc.com/listserver.htm
Cheers!
Keith Cayemberg |
|
| Back to top |
|
|
Richard Maher
*nix forums Guru Wannabe
Joined: 15 Jun 2005
Posts: 275
|
| Posted: Fri May 27, 2005 7:56 pm Post subject:
(VMS Rdb COBOL example) Was: Re: Dynamic SQL
|
|
|
Hi,
Didn't see the original post, but I was just looking at the following code
on an old floppy of mine as I was cleaning up my office after holidays.
FWIW
Cheers Richard Maher
PS. Obviously replace all the "#" with a space and sorry about the wrapping.
(After 20 odd years in I.T. I am simply incapable of stopping that from
happening. Or can't be arsed to find out how :-)
PPS. If you want to run multiple table scrambles in parralel then you'll
have to change the BATCH UPDATE transaction. But the performance is so
blisteringly fast I honestly wouldn't bother.
identification#division.
program-id.####dyn_test.
*
data#division.
working-storage#section.
01##rdb$_stream_eof#####################pic#9(9)########comp####value###exte
rnal####rdb$_stream_eof.
01##lib$_strtru#########################pic#9(9)########comp####value###exte
rnal####lib$_strtru.
01##ss$_abort###########################pic#9(9)########comp####value###exte
rnal####ss$_abort.
01##ss$_normal##########################pic#9(9)########comp####value###exte
rnal####ss$_normal.
01##sys_status##########################pic#9(9)########comp.
*
01##sqlcode#############################pic#9(9)########comp.
01##rdb$message_vector##########################################external.
####03#rdb$lu_num_arguments#############pic#9(9)########comp.
####03#rdb$lu_status####################pic#9(9)########comp.
####03#rdb$alu_arguments################################occurs#18#times.
########05#rdb$lu_arguments#############pic#9(9)########comp.
*
01##col_name############################pic#x(39).
01##col_count###########################pic#9(9)########comp.
*
01##cmd_string##########################pic#x(10000).
*
01##set_trans_statement.
####03##################################pic#x(39)###############value###"set
#transaction#batch#update#reserving".
####03##trans_table#####################pic#x(39).
####03##################################pic#x(21)###############value###"#fo
r#exclusive#write;".
*
01##select_statement.
####03##################################pic#x(7)################value###"sel
ect".
####03##select_list.
######04##select_array##################################occurs##256#times.
########05##select_col##################pic#x(30).
########05##select_delim################pic#x(1).
####03##################################pic#x(5)################value###"fro
m".
####03##select_table####################pic#x(39).
####03##################################pic#x(1)################value###";".
*
01##update_id###########################pic#9(9)########comp.
01##update_statement.
####03##################################pic#x(7)################value###"upd
ate".
####03##update_table####################pic#x(39).
####03##################################pic#x(5)################value###"#se
t".
####03##update_list.
######04##update_array##################################occurs##256#times.
########05##update_col##################pic#x(30).
########05##update_delim################pic#x(5).
####03##################################pic#x(22)###############value###"#wh
ere#current#of#sel;".
*
01##col_prefix_table.
####03##col_elem########################################occurs##256#times.
########05##col_prefix##################pic#x(39).
########05##col_prefix_len##############pic#9(4)########comp.
*
01##col_pfx#############################pic#x(39).
*
01##sqlda_char##########################pic#9(4)########comp####value###453.
01##sqlda_integer#######################pic#9(4)########comp####value###497.
01##sqlda_quadword######################pic#9(4)########comp####value###505.
*
01##sqlda_list.
####03##sqldaid#########################pic#x(################value###"SQL
DA".
####03##sqldabc#########################pic#9(9)########comp.
####03##sqln############################pic#9(4)########comp####value###256.
####03##sqld############################pic#9(4)########comp.
####03##sqlname_rec#####################################occurs##0#to####256#
########################################################depending#on#sqln#of
#sqlda_list.
########05##sqltype#####################pic#9(4)########comp.
########05##sqllen######################pic#9(4)########comp.
########05##sqldata#####################################pointer.
########05##sqlind######################################pointer.
########05##sqlname.
############07##name_len################pic#9(4)########comp.
############07##name_str################pic#x(30).
*
01##sqlda_update.
####03##sqldaid#########################pic#x(################value###"SQL
DA".
####03##sqldabc#########################pic#9(9)########comp.
####03##sqln############################pic#9(4)########comp####value###256.
####03##sqld############################pic#9(4)########comp.
####03##sqlname_rec#####################################occurs##0#to####256#
########################################################depending#on#sqln#of
#sqlda_update.
########05##sqltype#####################pic#9(4)########comp.
########05##sqllen######################pic#9(4)########comp.
########05##sqldata#####################################pointer.
########05##sqlind######################################pointer.
########05##sqlname.
############07##name_len################pic#9(4)########comp.
############07##name_str################pic#x(30).
*
01##col_desc.
####03##col_len#########################pic#9(9)########comp.
####03##col_addr########################################pointer.
*
01##scramble_eof########################pic#x(1).
01##unique_char#########################pic#x(65535).
01##unique_integer######################pic#s9(9)#######comp.
01##unique_quadword#####################pic#s9(1######comp.
01##scramble_field######################pic#x(65535).
01##scramble_desc.
####03##scramble_desc_len###############pic#9(9)########comp.
####03##################################################pointer#value###refe
rence#scramble_field.
*
01##unique_id_string####################pic#x(65535).
01##unique_id_integer###################################redefines
####unique_id_string####################pic#-9(9).
01##unique_id_quadword##################################redefines
####unique_id_string####################pic#-9(1.
01##unique_id_len#######################pic#9(4)########comp.
*
01##null_indicators.
####03##null_ind########################pic#s9(4)#######comp
########################################################occurs##256#times.
*
01##task_id#############################pic#x(39)###############value###"TES
T_TABLE".
01##relation_prefix#####################pic#x(39).
01##relation_prefix_len#################pic#9(4)########comp.
01##unique_id###########################pic#x(39).
01##vm_bytes############################pic#9(9)########comp.
*
procedure#division.
kick_off#section.
00.
####perform#get_setup.
####move#set_trans_statement#to#cmd_string.
####call#"sql_execute_immediate"#using#sqlcode,#cmd_string.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####call#"sql_prepare_select"
########using###sqlcode,
################select_statement.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####call#"sql_describe_select"
########using###sqlcode,
################sqlda_list.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####display#"Number#of#columns#in#select#list#is#",#sqld#of#sqlda_list#with#
conversion.
####perform#varying#sqln#of#sqlda_list#from#1#by#1#until#sqln#of#sqlda_list#
=#sqld#of#sqlda_list
########if#sqltype#of#sqlda_list#(sqln#of#sqlda_list)#not#=#sqlda_char
############display#"Can#only#handle#CHAR#datatypes#",#sqltype#of#sqlda_list
#(sqln#of#sqlda_list)#with#conversion
############call#"lib$stop"#using#by#value#ss$_abort
########end-if
########move#sqllen#of#sqlda_list#(sqln#of#sqlda_list)#to#vm_bytes
########call#"lib$get_vm"#using#vm_bytes,#sqldata#of#sqlda_list#(sqln#of#sql
da_list)#giving#sys_status
########if#sys_status#not#=#ss$_normal#
############call#"lib$stop"#using#by#value#sys_status
########end-if
########set#sqlind#of#sqlda_list(sqln#of#sqlda_list)#to#reference#null_ind(s
qln#of#sqlda_list)
####end-perform.
####evaluate####sqltype#of#sqlda_list(sqln#of#sqlda_list)
########when####sqlda_char######set#sqldata#of#sqlda_list(sqln#of#sqlda_list
)#to#reference#unique_char
########when####sqlda_integer###set#sqldata#of#sqlda_list(sqln#of#sqlda_list
)#to#reference#unique_integer
########when####sqlda_quadword##set#sqldata#of#sqlda_list(sqln#of#sqlda_list
)#to#reference#unique_quadword
########when####other###########call#"lib$stop"#using#by#value#sys_status
####end-evaluate.
####move#sqlda_list#to#sqlda_update.
####subtract#1#from#####sqln#of#sqlda_update,
########################sqld#of#sqlda_update.
####call#"sql_prepare_update"
########using###sqlcode,
################update_id,
################update_statement.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####call#"sql_open_sel"#using#sqlcode.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####move#"N"#to#scramble_eof
####call#"sql_fetch_sel"#using#sqlcode,#sqlda_list.
####evaluate####rdb$lu_status
########when####rdb$_stream_eof#move#"Y"#to#scramble_eof
########when####ss$_normal######continue
########when####other###########call#"sys$putmsg"#using#rdb$message_vector#g
iving#sys_status
################################call#"lib$stop"#using#by#value#ss$_abort
####end-evaluate.
####perform#scramble_data#until#scramble_eof#=#"Y".
####call#"sql_close_sel"#using#sqlcode.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####call#"sql_commit_db"#using#sqlcode.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
*
*
fini.
####stop#run.
*
get_setup#section.
00.
####call#"sql_task_tran"#using#sqlcode.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####move#task_id#to#####trans_table,
########################select_table,
########################update_table.
####call#"sql_get_scramble"
########using###sqlcode,
################relation_prefix,
################unique_id,
################task_id.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####call#"str$trim"
########using###by#descriptor###relation_prefix,#relation_prefix
################by#reference####relation_prefix_len
########giving##sys_status.
####if#sys_status#not#=#ss$_normal#call#"lib$stop"#using#by#value#sys_status
..
####call#"sql_open_enigma"#
########using###sqlcode,
################task_id.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####move#spaces#to######select_list,
########################update_list.
####move#zeros#to#col_count.
####call#"sql_fetch_enigma"
########using###sqlcode,
################col_name,
################col_pfx.
####perform#until#rdb$lu_status#not#=#ss$_normal
########add#1#to#col_count
########move#col_pfx##to########col_prefix(col_count)
########move#col_name#to########select_col(col_count)
################################update_col(col_count)
########call#"str$trim"
############using##by#descriptor#col_prefix(col_count),#col_prefix(col_count
)
###################by#reference##col_prefix_len(col_count)
############giving#sys_status
########if#sys_status#not#=#ss$_normal#
############call#"lib$stop"#using#by#value#sys_status
########end-if
########move#","#to#select_delim(col_count)
########move#"#=#?,"#to#update_delim(col_count)
########call#"sql_fetch_enigma"
############using#######sqlcode,
########################col_name,
########################col_pfx
####end-perform.
####if#rdb$lu_status#not#=#rdb$_stream_eof
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####if#col_count#=#zeros
########display#"No#columns#to#update#for#",#task_id
########call#"lib$stop"#using#by#value#ss$_abort.
####move#space#to#update_delim(col_count)(5:1).
####add#1#to#col_count.
####move#unique_id#to#select_col(col_count).
####call#"sql_close_enigma"#using#sqlcode.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
####call#"sql_commit_db"#using#sqlcode.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
*
scramble_data#section.
00.
####move#spaces#to#unique_id_string.
####evaluate####sqltype#of#sqlda_list(sqln#of#sqlda_list)
########when####sqlda_char######call#"str$trim"
####################################using#######by#descriptor###unique_char,
#unique_id_string
################################################by#reference####unique_id_le
n
####################################giving######sys_status
################################if#sys_status#not#=#ss$_normal#
####################################call#"lib$stop"#using#by#value#sys_statu
s
################################end-if
########when####sqlda_integer###move#unique_integer#to#unique_id_integer
################################move#10#to#unique_id_len
########when####sqlda_quadword##move#unique_quadword#to#unique_id_quadword
################################move#19#to#unique_id_len
####end-evaluate.
####perform#varying#sqln#of#sqlda_update#from#1#by#1#until#sqln#of#sqlda_upd
ate#>#sqld#of#sqlda_update
########move#spaces#to#scramble_field
########string##relation_prefix(1:relation_prefix_len),
################col_prefix(sqln#of#sqlda_update)(1:col_prefix_len(sqln#of#sq
lda_update)),
################unique_id_string(1:unique_id_len)
################delimited#by#size
########into####scramble_field
########add#####relation_prefix_len,
################col_prefix_len(sqln#of#sqlda_update),
################unique_id_len
########giving##scramble_desc_len
########move#sqllen##of#sqlda_update#(sqln#of#sqlda_update)#to#col_len
########move#sqldata#of#sqlda_update#(sqln#of#sqlda_update)#to#col_addr
########call#"lib$scopy_dxdx"#using#scramble_desc,#col_desc#giving#sys_statu
s
########if#sys_status#not#=#ss$_normal#and#lib$_strtru
############call#"lib$stop"#using#by#value#sys_status
########end-if
####end-perform.
####move#sqld#of#sqlda_update#to#sqln#of#sqlda_update.
####call#"sql_execute_stmt"
########using###sqlcode,
################sqlda_update,
################update_id.
####if#rdb$lu_status#not#=#ss$_normal
########call#"sys$putmsg"#using#rdb$message_vector#giving#sys_status
########call#"lib$stop"#using#by#value#ss$_abort.
*
fini.
####call#"sql_fetch_sel"#using#sqlcode,#sqlda_list.
####evaluate####rdb$lu_status
########when####rdb$_stream_eof#move#"Y"#to#scramble_eof
########when####ss$_normal######continue
########when####other###########call#"sys$putmsg"#using#rdb$message_vector#g
iving#sys_status
################################call#"lib$stop"#using#by#value#ss$_abort
####end-evaluate.
*
end#program#dyn_test.
module####dyn_sql
language##cobol
authorization#scram_db
parameter#colons
declare#external#scram_db#alias#filename#scram_db
declare#sel#cursor#for#sel_stmt
declare#enigma#cursor#for
########select#
################a.field_name,
################a.field_prefix
########from
################scramble_relation_fields#a
########where
################a.relation_name#=#:task_id
procedure#sql_task_tran
########sqlcode
########;
########set#transaction#read#write#reserving
################scramble_relation###############for#shared#write,
################scramble_relation_fields########for#shared#read;
procedure#sql_get_scramble
########sqlcode,
########:relation_prefix########char(39),
########:unique_id##############char(39),
########:task_id################char(39)
########;
########select
################a.relation_prefix,
################a.unique_id
########into
################:relation_prefix,
################:unique_id
########from#
################scramble_relation#a
########where
################a.relation_name#=#:task_id
########;
procedure#sql_open_enigma
########sqlcode,
########:task_id################char(39)
########;
########open#enigma;
procedure#sql_fetch_enigma
########sqlcode,
########:field_name#############char(39),
########:field_prefix###########char(39)
########;
########fetch
################enigma
########into
################:field_name,
################:field_prefix
########;
procedure#sql_close_enigma
########sqlcode
########;
########close#enigma;
procedure#sql_prepare_select
########sqlcode,
########:stmt###################char(7988)
########;
########prepare#sel_stmt#from#:stmt;
procedure#sql_describe_select
########sqlca,
########sqlda;
########describe#sel_stmt#select#list#into#sqlda;
procedure#sql_open_sel
########sqlca;
########open#sel;
procedure#sql_fetch_sel
########sqlca,
########sqlda;
########fetch#sel#using#descriptor#sqlda;
procedure#sql_close_sel
########sqlca;
########close#sel;
procedure#sql_release_stmt
########sqlca;
########release#sel_stmt;#
procedure#sql_prepare_update
########sqlcode,
########:update_id##############integer,
########:stmt###################char(9033)
########;
########prepare#:update_id#from#:stmt;
procedure#sql_execute_stmt
########sqlcode,
########:sqlda##################sqlda,
########:dyn_stmt_id############integer
########;
########execute#:dyn_stmt_id#using#descriptor#:sqlda;
procedure#sql_commit_db
########sqlcode;
########commit;
procedure#sql_execute_immediate
########sqlcode,
########:cmd_string#############char(10000)
########;
########execute#immediate#:cmd_string;
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:aqV8e.317613$za2.50898@news.easynews.com...
| Quote: | the E-level message says that "WS-SQL" is not of "type" VARCHAR.
See:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dsnaph13/2.4.3.7
for how to define a VARCHAR host variable (in COBOL - at least for IBM
mainframes and DB2), e.g.
01 VAR-NAME.
49 VAR-LEN PIC S9(4) USAGE BINARY.
49 VAR-TEXT PIC X(n).
Use of level "49" is required (as I recall) and you MUST have a binary
field
followed by the actual "data" portion.
--
Bill Klein
wmklein <at> ix.netcom.com
"kathie" <kktbva@yahoo.com> wrote in message
news:1113852104.333988.160920@f14g2000cwb.googlegroups.com...
Hi,
I'm struggling with a dynamic sql execution within my cobol program. I
keep getting these errors:
DSNH084I W DSNHLEXC LINE 831 COL 22 UNACCEPTABLE SQL STATEMENT
DSNH084I W DSNHLEXC LINE 833 COL 22 UNACCEPTABLE SQL STATEMENT
DSNH080I E DSNHSM3D LINE 2049 COL 37 STRING VARIABLE "WS-SQL" IS
NOT "VARCHAR" TYPE
PREPARE SQLSTMT FROM:WS-SQL
Here is what I have:
....
WORKING-STORAGE SECTION.
01 WS-SQL PIC X(400) VALUE SPACES.
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 SQLSTMT PIC X(400).
EXEC SQL END DECLARE SECTION END-EXEC.
.....
PROCEDURE DIVISION.
.....
IF condition1
create sql statement1 and STRING to ws-sql
ELSE
create sql statement2 and STRING to ws-sql
END-IF.
MOVE WS-SQL TO SQLSTMT.
EXEC SQL
PREPARE SQLSTMT FROM :WS-SQL
END-EXEC.
EXEC SQL
DECLARE ATTCUR CURSOR FOR SQLSTMT
END-EXEC.
EXEC SQL
OPEN ATTCUR
END-EXEC.
Could someone shed me some lights?
Thanks,
Kathie
|
|
|
| Back to top |
|
|
mickelsen-xuan@duskmail.c
*nix forums beginner
Joined: 27 May 2005
Posts: 1
|
|
| Back to top |
|
|
Keith Parris
*nix forums Guru Wannabe
Joined: 21 Jul 2005
Posts: 145
|
| Posted: Fri May 27, 2005 7:56 pm Post subject:
Re: New Cluster Interconnects
|
|
|
Richard Maher wrote:
| Quote: | 1) I saw 10 Gigabit NIC support scheduled for VMS 8.3 (Depending on which
slide you look at it says "Integrity Servers Only"). Now 10x what a lot of
people are using for a cluster-interconnect at the moment sounds pretty
s__t-hot to me! Especially if you're moving big lock-trees around the
cluster. Given that this functionality is less than a year away, surely some
performance figures or at least anecdotal evidence should be available?
|
One way to estimate the impact is to see how Gigabit Ethernet compared
with Fast Ethernet. Bandwidth went up by close to 10x; latency went from
about 240 microseconds for a round-trip lock conversion request with
Fast Ethernet to about 200 microseconds on Gigabit Ethernet, as measured
on a typical Alpha box of the recent past (Wildfire or ES40). So don't
expect a 10x latency improvement.
| Quote: | I mean, if I was an Rdb engineer that had used p___-poor DLM performance as
the rationale for sticking all of my R&D eggs in the stand-alone single-node
basket, then I'd be interested in what's happening with this. Right? "But
it's not the bandwidth, it's the latency that gets ya." Well that brings me
to the next slide. . .
|
Rdb supports Row Cache in Galaxy Shared Memory between multiple nodes.
| Quote: | 2) Next Generation Low-Latency Interconnects Post 8.3 (Integrity Servers
Only)
Am I the only person getting their jollies out of this or what?
|
Nope. I also find this exciting.
Potential candidate technologies one would naturally want to look at
could include Infiniband and RDMA/iWARP.
Infiniband promises low latency, but hasn't really taken off much in the
industry yet, and hardware is expensive. Some initial proponents have
subsequently backed out (like Intel). A lot of people are waiting to see
how this turns out.
RDMA/iWARP looks to have broad potential industry support, and will
quite possibly be built into commodity Ethernet adapters. Latency
wouldn't be quite as low, but price would be low and price/performance
very good.
Should be interesting. In any case, I'm know VMS Engineering has its
finger on the pulse of the technologies available in the marketplace,
and will provide a quality solution with the best interests of the
customers in mind.
| Quote: | Will there be a special limit on the distances between nodes for this stuff
to work? (Like memory channel) Can you have a Disaster Tolerant Low Latency
Cluster?
|
Infiniband has some fairly low distance limitations, unless you include
an Infiniband router, and that's for IP traffic.
For anything Ethernet-based I don't expect distance limitations. Other
than how far you can drive light over fiber, there's no inherent
distance limit in Gigabit Ethernet today, for example. But of course the
longer your inter-site distance, the more delay there is due to the
speed of light over the distance, which mitigates against low latency.
---
Looks likely I'll be doing a hands-on workshop at HP Technology Forum on
Long-Distance OpenVMS Clusters. We'll explore some of the impacts of
long distances on performance in that workshop, for folks who are
interested. |
|
| Back to top |
|
|
server
*nix forums addict
Joined: 19 Feb 2005
Posts: 60
|
| Posted: Fri May 27, 2005 7:56 pm Post subject:
New Cluster Interconnects
|
|
|
|
message unavailable |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 5:20 am | All times are GMT
|
|
Loans | Internet Advertising | Buy Anything On eBay | Verizon Ringtones | Mortgages
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Databases
»
rdb
