Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.vms > #58112 > unrolled thread
| Started by | "Paul Richards" <paulrichards@iinet.net.au> |
|---|---|
| First post | 2016-06-08 18:18 -0500 |
| Last post | 2016-06-10 08:26 -0500 |
| Articles | 20 on this page of 150 — 23 participants |
Back to article view | Back to comp.os.vms
Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 18:18 -0500
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-08 19:39 -0400
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 20:28 -0500
Re: Where to locate software "Bill Pedersen" <pedersen@ccsscorp.com> - 2016-06-08 19:40 -0400
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 20:30 -0500
Re: Where to locate software "Bill Pedersen" <pedersen@ccsscorp.com> - 2016-06-08 22:24 -0400
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 22:57 -0500
Re: Where to locate software Steven Schweda <sms.antinode@gmail.com> - 2016-06-08 17:02 -0700
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-08 20:31 -0500
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-08 21:53 -0700
Re: Where to locate software Steven Schweda <sms.antinode@gmail.com> - 2016-06-08 22:19 -0700
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-09 02:47 -0700
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-09 13:39 -0700
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 08:42 -0400
Re: Where to locate software Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-09 14:58 +0200
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 10:27 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 11:33 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 11:43 -0400
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-09 09:19 -0700
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 13:13 -0400
Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-09 18:58 +0000
Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-09 18:59 +0000
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 22:01 -0400
Re: VMS FAQ (was Re: Where to locate software) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 10:58 -0400
Re: VMS FAQ (was Re: Where to locate software) Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-10 16:50 +0000
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-09 13:28 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 22:06 -0400
Re: Where to locate software VAXman- @SendSpamHere.ORG - 2016-06-09 13:58 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 11:16 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-09 14:46 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 12:43 -0400
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-09 13:50 -0700
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 22:20 -0400
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 11:11 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-10 11:56 -0400
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-10 10:19 -0700
Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-10 18:03 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 15:59 -0400
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 09:02 -0400
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-13 16:34 +0200
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-10 16:53 -0400
Re: Where to locate software Hans Vlems <hvlems@freenet.de> - 2016-06-11 00:27 -0700
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-11 01:37 -0700
Re: Where to locate software Hans Vlems <hvlems@freenet.de> - 2016-06-11 03:21 -0700
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:02 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:27 -0400
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 09:05 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-10 16:13 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 15:50 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-10 20:54 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-10 17:47 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-11 01:59 +0000
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-10 19:13 -0700
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-11 03:01 +0000
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-10 22:47 -0700
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-11 12:45 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-11 15:02 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 02:07 +0000
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:05 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 04:17 +0000
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-11 03:09 +0000
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-10 23:39 -0400
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-10 22:44 -0700
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-11 01:42 -0700
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-11 18:25 -0700
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-11 11:15 +0200
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-11 13:44 -0400
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-11 11:54 -0700
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-11 15:23 -0400
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-11 18:28 -0700
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:38 -0400
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-12 00:59 -0700
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 14:09 +0000
devops / source control - (Was: Where to locate software) "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-12 10:43 -0500
Re: devops / source control - (Was: Where to locate software) "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-12 11:08 -0500
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-12 12:53 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 17:31 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-12 15:23 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 20:28 +0000
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-12 17:49 -0700
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-13 13:02 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-13 09:40 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-13 14:33 +0000
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-13 16:20 +0200
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-13 15:12 +0000
Re: Where to locate software RobertsonEricW <robertsonericw@netzero.net> - 2016-06-13 08:55 -0700
Re: Where to locate software John Reagan <xyzzy1959@gmail.com> - 2016-06-13 09:07 -0700
Re: Where to locate software "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-16 15:16 -0500
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-16 20:25 -0700
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-16 23:24 -0700
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-19 06:21 +0200
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-19 06:08 +0200
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-18 21:52 -0700
Re: Where to locate software "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-19 19:17 -0500
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-13 15:03 -0700
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 09:08 -0400
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-13 21:05 -0500
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-14 03:49 +0000
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-13 21:28 -0700
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-14 09:52 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-14 12:11 -0400
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-14 14:27 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-14 20:14 +0000
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-19 12:20 +0200
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-21 09:30 -0400
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-21 09:34 -0700
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-07-02 08:23 +0200
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-14 16:22 -0700
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-14 16:20 -0700
Re: Where to locate software koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-21 09:28 -0400
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-14 18:55 -0500
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-15 11:18 +0200
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-15 12:17 +0000
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-15 14:30 +0200
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-15 07:39 -0500
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-15 15:23 +0200
Re: Where to locate software "Craig A. Berry" <craig.a.berry@gmail.com> - 2016-06-15 08:03 -0700
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-15 19:41 +0200
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-15 19:10 -0500
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-16 11:24 +0200
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-16 08:33 -0500
Re: Where to locate software Johnny Billquist <bqt@softjar.se> - 2016-06-16 17:09 +0200
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-16 11:12 -0500
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-16 12:32 -0700
Re: Where to locate software "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-16 17:48 -0500
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-16 20:29 -0700
Re: Where to locate software Richard Levitte <richard@levitte.org> - 2016-06-16 23:21 -0700
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-19 05:56 +0200
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-13 13:21 -0400
Re: Where to locate software John Reagan <xyzzy1959@gmail.com> - 2016-06-12 14:46 -0700
Re: Where to locate software lawrencedo99@gmail.com - 2016-06-12 17:53 -0700
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-12 12:57 -0400
Re: Where to locate software Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 18:03 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-12 12:46 -0400
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-11 22:37 -0400
Re: Where to locate software Chris Scheers <chris@applied-synergy.com> - 2016-06-10 13:28 -0500
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 11:30 -0400
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 12:48 -0400
Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-09 18:55 +0000
Re: Where to locate software Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-09 16:00 -0400
Re: Where to locate software johnwallace4@yahoo.co.uk - 2016-06-09 14:18 -0700
Microsoft "innovation", was: Re: Where to locate software Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-10 17:47 +0000
Re: Where to locate software David Froble <davef@tsoft-inc.com> - 2016-06-09 22:26 -0400
Re: Where to locate software Dale Dellutri <daQQQle@panQQQix.com> - 2016-06-09 15:17 +0000
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-09 19:29 -0500
Re: Where to locate software Paul Sture <nospam@sture.ch> - 2016-06-10 06:23 +0200
Re: Where to locate software "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-09 23:45 -0500
Re: Where to locate software Steven Schweda <sms.antinode@gmail.com> - 2016-06-09 21:51 -0700
Re: Where to locate software Hans Vlems <hvlems@freenet.de> - 2016-06-10 00:15 -0700
Re: Where to locate software "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-10 08:26 -0500
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-10 16:53 -0400 |
| Message-ID | <njf9br$h81$1@dont-email.me> |
| In reply to | #58172 |
Simon Clubley wrote: > On 2016-06-10, David Froble <davef@tsoft-inc.com> wrote: >> Stephen Hoffman wrote: >> >>> If you're >>> doing fifty or five hundred servers or if you need rapid updates due to >>> security vulnerabilities or other serious issues, you're in deep >>> sneakers. And most everything here is only going to need to happen >>> faster. >>> >>> *This* is app stacking and containers and sandboxes. >>> >> This is not the world I live in, and so I must admit that any views I have just >> aren't applicable. > > Actually David, while I do think you do need to expose yourself more > to new ideas and see if they can bring benefits to you, I also think > your views _are_ applicable. Nor did I mean my views aren't applicable, in general. I've never seen a computer room, or building, or whatever, with 50 VMS systems. I have seen a single VMS system perhaps running large numbers of apps, if not as many as 50, and I've seen single VMS systems supporting hundreds of users. One customer long ago had I believe 6 11/780 or 785 or 782 systems and a 750. Today I'd guess the entire load could be supported by one system. To be more specific, if you got 50 VMS systems, then perhaps my views aren't applicable for that site. > Stephen likes to talk about the large internet focused companies with > a requirement for massive amounts of automation and web based stuff > and that is certainly a valid requirement. However, by number, those > companies are not the majority of the companies in existence and all > the different types of companies have different requirements. They may not be the majority, but, 50 VMS systems is the same in sales as single VMS systems to 50 customers. I tend to think it's a market worth pursuing. Not that I would know how to do so. > What you bring to the table is detailed real-world knowledge of actual > computing business requirements in a different type of company. > > Simon. >
[toc] | [prev] | [next] | [standalone]
| From | Hans Vlems <hvlems@freenet.de> |
|---|---|
| Date | 2016-06-11 00:27 -0700 |
| Message-ID | <983b27c4-25cb-4434-8290-c73e5e0537ca@googlegroups.com> |
| In reply to | #58183 |
I manage (own) 40 systems. Just hobbyist systems but I fully subscribe to Steve's point. It is very hard work to maintain parity among systems. As such it's a blessing in disguise that hobbyist users no longer have access to patches. It takes too much effort to keep up. And yes, there's no VMS built in tooling to help. Hans
[toc] | [prev] | [next] | [standalone]
| From | johnwallace4@yahoo.co.uk |
|---|---|
| Date | 2016-06-11 01:37 -0700 |
| Message-ID | <20aa4796-b0fe-47fe-99da-196e6e3fc3ea@googlegroups.com> |
| In reply to | #58198 |
On Saturday, 11 June 2016 08:27:34 UTC+1, Hans Vlems wrote: > I manage (own) 40 systems. Just hobbyist systems but I fully subscribe to Steve's point. It is very hard work to maintain parity among systems. > As such it's a blessing in disguise that hobbyist users no longer have access to patches. It takes too much effort to keep up. And yes, there's no VMS built in tooling to help. > Hans Are your 40 systems all the same? If you were (say) the IT Director of a retail chain operator with 400 branches each with its own instance of the shop-management system, would you perhaps see the benefit of having 400 systems which were basically identical apart from the site-specific stuff? It's been done. With VMS, with no in-shop IT skills just remote support, with upmarket taxi drivers doing any onsite swaps that might occasionally be required (e.g swap a storage unit when a software upgrade was being rolled out). Could it be easier with modern tooling and modern connectivity? Maybe, if it was available on the shop chain's OS of choice. Or maybe they could abandon what they have and instead run it all on an off the shelf package running in a timesharing bureau (er, sorry, cloud) and wait for the fun to start and the business to stop.
[toc] | [prev] | [next] | [standalone]
| From | Hans Vlems <hvlems@freenet.de> |
|---|---|
| Date | 2016-06-11 03:21 -0700 |
| Message-ID | <9dba67cf-b921-4eb1-aab8-da9986a9fca5@googlegroups.com> |
| In reply to | #58199 |
No they are not the same. But most VAX systems run V7.3, the Alphas run v8.4 and the IA64's are on v8.4 too. They all run IP DECnet C PASCAL CMS and MMS. To keep with patches was quite some work. These are hobbyist systems of course. Your question is how would I handle 400 production system? My max in that area is about 50 systems. In different factories on the same site. VMS and LP updates were applied initially on a development VAX 8550 and subsequently on all factory systems. Just VAX back then and if there were patches then I've ignored them by and large. For 400 identical systems I'd build one base image and modify that. Easier said than done but modparams.dat can be generated based on parameterfiles. I think (with the factory i used to work in in mind !!) that i could have done that on my own in 6 months. Hans
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-11 22:02 -0400 |
| Message-ID | <njifs6$gij$1@dont-email.me> |
| In reply to | #58203 |
Hans Vlems wrote: > No they are not the same. But most VAX systems run V7.3, the Alphas run v8.4 and the IA64's are on v8.4 too. > They all run IP DECnet C PASCAL CMS and MMS. > To keep with patches was quite some work. These are hobbyist systems of course. > > Your question is how would I handle 400 production system? My max in that area is about 50 systems. In different factories on the same site. VMS and LP updates were applied initially on a development VAX 8550 and subsequently on all factory systems. > Just VAX back then and if there were patches then I've ignored them by and large. > > For 400 identical systems I'd build one base image and modify that. Easier said than done but modparams.dat can be generated based on parameterfiles. I think (with the factory i used to work in in mind !!) that i could have done that on my own in 6 months. > Hans I don't think anyone objects to better management tools. I sure do not. However, I have to ask again, how many 50+ system VMS customers are there? How many 50+ non-VMS system customers are there, and might consider VMS? If they did consider VMS, would they still continue to need 50+ systems? Ok, for the situation of 400 locations, each with a local system. Yes, some manner of management with a VMS expert at each site would be a good thing. A very good thing. How many exist, and what's the cost of catering to the 0+ such customers, and what will that cost do to work maybe needed for many other VMS customers?
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-11 22:27 -0400 |
| Message-ID | <njihbf$kf3$1@dont-email.me> |
| In reply to | #58221 |
David Froble wrote: > Hans Vlems wrote: >> No they are not the same. But most VAX systems run V7.3, the Alphas >> run v8.4 and the IA64's are on v8.4 too. >> They all run IP DECnet C PASCAL CMS and MMS. >> To keep with patches was quite some work. These are hobbyist systems >> of course. >> >> Your question is how would I handle 400 production system? My max in >> that area is about 50 systems. In different factories on the same >> site. VMS and LP updates were applied initially on a development VAX >> 8550 and subsequently on all factory systems. >> Just VAX back then and if there were patches then I've ignored them by >> and large. >> >> For 400 identical systems I'd build one base image and modify that. >> Easier said than done but modparams.dat can be generated based on >> parameterfiles. I think (with the factory i used to work in in mind >> !!) that i could have done that on my own in 6 months. >> Hans > > I don't think anyone objects to better management tools. I sure do not. > > However, I have to ask again, how many 50+ system VMS customers are there? > > How many 50+ non-VMS system customers are there, and might consider > VMS? If they did consider VMS, would they still continue to need 50+ > systems? > > Ok, for the situation of 400 locations, each with a local system. Yes, > some manner of management with a VMS expert at each site would be a good > thing. A very good thing. How many exist, and what's the cost of > catering to the 0+ such customers, and what will that cost do to work > maybe needed for many other VMS customers? That should read "without a VMS expert at each site". Fingers got ahead of brain, not so hard to do anymore .... :-)
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-13 09:05 -0400 |
| Message-ID | <s10C+3Kaxcd$@eisner.encompasserve.org> |
| In reply to | #58203 |
In article <njifs6$gij$1@dont-email.me>, David Froble <davef@tsoft-inc.com> writes: > > How many 50+ non-VMS system customers are there, and might consider VMS? If > they did consider VMS, would they still continue to need 50+ systems? Consider instead: how many should there be?
[toc] | [prev] | [next] | [standalone]
| From | Kerry Main <kerry.main@backtothefutureit.com> |
|---|---|
| Date | 2016-06-10 16:13 +0000 |
| Message-ID | <mailman.0.1465575275.13355.info-vax_info-vax.com@info-vax.com> |
| In reply to | #58163 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > Stephen Hoffman via Info-vax > Sent: 10-Jun-16 11:11 AM > To: info-vax@info-vax.com > Cc: Stephen Hoffman <seaohveh@hoffmanlabs.invalid> > Subject: Re: [New Info-vax] Where to locate software > > On 2016-06-10 02:20:51 +0000, David Froble said: > > > I have run multiple applications on a single VMS system. I've even > > seen multiple companies using the same VMS system. It can be done, > if > > the people doing it have half a clue. > > That this is feasible is without question feasible. It's getting two > (or more) arbitrary software packages with arbitrary dependencies to > arbitrarily and repeatedly and reliably install and upgrade and to > cleanly deinstall where this — as OpenVMS is presently implemented — > gets interesting. It's certainly manually possible, but that tends to > delve far too deeply into the RTFM territory. And we all know that > automation beats RTFM. Further down the road from how OpenVMS > operates, this is also distributed updates via (for instance) RSS and > HTTPS and signed apps, and how vulnerable or even malicious apps are > isolated from each other with an effort toward avoiding wider breaches. > > *This* is why I rant about PCSI and patch distribution and app > isolation and certificate distributions and secure password storage and > package management and better tools. > > Because if you're doing one server, then manual processes and skilled > dev-ops folks can and does usually does work fine. If you're doing > five servers or if you're working with products whose developers have > chosen to implement RTFM and (for whatever reason) not expend the > effort on "it just works" in their packages, this gets tedious. If > you're doing fifty or five hundred servers or if you need rapid updates > due to security vulnerabilities or other serious issues, you're in deep > sneakers. And most everything here is only going to need to happen > faster. > > *This* is app stacking and containers and sandboxes. > No. App stacking is not only possible, but it is has been part of the culture of OpenVMS Customer environments for decades. The challenge with commodity OS's is that while there may be some layered on solutions like .Net to help address some of the challenges, they still have a huuuge issue where the 90's distributed systems culture simply does not want or think that putting multiple bus apps on the same OS instance is a good thing - usually because it means different groups might have to talk to each other and/or follow the same standards. Now, what you are talking about is improving automation of config and security changes to deal with larger numbers of OpenVMS servers to reduce the impact of manual processes and that Is certainly something I do agree with. Keep in mind though that there are also commercial support applications available that help with this automation. When one has larger numbers of servers, it often makes more sense to buy commercial support applications for automation than to try and build these on your own. In addition, server vendors like HPE are embedding OS independent provisioning technologies in their new (albeit X86-64 only) server architectures. As an example: HPE's Next Gen Blade Server Web site: (scroll down) https://www.hpe.com/info/synergy See page 11 of this WP for composer and streamer components: https://www.hpe.com/h20195/v2/GetDocument.aspx?docname=4AA6-3257EEW&doctype=Technical%20white%20paper&doclang=EN_GB&searchquery=&cc=us&lc=en Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-10 15:50 -0400 |
| Message-ID | <njf5lb$46s$1@dont-email.me> |
| In reply to | #58168 |
On 2016-06-10 16:13:32 +0000, Kerry Main said: > No. App stacking is not only possible, but it is has been part of the > culture of OpenVMS Customer environments for decades. Sure. If by "app stacking" you mean the 1970s through the 2000s, at least in terms of features, capabilities, isolation and ease of automation. What you keep pointing to as "app stacking" is increasingly problematic, at best. If Stark gets traction and starts scaling and starts having to do faster deployments and redeployments and upgrades — certainly a good thing — then you're going to start encountering these limits in OpenVMS. Or you're going to end up rolling out piles of custom code, or porting existing devops and deployment tools. For end-users, rolling out custom code and custom automation for devops is a cost, not a benefit. > The challenge with commodity OS's I'm rather less interested in how things were and how things are now, as — from a software development perspective — that's history. It's how things will be — not how they are or were — that matters to Stark and to other current and potential customers of OpenVMS, and to VSI. If your experience is limited to HPE and Windows and OpenVMS, and I'd recommend spending some time further afield, too. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | Kerry Main <kerry.main@backtothefutureit.com> |
|---|---|
| Date | 2016-06-10 20:54 +0000 |
| Message-ID | <mailman.295.1465592151.14919.info-vax_info-vax.com@info-vax.com> |
| In reply to | #58179 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > Stephen Hoffman via Info-vax > Sent: 10-Jun-16 3:50 PM > To: info-vax@info-vax.com > Cc: Stephen Hoffman <seaohveh@hoffmanlabs.invalid> > Subject: Re: [New Info-vax] Where to locate software > > On 2016-06-10 16:13:32 +0000, Kerry Main said: > > > No. App stacking is not only possible, but it is has been part of the > > culture of OpenVMS Customer environments for decades. > > Sure. If by "app stacking" you mean the 1970s through the 2000s, at > least in terms of features, capabilities, isolation and ease of > automation. > > What you keep pointing to as "app stacking" is increasingly > problematic, at best. > On the contrary, I view App Stacking as the way of the future in order to address both VM sprawl and significantly reduce server-server latency. Hint - do you think the latency associated App server to DB server network communications (think those with persistence updates) would not be exponentially smaller if the App Server(s) and the DB server were on the same OS instance sharing 32/64 cores and 768GB/1.5TB physical memory? Hint - the distributed model of the 90's is functionally still ok, but the deployment model is broke because the network inter-node latency has become one of the biggest inhibitors to scalability. > If Stark gets traction and starts scaling and starts having to do > faster deployments and redeployments and upgrades — certainly a good > thing — then you're going to start encountering these limits in > OpenVMS. > Nope - even today a brand new blade server can be brought online using custom gold images and common system disks in less than an hour. > Or you're going to end up rolling out piles of custom code, or porting > existing devops and deployment tools. > > For end-users, rolling out custom code and custom automation for > devops > is a cost, not a benefit. > Devops is like cloud computing or SOA or so many other hype filled concepts today. Still does not replace good old fashioned planning between the OPS and Dev groups along with something else which is not sexy, but still works - something called capacity planning. > > The challenge with commodity OS's > > I'm rather less interested in how things were and how things are now, > as — from a software development perspective — that's history. > > It's how things will be — not how they are or were — that matters to > Stark and to other current and potential customers of OpenVMS, and to > VSI. > Knowing why commodity OS's became popular is critical to understanding why the shared nothing compute model they both share is heading for some big challenges in the future. > If your experience is limited to HPE and Windows and OpenVMS, and I'd > recommend spending some time further afield, too. > Issue with Linux is that while they have some capabilities that OpenVMS does not yet have (and vice versa), many of the HA capabilities Linux are done at the App level. This means a distributed systems programmer needs to embed code in their application to take care of things if a server should fail, or how to take advantage of a new node added (or deleted), or how to address site issues e.g. dynamic config files, using replication to save data. Perhaps I am crazy, but imho, that model is the one that is broken. An App programmer should focus on optimizing and enhancing their code and not have to worry about numbers of nodes or where the code runs. That is the responsibility of the OS / infrastructure group. This is the way (or should be) a next gen model should be designed. Rather than simply taking the view of "the grass is greener on the other side", take a look at the following presentation for a real world look at how the typical group handles failures in a Linux shared nothing world: Posted Feb 27, 2016: Architecting Distributed Databases for Failure https://www.infoq.com/presentations/data-integrity-distributed-systems?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=presentations_link&utm_content=link_text (click on InfoQ video) Think about replication (over the network), network queries (over the network), & how to ensure data is protected when DB is split across many many nodes with each node having unique data i.e. how shared nothing model works) imho, the grass on the other side is not looking very good. Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-10 17:47 -0400 |
| Message-ID | <njfci9$roh$1@dont-email.me> |
| In reply to | #58184 |
On 2016-06-10 20:54:52 +0000, Kerry Main said: > > > On the contrary, I view App Stacking as the way of the future in order > to address both VM sprawl and significantly reduce server-server > latency. Yes, it is. No question. At least until you're undercut by changes to the underlying license prices. Which will kick the pins out from underneath more than a few of these discussions. The difference being that your approach to app stacking — what's out there now, on OpenVMS — is an increasing to massive hassle to deal with beyond even a couple of OpenVMS hosts. As currently "implemented", OpenVMS "app stacking" is a festering carbuncle of grief. But I'm being polite, having chased around more than a few of the interactions among disparate apps over the years, ranging from the DECC$ logical names to differences of opinions around the required system parameter settings across disparate applications to finding that reinstalling an an app was the easiest way to deal with a host name change to dealing with conflicts around different patch requirements, and that's before discussing dangling files and settings and the remainder of app cleanups, and the utter morass of manually-maintained startup files. You can keep telling me that this current septic tank is acceptable and even the wave of the future, and I'll keep my hip waders on when dealing with it and will keep asking for a hazmat suit and air supply. At least until the septic tank gets drained and the OpenVMS version of "app stacking" gets rethought and redeployed. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | Kerry Main <kerry.main@backtothefutureit.com> |
|---|---|
| Date | 2016-06-11 01:59 +0000 |
| Message-ID | <mailman.296.1465610447.14919.info-vax_info-vax.com@info-vax.com> |
| In reply to | #58185 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > Stephen Hoffman via Info-vax > Sent: 10-Jun-16 5:48 PM > To: info-vax@info-vax.com > Cc: Stephen Hoffman <seaohveh@hoffmanlabs.invalid> > Subject: Re: [New Info-vax] Where to locate software > > On 2016-06-10 20:54:52 +0000, Kerry Main said: > > > > > > > On the contrary, I view App Stacking as the way of the future in order > > to address both VM sprawl and significantly reduce server-server > > latency. > > Yes, it is. No question. At least until you're undercut by changes > to the underlying license prices. Which will kick the pins out from > underneath more than a few of these discussions. The difference being > that your approach to app stacking — what's out there now, on > OpenVMS — > is an increasing to massive hassle to deal with beyond even a couple of > OpenVMS hosts. As currently "implemented", OpenVMS "app > stacking" is > a festering carbuncle of grief. But I'm being polite, having chased > around more than a few of the interactions among disparate apps over > the years, ranging from the DECC$ logical names to differences of > opinions around the required system parameter settings across > disparate > applications to finding that reinstalling an an app was the easiest way > to deal with a host name change to dealing with conflicts around > different patch requirements, and that's before discussing dangling > files and settings and the remainder of app cleanups, and the utter > morass of manually-maintained startup files. You can keep telling me > that this current septic tank is acceptable and even the wave of the > future, and I'll keep my hip waders on when dealing with it and will > keep asking for a hazmat suit and air supply. At least until the > septic tank gets drained and the OpenVMS version of "app stacking" gets > rethought and redeployed. > Well, I have been on support calls and project engagements for mission critical OpenVMS customers (stock exchanges, banks, power utilities, manufacturing sites, government sites (like ones where you are escorted to the washroom) all over the globe for over 30 years. They are usually rock solid, well planned solutions and they typically all run more than one business application on the same OS/cluster - often using a common system disk because it is just so much easier from a config management perspective. Yes, proper resource naming and application planning Is part of this. Yes, you need experienced folks to do this planning. Course, you do not design new buildings with rookies either. You do it with experienced resources who often have different ideas of how to adapt previous best practices to the requirements of the current project. However, I would argue shared nothing architectures (Windows, Linux, UNIX) in distributed db's require much more up front planning because how you split up your Apps servers and especially data is critical. If hot spots occur due to unexpected loads in a few areas, then it becomes very difficult to address because you either increase that specific server size (and its designated backup) or re-partition the data or provide error messages to the client - the proverbial "server busy - please try later". This is the same reason btw where NonStop solutions run into major issues because it is also a shared nothing architecture. Course, in their environment, they are very good at estimating target workloads in one of their typical financial workload scenarios. Re: pricing- agree that current pricing strategies is an issue that needs to be addressed at some future point. Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-10 19:13 -0700 |
| Message-ID | <36b46c5f-d8f6-4282-a6e6-832ea449706f@googlegroups.com> |
| In reply to | #58188 |
On Saturday, June 11, 2016 at 2:05:05 PM UTC+12, Kerry Main wrote: > However, I would argue shared nothing architectures (Windows, Linux, > UNIX) in distributed db's require much more up front planning because > how you split up your Apps servers and especially data is critical. If hot > spots occur due to unexpected loads in a few areas, then it becomes very > difficult to address because you either increase that specific server size > (and its designated backup) or re-partition the data or provide error > messages to the client - the proverbial "server busy - please try later". Cluster filesystems, map-reduce, all that kind of thing. There was an article from a few years ago, from when Google only ran about 460,000 physical servers, about how they manage it all. Does your «insert name of favourite proprietary product here» scale to that level?
[toc] | [prev] | [next] | [standalone]
| From | Kerry Main <kerry.main@backtothefutureit.com> |
|---|---|
| Date | 2016-06-11 03:01 +0000 |
| Message-ID | <mailman.1.1465614169.13355.info-vax_info-vax.com@info-vax.com> |
| In reply to | #58189 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > lawrencedo99--- via Info-vax > Sent: 10-Jun-16 10:14 PM > To: info-vax@info-vax.com > Cc: lawrencedo99@gmail.com > Subject: Re: [New Info-vax] Where to locate software > > On Saturday, June 11, 2016 at 2:05:05 PM UTC+12, Kerry Main wrote: > > However, I would argue shared nothing architectures (Windows, Linux, > > UNIX) in distributed db's require much more up front planning because > > how you split up your Apps servers and especially data is critical. If hot > > spots occur due to unexpected loads in a few areas, then it becomes > very > > difficult to address because you either increase that specific server size > > (and its designated backup) or re-partition the data or provide error > > messages to the client - the proverbial "server busy - please try later". > > Cluster filesystems, map-reduce, all that kind of thing. There was an > article from a few years ago, from when Google only ran about 460,000 > physical servers, about how they manage it all. > > Does your «insert name of favourite proprietary product here» scale to > that level? Nope - Google is unique in that it has unlimited budgets and an application environment that on average is likely north of 90% reads. In addition, errors mean very little in real user impact e.g. if a search error returns an error, users simply retry. If it errors a second time, they will flip to Bing. Yes, marketers using data extracted from google mail will be upset, but Impact to end users - minimal to none. They also use rack servers only which means huge amounts of network latency that is imho, going to become the biggest bottleneck in the future for environments that require update persistence - as opposed to read only transactions. Because they have so many servers, I would also be willing to bet they have huge numbers of servers which are less than 20% busy at peak times. The future is all about getting the data closer to the compute engine in the least amount of time (latency). While compute, storage and memory has increased exponentially in recent years, network latency (not speed) is emerging as the next big bottleneck in the overall solution. Google's architecture works for Google, but I would NOT recommend it for a next generation environment which requires much lower overall latency AND at much lower costs. Reference: (from 2011, but still applies today) http://highscalability.com/blog/2011/8/29/the-three-ages-of-google-batch-warehouse-instant.html " The problem is we aren't meeting this challenge. Our infrastructure is broken. Datacenters have the diameter of a microsecond, yet we are still using entire stacks designed for WANs. Real-time requires low and bounded latencies and our stacks can't provide low latency at scale. We need to fix this problem and towards this end Luiz sets out a research agenda, targeting problems that need to be solved:" Hence, a fundamental conclusion is to eliminate network latency in as many areas as one can. Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-10 22:47 -0700 |
| Message-ID | <cd399f32-a321-4597-93c3-c34e98d63f7f@googlegroups.com> |
| In reply to | #58191 |
On Saturday, June 11, 2016 at 3:05:04 PM UTC+12, Kerry Main wrote: > Google is unique in that it has unlimited budgets ... Nobody has unlimited budgets. > They also use rack servers only which means huge amounts of network > latency ... You notice every time you do a Google query, it reports how many results it found, and how long it took? Have you ever implemented a search engine that could report similar performance?
[toc] | [prev] | [next] | [standalone]
| From | Kerry Main <kerry.main@backtothefutureit.com> |
|---|---|
| Date | 2016-06-11 12:45 +0000 |
| Message-ID | <mailman.298.1465649193.14919.info-vax_info-vax.com@info-vax.com> |
| In reply to | #58195 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > lawrencedo99--- via Info-vax > Sent: 11-Jun-16 1:47 AM > To: info-vax@info-vax.com > Cc: lawrencedo99@gmail.com > Subject: Re: [New Info-vax] Where to locate software > > On Saturday, June 11, 2016 at 3:05:04 PM UTC+12, Kerry Main wrote: > > Google is unique in that it has unlimited budgets ... > > Nobody has unlimited budgets. > > > They also use rack servers only which means huge amounts of network > > latency ... > > You notice every time you do a Google query, it reports how many > results it found, and how long it took? > > Have you ever implemented a search engine that could report similar > performance? Well, as I recall, AltaVista and NorthernLight used to be pretty impressive search engines. NorthernLight is (was?) an OpenVMS based web search engine. Its focus today is on Business Market Intelligence and not general web queries. https://northernlight.com/ https://northernlight.com/market-intelligence-solutions/ Here is testimonial quote from a past OpenVMS brochure: http://h18000.www1.hp.com/info/L4V13S/L4V13SSC.TXT "We had to have an operating system that could scale our database to billions of documents while providing very fast query times with uninterrupted 24 x 7 availability. Northern Light's Web search engine is the largest text-retrieval database in the history of the world, and it takes the unequaled power, speed and scalability of Compaq OpenVMS to run it." - David Seuss, CEO, Northern Light Technology, Inc. Also, more background: http://www.terabase.com/appnotes/NorthernLight/html/NorthernLight_1.html "Terabase delivered core server technology for the Northern Light Web Search Engine by leveraging the Terabase(r)/SRF Search and Retrieval Facility in conjunction with highly reliable OpenVMS Alpha clusters." My understanding is that there is also some UNIX In the solution as well. Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-11 15:02 -0400 |
| Message-ID | <njhn7n$pr5$1@dont-email.me> |
| In reply to | #58204 |
On 2016-06-11 12:45:24 +0000, Kerry Main said: > Well, as I recall, AltaVista and NorthernLight used to be pretty > impressive search engines. "Alta Vista is a very large project, requiring the cooperation of at least 5 servers, configured for searching huge indices and handling a huge Internet traffic load." That comprised a pair of AlphaStation 250 boxes at 266 MHz, an AlphaStation 400 at 233 MHz, a DEC 3000 model 900 for spider, and a 300 MHz AlphaServer 8400 Turbolaser box, with an aggregate of 130 gigabytes of RAM and a half-terabyte of storage. The computers were all running Unix. The web has grown in the ensuing ~twenty years, with attendant increases in the user query load, the activity of the crawlers, and coping with the effects of SEO, of course. Having a fast search engine integrated into OpenVMS — just for local content — would be handy. We're way past when having a half-terabyte of storage was notable, after all. Being able to maintain OpenVMS and to better structure applications for app stacking, now that's also interesting. Those five boxes — were they running OpenVMS, and not Unix — would involve maintaining stability- and security-related patches and application code to current, and promptly rolling out TLS patches and other updates for their systems. Preferably also with the applications designed for easy deployment. Which is still an entirely locally-implemented and/or documented and/or entirely manual process, even twenty years on. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | Kerry Main <kerry.main@backtothefutureit.com> |
|---|---|
| Date | 2016-06-12 02:07 +0000 |
| Message-ID | <mailman.299.1465697318.14919.info-vax_info-vax.com@info-vax.com> |
| In reply to | #58217 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > Stephen Hoffman via Info-vax > Sent: 11-Jun-16 3:02 PM > To: info-vax@info-vax.com > Cc: Stephen Hoffman <seaohveh@hoffmanlabs.invalid> > Subject: Re: [New Info-vax] Where to locate software > > On 2016-06-11 12:45:24 +0000, Kerry Main said: > > > Well, as I recall, AltaVista and NorthernLight used to be pretty > > impressive search engines. > > "Alta Vista is a very large project, requiring the cooperation of at > least 5 servers, configured for searching huge indices and handling a > huge Internet traffic load." > > That comprised a pair of AlphaStation 250 boxes at 266 MHz, an > AlphaStation 400 at 233 MHz, a DEC 3000 model 900 for spider, and a 300 > MHz AlphaServer 8400 Turbolaser box, with an aggregate of 130 > gigabytes > of RAM and a half-terabyte of storage. The computers were all > running Unix. > AltaVista on the web was much larger than what you have indicated. Reference: https://news.ycombinator.com/item?id=10407678 Hardware requirements for running AltaVista search engine in 1996: " By 1998, there were way more than five back end servers. I don't remember exactly how many 8400s we had -- 20? 40? Something in that range. They'd gone up to 12 GB of RAM apiece, which came on boards the size of a fairly large baking sheet. The servers were as big as a refrigerator. The primary datacenter was a floor above PAIX in the middle of downtown Palo Alto. Pricy server space." > The web has grown in the ensuing ~twenty years, with attendant > increases in the user query load, the activity of the crawlers, and > coping with the effects of SEO, of course. > Of course, no one disputes this. > Having a fast search engine integrated into OpenVMS — just for local > content — would be handy. We're way past when having a half- > terabyte > of storage was notable, after all. > Agree that might be useful, but would be a "nice to have" not a critical Item. > Being able to maintain OpenVMS and to better structure applications for > app stacking, now that's also interesting. Those five boxes — were > they running OpenVMS, and not Unix — would involve maintaining > stability- and security-related patches and application code to > current, and promptly rolling out TLS patches and other updates for > their systems. Preferably also with the applications designed for > easy deployment. Which is still an entirely locally-implemented > and/or documented and/or entirely manual process, even twenty years > on. > Northern Light was a popular public web server that ran on OpenVMS and in the very early 2000's was on par with Google. Large environments are all custom solutions. Those Customers that run stock exchanges, lotteries, banks etc. on OpenVMS all have custom configurations to deal with all of their requirements. They typically use standardized "gold" images that can be rapidly rolled out in an hour or less if required. They also typically use clusters to keep their mission critical App services available while servers are rebooted for OS patching and OS upgrades etc. In addition, these environments all have experienced resources that support these environments. Course, the same is true for Linux, Windows and every other mission critical solution out there today. These are not environments where the SysAdmin is reading "how to install OpenVMS" doc's. I am not saying there is not room for improvements - there certainly is, but let's remember that mission critical shops have ways of addressing anything that impacts them meeting their SLA's today. Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-11 22:05 -0400 |
| Message-ID | <njig1g$gij$2@dont-email.me> |
| In reply to | #58204 |
Kerry Main wrote: >> -----Original Message----- >> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of >> lawrencedo99--- via Info-vax >> Sent: 11-Jun-16 1:47 AM >> To: info-vax@info-vax.com >> Cc: lawrencedo99@gmail.com >> Subject: Re: [New Info-vax] Where to locate software >> >> On Saturday, June 11, 2016 at 3:05:04 PM UTC+12, Kerry Main wrote: >>> Google is unique in that it has unlimited budgets ... >> Nobody has unlimited budgets. >> >>> They also use rack servers only which means huge amounts of network >>> latency ... >> You notice every time you do a Google query, it reports how many >> results it found, and how long it took? >> >> Have you ever implemented a search engine that could report similar >> performance? > > Well, as I recall, AltaVista and NorthernLight used to be pretty impressive > search engines. > > NorthernLight is (was?) an OpenVMS based web search engine. Its focus > today is on Business Market Intelligence and not general web queries. > > https://northernlight.com/ > https://northernlight.com/market-intelligence-solutions/ > > Here is testimonial quote from a past OpenVMS brochure: > http://h18000.www1.hp.com/info/L4V13S/L4V13SSC.TXT > "We had to have an operating system that could scale our database > to billions of documents while providing very fast query times with > uninterrupted 24 x 7 availability. Northern Light's Web search engine > is the largest text-retrieval database in the history of the world, and it > takes the unequaled power, speed and scalability of Compaq OpenVMS > to run it." > - David Seuss, CEO, Northern Light Technology, Inc. > > Also, more background: > http://www.terabase.com/appnotes/NorthernLight/html/NorthernLight_1.html > "Terabase delivered core server technology for the Northern Light Web > Search Engine by leveraging the Terabase(r)/SRF Search and Retrieval > Facility in conjunction with highly reliable OpenVMS Alpha clusters." > > My understanding is that there is also some UNIX In the solution as well. > > Regards, > > Kerry Main > Kerry dot main at starkgaming dot com Kerry, if you don't put dates on those references, they aren't worth the bandwidth the words use.
[toc] | [prev] | [next] | [standalone]
| From | Kerry Main <kerry.main@backtothefutureit.com> |
|---|---|
| Date | 2016-06-12 04:17 +0000 |
| Message-ID | <mailman.4.1465705097.13355.info-vax_info-vax.com@info-vax.com> |
| In reply to | #58222 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > David Froble via Info-vax > Sent: 11-Jun-16 10:06 PM > To: info-vax@info-vax.com > Cc: David Froble <davef@tsoft-inc.com> > Subject: Re: [New Info-vax] Where to locate software > > Kerry Main wrote: > >> -----Original Message----- > >> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of > >> lawrencedo99--- via Info-vax > >> Sent: 11-Jun-16 1:47 AM > >> To: info-vax@info-vax.com > >> Cc: lawrencedo99@gmail.com > >> Subject: Re: [New Info-vax] Where to locate software > >> > >> On Saturday, June 11, 2016 at 3:05:04 PM UTC+12, Kerry Main wrote: > >>> Google is unique in that it has unlimited budgets ... > >> Nobody has unlimited budgets. > >> > >>> They also use rack servers only which means huge amounts of > network > >>> latency ... > >> You notice every time you do a Google query, it reports how many > >> results it found, and how long it took? > >> > >> Have you ever implemented a search engine that could report similar > >> performance? > > > > Well, as I recall, AltaVista and NorthernLight used to be pretty > impressive > > search engines. > > > > NorthernLight is (was?) an OpenVMS based web search engine. Its > focus > > today is on Business Market Intelligence and not general web queries. > > > > https://northernlight.com/ > > https://northernlight.com/market-intelligence-solutions/ > > > > Here is testimonial quote from a past OpenVMS brochure: > > http://h18000.www1.hp.com/info/L4V13S/L4V13SSC.TXT > > "We had to have an operating system that could scale our database > > to billions of documents while providing very fast query times with > > uninterrupted 24 x 7 availability. Northern Light's Web search engine > > is the largest text-retrieval database in the history of the world, and it > > takes the unequaled power, speed and scalability of Compaq > OpenVMS > > to run it." > > - David Seuss, CEO, Northern Light Technology, Inc. > > > > Also, more background: > > > http://www.terabase.com/appnotes/NorthernLight/html/NorthernLight > _1.html > > "Terabase delivered core server technology for the Northern Light > Web > > Search Engine by leveraging the Terabase(r)/SRF Search and Retrieval > > Facility in conjunction with highly reliable OpenVMS Alpha clusters." > > > > My understanding is that there is also some UNIX In the solution as > well. > > > > Regards, > > > > Kerry Main > > Kerry dot main at starkgaming dot com > > Kerry, if you don't put dates on those references, they aren't worth the > bandwidth the words use. David - these references were from the early 2000's (didn't think they would be confused as current) to point out where an OpenVMS based search engine was on par with Google (at the time) as per the question- > >> Have you ever implemented a search engine that could report similar > >> performance? Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.os.vms
csiph-web