|
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 +---
As an Amazon Associate we earn from qualifying purchases.
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.