On Thu, Mar 13, 2008 at 10:47 PM, Tom Liotta <qsrvbas@xxxxxxxxxxxx> wrote:
I can't quite agree with this. NotePad uses Windows native I/O
functions to do its reads/writes. I suspect that STRSST D/A/P is
You're confusing terms here. In the Windows world, the term "native
I/O" does not exist - it's called "I/O". Mainly because Windows lacks
the integrated database and multiple filesystem support that i5/OS
has. A direct mapping between i5/OS and Windows would be "I/O" vs.
"IFS Stream File I/O" (even that isn't entirely correct, because you
can access DB/2 through the IFS).
i5/OS and Windows are completely different platforms, built with a
different history and goals. Windows does not have the native I/O that
i5/OS has.
well outside of DB2 and even OS/400 or i5/OS. I'd guess that SST
D/A/P is a function of the underlying SLIC or LIC.
Yes, of course. But it's the only way to get low-level access to the
raw database data. On Windows, with the database just being an
application that uses standard operating system components it is
different to get low-level access to the raw database data. DB/2 on
i5/OS is part of the LIC, which means it's very tightly integrated.
This is not the case with the most popular operating systems and one
of the key advantages of i5/OS.
That architectural decision has also lead to several downsides, like
the fact that i5/OS object naming conventions are still stuck
somewhere in the 80ies, because changing that would break too much
stuff. When Microsoft released Windows 95 in August 1995, they finally
supported reasonable filenames - even though VFAT, which was just a
nasty hack. Everyone complained that Microsoft was late in the game.
Now we have the year 2008 and the hacks that IBM provides are even
more incomplete than those that Microsoft provided.
No simple "administrator" should have access to SST. It is a
*SERVICE function. How many sites are likely to have a functional
STRSST menu option available to users? Not even operators should
have STRSST (though I'm sure many do). Certainly if a DBA position
exists, there is no reason for *SERVICE for that job position.
I agree.
However, every Windows user has NotePad (or edlin or...). The
question of permissions applies (more or less) equally between the
platforms, but there's a clear disconnect when it's a question of
"native I/O".
Well, having Notepad is one thing. Being able to access the raw
database data on a Microsoft SQL Server is another. For that, you'll
need local administrator rights on that server. These local admin
rights are not necessary to administrate SQL Server as a DBA, the same
way that STRSST is not necessary for a DBA on i5/OS.
This configuration is also usual in large, enterprise deployment of
Windows with a strong privilege separation. In smaller shops, it's
quite likely that the DBA has full administrative privileges on a SQL
server. This is all about the companies specific IT policy and it's
implementation. It does not have anything to do with the underlying
platform.
If I use "native I/O" on one platform, the DBMS is in control. But
on the other, AFAICT, it is not. Simple. I'm looking for a
description of how that's not true.
You're comparing apple to oranges. It doesn't work like that on Windows.
Open your eyes. Open your mind. Look at other platforms. See how they
work. See how they solve problems.
Remember, different doesn't mean worse.
midrange.com
