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

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.


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.


Tom Liotta

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