Is VMS losing the Financial Sector, also?
David J Dachtera
(Sorry - the URL may wrap.)
Here's the relevant text, edited a bit to "sanitize":
Senior Systems Analyst
The Real-time Holdings (GDS) team has an open position for a dynamic individual
who is interested in joining our team. The candidate will support the Trust Bank
Reporting (TBR) application, as well as learning other applications supported by
the GDS team, to include the GDS application, PCA, Oscar, and Fidelity Sweep.
The candidate will support TBR... Components of TBR have been developed on the
DEC VAX and the IBM mainframe. The VAX platform will be sunset in the future,
requiring the remaining components and processes for TBR to be re-engineered on
the mainframe platform. To achieve the goal of porting the remaining components
of the application to a new platform, the role of the candidate will require
strong analysis and programming skills and full understanding of the components
on the current platform, to be able to contribute to the development on the new
platform. Additional responsibilities include production support on the current
and new system platforms.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
JF Mezei
> DEC VAX and the IBM mainframe. The VAX platform will be sunset in the future,
Gartner saw the cancer in its early stages. And that cancer slowly grew.
Now we are at the point where organs are shutting down one by one.
Initially, it was easy for VMS loyalists to be in denial and pretend
that Gartner was wrong and that VMS wasn't dying. Since the demise of
Alpha and forced migration to an even more unpopular platform, Gartner
hasn't even bothered to continue to comment on the lack of future for VMS.
VMS still has some stock exchanges due to the swedish stock exchange
software arm still somewhat loyal to VMS. Me thinks Sue should be
commuting every week to Sweden to ensure they are happy staying with VMS.
Main, Kerry
> From: JF Mezei [mailto:jfmezei...@vaxination.ca]
> Sent: May 19, 2007 12:09 AM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
> David J Dachtera wrote:
> > DEC VAX and the IBM mainframe. The VAX platform will be sunset in
> the future,
>
> Gartner saw the cancer in its early stages. And that cancer slowly
> grew.
> Now we are at the point where organs are shutting down one by one.
>
> Initially, it was easy for VMS loyalists to be in denial and pretend
> that Gartner was wrong and that VMS wasn't dying. Since the demise of
> Alpha and forced migration to an even more unpopular platform,
> Gartner
> hasn't even bothered to continue to comment on the lack of future for
> VMS.
>
Ah yes, this would be the same analyst company that stated in 1990 that
by 1995, all mainframes would be history.
Btw, did you notice in the article that this particular company was
planning new development on the mainframe?
:-)
Regards
Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)
OpenVMS - the secure, multi-site OS that just works.
ultr...@gmail.com
wrote:
> Encountered this job posting from one of my VMS job agents...
>
>
> (Sorry - the URL may wrap.)
>
> Here's the relevant text, edited a bit to "sanitize":
>
> Senior Systems Analyst
>
> The Real-time Holdings (GDS) team has an open position for a dynamic individual
> who is interested in joining our team. The candidate will support the Trust Bank
> Reporting (TBR) application, as well as learning other applications supported by
> the GDS team, to include the GDS application, PCA, Oscar, and Fidelity Sweep.
> The candidate will support TBR... Components of TBR have been developed on the
> DEC VAX and the IBM mainframe. The VAX platform will be sunset in the future,
> requiring the remaining components and processes for TBR to be re-engineered on
> the mainframe platform. To achieve the goal of porting the remaining components
> of the application to a new platform, the role of the candidate will require
> strong analysis and programming skills and full understanding of the components
> on the current platform, to be able to contribute to the development on the new
> platform. Additional responsibilities include production support on the current
> and new system platforms.
no it does not ... this company obviously was brainwashed by IBM as
they never
went to alpha or itanium but are keeping IBM ... the vms port would be
a lot easier
if they just went to alpha or itanium, but they do not know what they
are doing and
have chosen to listen to outside sales people like many companies ...
Tom Linden
Actually, not. Northern Trust like many other banks has been a PL/I shop
for almost 40 years. So they could gave ported to Alpha, but not Itanium.
Unlike Digital, IBM does not ignore their customers.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
David J Dachtera
>
> > -----Original Message-----
> > From: JF Mezei [mailto:jfmezei...@vaxination.ca]
> > Sent: May 19, 2007 12:09 AM
> > To: Info...@Mvb.Saic.Com
> > Subject: Re: Is VMS losing the Financial Sector, also?
> >
> > David J Dachtera wrote:
> > > DEC VAX and the IBM mainframe. The VAX platform will be sunset in
> > the future,
> >
> > Gartner saw the cancer in its early stages. And that cancer slowly
> > grew.
> > Now we are at the point where organs are shutting down one by one.
> >
> > Initially, it was easy for VMS loyalists to be in denial and pretend
> > that Gartner was wrong and that VMS wasn't dying. Since the demise of
> > Alpha and forced migration to an even more unpopular platform,
> > Gartner
> > hasn't even bothered to continue to comment on the lack of future for
> > VMS.
> >
>
> Ah yes, this would be the same analyst company that stated in 1990 that
> by 1995, all mainframes would be history.
>
> Btw, did you notice in the article that this particular company was
> planning new development on the mainframe?
I believe that as used these days "mainframe" could refer to high-end p-series
(AIX) machines, as well.
Dr. Dweeb
It's Rdb that is the keeper. They have been unsuccessful getting Oracle
classic to replace Rdb reliably, though AFAIK they have been trying for
quite some time. I think If Rdb turned up on WindowsAS, OM would be happy
to go in that direction I suspect (oh, it exists in fact, but is dead).
Same for some breed of U*x (oh, that existed too, but th U*x it ran on is
also dead).
NYMEX converted away from Rdb to Oracle8 recently. The requirement for VMS
in the future went out the window there as well. Not sure what OS they are
on at the moment.
I know plenty of other Rdb sites that will be ex-VMS sites as soon as they
can get the necessary quality/performance/operations reliability out of
Oracle Classic.
Dweeb.
Michael Kraemer
>
> Ah yes, this would be the same analyst company that stated in 1990 that
> by 1995, all mainframes would be history.
>
And what's wrong with that prediction ?
As far as my part of the world is concerned (academia,edu)
mainframes went out of service in 1994 to 1996 wherever I looked.
And in the rest of the world it didn't look much different.
Sure IBM still generates solid business (without having to
worry about competitors), but it's nowhere near where it once was.
So for most practical purposes mainframes indeed are history.
Richard B. Gilbert
At the parent company of my late employer, there was an IBM mainframe
that handled their order entry, database, etc, etc. It was still in
service when I was laid off in 2004. The company that bought out the
parent company was Novell based so that mainframe is probably history by
now.
Main, Kerry
> From: Michael Kraemer [mailto:M.Kr...@gsi.de]
> Sent: May 19, 2007 3:51 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
>
> >
> > Ah yes, this would be the same analyst company that stated in 1990
> that
> > by 1995, all mainframes would be history.
> >
>
> And what's wrong with that prediction ?
> As far as my part of the world is concerned (academia,edu)
> mainframes went out of service in 1994 to 1996 wherever I looked.
> And in the rest of the world it didn't look much different.
> Sure IBM still generates solid business (without having to
> worry about competitors), but it's nowhere near where it once was.
> So for most practical purposes mainframes indeed are history.
You are joking, right?
While mainframes may have disappeared from Universities etc, that market
is a pebble on the beach compared to financial, insurance, banks, and
many other mission critical environments. Lets face it, Universities and
Educational markets are extremely price sensitive and are even getting
off traditional OS's like Solaris, AIX, OpenVMS etc in favour of Linux
and other open source alternatives.
It was only a couple of years ago, there was a report that something
like 50% of all *business* transactions were still done on mainframe or
mainframe compatible servers. Even if that dropped a few % since then
that is still a huge, huge market.
For those who have not been exposed to that mainframe market, it's a bit
like "if you are on a farm and you spend all your time in the chicken
house, it is hard to understand just how many other animals there are
and how big the farm really is."
And with many Customers getting fed up with all the issues of managing
so many smaller systems all over the place and that are running at less
than 15% in peak times, some companies are even expanding their use of
the mainframe.
Main, Kerry
> From: David J Dachtera [mailto:djes...@spam.comcast.net]
> Sent: May 19, 2007 12:08 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
> >
> > > -----Original Message-----
> > > From: JF Mezei [mailto:jfmezei...@vaxination.ca]
> > > Sent: May 19, 2007 12:09 AM
> > > > DEC VAX and the IBM mainframe. The VAX platform will be sunset
> in
> > > the future,
> > >
> > > Gartner saw the cancer in its early stages. And that cancer slowly
> > > grew.
> > > Now we are at the point where organs are shutting down one by
> one.
> > >
> > > Initially, it was easy for VMS loyalists to be in denial and
> pretend
> > > that Gartner was wrong and that VMS wasn't dying. Since the
> demise of
> > > Alpha and forced migration to an even more unpopular platform,
> > > Gartner
> > > hasn't even bothered to continue to comment on the lack of future
> for
> > > VMS.
> > >
> >
> that
> > by 1995, all mainframes would be history.
> >
> > planning new development on the mainframe?
>
> I believe that as used these days "mainframe" could refer to high-end
> p-series
> (AIX) machines, as well.
>
> --
Not very likely.
Those who work in the mainframe environment look down on Windows and all
UNIX servers and call them "mid-range" which in their terms means "for
running not very important stuff .."
And that includes AIX.
Btw, its also why many vendors have a tough time convincing these
mainframe Customers to move their important stuff to UNIX or Windows
platforms - it's a major culture issue.
Tom Linden
wrote:
In the world of commerce the mainframe is still king
Michael Kraemer
> In the world of commerce the mainframe is still king
I wouldn't call that "king".
At best, "count". Amont other counts.
Michael Kraemer
>
> You are joking, right?
not at all.
> While mainframes may have disappeared from Universities etc, that market
> is a pebble on the beach compared to financial, insurance, banks,
I'm not sure if your "pebbles" comparison could be applied in the
1990 time frame (and this is what the Gartner prediction referred to).
The number of german national labs alone (several dozens) is about as
large as the number of german based banks and insurances,
and each of those ran at least one mainframe. Plus about hundred or
more universities, each of which probably also with at least one mainframe.
Even if the total market volume in $$$ was less than those of
financial customers, I wouldn't call it insignificant.
And don't count out the fact that fresh blood is usually
trained at universities.
> and
> many other mission critical environments.
such as ?
>
> It was only a couple of years ago,
that's a pretty long time
> there was a report that something
> like 50% of all *business* transactions were still done on mainframe
now this is a rather silly measure of importance, IMHO.
In today's networked IT any component can claim such importance.
How about "Windoze is indispensable because 90+x% of all online banking
is processed through Windoze based desktops" ?
How about cash dispensers (dunno what OS they use to run) ?
Or the bank clerk's office PCs ?
Without all those boxes, mainframes wouldn't have that much to transact.
> or
> mainframe compatible servers.
Do these still exist ?
I seem to remember they are physically extinct by now.
Does Amdahl still make PCMs ?
> Even if that dropped a few % since then
> that is still a huge, huge market.
Huge ? Compared to what ?
IBM used to be a $60B company in 1990 with the majority
of income from mainframe-related sales.
By now they are a $80B+x company with mainframe business
of the order of maybe $4B (that's the number I seem to remember).
In view of such numbers, Gartner is perfectly right.
> For those who have not been exposed to that mainframe market, it's a bit
> like "if you are on a farm and you spend all your time in the chicken
> house, it is hard to understand just how many other animals there are
> and how big the farm really is."
The farm obviously isnt big enough to feed more than one
significant vendor.
It isnt important enough (any more) for universities
to offer general mainframe courses.
>
> And with many Customers getting fed up with all the issues of managing
> so many smaller systems all over the place and that are running at less
> than 15% in peak times, some companies are even expanding their use of
> the mainframe.
How many are "some" ?
And: provided they find enough mainframe experts.
Most of these have retired together with their machines.
Richard B. Gilbert
I knew there was a reason I always did my banking at the bank!
Main, Kerry
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
>
> >
> > You are joking, right?
>
> not at all.
>
> > While mainframes may have disappeared from Universities etc, that
> market
> > is a pebble on the beach compared to financial, insurance, banks,
>
> I'm not sure if your "pebbles" comparison could be applied in the
> 1990 time frame (and this is what the Gartner prediction referred to).
> The number of german national labs alone (several dozens) is about as
> large as the number of german based banks and insurances,
> and each of those ran at least one mainframe. Plus about hundred or
> more universities, each of which probably also with at least one
> mainframe.
> Even if the total market volume in $$$ was less than those of
> financial customers, I wouldn't call it insignificant.
> And don't count out the fact that fresh blood is usually
> trained at universities.
>
And you think this is not understood by the mainframe supporters?
Check out these links related to Universities, SOA, Web Services and
mainframes:
http://www.internetnews.com/ent-news/article.php/3604231
http://www.theregister.co.uk/2006/06/09/students_love_mainframes/
I am not saying that mainframes are the right go forward strategy, but
many mission critical Customers literally have PB of existing data and
applications. Converting these would literally take years of effort
And these folks understand applying monthly OS security patches is not
something that should have to be done every month. And they have been
doing virtualization for about 30+ years, so just try and impress them
about how good VMware or Zen is.
If you want to play in their sand box, you need to understand their
culture.
> > and
> > many other mission critical environments.
>
> such as ?
>
Retail, manufacturing, telecommunication, transportation ...
> >
> > It was only a couple of years ago,
>
> that's a pretty long time
>
As compared to what?
> > there was a report that something
> > like 50% of all *business* transactions were still done on mainframe
>
> now this is a rather silly measure of importance, IMHO.
Let me clarify this by stating *server based business transactions*
> In today's networked IT any component can claim such importance.
> How about "Windoze is indispensable because 90+x% of all online
> banking
> is processed through Windoze based desktops" ?
> How about cash dispensers (dunno what OS they use to run) ?
> Or the bank clerk's office PCs ?
> Without all those boxes, mainframes wouldn't have that much to
> transact.
>
> > or
> > mainframe compatible servers.
>
> Do these still exist ?
> I seem to remember they are physically extinct by now.
> Does Amdahl still make PCMs ?
>
> > Even if that dropped a few % since then
> > that is still a huge, huge market.
>
> Huge ? Compared to what ?
> IBM used to be a $60B company in 1990 with the majority
> of income from mainframe-related sales.
> By now they are a $80B+x company with mainframe business
> of the order of maybe $4B (that's the number I seem to remember).
> In view of such numbers, Gartner is perfectly right.
>
I am not saying their mainframe revenue has not declined. It certainly
has. However, even if it is *only* $4-5B / year, think about this in
terms of revenue per server. Very big numbers.
Having stated this, what is by far the biggest target for server
consolidation today?
Windows and x86 platforms. No other platform even comes close.
> > For those who have not been exposed to that mainframe market, it's a
> bit
> > like "if you are on a farm and you spend all your time in the
> chicken
> > house, it is hard to understand just how many other animals there
> are
> > and how big the farm really is."
>
> The farm obviously isnt big enough to feed more than one
> significant vendor.
> It isnt important enough (any more) for universities
> to offer general mainframe courses.
>
> >
> > And with many Customers getting fed up with all the issues of
> managing
> > so many smaller systems all over the place and that are running at
> less
> > than 15% in peak times, some companies are even expanding their use
> of
> > the mainframe.
>
> How many are "some" ?
> And: provided they find enough mainframe experts.
> Most of these have retired together with their machines.
J2EE, Java, SOA are all relatively platform independent. Develop on one
platform, QA and deploy on another platform for additional security and
scalability is done quite a bit these days. See article in link above
about SOA and web enabling applications.
I remember an article a couple of years back that stated the hands down
biggest resources you could want or have skills in these days are Cobol
application programmers who understand SOA and can web enable Cobol/PL1
applications.
Like I said before, I am certainly not promoting mainframe environments,
but you need to have a healthy respect for what they provide. Don't get
caught up in the "we can do anything they can do" hype that is all to
often circulating around.
JF Mezei
Mainframes used to be big, expensive, very very expensive. And IBM used
its social muscle to convince MIS directors (that is what they were
called back then) that only IBM could do the job.
In the 1990s, even mainframe shops couldn't ignore the growing "minis"
(aka: Solaris) and even banks starts to accept Solaris in their shops.
IBM reacted by making its mainframes more competitively priced. It was
far more agressive at preserving its mainframe business than DEC was.
DEC was in fact purposefully sabotaging its VMS business while IBM was
trying to salvage its MVS business.
The scope of computing has widened. Banks now have web sites, they have
automated telephone banking etc. Those were deployed on Unix because the
software was available on Unix. But their core remains in the mainframe
because that is where the big software exists and because it is already
installed and has taken a lot of roots over the years with many many
applications tying into the mainframe databases. The mainframe may not
have 100% of banking left, but it still has a significant chunk of it.
IBM actively protects its markets. HP actively is pushing away ISVs from
VMS.
Mainframe customers tend to be more mature about IT and not jump onto
the latest and greatest bandwagon just for the sake of it.
With Oracle, it makes Unix platforms quite serious for real business. So
IBM's competition is no longer from Amdhal, it is from Solaris for the
serious applications. For anciliary apps, Solaris and Linux and Windows
are acceptable.
The big question is whether Oracle will succeed in making Linux a
serious platform, acceptable to banks for serious applications.
Arne Vajhøj
> The big question is whether Oracle will succeed in making Linux a
> serious platform, acceptable to banks for serious applications.
Replacing the mainframe stuff: probably not.
Replacing all the Unix/VMS/Windows stuff: it is already
happening.
Arne
Michael Kraemer
>
> I am not saying their mainframe revenue has not declined. It certainly
> has. However, even if it is *only* $4-5B / year, think about this in
> terms of revenue per server. Very big numbers.
This is certainly a nice add-on for IBMs overall revenue, however,
$5B in comparison to the total IT market is almost nothing,
or, in your own words, just a single pebble on the beach.
And, returning to the origin of this partial thread,
this is the gist of Gartner's prediction in 1990.
It's not necessary to be physically extinct to be
relegated to "history".
Bob Koehler
>
> no it does not ... this company obviously was brainwashed by IBM as
> they never
> went to alpha or itanium but are keeping IBM ... the vms port would be
> a lot easier
> if they just went to alpha or itanium, but they do not know what they
> are doing and
> have chosen to listen to outside sales people like many companies ...
will be here tomorrow and be worried whether IA-64 will be? I don't
know what VMS will be running on five years from now, and niether
does that company.
Its quite possible that by "VAX" they really meant VMS and are
running on Alphas, I hear that all the time. While DEC would build
a product and provide support for it decades later, HP's record has
shown that it will not. When all the dust settles on what VMS'
future will be then customers will look at it again as a long term
platform.
In the meantime HP has an "Alpha Retain Trust" program that PL/I
shops can't trust. In their current state HP needs some heavy
advertising to convince people that they don't need an IA-64 retain
trust program.
Main, Kerry
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
>
[snip ...]
>
> The big question is whether Oracle will succeed in making Linux a
> serious platform, acceptable to banks for serious applications.
mmm... with 5-20 security patches released each and every month?
Good luck to them ..
Yeah, I can see the banks jumping all over this as they are not
concerned to much about security are they?
And in terms of cost savings, I know the billions of $'s in profit banks
make each year is not much, so I can see them really being under
pressure to get rid of those nice, safe back end systems.
:-)
Regards
John Smith
>> -----Original Message-----
>> From: JF Mezei [mailto:jfmezei...@vaxination.ca]
>> Sent: May 20, 2007 12:58 PM
>> To: Info...@Mvb.Saic.Com
>> Subject: Re: Is VMS losing the Financial Sector, also?
>>
>> re: mainframes
>>
>
>
> [snip ...]
>
>>
>> The big question is whether Oracle will succeed in making Linux a
>> serious platform, acceptable to banks for serious applications.
>
> mmm... with 5-20 security patches released each and every month?
>
> Good luck to them ..
>
> Yeah, I can see the banks jumping all over this as they are not
> concerned to much about security are they?
>
> And in terms of cost savings, I know the billions of $'s in profit
> banks make each year is not much, so I can see them really being under
> pressure to get rid of those nice, safe back end systems.
>
> :-)
Being *very* active in the financial services indusrty, I can assure you
that Oracle, notwithstanding its mult-patches per month, and Linux with its
patch du jour approach are in fact supplanting most things.
There are very few customers still using VMS, and of those, some are fully
committed to VMS whilst most are looking to migrate to unix...usually to
Solaris or AIX. I can't recall the last time I saw a shop have any
significant PHUX in-house.
--
OpenVMS - The never-advertised operating system with the dwindling ISV and
customer base.
David J Dachtera
>
> > -----Original Message-----
> > From: JF Mezei [mailto:jfmezei...@vaxination.ca]
> > Sent: May 20, 2007 12:58 PM
> > To: Info...@Mvb.Saic.Com
> > Subject: Re: Is VMS losing the Financial Sector, also?
> >
> > re: mainframes
> >
>
> [snip ...]
>
> >
> > The big question is whether Oracle will succeed in making Linux a
> > serious platform, acceptable to banks for serious applications.
>
> mmm... with 5-20 security patches released each and every month?
>
> Good luck to them ..
>
> Yeah, I can see the banks jumping all over this as they are not
> concerned to much about security are they?
>
> And in terms of cost savings, I know the billions of $'s in profit banks
> make each year is not much, so I can see them really being under
> pressure to get rid of those nice, safe back end systems.
All I can say is, read the paged linked to the URL in the OP.
Pressure or not, it's happening.
Main, Kerry
> From: John Smith [mailto:a...@nonymous.com]
> Sent: May 23, 2007 10:01 AM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
> Main, Kerry wrote:
> >> -----Original Message-----
> >> From: JF Mezei [mailto:jfmezei...@vaxination.ca]
> >> Sent: May 20, 2007 12:58 PM
> >> To: Info...@Mvb.Saic.Com
> >> Subject: Re: Is VMS losing the Financial Sector, also?
> >>
> >> re: mainframes
> >>
> >
[snip...]
>
> Being *very* active in the financial services indusrty, I can assure
> you
> that Oracle, notwithstanding its mult-patches per month, and Linux
> with its
> patch du jour approach are in fact supplanting most things.
>
> There are very few customers still using VMS, and of those, some are
> fully
> committed to VMS whilst most are looking to migrate to unix...usually
> to
> Solaris or AIX. I can't recall the last time I saw a shop have any
> significant PHUX in-house.
>
>
Yeah, have seen a number of cases where the OS religion over-rides sound
business judgement. The techies go down a certain road and their
managers do not have the will or the smarts to reign them in.... kind of
like sailing down the rapids in a canoe with no paddle.
Perhaps this is not politically correct, but where have all the IT
managers with sound business sense disappeared to these days?
I guess the banks will have to experience a major hack and major audit
before someone asks the question "Excuse me - are you saying you put our
mission critical XYZ application on an OS platform that you *knew* had
5-20 security patches released each and every month?"
Yep, auditors will love this when someone finally does get around to
asking those tough questions.
Reminds me of movie called Swordfish where the hacker spends a great
deal of time using a super computer to hack into a secure bank. With
Linux on that platform, how long do you think that would hold up?
And please do not say banks do not need to worry because they have good
firewalls - 50-60% of significant security events are internal issues.
Gotta love the IT hype these days.
JF Mezei
> Yeah, have seen a number of cases where the OS religion over-rides sound
> business judgement.
> Gotta love the IT hype these days.
Which is exactly why VMS needs strong and modern marketing if it wants
to survive. IT has a heard mentality. And VMS needs to be protrayed as
being part of the pack so that the heard will adopt it.
The fact that Linux was able to make so many inroads against Windows is
proof that it is possible with the right marketing to get it done.
VMS needs a major dose of marketing to counter not only windows and
linux, but also Solaris (Sun is trying hard to position Solaris as an
"in" OS that is seen as part of the pack.
JF Mezei
scandinavian stock exchanges, and more importantly, the developer of
VMS-based stock exchange software sold to many stock exchanges around
the world.
With European markets having overtaken the USA ones last year, NASDAQ
has been desperate to buy into a european exchange. They failed to
impress LSE (London) shareholders and hoppefully they will also fail to
get OMX.
One of the reasons non-USA companies have chosen european over US
exchanges recently is the US Sarbanes Oxley rules which are very onerous
on companies. And there are fears that a US owned exchange in Europe
would eventually have to force listed companies to also abide by USA
rules. (Euronext is now owned by NYSE and it remains to be seen what
will happen to its business)
So, if NASDAQ gets its hands on OMX, there is no telling what will
happen to the VMS software. Not long ago, I had heard on ainterview with
the president of OMX who stated that the software business was very
important to OMX.
However, if folks like Stallard at HP have already comvinced NASDAQ that
VMS is to be retired, NASDAQ may force OMX to stop development on VMS.
Note that Deutsche Börse (sp ?) bought into the International Securities
Exchange (ISE) in New York. But this is neutral to VMS since both are
VMS shops.
David J Dachtera
> [snip]
> Perhaps this is not politically correct, but where have all the IT
> managers with sound business sense disappeared to these days?
Too busy playing "point and click, hunt and peck - now what did those goofy
nerds say to do next...?"
Real Gagnon
$cef8887a$18...@TEKSAVVY.COM:
> So, if NASDAQ gets its hands on OMX, there is no telling what will
> happen to the VMS software. Not long ago, I had heard on ainterview with
> the president of OMX who stated that the software business was very
> important to OMX.
NASDAQ trading technology runs on Java.
At the last Javaone in SanFrancisco, Anna Ewing, CIO of NASDAQ gave a talk
about the system which process 150,378 transactions per second and their
long-term partnership with Sun. I guess that if VMS is still present it's
not in the core business.
Bye.
--
Real Gagnon from Quebec, Canada
* Java, Javascript, VBScript and PowerBuilder code snippets
* http://www.rgagnon.com/howto.html
* http://www.rgagnon.com/bigindex.html
Richard Maher
[The techies go down a certain road and their
managers do not have the will or the smarts to reign them in.... kind of
like sailing down the rapids in a canoe with no paddle.]
You mean a bit like Java, SOAP and the Waste os Substantial Investment in
Technology?
[Perhaps this is not politically correct, but where have all the IT
managers with sound business sense disappeared to these days?]
They were all sacked after implementing every hare-brained scheme that some
myopic Digital feather-bedder threw at them. DECforms, ONC/DCE, DCE/RPC,
Bridgeworks, DECAdmire, RALLY, Forte, WebConnector, ACMSxp, DECnet/OSI.
Those managers left are now so gun-shy that they just keep their heads down
and parrot whatever Gartner said last. (Bit like *some* Digital employees
really)
Still, the good news has to be the amount of traditional
COBOL/Pascal/ACMS/DECforms working going at the moment (at least in Europe)
and most of it in the Financial Sector. Companies are once again awash with
IT money and VMS development seems to be picking up its fair share. Maybe
the Northern Spring just cheers people up and loosens the purse strings?
Cheers Richard Maher
"Main, Kerry" <Kerry...@hp.com> wrote in message
news:FA60F2C4B72A584DBFC6...@tayexc19.americas.cpqcorp.net...
Richard Maher
> Rumours abound that NASDAQ will want be buying OMX, the operator of many
> scandinavian stock exchanges, and more importantly, the developer of
> VMS-based stock exchange software sold to many stock exchanges around
> the world.
When OM Gruppen failed in its bid for the London Stock Exchange (Is "LSE"
the London School of Economics?) I thought someone may try to turn the
hunter into the hunted, but that was a few years ago now. Where exactly are
these rumours abounding?
The ASX just went OM Click (and must be retiring its home grown VMS app) and
wasn't the Shanghai exchange another big win recently? Although it's built
with RTR (and therefore fundamentally flawed) you have to say this
software's bloody popular! I'm not a businees guru but I just can't see
OMX's software division disappearing anytime soon. (Now whether *they* can
port to another platform and if it's ever in their interests to do so, could
be another matter)
Cheers Richard Maher
"JF Mezei" <jfmezei...@vaxination.ca> wrote in message
news:1fbd8$46563c1c$cef8887a$18...@TEKSAVVY.COM...
P. Sture
David J Dachtera <djes...@spam.comcast.net> wrote:
> "Main, Kerry" wrote:
> > [snip]
> > Perhaps this is not politically correct, but where have all the IT
> > managers with sound business sense disappeared to these days?
>
> Too busy playing "point and click, hunt and peck - now what did those goofy
> nerds say to do next...?"
Oh, you mean like publishing an Excel chart to show that the number of
calls made by nightshift operators to support staff at home went up by
50% one month?
The actual number went from 2 to 3, and that was caused by an operator
forgetting a password.
You couldn't make this up.
--
Paul Sture
Dr. Dweeb
> Hi JF,
>
>> Rumours abound that NASDAQ will want be buying OMX, the operator of
>> many scandinavian stock exchanges, and more importantly, the
>> developer of VMS-based stock exchange software sold to many stock
>> exchanges around the world.
>
> When OM Gruppen failed in its bid for the London Stock Exchange (Is
> "LSE" the London School of Economics?) I thought someone may try to
> turn the hunter into the hunted, but that was a few years ago now.
> Where exactly are these rumours abounding?
>
> The ASX just went OM Click (and must be retiring its home grown VMS
> app) and wasn't the Shanghai exchange another big win recently?
> Although it's built with RTR (and therefore fundamentally flawed) you
> have to say this software's bloody popular! I'm not a businees guru
> but I just can't see OMX's software division disappearing anytime
> soon. (Now whether *they* can port to another platform and if it's
> ever in their interests to do so, could be another matter)
>
Shanghai is based on the Deautsche Börse/Swiss Stock Exchange software, not
OM.
AFAIK OM has been trying to move to OracleClassic on a 5 year plan that
started, well, quite a bit more than 5 years ago, and they are apparently
not much closer to getting the job done or getting it to work.
OM also operate a lot of the exchanges, and they own a lot of kit - they are
a very important VMS client. EVen so, they know what way the wind is
blowing and expect VMS and Rdb to go the way of the dod as soon as
technically possible.
Dr. Dweeb
Richard Maher
are
> a very important VMS client. EVen so, they know what way the wind is
> blowing and expect VMS and Rdb to go the way of the dod as soon as
> technically possible.
Yeah but they're clearly also very shrewd; they've managed to lump HP with
all the dead-wood, talentless RTR development and support o/head whilst at
the same time getting it given to their Click customers for free! Their just
not gonna find suckers like that every day.
Cheers Richard Maher
PS. Hold on! Rumours of another HP head-count reductions mean that Capt'n
RTR must already be positioning his team as the WS-AT solution for SOAP and
WSIT on VMS. Honestly, if you didn't laugh you'd cry :-(
"Dr. Dweeb" <sp...@dweeb.net> wrote in message
news:46568520$0$21926$157c...@dreader1.cybercity.dk...
Rob Fowler
>
> Shanghai is based on the Deautsche Börse/Swiss Stock Exchange software, not
> OM.
>
project. Shanghai A/B runs an early version of the popularl X-stream
platform, a C Unix (in this case HPUX) based trading system,
originally called ASTS at the time. OMX owns this platform through the
aquisition of Computershare Markets Technology.
Dr. Dweeb
Sorry about jumping the gun. I was unaware that OM owned the incumbent
system.
Dweeb
Phillip Helbig---remove CLOTHES to reply
<mahe...@hotspamnotmail.com> writes:
> When OM Gruppen failed in its bid for the London Stock Exchange (Is "LSE"
> the London School of Economics?) I thought someone may try to turn the
> hunter into the hunted, but that was a few years ago now. Where exactly are
> these rumours abounding?
All over the place. I'm not on the lookout for such rumours, so if I've
heard them, they must be quite common.
> > Note that Deutsche Börse (sp ?)
Spelling is correct.
> bought into the International Securities
> > Exchange (ISE) in New York. But this is neutral to VMS since both are
> > VMS shops.
Indeed.
Ron Johnson
[snip]
>> The big question is whether Oracle will succeed in making Linux a
>> serious platform, acceptable to banks for serious applications.
>
> mmm... with 5-20 security patches released each and every month?
>
There were 72 *bug* fixes to RHAS4 between 01-DEC-2006 and 30-APR-2007.
50 were against packages that would typically sit on a server, the rest on
client s/w. Not all of those 50 will be installed at every site.
In that same span, there were 46 security patches:
LOW MODERATE IMPORTANT CRITICAL
--- -------- --------- --------
DESKTOP: 0 7 4 11
SERVER: 3 12 8 1
So, we see *one* critical server-related security patch in 6 months. Not
bad, in my estimation.
10 various feature bugs per month, and 5 various security bugs per month.
When you consider that there are pushing 8000 (or more?) packages in Red
Hat (and 10000 in Debian), that's just not too shabby.
And if you haven't installed squid or samba or nfs or dovecot or
squirrelmail or, $DEITY forbid, uucp* on your particular server, then many
of these patches didn't apply to you.
* The UUCP "bug" wasn't that much of a bug, really. It wa a problem with
the packaging. An improper dependency meant that you couldn't rebuild it.
If you stuck with the official binary, there was no problem.
Ron Johnson
New Orleans LA
Main, Kerry
> From: Ron Johnson [mailto:ron.l....@cox.net]
> Sent: May 27, 2007 11:47 AM
> To: Info...@Mvb.Saic.Com
> Subject: RE: Is VMS losing the Financial Sector, also?
>
> On Mon, 21 May 2007 21:59:12 -0400, Main, Kerry wrote:
> [snip]
> >
> >> The big question is whether Oracle will succeed in making Linux a
> >> serious platform, acceptable to banks for serious applications.
> >
> > mmm... with 5-20 security patches released each and every month?
> >
> [snip]
>
> There were 72 *bug* fixes to RHAS4 between 01-DEC-2006 and 30-APR-
> 2007.
> 50 were against packages that would typically sit on a server, the
> rest on
> client s/w. Not all of those 50 will be installed at every site.
>
> In that same span, there were 46 security patches:
> LOW MODERATE IMPORTANT CRITICAL
> --- -------- --------- --------
> DESKTOP: 0 7 4 11
> SERVER: 3 12 8 1
>
> So, we see *one* critical server-related security patch in 6 months.
> Not
> bad, in my estimation.
>
Nice try, but the patches listed on the RH security web site are
*security* patches - not bug fixes (although they do bundle fixes with
their security fixes from what I can tell).
An actual tally for each month:
May 2007 - 34
April 2007 - 17
March 2007 - 19
February 2007 - 19
January 2007 - 13 (good month - *only* 13 security patches..)
Total = 102 *security* not "bug" patches.
And keep in mind that many (most?) of the security fixes they rate in
applications as low, moderate etc, can result in elevated security
priv's and/or the ability to access system protected data, so imho, that
is pretty critical.
Keep in mind that most Cust environments do not have just one version of
Linux. They have ES3, ES4, ES5 and various WS versions as well, then
that means the Operations folks need to track what apps are running on
what servers and then map out what security patches to apply to what
systems.
Does this not sound like a lot of work?
(and this does not even discuss the re-cert and testing efforts of their
App's with these monthly security patches)
> 10 various feature bugs per month, and 5 various security bugs per
> month.
> When you consider that there are pushing 8000 (or more?) packages in
> Red
> Hat (and 10000 in Debian), that's just not too shabby.
>
Looks like a hackers dream world to me.
Since it is very difficult for the Operations to keep up with all these
security patches in all of their Dev / QA / Test / Prod environments,
corp folks either ignore the patches and hope no one attacks them
(remember internal users are biggest threat) or they arrange to set
aside time to test their business app's against the monthly security
patches which significantly reduces the resources available to do normal
Dev/ Test / QA testing for new App functionality requests.
So, these systems go unpatched for extended periods and hackers
(external or internal) are left to do what they want since they know
exactly the vulnerabilities they can capitalize on.
Ron Johnson
[snip]
>
> Being *very* active in the financial services indusrty, I can assure you
> that Oracle, notwithstanding its mult-patches per month, and Linux with its
> patch du jour approach are in fact supplanting most things.
>
> There are very few customers still using VMS, and of those, some are fully
> committed to VMS whilst most are looking to migrate to unix...usually to
> Solaris or AIX. I can't recall the last time I saw a shop have any
> significant PHUX in-house.
We have a bunch of HP-UX boxes because the old CIO got into a big
argument with Sun and replaced them all with HP-UX. (Don't know why
he didn't go with AIX, since this is also a m/f shop.)
He's gone now, and new management is convinced that Linux is "good
enough", so any new mid-range kit is ProLinant and either Linux or
Windows (dependent on the contract, the app & the specific manager).
The development group is busily working to port a DEC C, (hack,
spit) Forte' & Rdb app to Java, (gag, groan) Siebel & Oracle on
Linux. (Don't ask why they chose Siebel.)
Why? Our customers (we're a government contractor) specifically do
not want their (the public's) data in an obscure format on a fading
platform.
Ron Johnson
https://www.redhat.com/security/updates/
https://rhn.redhat.com/errata/rhel4as-errata.html
Click a button to filter by All, Security, Bug fixes, Enhancements.
Click another button to sort by date, severity, etc.
> An actual tally for each month:
> May 2007 - 34
> April 2007 - 17
> March 2007 - 19
> February 2007 - 19
> January 2007 - 13 (good month - *only* 13 security patches..)
>
> Total = 102 *security* not "bug" patches.
>
> And keep in mind that many (most?) of the security fixes they rate in
> applications as low, moderate etc, can result in elevated security
> priv's and/or the ability to access system protected data, so imho, that
> is pretty critical.
>
> Keep in mind that most Cust environments do not have just one version of
> Linux. They have ES3, ES4, ES5 and various WS versions as well, then
> that means the Operations folks need to track what apps are running on
> what servers and then map out what security patches to apply to what
> systems.
You don't seem to know very much about Linux package management.
If you are a good sysadmin and have only installed the packages
necessary for your application, then a single "yum update" command
on your test box downloads all the *relevant* patch packages and
installs them. When you are satisfied that the patches don't hose
your system and can schedule an app downtime, run "yum update" again.
> Does this not sound like a lot of work?
>
> (and this does not even discuss the re-cert and testing efforts of their
> App's with these monthly security patches)
>
>> 10 various feature bugs per month, and 5 various security bugs per
>> month.
>> When you consider that there are pushing 8000 (or more?) packages in
>> Red
>> Hat (and 10000 in Debian), that's just not too shabby.
>>
>
> Looks like a hackers dream world to me.
You sound jealous. Most people in this group would love for VMS to
have that many applications.
> Since it is very difficult for the Operations to keep up with all these
> security patches in all of their Dev / QA / Test / Prod environments,
> corp folks either ignore the patches and hope no one attacks them
> (remember internal users are biggest threat) or they arrange to set
> aside time to test their business app's against the monthly security
> patches which significantly reduces the resources available to do normal
> Dev/ Test / QA testing for new App functionality requests.
Only if you install a kitchen sink install.
> So, these systems go unpatched for extended periods and hackers
> (external or internal) are left to do what they want since they know
> exactly the vulnerabilities they can capitalize on.
--
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
Larry Kilgallen
> If you are a good sysadmin and have only installed the packages
> necessary for your application, then a single "yum update" command
> on your test box downloads all the *relevant* patch packages and
> installs them. When you are satisfied that the patches don't hose
> your system and can schedule an app downtime, run "yum update" again.
So what is the syntax to switch from:
"all the *relevant* patch packages"
to
"all the *relevant* patch packages as of the prior date"
so that the only patch packages installed are those that were tested ?
Main, Kerry
Don't have to. An OS is an OS is an OS. Security patches are security
patches. They are not like bug fixes which you can decide to do when you
feel like it. Most large shops do not want to run exposed when there are
known security patches available. The risk to their business is to
large.
Nothing to do with OpenVMS or Linux or Windows for that matter.
The challenge with Linux (and Windows) is the sheer volume of monthly
security patches and the impact they have on Operations and QA/Testing
is mind boggling.
That is experience talking vs. "ignore the faults, because I can manage
my own small little world just fine, therefore all those other large
shops struggling with little things like no App downtime, strict
revision and config management and App re-cert testing processes just do
not know what they are doing .."
> If you are a good sysadmin and have only installed the packages
> necessary for your application, then a single "yum update" command
> on your test box downloads all the *relevant* patch packages and
> installs them. When you are satisfied that the patches don't hose
> your system and can schedule an app downtime, run "yum update" again.
>
So are you saying that this is what a med shop must do every month for
the 100+ Linux servers running all different versions of Linux? And what
do they do when they ask the business for monthly shutdowns to apply
these security patches?
> > Does this not sound like a lot of work?
> >
> > (and this does not even discuss the re-cert and testing efforts of
> their
> > App's with these monthly security patches)
> >
> >> 10 various feature bugs per month, and 5 various security bugs per
> >> month.
> >> When you consider that there are pushing 8000 (or more?) packages
> in
> >> Red
> >> Hat (and 10000 in Debian), that's just not too shabby.
> >>
> >
> > Looks like a hackers dream world to me.
>
> You sound jealous. Most people in this group would love for VMS to
> have that many applications.
>
Yeah right.
How about just trying to put some reality into all of the industry hype?
Can anyone here imagine telling existing OpenVMS Customers that 5-20 OS
security patches per month is ok and just part of normal business
operations so get used to it?
Think NASDAQ would think this is acceptable?
Linux (and Windows) have a place, but lets get real with understanding
the real Operations challenges when compared to more enterprise class
platforms.
> > Since it is very difficult for the Operations to keep up with all
> these
> > security patches in all of their Dev / QA / Test / Prod
> environments,
> > corp folks either ignore the patches and hope no one attacks them
> > (remember internal users are biggest threat) or they arrange to set
> > aside time to test their business app's against the monthly security
> > patches which significantly reduces the resources available to do
> normal
> > Dev/ Test / QA testing for new App functionality requests.
>
> Only if you install a kitchen sink install.
>
And what do you think large companies use for their standard OS
versions? Do you think they want 20+ different config's running all
across their 100+ Linux servers?
> > So, these systems go unpatched for extended periods and hackers
> > (external or internal) are left to do what they want since they know
> > exactly the vulnerabilities they can capitalize on.
>
> --
> Ron Johnson, Jr.
> Jefferson LA USA
>
> Give a man a fish, and he eats for a day.
> Hit him with a fish, and he goes away for good!
Regards
Ron Johnson
Well, you're only testing the patches* for the packages installed on
that box, no? And the package manager "knows" if you've already
installed a patch and if there are or aren't any updates for a given
package. And you can always enumerate specific packages if you
don't want to install every relevant package. And since you've only
installed the bare minimum of packages on your server (who needs a
GUI on a server, anyway??), the list will always be minimal.
Or am I misunderstanding you.
* Calling them patches is a fiction. They are full-blown updated
packages.
Ron Johnson
We do it every weekend. Suck-arse Forte and geezer VMS that can't
coalesce defragmented P0(??) space means that *apps* never stay up
longer than a week, and the boxes never stay up more than 45 days.
Of course, the "black box" machine running rarely-changing native
code on VMS 6.2 and Rdb 7.0.5 easily stay up for 270 days.
> Think NASDAQ would think this is acceptable?
See the last paragraph in this post, and ask yourself if NASDAQ
would accept that.
> Linux (and Windows) have a place, but lets get real with understanding
> the real Operations challenges when compared to more enterprise class
> platforms.
Don't get me started on the problems we've had with Alpha & VMS in
the past year. I'm going to miss a heck of a lot of stuff, but
monthly reboots, weekly app bounces and occasional crashes are not
among them.
>>> Since it is very difficult for the Operations to keep up with all
>> these
>>> security patches in all of their Dev / QA / Test / Prod
>> environments,
>>> corp folks either ignore the patches and hope no one attacks them
>>> (remember internal users are biggest threat) or they arrange to set
>>> aside time to test their business app's against the monthly security
>>> patches which significantly reduces the resources available to do
>> normal
>>> Dev/ Test / QA testing for new App functionality requests.
>> Only if you install a kitchen sink install.
>>
>
> And what do you think large companies use for their standard OS
> versions? Do you think they want 20+ different config's running all
> across their 100+ Linux servers?
Sure!!!
It's *stupid* to install Samba and NFS and yp/nis and GNOME and 1000
other apps on a dedicated web server, and it's just as stupid to
install non-essential stuff on a dedicated Samba server.
Not only does this make your system easier to patch, but it reduces
the "surface area" on which a bad guy can make an attack.
KISS, man, KISS.
>
> OpenVMS - the secure, multi-site OS that just works.
Except when it crashes due to a suck-arse TCP/IP implementation,
taking down 3 servers in the middle of the day!
Main, Kerry
> From: Ron Johnson [mailto:ron.l....@cox.net]
> Sent: May 27, 2007 5:48 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
[snip...]
Well, you have obviously been bitten by the hype and do not manage large
DC operations.
That's ok - for you, Linux works fine and that is great. To each his
own.
>
> Except when it crashes due to a suck-arse TCP/IP implementation,
> taking down 3 servers in the middle of the day!
>
>
You seem to be not managing the OpenVMS environment the way most
experienced OpenVMS SysAdmins would or you have some very unique
circumstances, or it has never been tuned properly because I have never
heard of a TCPIP issue taking out 3 systems. As well, weekly reboots for
an application is a sure sign that someone does not understand the App
and or the way it has been tuned (system or process parameters).
What is typical for most OpenVMS Customers are long time uptime examples
like the following:
http://www.openvms.org/stories.php?story=07/04/13/5402784
"On 13 April 2007 at 09:35:50 GMT the Amsterdam Police Cluster
celebrates 10 years uptime.
This cluster is a multiple site cluster which has been upgraded and
relocated during the 10 years while maintaining 100% application
availability."
As I stated, if you are happy with it and Linux works for you, then that
is great.
However, just remember that large shops have much more complicated
environments than you and 5-20 security patches per month is a *very*
big issue for them.
Regards
Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)
OpenVMS - the secure, multi-site OS that just works.
Ron Johnson
>> -----Original Message-----
>> From: Ron Johnson [mailto:ron.l....@cox.net]
>> Sent: May 27, 2007 5:48 PM
>> To: Info...@Mvb.Saic.Com
>> Subject: Re: Is VMS losing the Financial Sector, also?
>>
>
> [snip...]
>
> Well, you have obviously been bitten by the hype and do not manage large
> DC operations.
>
> That's ok - for you, Linux works fine and that is great. To each his
> own.
>
>> Except when it crashes due to a suck-arse TCP/IP implementation,
>> taking down 3 servers in the middle of the day!
>>
>>
>
> You seem to be not managing the OpenVMS environment the way most
> experienced OpenVMS SysAdmins would or you have some very unique
Sadly (or fortunately), I'm not the SysAdmin.
And we never had problems like this before Forte came along.
> circumstances, or it has never been tuned properly because I have never
> heard of a TCPIP issue taking out 3 systems. As well, weekly reboots for
> an application is a sure sign that someone does not understand the App
> and or the way it has been tuned (system or process parameters).
>
> What is typical for most OpenVMS Customers are long time uptime examples
> like the following:
> http://www.openvms.org/stories.php?story=07/04/13/5402784
> "On 13 April 2007 at 09:35:50 GMT the Amsterdam Police Cluster
> celebrates 10 years uptime.
>
> This cluster is a multiple site cluster which has been upgraded and
> relocated during the 10 years while maintaining 100% application
> availability."
>
> As I stated, if you are happy with it and Linux works for you, then that
> is great.
Whether I'm happy with it or not, It's Coming. The first Alphas are
rolling out and Linux/Oracle systems rolling in supposedly in 1Q08
(but probably 2Q08). That's a small cluster that does ~1.6M
txn/day. Depending on how well it functions, and how the contracts
read for our 2 big clients (each do ~10M txn/day), VMS will be out
in 2009 and Linux/Solaris/HPUX will be in.
Any way you cut it, though, VMS is *out* and "Unix" is in. Why?
The customers (who all talk with each other) *specifically* don't
want VMS anymore.
Just like in 1998 they wanted GUI and in came Forte and fat client
machines.
P. Sture
Ron Johnson <ron.l....@cox.net> wrote:
> On 05/27/07 15:28, Larry Kilgallen wrote:
> > In article <4cl6i.7903$gM1....@newsfe21.lga>, Ron Johnson
> > <ron.l....@cox.net> writes:
> >
> >> If you are a good sysadmin and have only installed the packages
> >> necessary for your application, then a single "yum update" command
> >> on your test box downloads all the *relevant* patch packages and
> >> installs them. When you are satisfied that the patches don't hose
> >> your system and can schedule an app downtime, run "yum update" again.
> >
> > So what is the syntax to switch from:
> >
> > "all the *relevant* patch packages"
> >
> > to
> >
> > "all the *relevant* patch packages as of the prior date"
> >
> > so that the only patch packages installed are those that were tested ?
>
> Well, you're only testing the patches* for the packages installed on
> that box, no? And the package manager "knows" if you've already
> installed a patch and if there are or aren't any updates for a given
> package. And you can always enumerate specific packages if you
> don't want to install every relevant package. And since you've only
> installed the bare minimum of packages on your server (who needs a
> GUI on a server, anyway??), the list will always be minimal.
>
> Or am I misunderstanding you.
>
My interpretation of Larry's question is this:
On 28-May-2007 at 11:53, you run yum on a test system to get the
relevant patch packages.
Once you have tested these (and this can take several days, even weeks
in a corporate environment), you decide to implement them on your
production systems.
How do you specify to yum that you want *only* the patches that were
available at 28-May-2007 at 11:53.
There is also the subsidiary question of how yum handles packages which
may be released while you are running yum. Could a package released at
11:54 be omitted from one run, but included in another, simply due to
differences in network speeds on two successive runs? (here I am
thinking of the logic whereby BACKUP/RECORD records the date and time of
the *start* of the backup, not the time an individual file is backed up).
> * Calling them patches is a fiction. They are full-blown updated
> packages.
Understood, but if shared libraries are being updated, that isn't
entirely true for the products using them.
> Give a man a fish, and he eats for a day.
> Hit him with a fish, and he goes away for good!
:-)
--
Paul Sture
Main, Kerry
That's crap .. Customers do not care what platform is being used to
deliver the service they are contracting for as long as it is always
available, always sub-second response times and it gets magically fixed
5 minutes before it breaks.
How many people do you think know or care what runs as the primary
platform for Google?
Saying "Customers do not want this platform or that platform" any more
is really IT's way of promoting their own agenda and OS religion as a
means to justify whatever their favourite program of the day is.
And that usually boils down to OS religion and hype of key techies in
the IT organization who have Managers who are afraid to disagree as it
might position them as being to much from the old school.
Btw - If you have Customers (internal or external) dictating to you what
the solution is vs. what their requirements are, then you are in a whole
lot more trouble than just determining what is the next big platform of
the day.
Ron Johnson
Oh, ok.
Well, typically, you download them into a private mini-repository on
your own server and then do all your testing and upgrading from it.
That also saves bandwidth so that all 100 servers don't hit the
public server.
> There is also the subsidiary question of how yum handles packages which
> may be released while you are running yum. Could a package released at
> 11:54 be omitted from one run, but included in another, simply due to
> differences in network speeds on two successive runs? (here I am
> thinking of the logic whereby BACKUP/RECORD records the date and time of
> the *start* of the backup, not the time an individual file is backed up).
The private repository should also take care of that.
>> * Calling them patches is a fiction. They are full-blown updated
>> packages.
>
> Understood, but if shared libraries are being updated, that isn't
> entirely true for the products using them.
I kinda see what you mean, but don't know if I've ever considered it
relevant, since shared libraries are always packaged separately.
Debian has a sweet little Python script named checkrestart which
goes thru the list of open shared library files, looking to see if
any "non-existent" files are still being used. (In Unix, even
though you can "delete" a file that's being used, it doesn't
disappear until it it's not used anymore.) Thus, if you upgrade a
fundamental or "mid-range" library, you run this script and it tells
you which apps have to be restarted. I don't know if Red Hate has
anything like that, but it's shouldn't be hard to port the Debian tool.
Of course, you'd do this on your test server first, and have that
list ready when you go to upgrade your production machines.
>> Give a man a fish, and he eats for a day.
>> Hit him with a fish, and he goes away for good!
>
> :-)
>
--
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Ron Johnson
[snip]
>>
>> Just like in 1998 they wanted GUI and in came Forte and fat client
>> machines.
>>
>
> That's crap .. Customers do not care what platform is being used to
> deliver the service they are contracting for as long as it is always
> available, always sub-second response times and it gets magically fixed
> 5 minutes before it breaks.
Geez, all I can do is shake my head.
> How many people do you think know or care what runs as the primary
> platform for Google?
>
> Saying "Customers do not want this platform or that platform" any more
> is really IT's way of promoting their own agenda and OS religion as a
> means to justify whatever their favourite program of the day is.
>
> And that usually boils down to OS religion and hype of key techies in
> the IT organization who have Managers who are afraid to disagree as it
> might position them as being to much from the old school.
There's definitely faddism & hype, no doubt about it.
If they say "terminals are old-fashioned and GUIs are hip", and we
want to win that contract, I *guarantee* you that we're going to
toss those VTs and bring in a GUI, no matter how expensive.
If (or *when* then *did*) say, "VMS must go!", then guess God Damned
what!! Out goes VMS.
Why? Because we're wedded to our paychecks, not to VMS.
> Btw - If you have Customers (internal or external) dictating to you what
> the solution is vs. what their requirements are, then you are in a whole
> lot more trouble than just determining what is the next big platform of
> the day.
We're *government contractors*!!! We do what we have to do to win
the contract.
See, government agencies either have their own SMEs, or hire
consultants. Or both. They are people, and people have biases.
And these SMEs let those biases seep into their reports.
So, that means figuring out what those biases are, and (if they are
at all vaguely reasonable) putting them in your Proposal. Because
if said SMEs are *hostile* to VMS, and you're proposal includes VMS,
then your chances of a favorable technical review are Very Very Low.
John Smith
Not surprising.
If you need any help on the conversion, we have some people on-staff who
used to be with Forte's software engineering & consulting team and who have
a bunch of Siebel/Oracle experience.
Some of my customers were amongst the first non-beta V1.0 sites Forte had.
Always thought it was a great product - incredibly productive to code in and
flexible for the server side - unlike that 3gl write once-crash anywhere
Java garbage.
--
OpenVMS - The never-advertised operating system with the dwindling ISV
base.
Ron Johnson
> Not surprising.
>
> If you need any help on the conversion, we have some people on-staff who
> used to be with Forte's software engineering & consulting team and who have
> a bunch of Siebel/Oracle experience.
>
> Some of my customers were amongst the first non-beta V1.0 sites Forte had.
> Always thought it was a great product - incredibly productive to code in and
> flexible for the server side - unlike that 3gl write once-crash anywhere
> Java garbage.
I'm sure that the app wasn't implemented well (no one in our group
had any OO experience back in 1998), and the framework that
consultants set up was a disaster.
Contact me off-line and I'll try to put you in touch with the right
person.
David J Dachtera
> [snip]
> That's crap .. Customers do not care what platform is being used to
> deliver the service they are contracting for as long as it is always
> available, always sub-second response times and it gets magically fixed
> 5 minutes before it breaks.
Um, Kerry?
Sorry to be the bearer of bad news, but that has not been true since the
Alphacide. See the concurrent thread titled, "Anyone know why the Alpha market
is so so quiet?".
> [snip]
> Saying "Customers do not want this platform or that platform" any more
> is really IT's way of promoting their own agenda and OS religion as a
> means to justify whatever their favourite program of the day is.
Actually, I wish that were true. If so, there'd be a lot more customers outside
HP's corporate offices with pitchforks, torches, tar and feathers in hand
demanding EV9 and later.
> And that usually boils down to OS religion and hype of key techies in
> the IT organization who have Managers who are afraid to disagree as it
> might position them as being to much from the old school.
Try again. Our managers would love nothing better than a return to the machines
that run z/OS. AIX on p-series is their second choice since Power-5 has such a
tremendous performance advantage over EV7z (and, of course, EV7z systems perform
better overall than I64 SuperDomes). Power-6 is, of course, "out the door" at
IBM and ready for deployment, BTW. AIX-6 is now in field test, from what I hear.
...not to mention that my VMS job agent in Dice.com sent me no less than two IBM
jobs for migration specialists (VMS->AIX) Saturday (restricted to the Chicago
job market).
> Btw - If you have Customers (internal or external) dictating to you what
> the solution is vs. what their requirements are, then you are in a whole
> lot more trouble than just determining what is the next big platform of
> the day.
True - but not because of the customers' demands. The customer is, after all,
always right (the ones with the gold make the rules!).
Only Micro$lop is big enough to dictate that the vendor is always right!
Your bosses are blowing sunshine up your skirt again. Be careful about anyone
offering you a cup of Kool-Aid...
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
JF Mezei
> How many people do you think know or care what runs as the primary
> platform for Google?
Google is special because part of their database might go offline and
the "system" would still appear to function. It just wouldn't return all
hits for what you are looking for.
Secondly, people do care what Google runs because they are a guide on
how to setup a very large system. If they can do it succesfully with
Linux on commodity boxes they build themselves, then other corporations
can also rely on Linux.
Arne Vajhøj
> That's crap .. Customers do not care what platform is being used to
> deliver the service they are contracting for as long as it is always
> available, always sub-second response times and it gets magically fixed
> 5 minutes before it breaks.
End users: no.
If you sell technology solutions to other companies: yes - they do care.
> Saying "Customers do not want this platform or that platform" any more
> is really IT's way of promoting their own agenda and OS religion as a
> means to justify whatever their favourite program of the day is.
No - it is a fact of life for all companies selling IT solution to
non end users.
Arne
Larry Kilgallen
> On 05/27/07 15:28, Larry Kilgallen wrote:
>> In article <4cl6i.7903$gM1....@newsfe21.lga>, Ron Johnson <ron.l....@cox.net> writes:
>>
>>> If you are a good sysadmin and have only installed the packages
>>> necessary for your application, then a single "yum update" command
>>> on your test box downloads all the *relevant* patch packages and
>>> installs them. When you are satisfied that the patches don't hose
>>> your system and can schedule an app downtime, run "yum update" again.
>>
>> So what is the syntax to switch from:
>>
>> "all the *relevant* patch packages"
>>
>> to
>>
>> "all the *relevant* patch packages as of the prior date"
>>
>> so that the only patch packages installed are those that were tested ?
>
> Well, you're only testing the patches* for the packages installed on
> that box, no? And the package manager "knows" if you've already
> installed a patch and if there are or aren't any updates for a given
> package.
No, you are testing those patches on a sacrificial test machine to
ensure they do not harm operations on the production machine. But
when it comes time to install on the production machines, you want
only patches that have been tested on the sacrificial test machine.
> And you can always enumerate specific packages if you
> don't want to install every relevant package.
Thereby removing any advantage of the simple syntax you touted.
That syntax is not appropriate for a production environment where
effective change control is in place.
> * Calling them patches is a fiction. They are full-blown updated
> packages.
My use is "patch" as in "afterthough due to earlier inadequate design
or testing". To say that it is bigger just says that a longer test
period is appropriate.
Larry Kilgallen
> See the last paragraph in this post, and ask yourself if NASDAQ
> would accept that.
> Except when it crashes due to a suck-arse TCP/IP implementation,
> taking down 3 servers in the middle of the day!
You have a choice of multiple TCP/IP implementations on VMS.
Main, Kerry
> From: Ron Johnson [mailto:ron.l....@cox.net]
> Sent: May 28, 2007 11:14 AM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
> [snip]
> >>
> >> Just like in 1998 they wanted GUI and in came Forte and fat client
> >> machines.
> >>
> >
> > deliver the service they are contracting for as long as it is always
> > available, always sub-second response times and it gets magically
> fixed
> > 5 minutes before it breaks.
>
>
My statement referred to internal IT environment.
I do agree that a contractors strategy is typically to win the business
and worry about the implementation later. Its why many Customers now
dictate fixed price contracts as they understand the old game of ``low
balling up front proposals and then up sell with change requests later`
game.
However, most contractors know that the OS platform NBT (next big thing)
changes every 3-4 years. So it is always amazing to hear Customers who
still want to chase the golden rainbow every where that it goes.
:-)
John Smith
> On 05/28/07 10:21, John Smith wrote:
>> Not surprising.
>>
>> If you need any help on the conversion, we have some people on-staff
>> who used to be with Forte's software engineering & consulting team
>> and who have a bunch of Siebel/Oracle experience.
>>
>> Some of my customers were amongst the first non-beta V1.0 sites
>> Forte had. Always thought it was a great product - incredibly
>> productive to code in and flexible for the server side - unlike that
>> 3gl write once-crash anywhere Java garbage.
>
> I'm sure that the app wasn't implemented well (no one in our group
> had any OO experience back in 1998), and the framework that
> consultants set up was a disaster.
>
> Contact me off-line and I'll try to put you in touch with the right
> person.
One of my partners will contact you either later today or tomorrow.
--
OpenVMS - The never-advertised operating system with the dwindling ISV and
customer base.
Ron Johnson
[snip]
>
> However, most contractors know that the OS platform NBT (next big thing)
> changes every 3-4 years. So it is always amazing to hear Customers who
> still want to chase the golden rainbow every where that it goes.
That I can agree with! If it were up to me, our app would be
written in COBOL and ACMS.
Arne Vajhøj
> The challenge with Linux (and Windows) is the sheer volume of monthly
> security patches and the impact they have on Operations and QA/Testing
> is mind boggling.
>
> That is experience talking vs. "ignore the faults, because I can manage
> my own small little world just fine, therefore all those other large
> shops struggling with little things like no App downtime, strict
> revision and config management and App re-cert testing processes just do
> not know what they are doing .."
They know what they are doing.
A lot of them are moving towards Linux.
> So are you saying that this is what a med shop must do every month for
> the 100+ Linux servers running all different versions of Linux?
They are not running 100 different versions of Linux more than they
are running 100 different versions of VMS or Solaris or z/OS.
> And what
> do they do when they ask the business for monthly shutdowns to apply
> these security patches?
They don't.
> Linux (and Windows) have a place, but lets get real with understanding
> the real Operations challenges when compared to more enterprise class
> platforms.
Let us understand that out in the real world companies are moving
to Linux.
> And what do you think large companies use for their standard OS
> versions? Do you think they want 20+ different config's running all
> across their 100+ Linux servers?
They do the same for Linux as for VMs as for Solaris as for z/OS ...
Arne
Main, Kerry
> From: Arne Vajhøj [mailto:ar...@vajhoej.dk]
> Sent: June 9, 2007 3:14 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
> > The challenge with Linux (and Windows) is the sheer volume of
> monthly
> > security patches and the impact they have on Operations and
> QA/Testing
> > is mind boggling.
> >
> > That is experience talking vs. "ignore the faults, because I can
> manage
> > my own small little world just fine, therefore all those other large
> > shops struggling with little things like no App downtime, strict
> > revision and config management and App re-cert testing processes
> just do
> > not know what they are doing .."
>
> They know what they are doing.
>
> A lot of them are moving towards Linux.
>
Yes, but most are ignoring the monthly security patch issues. I can almost guarantee that most senior IT managers have no idea that there are so many monthly security patches for Linux. And those in the IT shop that are promoting Linux as their new big thing are certainly not raising any alarms either.
> > So are you saying that this is what a med shop must do every month
> for
> > the 100+ Linux servers running all different versions of Linux?
>
> They are not running 100 different versions of Linux more than they
> are running 100 different versions of VMS or Solaris or z/OS.
>
Let me rephrase this .. In my experience in collecting inventory and version information for multi-platform consolidation projects, there are very few shops (none that I have found to date) that are running the same version of Linux on their many different Dev/Test/Prod Linux environments. And these systems can number in the hundreds when you factor in Dev/QA/Prod distributed environments in many different sites.
Different IT groups have different versions and different commitments to change and configuration management standards.
Now, having different version of OS is not so much an issue, but when you have 5-20 security patches for Linux being released each and every month, with different groups using different versions, it becomes a nightmare on how to keep each of these different environments current with the latest App and Kernel security patches.
And that does not even bring in the issues of testing the important Apps with these security patches before they are released to Prod.
For small-med shops, its not so much as big an issue if you have a really well run IT shop with limited numbers of systems being maintained by the same group.
> > And
> what
> > do they do when they ask the business for monthly shutdowns to apply
> > these security patches?
>
> They don't.
>
Since typically no production shop can shut down important services without getting approvals from the business, are you saying they don't apply these monthly security patches?
> > Linux (and Windows) have a place, but lets get real with
> understanding
> > the real Operations challenges when compared to more enterprise
> class
> > platforms.
>
> Let us understand that out in the real world companies are moving
> to Linux.
>
Absolutely. But lets not pretend that Linux is going to take over the world and that serious IT shops will not soon realize the real costs of adopting a platform that has 5-20 security patches released each and every month.
> > And what do you think large companies use for their standard OS
> > versions? Do you think they want 20+ different config's running all
> > across their 100+ Linux servers?
>
> They do the same for Linux as for VMs as for Solaris as for z/OS ...
>
> Arne
Yes, but these OS platforms (and that includes Solaris btw) do *not* have 5-20 security patches released each and every month.
Yes, all OS platforms have patches and bug fixes, but remember that these are hugely different than security patches as most serious company IT shops will always test and implement security patches when they are released, but may decide to implement other patches and fixes perhaps once per year (unless they have experienced a system crasher etc).
And for those that think they can hide behind a good firewall and not apply all these security patches, remember that 50-60% of all security issues are internal related.
Ron Johnson
Just like not all sites have their VMS systems running the same
version of VMS, ACMS, Rdb, etc.
> Different IT groups have different versions and different
> commitments to change and configuration management standards.
>
> Now, having different version of OS is not so much an issue, but
> when you have 5-20 security patches for Linux being released each
> and every month, with different groups using different versions,
> it becomes a nightmare on how to keep each of these different
> environments current with the latest App and Kernel security
> patches.
You've beaten this dead horse into a maggot-infested pulp.
According to my company's development group, our app runs
significantly faster on Oracle/Linux than it does on Rdb/Alpha.
The only reason you need 100s of distinct Linux boxes (unless you
are a co-lo service) is a residual Windows mentality. 4-core x86-64
systems can handle a whole lot of simultaneous tasks, just as VMS can.
Main, Kerry
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
[snip ...]
> >
> > Let me rephrase this .. In my experience in collecting inventory
> > and version information for multi-platform consolidation
> > projects, there are very few shops (none that I have found to
> > date) that are running the same version of Linux on their many
> > different Dev/Test/Prod Linux environments. And these systems can
> > number in the hundreds when you factor in Dev/QA/Prod distributed
> > environments in many different sites.
>
> Just like not all sites have their VMS systems running the same
> version of VMS, ACMS, Rdb, etc.
>
See my note below - running different versions is not the issue until
you have to test the Apps and patch them because of some security patch.
With Windows / Linux the sheer volume of these monthly security patches
is what makes running different versions so hard to manage.
> > Different IT groups have different versions and different
> > commitments to change and configuration management standards.
> >
> > Now, having different version of OS is not so much an issue, but
> > when you have 5-20 security patches for Linux being released each
> > and every month, with different groups using different versions,
> > it becomes a nightmare on how to keep each of these different
> > environments current with the latest App and Kernel security
> > patches.
>
> You've beaten this dead horse into a maggot-infested pulp.
>
So you agree then?
Good.
Let me guess, this would be the App group that wants to move to Linux,
right?
mmmm... any developer can make one platform outperform another if they
want to.
Also, many developers typically look at platforms from their perspective
only. Seldom do they look at it from an Operations perspective, i.e.
"how do we test and patch this app every month?"
> The only reason you need 100s of distinct Linux boxes (unless you
> are a co-lo service) is a residual Windows mentality. 4-core x86-64
> systems can handle a whole lot of simultaneous tasks, just as VMS can.
>
You are to far down in the weeds. The HW has nothing (ok, very little)
to do with it. It has to do with:
- how well multiple applications will run together under a single OS,
- culture of App developers in different groups agreeing to support
their application on the same server and same OS as another number of
groups,
- getting every Dev group to agree on standards .. like no developer has
direct access to production systems. That's always a lively discussion.
- culture of ISV's on that platform ie. how willing are they to support
their application running on the same server as a number of different
ISV and locally developed applications.
Why do you think most Wintel / Linux servers today are running less than
20% utilization in peak times?
Why do you think VMware is so hot these days for both Windows and Linux
environments?
Its because the culture of Windows and Linux App or ISV environments are
still stuck in the one App, one server culture. VMware allows them to
achieve some HW savings but still keep the one app, one server culture,
so technically and politically, it is an easy solution to implement.
The next big step will be to consolidate OS instances as that is where
the biggest savings are (FTE counts are tied to OS instances) and then
that is when the fun will really begin in the Wintel / Linux
environments.
:-)
Ron Johnson
It *is* good that you agree that you've bean that dead horse into a
maggot-infested pulp.
>>> And that does not even bring in the issues of testing the
They did that testing *after* the word came down that we WILL
migrate off of VMS.
The alternatives were HP-UX and Linux. If Windows Server was ever a
choice, I never heard of it.
> mmmm... any developer can make one platform outperform another if they
> want to.
>
> Also, many developers typically look at platforms from their perspective
> only. Seldom do they look at it from an Operations perspective, i.e.
> "how do we test and patch this app every month?"
We cycle the application every Saturday night, to app patches and
feature upgrades.
Gives us DBAs time to do work on the databases that would otherwise
block or be blocked by the on-line system.
>> The only reason you need 100s of distinct Linux boxes (unless you
>> are a co-lo service) is a residual Windows mentality. 4-core x86-64
>> systems can handle a whole lot of simultaneous tasks, just as VMS can.
>>
>
> You are to far down in the weeds. The HW has nothing (ok, very little)
> to do with it. It has to do with:
> - how well multiple applications will run together under a single OS,
> - culture of App developers in different groups agreeing to support
> their application on the same server and same OS as another number of
> groups,
> - getting every Dev group to agree on standards .. like no developer has
> direct access to production systems. That's always a lively discussion.
> - culture of ISV's on that platform ie. how willing are they to support
> their application running on the same server as a number of different
> ISV and locally developed applications.
You mean that each ISV wants to put their app on a dedicated box?
> Why do you think most Wintel / Linux servers today are running less than
> 20% utilization in peak times?
>
> Why do you think VMware is so hot these days for both Windows and Linux
> environments?
>
> Its because the culture of Windows and Linux App or ISV environments are
> still stuck in the one App, one server culture. VMware allows them to
> achieve some HW savings but still keep the one app, one server culture,
> so technically and politically, it is an easy solution to implement.
Seems pretty foolish, if you ask me.
> The next big step will be to consolidate OS instances as that is where
> the biggest savings are (FTE counts are tied to OS instances) and then
> that is when the fun will really begin in the Wintel / Linux
> environments.
I actually do agree with you on this issue.
Main, Kerry
> From: Ron Johnson [mailto:ron.l....@cox.net]
> Sent: June 10, 2007 3:30 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
[snip ..]
> >> The only reason you need 100s of distinct Linux boxes (unless you
> >> are a co-lo service) is a residual Windows mentality. 4-core x86-
> 64
> >> systems can handle a whole lot of simultaneous tasks, just as VMS
> can.
> >>
> >
> > You are to far down in the weeds. The HW has nothing (ok, very
> little)
> > to do with it. It has to do with:
> > - how well multiple applications will run together under a single
> OS,
> > - culture of App developers in different groups agreeing to support
> > their application on the same server and same OS as another number
> of
> > groups,
> > - getting every Dev group to agree on standards .. like no developer
> has
> > direct access to production systems. That's always a lively
> discussion.
> > - culture of ISV's on that platform ie. how willing are they to
> support
> > their application running on the same server as a number of
> different
> > ISV and locally developed applications.
>
> You mean that each ISV wants to put their app on a dedicated box?
>
Welcome to the world of Windows and Linux - that great new frontier.
> > Why do you think most Wintel / Linux servers today are running less
> than
> > 20% utilization in peak times?
> >
> > Why do you think VMware is so hot these days for both Windows and
> Linux
> > environments?
> >
> > Its because the culture of Windows and Linux App or ISV environments
> are
> > still stuck in the one App, one server culture. VMware allows them
> to
> > achieve some HW savings but still keep the one app, one server
> culture,
> > so technically and politically, it is an easy solution to implement.
>
> Seems pretty foolish, if you ask me.
>
Welcome to the world of Windows and Linux - that great new frontier.
> > The next big step will be to consolidate OS instances as that is
> where
> > the biggest savings are (FTE counts are tied to OS instances) and
> then
> > that is when the fun will really begin in the Wintel / Linux
> > environments.
>
> I actually do agree with you on this issue.
>
> --
> Ron Johnson, Jr.
> Jefferson LA USA
>
> Give a man a fish, and he eats for a day.
> Hit him with a fish, and he goes away for good!
Similar to the monthly security issues, these one app, one server
culture issues are the issues that senior managers only find out after
the initial decisions are made.
And of course, the lower level techies or those who do understand are
not saying anything about these during the decision making process
because raising any doubts on the next big thing might be grounds for
getting the dinosaur label attached to their neck.
Here is something to consider. A new trend is developing (and being
promoted by big SW companies like SAP) is Tier consolidation whereby OS
instances are reduced by placing the App server(s) on the same server as
the DB. Since most servers are only running less than 20% in peak time,
this makes a lot of sense - you just need to ensure things like workload
mgmt are in place to ensure one process does not do something silly and
impact other processes. No big deal as this has been a practice on many
other platforms for years (including OpenVMS).
You not only eliminate OS instances, but also network latency issues, as
well as provide a common OS environment for doing batch jobs.
Now, ask your Dev team that is hot for Linux how they plan to address
this growing trend in the future i.e. a common platform for the App
server, db and batch environment.
Want to bet they will say they need a separate server for each
Application and DB?
Want to bet they have likely not even thought or included the pricing
for converting and migrating their batch requirements (some environments
run hundreds of jobs per day) or their many supporting Operational
applications with associated custom code developed over many years that
now must also change as part of the new platform?
Dr. Dweeb
Mmm. So you are not a multi-billion dollar SOX compliant 365*24*7
production shop that measures downtime downtime per hour at rates higher
than your salary then? So what you do is fairly irrelevant, because you
clearly either (1) do not have the requirements of which we are discussing,
and/or (b) you have successfully hidden them from the PHBs.
Its the business requirements that drive the problem. Sadly, there are not
enough businessmen as IT bosses, just a lot of slick Willie's looking for a
quick buck, stock options and an exit strategy before it all goes titsup, or
someone with a brain catches em.
Dweeb
JF Mezei
> Yes, but most are ignoring the monthly security patch issues. I can almost guarantee that m
(please arrange your non-compliant microsoft software to break lines at
70 to 75 characters per line).
Now, if I were working for a competitor of VMS, I would respond with:
It is better to get patches regularly than getting total silence about
whether VMS is impacted or not but its implementation of the same
software, or having to wait for the next release of FVMS to get things
fixed (and hoping the release notes actually mention that this problem
has been fixed).
One can easily argue that the lack of patches for VMS isn't because ot
doesn't need anym but because the engineers do not have the
time/budget/resources to issue the patches.
Main, Kerry
> -----Original Message-----
> From: JF Mezei [mailto:jfmezei...@vaxination.ca]
> Sent: June 10, 2007 5:19 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
> > Yes, but most are ignoring the monthly security patch issues. I can
> almost guarantee that m
>
>
> (please arrange your non-compliant microsoft software to break lines
> at
> 70 to 75 characters per line).
>
>
> Now, if I were working for a competitor of VMS, I would respond with:
>
> It is better to get patches regularly than getting total silence about
> whether VMS is impacted or not but its implementation of the same
> software, or having to wait for the next release of FVMS to get things
> fixed (and hoping the release notes actually mention that this problem
> has been fixed).
>
Ah yes, the old competitive "if you can't match the competition, make
something up and throw FUD at it .."
And then someone on the side of OpenVMS would respond with whitepaper
pointers that describe how OpenVMS security was designed into the
architecture from the beginning and not an add-on later in the game like
some other platforms.
And then as a competitor, you would say ...
Bottom line is that OpenVMS Engineering has a proven history and assigns
a very high priority of fixing any security issues it finds out about
(whether it is internal or external generated).
>
> One can easily argue that the lack of patches for VMS isn't because ot
> doesn't need anym but because the engineers do not have the
> time/budget/resources to issue the patches.
One can make up unsubstantiated FUD all they want. Heck, one could say
IBM was buying Sun next week to discourage a Cust from choosing Solaris,
but that would only sink ones reputation in the eyes of that Customer as
they know its not true.
JF Mezei
> And then someone on the side of OpenVMS would respond with whitepaper
> pointers that describe how OpenVMS security was designed into the
> architecture from the beginning and not an add-on later in the game like
> some other platforms.
Yep. Did you guys ever issue ANY statement on whether the TCPIP Services
BIND software for VAX (bind 8) had the vulnerabilities that were
published a LONG time ago ?
When more and more of the software on VMS comes from unixland, all those
unixland bugs also make it to VMS.
Consider that you guys dropped Pathworks in favour of Samba. So, when a
Samba bug in found in the rest of the world, will VMS engineers remain
silent on whether it is present on VMS or whether it had been written
out during the port to VMS ?
Ron Johnson
> Ron Johnson wrote:
[snip]
>> We cycle the application every Saturday night, to app patches and
>> feature upgrades.
>>
>
> Mmm. So you are not a multi-billion dollar SOX compliant 365*24*7
> production shop that measures downtime downtime per hour at rates higher
> than your salary then? So what you do is fairly irrelevant, because you
> clearly either (1) do not have the requirements of which we are discussing,
> and/or (b) you have successfully hidden them from the PHBs.
Well, we used to be (kinda, since Enron was still flourishing when
we took a wrong path), until management took the advice of a couple
of (well-respected, because they are *very* smart and really know
VMS and Rdb) ex-DEC Consultants members of the technical staff who
love everything related to DEC, and so lead us down the Forte'
garden path of doom.
Before that, the app was written in C and functioned *very* well.
Uptimes were regularly around 6 months.
I proposed COBOL and DECforms, but no one listened.
Ron Johnson
>> -----Original Message-----
>> From: Ron Johnson [mailto:ron.l....@cox.net]
[snip]
>
> Here is something to consider. A new trend is developing (and being
> promoted by big SW companies like SAP) is Tier consolidation whereby OS
> instances are reduced by placing the App server(s) on the same server as
> the DB. Since most servers are only running less than 20% in peak time,
> this makes a lot of sense - you just need to ensure things like workload
> mgmt are in place to ensure one process does not do something silly and
> impact other processes. No big deal as this has been a practice on many
> other platforms for years (including OpenVMS).
And how things used to on Unix. Remember, it *is* a timesharing OS,
just like VMS.
> You not only eliminate OS instances, but also network latency issues, as
> well as provide a common OS environment for doing batch jobs.
True. Depending on how beefy your server is, and how parsimonious
the CFO is. Since it's being rewritten in Oracle and hosted on a
SAN, moving the batch cycle to another machine (a blade, maybe)
shouldn't be "that much" of a chore if the database+batch machine
gets burdened.
Which is what has happened on 2 of our VMS clusters. But one of
them is /finally/ migrating to a GS1280. Yay!!! I guess the string
of crashes attributed to ancient hardware pried open the purse strings.
I guess the falling price of used Alpha kit made it palatable.
> Now, ask your Dev team that is hot for Linux how they plan to address
> this growing trend in the future i.e. a common platform for the App
> server, db and batch environment.
See, that's the beauty of client-server. If it's written in a
network-centric manner, the apps don't care where they are.
And since x86 Gbit NICs cost probably the same as 100Mb NICs that
are VMS-qualified, and 4Gbit Linux-qualified HBAs are also readily
available, making the database server a bandwidth demon is pretty
darned simple.
And the forever-growing power of x86-64 h/w means that if "they" do
decide to keep it host-based, regular guts swaps are pretty darned
cheap.
> Want to bet they will say they need a separate server for each
> Application and DB?
>
> Want to bet they have likely not even thought or included the pricing
> for converting and migrating their batch requirements (some environments
> run hundreds of jobs per day)
If *management* did not factor that into the contract with our
clients (who wanted off of VMS), then shame on them, not the developers.
> or their many supporting Operational
> applications with associated custom code developed over many years that
You must think us flaming idiots.
> now must also change as part of the new platform?
They may be "just" developers, but they're not stupid.
A dozen or so of the lead developers have been with the project 8
years or more (in that time, 2 of them have had the time to segue
from "Indian consultants wanting to return in 5 years" to married-
with-children naturalized citizens).
Main, Kerry
> From: JF Mezei [mailto:jfmezei...@vaxination.ca]
> Sent: June 10, 2007 8:03 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
> > And then someone on the side of OpenVMS would respond with
> whitepaper
> > pointers that describe how OpenVMS security was designed into the
> > architecture from the beginning and not an add-on later in the game
> like
> > some other platforms.
>
> Yep. Did you guys ever issue ANY statement on whether the TCPIP
> Services
> BIND software for VAX (bind 8) had the vulnerabilities that were
> published a LONG time ago ?
>
No idea. I assume if it was an issue, it was fixed. If it was not an
issue there was no need to fix anything.
> When more and more of the software on VMS comes from unixland, all
> those
> unixland bugs also make it to VMS.
>
Yes, but do not assume that just because a bug in one platform
implementation of an app automatically means it will be an issue with
all platform implementations of the application.
> Consider that you guys dropped Pathworks in favour of Samba. So, when
> a
> Samba bug in found in the rest of the world, will VMS engineers remain
> silent on whether it is present on VMS or whether it had been written
> out during the port to VMS ?
Same thing as for Apache on OpenVMS .. if there is an issue, I assume it
will be fixed.
Regards
JF Mezei
> No idea. I assume if it was an issue, it was fixed. If it was not an
> issue there was no need to fix anything.
Customers don't pay support money to "assume" it is an issue or not.
They pay real money to be informed that a very public bug applies or
does not apply to the VMS version, and that if it does apply, a patch is
available quickly.
If the VMS engineers tested the Bind stuff and found it did not applu,
they should have made a statement to that effect.
And this would have beena good statement to make since it would have
been <cough> good marketing </cough> for VMS, showing how the unix
software, when ported to VMS is of better quality.
By remaining silent, customers have to wonder if engineers tested and
found no issue, whethere engineers are asleep at the switch, or whether
VMS management doesn't allow vms engineers to test and fix such problems
due to priorities etc.
Bob Koehler
>
> Yes, but most are ignoring the monthly security patch issues. I can =
> almost guarantee that most senior IT managers have no idea that there =
> are so many monthly security patches for Linux. And those in the IT shop =
> that are promoting Linux as their new big thing are certainly not =
> raising any alarms either.
The current accepted standard in the IT industry is install and patch
and patch ...
The IT shop has no idea they're doing anything out of the ordinary
that might be cause for alarm.
And as long as the owners of more secure OS refuse to advertise what
computers can actually do the IT shops of the world will continue
to be clueless.
There are lots of consultants who will teach you how to "secure"
your low security systems and no one saying otherwise.
\
Bob Koehler
> We cycle the application every Saturday night, to app patches and
> feature upgrades.
Most big businesses these days can no longer aford that downtime.
Saturday night in the US is a fairly busy time in the world. Not
everybody goes to church Sunday morning.
Ron Johnson
I agree. Setting the web site to Not Available stuns the heck out
of me, too. If I were a customer, I'd be pretty irate.
This never happened when we wrote all our code in a DEC language. :(
Arne Vajhøj
>>> So are you saying that this is what a med shop must do every
>>> month for
>>> the 100+ Linux servers running all different versions of Linux?
>> They are not running 100 different versions of Linux more than they
>> are running 100 different versions of VMS or Solaris or z/OS.
>
> Let me rephrase this .. In my experience in collecting inventory and
> version information for multi-platform consolidation projects, there
> are very few shops (none that I have found to date) that are running
> the same version of Linux on their many different Dev/Test/Prod Linux
> environments. And these systems can number in the hundreds when you
> factor in Dev/QA/Prod distributed environments in many different
> sites.
>
> Different IT groups have different versions and different commitments
> to change and configuration management standards.
Same as for any other OS.
> Now, having different version of OS is not so much an issue, but when
> you have 5-20 security patches for Linux being released each and
> every month, with different groups using different versions, it
> becomes a nightmare on how to keep each of these different
> environments current with the latest App and Kernel security patches.
>
> And that does not even bring in the issues of testing the important
> Apps with these security patches before they are released to Prod.
Most of those systems does not get all those patches.
>>> And what
>>> do they do when they ask the business for monthly shutdowns to
>>> apply these security patches?
>> They don't.
>
> Since typically no production shop can shut down important services
> without getting approvals from the business, are you saying they
> don't apply these monthly security patches?
Depends on what systems. Those systems in direct contact with
potential hostile users get patches. The backend where all the
critical apps that may need retest if touched does not.
>>> Linux (and Windows) have a place, but lets get real with understanding
>>> the real Operations challenges when compared to more enterprise class
>>> platforms.
>> Let us understand that out in the real world companies are moving
>> to Linux.
>
> Absolutely. But lets not pretend that Linux is going to take over
> the world and that serious IT shops will not soon realize the real
> costs of adopting a platform that has 5-20 security patches released
> each and every month.
Linux will not take over the world next year.
The patch problem is not really a problem. So do not expect that
to have any effect.
> And for those that think they can hide behind a good firewall and not
> apply all these security patches, remember that 50-60% of all
> security issues are internal related.
Yes.
And as I have already asked in another thread without getting
an answer: how many of those 50-60% uses security holes in software ?
Arne
Arne Vajhøj
> Here is something to consider. A new trend is developing (and being
> promoted by big SW companies like SAP) is Tier consolidation whereby OS
> instances are reduced by placing the App server(s) on the same server as
> the DB. Since most servers are only running less than 20% in peak time,
> this makes a lot of sense - you just need to ensure things like workload
> mgmt are in place to ensure one process does not do something silly and
> impact other processes. No big deal as this has been a practice on many
> other platforms for years (including OpenVMS).
>
> You not only eliminate OS instances, but also network latency issues, as
> well as provide a common OS environment for doing batch jobs.
>
> Now, ask your Dev team that is hot for Linux how they plan to address
> this growing trend in the future i.e. a common platform for the App
> server, db and batch environment.
>
> Want to bet they will say they need a separate server for each
> Application and DB?
They may or they may not.
There are nothing preventing them from doing the same thing
on Linux.
Why do you think Xen was added to RHEL 5 ?
Arne
Stephen Hoffman
> Main, Kerry wrote:
>> Now, ask your Dev team that is hot for Linux how they plan to address
>> this growing trend in the future i.e. a common platform for the App
>> server, db and batch environment.
>>
>> Want to bet they will say they need a separate server for each
>> Application and DB?
>
> They may or they may not.
>
> There are nothing preventing them from doing the same thing
> on Linux.
>
> Why do you think Xen was added to RHEL 5 ?
Xen certainly works nicely for this approach.
With the Parallels (US$49) package, I can run Mac OS X, Windows as
far back as MS-DOS, Linux, and other x86-class operating systems -- and
on the same box. Underneath, there can be Mac OS X, any of various
Windows, or Linux platforms. And various guest operating systems. And
as the product name indicates, in parallel. This whether you're
running your software on an Xserve or a ProLiant box, or on some other iron.
It might be entertaining to load and fire up SIMH or another hardware
emulation on one of that tool's various platforms, and running that
platform as a guest underneath Parallels or Xen. That's one of the few
ways where you could get OpenVMS applications involved within one of
these software stacks -- this for VAX stuff, and emulation. (When last
investigated, there were fewer options for Itanium -- the central option
was HP-VM on HP-UX, and that seemingly hadn't been fully vetted for use
with OpenVMS I64. Xen didn't have support for the four OpenVMS modes,
though that may well have changed.)
Xen and Parallels and similar virtualizing tools are at the core of
the classic server consolidation scheme, as well as how you can manage
and upgrade and patch and maintain multiple operating systems, and
operating system instances.
The next wave after the current server hardware and power and
mixed-environment software consolidation will almost certainly involve
getting rid of many of these operating systems and applications; it'll
target consolidation of the software stacks.
--
www.HoffmanLabs.com
Services for OpenVMS
Main, Kerry
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
[big snip ...]
> >> Let us understand that out in the real world companies are moving
> >> to Linux.
> >
> > Absolutely. But lets not pretend that Linux is going to take over
> > the world and that serious IT shops will not soon realize the real
> > costs of adopting a platform that has 5-20 security patches released
> > each and every month.
>
> Linux will not take over the world next year.
>
> The patch problem is not really a problem. So do not expect that
> to have any effect.
>
You are looking at this from a developer who wants to believe this perspective - not from a reality Operations view.
Most BU's do not care what the IT group uses as platforms, but they do expect that there will be slim to zero security issues and for that these BU's and senior managers have near zero tolerance.
If a major breach is exposed or incident happens because IT did not apply a known patch to a specific documented security issue, who's head do you think will be served up on a platter?
The Dev group? No.
The Operations group - you bet. Hence, the focus on security is always more prevalent from an Operations perspective than a developers perspective.
> > And for those that think they can hide behind a good firewall and
> not
> > apply all these security patches, remember that 50-60% of all
> > security issues are internal related.
>
> Yes.
>
> And as I have already asked in another thread without getting
> an answer: how many of those 50-60% uses security holes in software ?
>
> Arne
As I mentioned in another thread, disgruntled employees using known passwords is only one small part of the problem. [Course, the password issues are worse on platforms that have all or user type environments, but that is another discussion.]
Re: software security - Well, what do you think, trojans, worms, viruses on all those personal devices attack with?
They reside on laptops, PDA's memory sticks, cell phones and what ever other personal devices are out there. They are all looking for known WS and server services exploits to attack. And most traverse external and internal networks all the time which exponentially increases the chances of picking up some nasty bug.
Main, Kerry
> From: Arne Vajhøj [mailto:ar...@vajhoej.dk]
> Sent: July 4, 2007 6:34 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
> > Here is something to consider. A new trend is developing (and being
> > promoted by big SW companies like SAP) is Tier consolidation whereby
> OS
> > instances are reduced by placing the App server(s) on the same
> server as
> > the DB. Since most servers are only running less than 20% in peak
> time,
> > this makes a lot of sense - you just need to ensure things like
> workload
> > mgmt are in place to ensure one process does not do something silly
> and
> > impact other processes. No big deal as this has been a practice on
> many
> > other platforms for years (including OpenVMS).
> >
> > You not only eliminate OS instances, but also network latency
> issues, as
> > well as provide a common OS environment for doing batch jobs.
> >
> address
> > this growing trend in the future i.e. a common platform for the App
> > server, db and batch environment.
> >
> > Want to bet they will say they need a separate server for each
> > Application and DB?
>
> They may or they may not.
>
> There are nothing preventing them from doing the same thing
> on Linux.
>
> Why do you think Xen was added to RHEL 5 ?
>
Because having servers running in peak time with only 5-15% peak utilization is not only embarrassing, but financially unjustifiable. Same issue with Windows and why VMware is so hot these days.
But like VMware, Xen only addresses HW consolidation - not OS consolidation. Yes, it does have some benefits in terms of HW (power, cooling, space etc) savings. However, OS maintenance (managing, patching, licensing, upgrading) is where the big cost savings are as this directly relates to FTE staffing counts - by far the biggest slice of any IT budget.
OS stacking with the likes of Xen, VMware are a temporary savings. Once this wave is near completion, the next question will be - "ok, now how do we do OS consolidation to reduce our FTE counts"?
Paul Raulerson
with SOX auditing firms to come in and audit every single one of those
issues. The auditors are not always well experienced in the technologies
being used, but they are usually smart enough to recognize a problem when
they see it.
And there are serious repercussions to failing a SOX audit - up to and
including being delisted from the stock exchange and/or jail time. You bet
we take things seriously when we have our OPS hats on. And, despite all the
infrastructure design in the world, we still have to apply security patches.
Given that, we do NOT apply patches randomly or without upfront testing.
Production systems are just too darn *important* to mess up. But we *do*
the testing necessary and *do* apply whatever patches are necessary. Note
that Novell has sent out at least 100 patch notices in the past 60 days for
SuSE Linux.
We don't get nearly as many updates for other OS's - and what we do get are
often engineering changes. That is, except for Windows and the attendant
Microsoft applications. Those, we get a LOT more of. "Patch Tuesday" is NOT
a happy time in my shop!
-Paul
> -----Original Message-----
> From: Main, Kerry [mailto:Kerry...@hp.com]
> Sent: Thursday, July 05, 2007 6:34 AM
> To: Info...@Mvb.Saic.Com
> Subject: RE: Is VMS losing the Financial Sector, also?
>
>
> > -----Original Message-----
> > From: Arne Vajhøj [mailto:ar...@vajhoej.dk]
> > Sent: July 4, 2007 6:31 PM
> > To: Info...@Mvb.Saic.Com
> > Subject: Re: Is VMS losing the Financial Sector, also?
> >
>
JF Mezei
In the late 1990s, the weenies would convince management to deploy
Windows because it was a lot cheaper, there were a lot more available
staff and it had an assured future. When asked if there was a virus
problem, the answer would inevitably be "we'll set it up properly and it
won't affect us".
By the time they got hit with I LOVE YOU or some other debilitating
event, their deployment of windows was so entrenched that it was
impossible to change to a real OS so thet learned to live with it and
try to minimise the damage.
Your story of Vista switching back to VMS because of a windows virus is
very good, but unfortunatly rare.
JF Mezei
> Because having servers
> running in peak time with
>only 5-15% peak utilization is
>not only embarrassing, but financially
> unjustifiable.
1- Please fix your client so it abides by internet standard instead of
Microsoft standard and breaks lines at between 72 and 78 characters per
line. Having to break your lines because your use Microsoft isn't pleasant.
2- The same can be said of mainframes. Back when MVS was called MVS, I
knew of a bank that had 16 instances of MVS. One of the big problem they
had was that each different application was certified to run on a
certain set of middleware versions. So when a new version of CICS came
out to fix a problem with application X, they would only install on on
the instance running application X because applications Y and Z were not
yet certified to run on CICS of that version.
Because this was IBM and a BANK, the bank was able to put pressure on
their software suppliers to get their act together and start having
faster certification on the latest and greatest IBM versions so that the
bank wouldn't need to maintain so many instances of MVS. (with CICS,
IMS, DB2 all mixed in there).
Fast forward to today with shrink-wrapped software. Companies don't
actually have a real relationship with the windows software vendor so
they have no leverage to get all software vendors to structure and
package their apps so that they can co-exist on the same instance of
Windows. As a result, you need separate instances of windows to run the
software. But because wintel gear is cheap, low cost commodity, it
really isn't a problem to have those boxes.
You mention it being a problem. But consider that those companies had no
problem deploying those many many 1 app servers.
It is only because trade rags are now pushing for virtualisation that
they are seeing pressure to also jump on the bandwagon.
Main, Kerry
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
Well, imho, platform decisions are often driven by whether the company
is moving to distributed or centralized systems.
The timeframes you are talking about were focussed very heavily on
distributed systems. Windows servers did very well in that environment.
Times change. Not over night, but they do change.
With out a doubt, the industry is moving back to much more centralized
computing strategies. The impact and cost of managing, licensing and
upgrading so many distributed servers that are at their peak running
5-15% utilization is no longer sustainable.
So, the questions now being raised are "if we move back to centralized
models (with closer ties to BU's), what is the best strategy to do this?
Imho, the question to be asked is "Is Windows and/or Linux the best
platform with their one app, one server culture and monthly security
patches the best strategy for a much more centralized computing future?"
For some it may be yes. For others, like VISTA (and other Windows to
OpenVMS switches I know about), the answer will be no.
Main, Kerry
> From: JF Mezei [mailto:jfmezei...@vaxination.ca]
> Sent: July 5, 2007 11:19 AM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
> > Because having servers
> > running in peak time with
> >only 5-15% peak utilization is
> >not only embarrassing, but financially
> > unjustifiable.
>
>
>
>
> 1- Please fix your client so it abides by internet standard instead of
> Microsoft standard and breaks lines at between 72 and 78 characters
> per
> line. Having to break your lines because your use Microsoft isn't
> pleasant.
>
I have now set my client to break at 72 characters (it was 75). Is this
what you were referring to?
Other than setting the line break, there are no other email options that
I have.
These were hidden in that huge management costs were not fully
understood at the time.
> It is only because trade rags are now pushing for virtualisation that
> they are seeing pressure to also jump on the bandwagon.
>
No, this is not the issue.
It is because IT shops are under tremendous pressure to reduce IT costs
- now. And real costs - not imaginary or "soft" costs.
Virtualization is simply one of a number of strategies Cust's can adopt
to obtain those IT savings.
Bill Gunshannon
And probably not the whole (or even the real) story as what people use
Vista for can not be done on VMS. Vista is a desktop operating system,
not a server operating system.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
JF Mezei
> Imho, the question to be asked is "Is Windows and/or Linux the best
> platform with their one app, one server culture and monthly security
> patches the best strategy for
The owner of any competing platform would very much want to see his
product in that list of options to move to. And you'll find Sun very
much wantin to insert "Solaris" in those options. You will not find HP
pushing VMS though. VMS should be in that list.
If we are on the start of a paradigm change, then VMS has a good chance
of catching the train and be in there to get sales. If you wait too
long, then it will again miss the train and be left behind.
Main, Kerry
> From: bi...@triangle.cs.uofs.edu [mailto:bi...@triangle.cs.uofs.edu]
> On Behalf Of Bill Gunshannon
> Sent: July 5, 2007 12:43 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
Bill...
mmm.. you missed the point.
The earlier URL points to a company called VISTA that packages or uses a
mission critical software package called SCADA on a number of platforms.
One of their Customers was running Windows Server and was down for 2
days because of a nasty virus. Subsequently, they have since switched to
OpenVMS on Integrity and by the report, the migration went very well.
Absolutely zero to do with client stuff.
Paul Raulerson
I keep wondering - why in the devil do you expect HP, or any other sane company, to push a product that generates so much negative nonsense as this?
FIND SOME BLINKING MARKETS AND START SELLING.
HP will sit up and notice that, and start backing you up. I'm about 60% convinced that VMS can do everything I need it to do, and will save my customers and myself money doing it. I belive it has all the technical capabilities it needs to handle small and medium shops. It has the potentional to grow to handle larger shops.
HP has huge name recognition, a very good reputation, and some very good tecnincal products. They have a good developer program that fully supports OpenVMS, and on top of that, they have co-marketing programs and other benefits.
What they do not have is 1000 people out here finding solutions that OpenVMS can fit into and make a decent profit. That, by the way, is the other 30% of me that wonders if this is a vain exercise. The other 10% is a worry that HP won't develop the hardware needed to run VMS in a larger environment, or that VMS will not properly scale to a large transaction processing environment. Maybe it is not meant to.
-Paul
Bill Gunshannon
"Main, Kerry" <Kerry...@hp.com> writes:
>> And probably not the whole (or even the real) story as what people
>> use
>> Vista for can not be done on VMS. Vista is a desktop operating
>> system,
>> not a server operating system.
>> bill
>>=20
>
> Bill...
>
> mmm.. you missed the point.
>
> The earlier URL points to a company called VISTA that packages or uses a
> mission critical software package called SCADA on a number of platforms.
> One of their Customers was running Windows Server and was down for 2
> days because of a nasty virus. Subsequently, they have since switched to
> OpenVMS on Integrity and by the report, the migration went very well.
>
> Absolutely zero to do with client stuff.
OK, sorry. When one uses the terms "Vista" and Windows in the same
paragraph today certain assumptions are bound to be made. So then,
this just goes back to the original argument about someone was doing
with a servert hat allowed it to come in contact with a virus!! If
the VMS system is managed as badly as the Windows system obviously
was they are bound to have problems even with VMS. Not necessarily
the same problems, but problems and possibly security problems. No
OS is immune from the effects of incompetent sys admins.
Mark Berryman
If I read you correctly you seem to be claiming that only incompetently
managed Windows systems get infected. If so, you are far from correct.
There are many documented cases of systems being hacked and/or
infected even though they were up to date on patches and running current
antivirus software (as well as other protections). Look up the impact
of almost any zero-day exploit to name just one example.
Mark Berryman
Bill Gunshannon
There is a lot more to admining any system than just that. Starting
with a proper config.
> Look up the impact
> of almost any zero-day exploit to name just one example.
I don't have to all I have to do is look at systems that are not being
hacked/zombied/infected. A properly admined IT system, no matter what
the OS, is going to be stable, secure and usefull. The reciprical also
applies, no matter what the OS.
The fact that the news is loaded with cases of systems being hacked only
points out the fact that with the proliferation of IT systems has come
a dearth of competent sysadmins. Just because you admined the 2 PC's in
your high school library when you were a sophmore doesn't make you a
sysadmin. Any more than the fact that you ran a web site on Linux
out of your dad's garage during the dot-com boom made you an "IT
Professional". Maybe, in the name of true investigative reporting,
the journals running these aryicles should also publish the credentials
of the parties responsible for maintaining the systems. Oh wait, if
we did that we would have to stop bashing Windows, Unix. Can't have
that now, can we.....
David J Dachtera
>
> I keep wondering - why in the devil do you expect HP, or any other sane
> company, to push a product that generates so much negative nonsense as this?
>
> FIND SOME BLINKING MARKETS AND START SELLING.
How do we convince people to buy something that's "invisible"?
> HP will sit up and notice that, and start backing you up.
Don't hold your breath!
> I'm about 60%
> convinced that VMS can do everything I need it to do, and will save my
> customers and myself money doing it. I belive it has all the technical
> capabilities it needs to handle small and medium shops. It has the potentional
> to grow to handle larger shops.
VMS *DOES* handle larger shops. *THAT* is why HP doesn't want it!
HP wants to sell UX. HP does NOT want VMS. (Usual disclaimer applies: prove me
wrong!)
> HP has huge name recognition,
Somewhat true - more as a printer vendor than anything else, at least in the
business world.
> a very good reputation,
Where have you been the past 10 years?
> and some very good
> tecnincal products. They have a good developer program that fully supports
> OpenVMS,
That has been found highly debatable.
> and on top of that, they have co-marketing programs and other
> benefits.
...as long as you sell what HP wants you to sell.
> What they do not have
...and do not want...
> is 1000 people out here finding solutions that OpenVMS
> can fit into and make a decent profit. That, by the way, is the other 30% of
> me that wonders if this is a vain exercise.
Next question, please...
> The other 10% is a worry that HP
> won't develop the hardware needed to run VMS in a larger environment,
A very valid concern
> or that
> VMS will not properly scale to a large transaction processing environment.
They did. It was called, "Alpha".
> Maybe it is not meant to.
It *IS* meant to - but no longer can due to hardware platform limitations.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Paul Raulerson
Paul Raulerson wrote:I keep wondering - why in the devil do you expect HP, or any other sanecompany, to push a product that generates so much negative nonsense as this?FIND SOME BLINKING MARKETS AND START SELLING.How do we convince people to buy something that's "invisible"?
HP will sit up and notice that, and start backing you up.Don't hold your breath!
I'm about 60%convinced that VMS can do everything I need it to do, and will save mycustomers and myself money doing it. I belive it has all the technicalcapabilities it needs to handle small and medium shops. It has the potentionalto grow to handle larger shops.VMS *DOES* handle larger shops. *THAT* is why HP doesn't want it!
HP wants to sell UX. HP does NOT want VMS. (Usual disclaimer applies: prove mewrong!)
HP has huge name recognition,Somewhat true - more as a printer vendor than anything else, at least in thebusiness world.
a very good reputation,Where have you been the past 10 years?
and some very goodtecnincal products. They have a good developer program that fully supportsOpenVMS,That has been found highly debatable.and on top of that, they have co-marketing programs and otherbenefits....as long as you sell what HP wants you to sell.What they do not have...and do not want...
is 1000 people out here finding solutions that OpenVMScan fit into and make a decent profit. That, by the way, is the other 30% ofme that wonders if this is a vain exercise.Next question, please...
The other 10% is a worry that HPwon't develop the hardware needed to run VMS in a larger environment,A very valid concern
or thatVMS will not properly scale to a large transaction processing environment.They did. It was called, "Alpha".
John Santos
If competent administration is all that is needed to prevent a system from
being hijacked, then why do you need *any* antivirus software at all?
And why do you *ever* need to apply any patches?
The answer, of course, is that a system exposed to a virus or an unpatched
exploit can get hacked anyway, no matter how competent the administrator.
Keeping up on patches and A/V is part of the job of the administrator.
But there is a race condition. What if the bad guy attacks before the
O/S vendor knows about the exploit, or the A/V vendor designs, implements
and distributes a test for it? Then you're up the creek. What are the
chances of this happening? Obviously, the more viruses and serious O/S
bugs, the greater the odds.
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
P. Sture
wrote:
> The answer, of course, is that a system exposed to a virus or an unpatched
> exploit can get hacked anyway, no matter how competent the administrator.
> Keeping up on patches and A/V is part of the job of the administrator.
>
> But there is a race condition. What if the bad guy attacks before the
> O/S vendor knows about the exploit, or the A/V vendor designs, implements
> and distributes a test for it? Then you're up the creek. What are the
> chances of this happening? Obviously, the more viruses and serious O/S
> bugs, the greater the odds.
>
One problem there is that certain M$ patches have broken things,
sometimes quite seriously. This can lead to a certain reticence to apply
patches in a timely fashion.
--
Paul Sture
Bill Gunshannon
So, what, is everything mutually exclusive here? Using anti-virus
software (are you aware that you should actually be using at least
two different anti-virus prodicts?) and applying patches (as needed
based on your system and operational necessity) is part of being a
competent sys admin.
>
>
>
>
>
>
>
>
>
>
> The answer, of course, is that a system exposed to a virus or an unpatched
> exploit can get hacked anyway, no matter how competent the administrator.
Well, being as we are talking server boxes and not desktops, a competent
sysadmin doesn read email or surf the web with the server box which would
eliminate pretty much all the standard attack vectors. Which comes back
the Los Alamos story. Just how did the server get exposed to the virus?
> Keeping up on patches and A/V is part of the job of the administrator.
Of course it is. But that doesn't mean installing every patch wether it
applies to your system or not or applying it the second you hear it exists.
It is the sys admins job to decide the impact and then decide when and even
if the patch is an operational necessity. For example, if my server does
not need to serve up webpages I certainly wouldn't install the IIS component
on it. So then, why would I apply IIS patches?
>
> But there is a race condition. What if the bad guy attacks before the
> O/S vendor knows about the exploit,
Not knowing "the expolit" this question can obviously not be answered.
Of course, what if a meteor hits your data center and lands right on
top of your prime server? I try no tot loose sleep over things over
which I have no control.
> or the A/V vendor designs, implements
> and distributes a test for it?
If you don;t let your servers access the known virus vectors this is a
non-problem.
> Then you're up the creek. What are the
> chances of this happening? Obviously, the more viruses and serious O/S
> bugs, the greater the odds.
Well, the virus ones are easy to avoid, as I (and others) have repeatedly
pointed out. The others take a much more complete scheme but can be avoided
as well.
Main, Kerry
> From: P. Sture [mailto:paul.stu...@hispeed.ch]
> Sent: July 6, 2007 4:38 AM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Is VMS losing the Financial Sector, also?
>
>
> > The answer, of course, is that a system exposed to a virus or an
> unpatched
> > exploit can get hacked anyway, no matter how competent the
> administrator.
> administrator.
> >
> before the
> implements
> > and distributes a test for it? Then you're up the creek. What
> are the
> > chances of this happening? Obviously, the more viruses and
> serious O/S
> > bugs, the greater the odds.
> >
>
> sometimes quite seriously. This can lead to a certain reticence to
> apply
> patches in a timely fashion.
>
> --
> Paul Sture
Which is why experienced IT shops always test their important
applications with any new patches - especially security ones as it often
translates to access or auditing or authentication type errors.
This is also why using a platform that has 5-20 security patches
released *each and every* month is such a major impact on normal
QA/Testing and Operations staff. When you have hundreds of systems
(small-medium DC), think of the effort that this entails.
A few examples:
http://www.theregister.co.uk/2006/08/26/linux_update_shocker/
http://tinyurl.com/z9p4d
And in case anyone thinks this is a recent happening, here is article
from 2002:
http://www.eweek.com/article2/0,1759,1513928,00.asp
"More Patches Aren't the Answer"
Key extract (and remember this is from 2002):
" Sorry, but that doesn't cut it. First of all, as the broken patch for
IE illustrates, patches don't always fix things and can often cause new
problems. Using an automated patching tool means you are constantly at
risk of introducing new problems without any chance to do testing before
the patches are applied.
Of course, the other option is to watch alerts and use patch-scanning
tools and update systems yourself. Oh, you have another job that you
need to do? I'm sure you can squeeze it in between the hours you'll
spend finding the right patches, testing them, then deploying them."