Re: AIX - i5/OS feature comparison was the notorious Steve's soapbox

I don't know the state of AIX today, but I used to administer a fleet of
12 AIX boxes (local and remote) and, prior to that, they were System-V
Unix boxes.  So, I think I'm comfortable in weighing in on this. 

While AIX has a lot of great qualities, there is absolutely no
comparison to the 400 as far as management goes.  If you think comparing
"ps" to "wrkactjob" and "at" to "sbmjob" or "wrkjobq" is a valid
comparison, clearly you haven't lived with them.  

I built a polling suite to gather data from the remotes and ship it to
the 400 using shell & C.  Jeesh......  I would have killed for CL,
message queues, job queues, etc.  

Like everyone else, I'd love to see a lower price point for the 400. 
But if the utility/functionality is deprecated (no offense to the AIX
guys) to that of AIX then NO WAY.  

spanner@xxxxxxxxxx 09/07/2006 9:17:01 PM >>>

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.

Regards
Evan Harris

Evan,

I asked this question on the AIX list back in the spring [1] . I have
not worked with AIX yet so I cant say for sure who is right and who is
wrong.  Here is part of the answer:

The  "at" command that can be used to start a batched job now or at a
specific time. There is also the cron daemon that lets you submit a job
on a regular basis, such as every morning at 8am. There is the "atq"
command to show what is in the queue, and "atrm" command to cancel
jobs.

Our company created special "batch" queues in the qdaemon subsystem
that lets us queue up batch jobs much like you would do for a print
job. For example, we create a short script that sets our environment
and then calls a COBOL program, and then we simply use the lp command
to submit to that queue, whose backend program is /bin/ksh instead of
piobe (the standard printer I/O backend).

CPU usage can be seen for each process using the ps command

-Steve