home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 262,974 of 264,096   
   =?UTF-8?Q?Arne_Vajh=C3=B8j?= to Craig A. Berry   
   Re: Oracle (Rdb) on OpenVMS   
   15 Aug 25 09:48:25   
   
   From: arne@vajhoej.dk   
      
   On 8/15/2025 8:50 AM, Craig A. Berry wrote:   
   > On 8/14/25 7:02 PM, Arne Vajhøj wrote:   
   >> On 8/14/2025 7:48 PM, Arne Vajhøj wrote:   
   >>> In another post I wrote:   
   >>> # Note that both Rdb team and VSI seems to have been   
   >>> # trying to build an alliance by pushing Oracle cloud   
   >>> # for Rdb and VMS in general.   
   >>> #   
   >>> # The competition OCI vs AWS vs Azure vs GCP is hard. And   
   >>> # anything giving more customers for Oracle cloud could   
   >>> # get at least some support from Oracle cloud team.   
   >>   
   >> OCI is practically the only choice for cloud if running Rdb   
   >> due to Oracle license policy.   
   >>   
   >> But even for non-Rdb customers then OCI would be first choice   
   >> if that is what VSI recommend and/or test first on.   
   >   
   > Which is kind of a death knell for Rdb on VMS and can only hurt the   
   > prospects of VMS more generally if someone tells VMS customers that   
   > Oracle Cloud is preferred over the other cloud vendors.  Last I checked,   
   > Oracle was a very distant fifth place among cloud vendors, with AWS   
   > having 10 times the market share that Oracle has.   
   >   
   > The whole point of the x86 port was to be able to run VMS on the same   
   > platform people were already using for all their other systems, which   
   > usually means KVM or VMWare in some mix of on-premises and in the cloud,   
   > with the folks wanting bare metal x86 already having to make other plans   
   > or run unsupported. You can get a VMWare instance in Azure, and AWS is   
   > now based on KVM; I don't know if anyone has successfully booted VMS on   
   > them, but that is the "hardware" that almost everyone already has these   
   > days.   
   >   
   > On a Venn diagram showing people already running Oracle cloud and people   
   > possibly interested in running VMS on x86, the overlap will be very   
   > small.  Add Rdb to the diagram and it may well be that the overlap   
   > consists of the 20 customers who have already replied to Oracle.   
      
   I believe I have seen a hobbyist report of VMS in AWS.   
      
   Yes:   
      
   https://aws.amazon.com/blogs/migration-and-modernization/deployi   
   g-openvms-x86-on-amazon-ec2/   
      
   For Rdb then this is not really Rdb specific.   
      
   Oracle license policy in general including Oracle DB (sometimes   
   called Oracle Classic in VMS circles) is that customers pay   
   per physical core with the exception that it is by VCPU if it is in   
   Oracle environment: KVM on Oracle Linux on-prem or in OCI. I believe   
   recently Oracle made some agreement with MS about Oracle DB in Azure,   
   so maybe that will work as well - those interested should talk to   
   their friendly Oracle sales person about that.   
      
   It has been like that for many many years.   
      
   For non-Rdb usage there are no license or technical reasons   
   to prefer OCI over  AWS, Azure or GCP.   
      
   But VSI are very friendly with Oracle at this time. Which   
   sort of make OCI a natural option for those VMS customers   
   just moving to cloud now.   
      
   A VMS customer that already have non-VMS workloads in   
   AWS/Azure/GCP, then it would make sense to move VMS to the   
   same vendor.   
      
   And nothing prevents that. And if the customer already have   
   both AWS/Azure/GCP expertise and VMS expertise - just not the   
   same resources, then no problem.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca