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 *