× 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.



h
Hello Scott,

You wrote:
>Wow...   you know, there is not a shadow of a doubt in my mind that the
>AS/400 is a "closed system".   The REAL question is, "is that a bad
>thing?"

It's not closed.  It's just not as open as the particular OS you choose to 
compare it too.  It is at least as open as any proprietary Unix (AIX, HP-UX, 
and all the rest -- though most of them are fading), VMS, Win-whatever, etc.  
So you can't easily rewrite the AS/400 I/O routines, or easily insert your 
own scheduling algorithm into work management, or any number of things some 
people want to do, but you can talk to any device on the planet that 
understands a communications protocol -- TCP/IP, APPC, BISYNC, ASYNC, SYNC, 
etc.  You can port almost any C code to the AS/400.  That sounds pretty open 
to me.

>Lets say you wanted to write your own operating system to replace 
>OS/400.  What kind of hoops would you have to jump through to get THAT
>kind of info from IBM?   Or couldn't get get them at all?

This was certainly possible on the S/38 where documentation in the form of 
the S/38 Functional Concepts manual, S/38 Functional Reference Vol 1, and 
S/38 Functional Reference Vol 2 would have provided most, if not all, you 
need to know about the MI level.  The proviso is that you would build your OS 
on top of the LIC.  

It is harder on the AS/400 because Rochester have blocked the MI instructions 
they feel we don't need to know about (e.g., source/sink instructions so that 
pretty much buggers up any I/O routines) and privide only an expurgated 
version of the MI reference.

Now, you could argue that LIC (in its various forms) is actually an OS and 
you'ld like to write to the bare metal.  For that you would need to speak 
nicely to IBM (and wave large wodges of cash) -- although since the CPU is 
just a PowerPC at heart you could probably start with that instruction set.

But really, what's the point?  Writing your own OS only makes sense if the 
target hardware is a commodity item (Intel, Motorola, Acorn, etc.).  If 
that's what gives you kicks then do so on cheap hardware with a group of 
like-minded developers as a learning exercise.  Why would you want to do it 
on really expensive hardware?

>Or how about writing a device driver for some piece of hardware you'd
>like to sell, independent of IBM...   at *BEST* you'd have to be a
>registered business partner, at *WORST* you wouldn't be allowed to at all.

Where's the problem?  You knock up a driver in your spare time, on your 
employers system (or a time-share) to handle some obscure peice of equipment 
and your driver causes problems with existing code -- who foots the bill for 
determining and correcting the problem?   What if the code you load into an 
IOP to drive your special hardware causes disk writes to be ignored?  What if 
....

If you are a business partner (or prepared to become one) there is at least 
some expectation you know what you are doing.  Why should every pissant 
programmer get access to the internals?

>When I'm writing a program on my FreeBSD system (which *is* open) I can
>ask myself "hmmm... how much work does the system do when I call the
>read() function?  Is it better to optimize the code so that I don't
>have to call it as frequently?"  And then I can look at the source code
>for the read() function and see EXACTLY what it has to go through, and
>how efficient it is...   I can even recompile the whole operating 
>system with debugging symbols included, and use a debugger to go step
>by step through the OS code, just as I can do with STRDBG on my RPG
>code...

>Are these good things or bad things?   This closed-ness to the iSeries
>architecture has ensured the stability of the system.  It would be very
>easy to argue that a "closed system" is a "stable system"

And that's one of the main reasons we like the box so much.  It wouldn't work 
anywhere near as well if every T,D, and H were allowed to mess with the 
internals -- and they can if they are sufficiently determined.

>But,hthere should be no doubt in anyone's mind that the AS/400 is a 
>closed system.   It's VERY MUCH a closed system.

No it's not.  It just doesn't fit your definition of "open".  You not only 
want the doors unlocked, you want them taken off the hinges.  Do that and 
watch the much vaunted stability of the AS/400 fall apart.  Short of 
rebuilding the kernel there is very little on Unix that can't also be done on 
the AS/400.

This whole "AS/400 is not open" argument smacks of the same silliness 
apparent in the "Unix is not proprietary" argument.  Oh, really?  Can I take 
HP-UX binaries and run them on AIX?  Can I take 32-bit code and run it on a 
64-bit system and get full access to the address space?  Can I take the 
source code and compile it without changes?  What about DB access?  If all my 
SQL is in the Informix flavour can I move that to Oracle or DB2 without 
changes?  Hah!

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  / \   «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.