Re: How to lookup Qshell error messages?

Hello Fred,

You wrote:
>Now, that said, we could certainly do a better job grouping BCI
>jobs somehow and providing servicability hooks for them.

I agree with your summation of the possible options and that BCI is the 
best of a bad lot.  But why initiate a new BCI job for each command?  If I 
had done this I'd be looking at a single BCI job per shell instance to 
handle the commands and queue them via user queues.  Admittedly that is 
just off the top of my head and there may be other considerations I've not 
considered.  It might not implement the Unix philosophy properly but then 
ANU (AS/400s NOT UNIX).  All the kludges involved in creating a Unix-like 
environment on the AS/400 simply scream out that you should not be 
attempting it, that it is the wrong approach.  If customers wanted Unix 
then they'd buy Unix.

This is now getting a little off topic but I'll continue for a bit (until 
Joe shuts me down):

Why do we need QSHELL?  Why do we need PASE?  Because it makes life easy 
for Unix applications.  Why do we need those?  Well, that's the 64,000 
dollar question.  Someone in Rochester thinks it would be a good idea to 
get Unix applications on the AS/400 so they can continue the time-worn 
argument of ME TOO!  Rochester have never broadcast the things that make 
the AS/400 different and, in many ways, better than the alternatives.  
They've always gone around saying "But we can do that", "We do that too", 
and its now probably too late to rectify the situation.

Rochester has been guilty of forever trying to get other architectures to 
run on the AS/400 instead of singing the praises of the best box on the 
planet.  I realise they are hamstrung by Armonk and Poughkeepsie but they 
could be doing a better marketing job.  Instead of saying ME TOO they 
should be saying "Well, why can't you do this?  Look how much better it 
is".

So now we have WebSphere ported from AIX, DDNS ported from AIX, LDAP, 
ported from AIX, PASE so you don't need to port.  All of which are truly 
awful to configure.  None of which is managed like a proper AS/400 
application.  They either use a poxy PC to install and configure or some 
collection of shell scripts to install and configure.  It's all crap.  If 
we wanted to run Unix then we'd buy Unix!  

None of these applications send decent error messages.  They hide errors 
off in some log file hidden away in nested directories.  Make one change 
to one of the dozen or so configuration files and suddenly things stop 
working.  Do these applications tell you why they died or what they don't 
like about the configuration?  Not a hope in hell.  Now I actually like 
the concept of WebSphere (at least the Application Server part, not the 
current branding of anything remotely web-related) but from an AS/400 
perspective it is simply too hard to configure (and the GUI admin client 
doesn't make it better, just different).

What brain-dead weasel thinks it's a good idea to fight Windows 
configuration problems, network configuration problems, etc. just to be 
able to configure an AS/400?  Rochester force me to run Windows and to 
upgrade it simply in order to manage my AS/400.  I have no business 
requirement for Windows yet Rochester force me to buy a competitor's 
OS!!!!  Besides, Windows is a horrible OS.  If these admin tools were at 
least written in pure Java (he says attempting to justify the rant) then I 
could run them on MY choice of OS.

I have used DOS/VSE, MVS, ICLs, Unix (in various flavours), OS/2, Windoze 
(in most of its variants), Mac, S/38 and AS/400.  The Mac, S/38 and AS/400 
are the only systems where there is a cohesive concept and clear goal in 
the design and implementation.  They are also simply easier to learn, use, 
and manage than any thing else.  However there is no services revenue in 
'easy'.  Much better to make it complicated so a services company (like 
IBM, CSC, Andersens, etc.) can milk services revenue from existing 
customers rather than having to work a bit harder and find new custo
rs.  
So we see the AS/400 getting cluttered with alien architecures, ported 
applications, and general crud.

I foresee a future where there is just one e-Server from IBM.  It will 
probably be an AS/400 under the skin because that is IBM's best bet at 
converging the different servers.  It will have a distinct Unix flavour.  
Text configuration files hidden away in directories 50 levels deep.  It 
will require a Windows PC to manage it.  It will run mostly Unix type 
software with some support for legacy environments like OS/400 and MVS.  
It will be just as difficult to manage as Unix but it will generate lot's 
of services revenue and the IT industry will be a poorer place as a 
result.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\   «»
«» Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /   «»
«»                                                           X    «»
«»               ASCII Ribbon campaign against HTML E-Mail  / \   «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---