× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



"They should be sold at the same price."

Do you really think price is based on (perceived) value? Price is based on
what the market will bear.

On 9/8/06, Steve Richter <stephenrichter@xxxxxxxxx> wrote:

On 9/8/06, Evan Harris <spanner@xxxxxxxxxx> wrote:
> Steve
>
> I wasn't trying to say these things couldn't be done (which it what
> it seems you are assuming), I'm just trying to point out how much
> more effort is involved  that's the whole point of the discussion.
>
> Starting a job at a particular time is no great trick (even Windows
> can do this) - as you point out cron does the job, but making jobs
> run in series and preventing clashes is much harder. It was the
> queueing and management aspect I was really getting at. I am of
> course ignoring the fact that the cron interface is highly
> unintuitive compared to the friendly iseries job scheduler.
>
> I've seen the back end of printer queues used for batch work before,
> but it requires extra scripting and coding; hardly as simple and
> elegant as a jobqueue and nowhere near as manageable or configurable.
> if you want to move an already "submitted" job then it is a major
> pain. of course, the fact that your guys had to set this up merely
> proves my point; every iseries has queued batch processing set up out
> of the box - you don't have to do anything.
>
> I don't see how being able to see CPU is has any bearing on the
> points I made. Theres another command (topas from memory) that also
> let's you see this stuff in a "poor relative" version of WRKACTJOB,
> but knowing the CPU use doesn't help you much when two jobs can't
> decide which of them has exclusive use of the CPU and memory.
> Separating jobs is not simple under unix, but is a piece of cake on
> the iseries. Again, you have this ability right out of the box,
> without doing anything.
>
> The point is not whether these things can be done or not, it's the
> degree of effort and sophistication required to accomplish them.
> getting this ability out of the box is the point of the discussion
> not whether it can be done or not.
>
> Anyway, you can accept it or not; until you really understand what it
> takes to manage a system (unix and/or iseries) day in day out, easily
> and efficiently and what actually has to be done from day one to set
> them up I doubt we are going to get anywhere.

Evan,

Your killing me. why me!?  I have no problem accepting that i5/OS has
superior work managment tools than Linux.  I am doubtful that there
are no job queue add ons for Linux, but I asked the question and you
said no so I will accept that. My point is neither i5/OS or Linux are
superior to the other. ( Windows with the built in managed code .NET
framework, that is a different story! )  i5/OS has great job
management capabilities. AIX gets 50% more transactions per minute per
unit of power5+ CPU than its counterpart.  i5/OS has database and
security built in. AIX is able to run more than one brand of database
at the same time. The p5 is a great web server that can scale to
millions of TPM. The i5 can run functional green screen applications
with a minimum of intervention.  i5/OS is not worth more than AIX.
They should be sold at the same price.

-Steve
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.