Konrad Underkofler wrote:
Pricing for the commercial packages, even for the smallest System i seems to range between $2500 and $4000 with a 20% yearly maintenance fee.
Konrad:
Definitely true. But at those prices, it's difficult to do it
cheaper with open source. (It's difficult even to put such low
selling prices on them.)
For example, a standard syslog message maxes out at 1024 bytes.
Header info brings it down to 1000 bytes or less. All of it is ASCII
(UTF-8 might be best. Maybe.)
Now, pick any single security related audit journal entry and try to
express it in an ASCII string in some meaningful way, something that
will be readable and remain within 1000 bytes. Look at a couple
other entries where an entry might be for a QSYS.LIB object one time
and a /root streamfile the next time.(If there's extra time, try to
include entry fields that some auditor is going to want to know about.)
Make sure that any fields that have CCSID tags are converted
properly. Not all fields have the same CCSIDs, especially for IFS
formatting.
It doesn't take much more than a few entry types to surpass the
purchase price for a supported package, just to create the routines
for format conversions. This is especially true if the processing
must be done without sucking up resources from the jobs running the
business.
But so far, some reformatting procs are all you have. Now you need
to wrap those into something that can pull the proper entries from
the journal. And handle startup and shutdown and restart. And then
the sockets code to send the messages to some remote syslog server...
Seriously, at a $2500 level, we're only talking about three weeks or
so of some developer's time as a cost to a business. It can take
that long just to figure out how to get some 'free' open-source
projects to run at all in a lot of system environments, much less
get them to do what you want.
If _any_ bugs are uncovered and have to be fixed,...? And if an IBM
PTF needs to be developed because of some uncovered audit entry
bug...? If it's simply not workable and you need to scrap that
effort and try a different one...?
Now that some audit journal entries are handled, critical system
messages from, say, QSYSMSG to syslog... Too bad none of the journal
handling code can be used. At least the sockets stuff is mostly
relevant.
When you fire it up, you notice that your syslog console isn't
reporting anything you're sending. Why not? Where's the little
detail in the syslog RFC that isn't correctly implemented? If you're
lucky enough to find it and fix it, and some entries start to
appear, and they're showing up with data that you're not sending,
what's changing your messages? Or is it something in the User's
Guide for the syslog console app that needs to be attended to?
Sigh. Too bad that syslog isn't an exact science.
Then, you're going to upgrade to V5R4 from V5R3. You need to handle
the new IM entry type, but you _can't_ test it out on V5R3 because
it's invalid on V5R3. And the Memo to Users points out a couple
minor changes in other audit journal entries... Looks like your
'security related' reporting app might be quiet for a while during
the transition time when it's most important. But there's sure to be
some development time available soon...
I can't argue that $2500-$4000 is 'cheap' for a small business nor
that maintenance costs are cheap. But possibly I can argue that it's
cheaper than alternatives.
Quite a few commercial product developers contribute to these lists.
I suspect that the vast majority stay in the business while
maintaining some belief that it's commonly cheaper to buy than
build, particularly when the products are fairly standardized across
different businesses. I suspect that most of them actually use
purchased products to develop products rather than 'build their
own', even though building is their business.
I could rant for longer, but I think it's important to get multiple
viewpoints -- both from vendors _and_ from small business
representatives like you, Konrad. Let's get a wider discussion going.
Anybody?
Tom Liotta
midrange.com
