From: David N. Barnett 

Please trim your bleepin' quotebacks!!!

--dnb

On Mon, 16 Dec 2002 22:16:06 -0500, "Robert Comer"
 wrote in message :

| Wow Rich you sure like to spin!!
|
| We were talking about Windows -- I have the tools I need on the 400 as
well as the knowledge to use them very effectively. (They are included in
every install and any halfway experienced programmer/admin can handle
them.) |
| >As for the unrelated questions you asked, I have the knowledge and tools to
answer these on Windows.
|
| That was the whole point of the discussion!!!  If they are available on
Windows, name them and what they do.  If you want to talk about something
else, go ahead but I wont be covering that ground any more. |
| - Bob Comer
|
|
|   "Rich"  wrote in message news:3dfe8086{at}w3.nls.net...
|      Again, nothing you mention has anything to do with the shared library
compatibility problems that you acknowledged exist with OS/400. |
|      As for the unrelated questions you asked, I have the knowledge and tools
to answer these on Windows.  I haven't a clue to how to do so with OS/400.
Your position appears to be the reverse.  No big deal.  I don't feel bad
for not knowing how to manage an OS/400 system. |
|   Rich
|
|     "Robert Comer"  wrote in message
news:3dfe761f{at}w3.nls.net...
|     >   You can see the process list using the task manager, performance
monitor, WMI and scripting, etc.  Much of what you listed is OS/400 specific. < |
|     Okay, so where's the path on each job/process and the location of all the
called programs?  How about open files?Those are AS400 specific.  (It's a
pity, Windows could *use* some of those AS/400 specific things...) |
|     >None of this has anything to do with shared library problems like those
you acknowledged occur with OS/400 and its applications. |
|     But that's just it, with all that info I gave I can track down EVERY
problem like that on the AS/400. To bad the same can't be done for Windows. |
|     >   You have repeated that you don't have the tools.
|
|     These "tools" should be part of each and every install. 
You don't have
to program to run into these problems so why should you have programming
tools to solve them?
|
|     >I think what you lack is the knowledge and experience.
|
|     You always fall back to that, call someone else's skill level into
question to deflect the argument... Well, maybe so, you might be right, but
you just might be surprised what I can do if I have the right tools. (if
they are indeed available and I don't think they are.) |
|     - Bob Comer
|
|
|
|
|
|       "Rich"  wrote in message news:3dfe5e6a{at}w3.nls.net...
|          You can see the process list using the task manager, performance
monitor, WMI and scripting, etc.  Much of what you listed is OS/400
specific. I could provide you with a similarly pointless list of session,
window station, desktop, process, service, and thread attributes that exist
on Windows but don't apply to the OS/400.  None of this has anything to do
with shared library problems like those you acknowledged occur with OS/400
and its applications. |
|          You have repeated that you don't have the tools.  Maybe but not for
their lack of availability.  I think what you lack is the knowledge and experience.
|
|       Rich
|
|         "Robert Comer"  wrote in message
news:3dfe4936{at}w3.nls.net...
|         >  When I say complete I mean complete.
|
|         To you, yes, I want more.
|
|         >All the information to develop applications also tells how things
work.
|
|         Not well enough for me.
|
|         >There are tools that tell me everything that is running and what
libraries
|         are used.  Getting information is in no way a problem.<
|
|         Do they come in the box?  If so just where do I see, for each task,
|
|         the job status (user, date and time of entrance into system, what
subsystem,
|         is it interactive or batch, what system submitted it, wther an end
pgm has
|         been requested),
|
|         job definition attributes (job description {for defaults}, default
outq and
|         printer, message logging level, job priorities {jobq, run, and outq}
date
|         format, decimal format, time format, break message handling, print
key
|         format, language {locale}, coded character set message queue overflow
|         handling),
|
|         Job run attributes (cpu usage/max, default wait time, threads,
temprary
|         storage used/max)
|
|         All spool files
|
|         Job log
|
|         Call stack
|
|         Locks (status of all db, device and any others)
|
|         Library list (path for the job)
|
|         All open files, including io count, current record, IO status,
location and
|         member (kind of like stream)
|
|         File and print overrides
|
|         Committment control status
|
|         comms status (if a comm job)
|
|         Mutexes
|
|         Threads status
|
|         ?
|
|         I have all that and more easily.
|
|         >   The problem is simply that some shared libraries are not 100%
compatible
|         with the ones they replace.<
|
|         I understand that.
|
|         >You already acknowledged that IBM releases fixes for compatibility
problems
|         which means that OS/400 or IBM software has this problem. <
|
|         Not really, apps don't install IBM stuff like OS stuff can gets
installed in
|         windows.
|
|         >You also acknowledged that programmers writing for the OS/400 aren't
|         perfect.
|
|         Who is?
|
|         >The only difference I see is that you don't install on your OS/400
the kind
|         of software that many PC users do (e.g. Kazaa) and that you are paid
good
|         money for being a trained administrator while home users lack this
|         experience.<
|
|         That's only partially true as this paid for administrator is almost
as
|         helpless as normal users when Windows goes awry.  There's just not
the tools
|         I need to debug the problem included in Windows.
|
|         - Bob Comer
|
|
|
|
|         the pgm stack, the path for that process
|
|
|         "Rich"  wrote in message news:3dfe429b{at}w3.nls.net...
|            When I say complete I mean complete.  All the information to
develop
|         applications also tells how things work.  Not that I have to snoop to
that
|         level.
|
|            The problem is simply that some shared libraries are not 100%
compatible
|         with the ones they replace.  You already acknowledged that IBM
releases
|         fixes for compatibility problems which means that OS/400 or IBM
software has
|         this problem.  You also acknowledged that programmers writing for the
OS/400
|         aren't perfect.  The only difference I see is that you don't install
on your
|         OS/400 the kind of software that many PC users do (e.g. Kazaa) and
that you
|         are paid good money for being a trained administrator while home
users lack
|         this experience.
|
|         Rich
|
|         "Robert Comer"  wrote in message
|         news:3dfe2a75{at}w3.nls.net...
|         >   I don't see how since I have complete information about running
|         processes and paths under Windows.  It's also not the issue.<
|
|         It all depends on what you call complete and what I call complete,
Windows
|         has a lot less info available and what's there is kind of hard to get
to.
|
|         >   That OS/400 has less software available than for the PC is not an
|         insult.
|
|         Whatever.  You might be a bit surprised how many users there are
though and
|         there's quite a lot of software available actually, more,or at least
|         comparable to Windows in some areas.  It's not a do everything
machine hence
|         the smaller marketshare. (It's a business machine, pure and simple.)
|
|         >   The really funny bit is you then acknowledge that you do
experience
|         shared library hell on OS/400. <
|
|         No, I admitted no such thing.  The term library isn't what you think.
|         (library  DLL Library is kind of like a directory in Windows.  Path
=
|         Library list)  Shared components are VERY rare in multiple
apps/vendors
|         outside of OS stuff.
|
|         >All DLL or shared library hell is is a compatibility problem when a
shared
|         component is updated.
|
|         Aye, that's what it is but often there is no way to figure out what
is
|         causing the problem -- on the AS/400, there is. (out of the box in
both
|         instances, no addons or addon cost.)
|
|         - Bob Comer
|
|         "Rich"  wrote in message news:3dfe1536{at}w3.nls.net...
|            I don't see how since I have complete information about running
processes
|         and paths under Windows.  It's also not the issue.
|
|            That OS/400 has less software available than for the PC is not an
insult.
|         It's a simple truth and not a particularly embarrassing one given the
small
|         number of OS/400 systems relative to PCs.
|
|            The really funny bit is you then acknowledge that you do
experience
|         shared library hell on OS/400.  All DLL or shared library hell is is
a
|         compatibility problem when a shared component is updated.
|
|         Rich
|
|         "Robert Comer"  wrote in message
|         news:3dfe060f$1{at}w3.nls.net...
|         >   Easier how?
|
|         I have MUCH more information about running jobs and paths than
anything
|         available in the Windows world.
|
|         >Because there is so little software for OS/400 in comparison or that
you
|         are much more careful about what you install then many PC users?<
|
|         Nice try at in insult, but no, that's not the reason.
|
|         >   Maybe you mean that no programmer writing for OS/400 would ever
make a
|         mistake
|
|         Definitely not, we're as human as anyone else.
|
|         >introduce a compatibility issue in an updated version of any
software
|         component?
|
|         It just doesn't usally happen between different apps, but sure an
update to
|         an app can break itself. OS changes can break break things of course,
but
|         it's certainly not anything like DLL hell.
|
|         >Can you confirm that neither IBM nor anyone else has ever released a
fix
|         for a compatibility problem?<
|
|         Not even close, IBM's always fixing "compatibility
problems", as are
a lot
|         of lower level utility vendors.  It's just easier for an AS/400 admin
to
|         figure out just where a problem is occuring and to backlevel things
if
|         needed.
|
|         - Bob Comer
|
|
|
|         "Rich"  wrote in message news:3dfdfe1a$1{at}w3.nls.net...
|            Easier how?  Because there is so little software for OS/400 in
comparison
|         or that you are much more careful about what you install then many PC
users?
|
|            Maybe you mean that no programmer writing for OS/400 would ever
make a
|         mistake and introduce a compatibility issue in an updated version of
any
|         software component?  Can you confirm that neither IBM nor anyone else
has
|         ever released a fix for a compatibility problem?
|
|         Rich
|
|         "Robert Comer"  wrote in message
|         news:3dfde800$1{at}w3.nls.net...
|         > My iSeries guys tell me it is possible to have files places in QSYS
and
|         QGPL
|         > and have them replaced and overwritten in OS/400 as welll.
Customized
|         > objects are not secure there either.
|
|         They are absolutely correct (assuming one as unlimited access to
everything
|         which isn't all that common), but where things differ is that it's
MUCH
|         easier to control where every job/program gets its shared stuff, not
to
|         mention it's MUCH easier to track down such problems.
|
|         There's also a big difference in the way AS/400 programmers treat
things
|         like this -- I'd have a programmer basically fired if he were to be
messing
|         around with QSYS and other IBM specific libraries -- there's no
reason to do
|         it as there's a perfectly acceptable way of doing anything you need
without
|         messing with IBM stuff.
|
|         - Bob Comer
|
|
|         "Ronnie T. Mungo, Boy Genius" 
wrote in message
|         news:3dfde54e$1{at}w3.nls.net...
|         > My iSeries guys tell me it is possible to have files places in QSYS
and
|         QGPL
|         > and have them replaced and overwritten in OS/400 as welll.
Customized
|         > objects are not secure there either.
|         >
|         > RTM, BG
|         >
|         >
|         > "Robert Comer" 
wrote in message
|         > news:3dfb50ff{at}w3.nls.net...
|         > > > If the operating system had been designed so that
applications
could
|         > > > not put their DLLs any place they desired, DLL
hell would not
be a
|         > > > problem.
|         > >
|         > > Definitely right.
|         > >
|         > > > But that requires software that is architected and designed.
|         > > > Unfortuantely, with Windows, we have software that
"happened".
|         > >
|         > > A lot of it, yes, and that's where all the problems come from...
|         > >
|         > > - Bob Comer
|         > >
|         > >
|         > > "Mike '/m'"  wrote in message
|         > > news:m1jmvuki2dbqh0v7dru0rf684ea5ulfg54{at}4ax.com...
|         > > >
|         > > > If the operating system had been designed so that
applications
could
|         > > > not put their DLLs any place they desired, DLL
hell would not
be a
|         > > > problem.
|         > > >
|         > > > But that requires software that is architected and designed.
|         > > > Unfortuantely, with Windows, we have software that
"happened".
|         > > >
|         > > >  /m
|         > > >
|         > > > On Fri, 13 Dec 2002 10:22:47 -0500, "Robert Comer"
|         > > >  wrote:
|         > > >
|         > > > >> It isn't just Microsoft's issue.
|         > > > >
|         > > > >No it's not, but they were the ones that
designed it so that
dll hell
|         > was
|         > > > >possible.
|         > > > >
|         > > > >- Bob Comer
|         > > > >
|         > > > >
|         > > > >"Ronnie T. Mungo, Boy Genius"
 wrote in
message
|         > > > >news:3df9f505$1{at}w3.nls.net...
|         > > > >> Who got you there? Any combination of
software vendors not
limited
|         to
|         > > just
|         > > > >> Microsoft.
|         > > > >>
|         > > > >> Include IBM, Borland, and anyone else
that comes into the
mix. All
|         > > those
|         > > > >> install programs that let developers put
DLLs in place
willy-nilly
|         > > without
|         > > > >> verification.
|         > > > >>
|         > > > >> It isn't just Microsoft's issue.
|         > > > >>
|         > > > >> RTM, BG
|         > > > >>
|         > > > >>
|         > > > >>
|         > > > >> "Richard B."
 wrote in message
|         > > > >> news:vtchvuck9t9q0t6p87k3lpmg2b4tcg4e3a{at}4ax.com...
|         > > > >> > So this is what VisualStudio.net
promises in their ad?
|         > > > >> >
|         > > > >> > Who got you there in the first
place? LMAO, I had no idea
the DNC
|         > ran
|         > > > >> > MS!
|         > > > >> >
|         > > > >> > - Richard
|         > > > >>
|         > > > >>
|         > > > >
|         > > >
|         > >
|         > >
|         >
|         >

--- BBBS/NT v4.01 Flag-4