The whole "vi is unfriendly" thing always gets me. What's unfriendly about
it? Sure the commands are not the most intuitive, but at the same time,
they are extremely powerful. Some of them even make sense - but I find
those to be the hardest to remember for some reason. Not only that, but
what you learn for vi, also applies to produces like sed (stream editor) and
regular expressions in general - and those are used constantly.
Fancy editors are nice, but I for one tend not to use them for one reason.
In a crisis situation where I don't have access to tools like qedit (though
this is an excellent product for those who don't like vi IMHO), I don't
necessarily have the time to pull out the vi manual and fumble my way
through.
As for patching, one thing I will say is at least patches are generated
quickly for problems. I've seen many cases where a problem is identified,
and the patch is released for unix first. Sure a lot of patches are
generated. I'll bet that a good number of those is to fix problems that are
identified using non-hp products. I'm not saying that you shouldn't use
non-hp products, I'm just saying that HPUX is going to have a whole lot more
of them than MPE.
Last HPUX server failure for me was over a year ago. I won't even mention
how many MPE failures we've had in that time frame.
This whole topic is kind of amusing to me in that I love MPE and wish it
wouldn't go away. Yet, I find myself defending HPUX. Strange.
-------------------------------------------------------------
Gary L. Paveza, Jr.
Production Support Analyst - Lead
(302) 761-3173 - voice
(877) 716-5096 - pager
[log in to unmask] - email pager
-----Original Message-----
From: Lynn Price [SMTP:[log in to unmask]]
Sent: Thursday, May 02, 2002 9:40 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] HP3000 and HP-UX
Just an additional statement about HPUX. We had three servers on
10.? and 2
on 11.0 where I use to work and installing patches was a regular
occurance.
Our 3000 was a very stable server (of course), but the 9000s went
down. We
received annoucements of OS patches at least weekly. In other words,
you
don't need to "plan" to reboot your server on a regular basis. The
reboot
after some of the patch installations will force you to do it
anyway. The
differences in HPUX and MPE? Let's just say....... get some
training. The
"vi" editor alone is one of the most unfriendly editors I have ever
used.
Learning to use MPE's Posix shell is a great idea, but you might
want to
invest in QEdit or something a little more "user-friendly".
----- Original Message -----
From: "John R. Wolff" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, May 02, 2002 8:03 AM
Subject: Re: [HP3000-L] HP3000 and HP-UX
> On Wed, 1 May 2002 15:45:19 -0700, Stan Sieler
<[log in to unmask]> wrote:
>
> >Re:
> >> > Even *HP* admits the problem: they offer migration consulting
to
> migrate from
> >> > 10.x to 11i.
> >>
> >> Huh? Just what is it that HP is changing so much that forces
significant
> >> application changes? Unix isn't Unix? I'm no HP-UX expert so
I don't
> know
> >> if this is simply poor planning or if there is some logic
behind the OS
> >> changes that require application changes!
> >
> >Things like:
> >
> >1) dropping software:
> >
> >Some examples include:
> >almanac getcollate
> >getlangid getlangs
> >gettables nlappend
> >nlcollate nlcollatesys
> >nlconvclock nlconvcustdate
> >nlconvnum sub_in_outstr
> >extract_nldt format_nldt
> >get_end getjulian
> >isvalidgregorian isvalidjulian
> >nlcrtm calendar
> >clock nlfindstr
> >nlfmtcalendar nlfmtclock
> >nlfmtcustdate nlfmtdate
> >nlfmtlongcal format_outstr
> >nlfmt_cleanup
> >
> >
> >2) moving software:
> >
> > One at random from ITRC:
> > . Some libc APIs were moved to libm, libnsl due to
standards/de facto
> > standards and will require a link line change to find the APIs
in the
> > new library. (This breaks some Makefiles)
> >
> >3) command changes:
> >
> > One at random from ITRC:
> > "What is the HP-UX 11.0 command is equivalent to the
> > HP-UX 10.x
> > command cmgetconfig-f ?"
> >
> > "find" command parameters removed
> >
> >
> >The release notes for 11.00, at
>
>http://devresource.hp.com/STK/partner/relnotes/11.00/relnotes_1100.txt
> >provide a good starting point for answering the question :)
>
> I think that Stan has made my point about UNIX incompatibilities
quite
> clear. UNIX has never respected and does not value compatibility
and UNIX
> users (of all people) should know this. (I do not know for sure
why this
> is the case, but accept the fact that it is. I suspect that it is
a
legacy
> from the university laboratory days of UNIX which was never
intended to be
> an operating system for business use.) Potential new UNIX users
coming
> from MPE need to understand that this is a major philosophical
change
> between MPE and any UNIX; i.e., there is no reasonable guarantee
that
> applications will not be affected. HP tells you this also.
>
> In addition the myth of UNIX "standards" is a joke. UNIX from HP,
SUN and
> IBM (all proprietary) have many similarities, but they are not
compatible
> with each other! I just returned from the annual user conference
for our
> application package and the new releases of the vendors software
have very
> different install experiences from platform to platform (SUN being
the
most
> difficult).
>
> Why do package vendors supply different editions of the same
release of
> their software for the same platform if the OS is transparent? We
found
> this to be true just going to 10.20 HP-UX from 10.01, and it has
been true
> for every release I have ever seen or investigated.
>
> I am not saying that ALL applications will ALWAYS be caught up by
a new OS
> release -- absolutes are rarely true. In general, packaged
software
will
> probably have a higher chance of this than custom software -- at
least
> that is my experience with packaged software. But I will make
this
> absolute statement: ALL applications need to be considered and
tested
> thouroughly when making a UNIX OS change. To be prudent this
should be
> done under MPE too, but problems are much less likely to exist for
non-
> privileged code. To just upgrade the UNIX OS without considering
this is
> irresponsible.
>
> The HP document that Stan has kindly referenced is very daunting
and
should
> scare the hell out of anyone. Just the table of contents is
exhausting.
I
> have no idea how many pages this document is, but I can say that I
have
> never had to wade through something even remotely as complex for
MPE
> upgrades. This is one reason I have an HP S.E. to bring such
issues to my
> attention and help me steer through the mine fields. Greg says he
has
> never heard of any 10 to 11 OS issues, but that does not mean that
they do
> not exist -- it just means that he is lucky so far.
>
> By the way, I have been fascinated to see the discourse over my
statement
> about file locking. I was referring to the fact that the
*operating
> system* does not offer this service. Obviously applications or
databases,
> such as Oracle, manage to accomplish this through language
libraries or
> whatever. UNIX, as is often the case, pushs functions performed
by MPE
> down to the application level to handle. The need to internally
structure
> files with application software is another good example.
>
> Somehow this point has gotten mangled into discussions of being
able to
> blast away program files as though locking for data integrity had
anything
> to do with it. These are two completely separate concepts that
have
> absolutely nothing to do with each other. I was not even remotely
thinking
> about the idea of replacing programs, etc. with the "rm" command.
I have
> been using that for years on MPE for UDC's and programs.
PURGELINK is
> really quite dangerous and I have created a special UDC to control
it.
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
