Dear Rob,
To answer your question .... yes ... Stitch-in-Time does store information.
The storage required can be approximately 20 to 45 times leaner than the
DASD consumed by Journal Receivers (depending on the nature of a file). The
difference? Stitch-in-Time provides decidedly stronger tools for storing only
pertinent data.
About your "price is right" conclusion ..... we keep looking, but if you add
the cost of programmer labor and DASD consumption on top of the license fee,
we haven't found a higher ROI solution than Stitch-in-Time.
Rob, the Stitch-in-Time demo is free ...... but ...... proceed with
c-a-u-t-i-o-n on that because companies who try the demo end up purchasing
the software.
www.unbeatenpath.com/software/sit/Stitch-in-Time.pdf
Peace to you ,
Milt
(888) 874-8008
mhabeck@xxxxxxxxxx
From: rob@xxxxxxxxx
Sent: Thursday, March 01, 2012 2:30 PM
To: BPCS ERP System
Subject: Re: [BPCS-L] finding rogue updates to rate fields in LWK file
I did say they would have to be managed. They can also be set to 'system
managed' with all sorts of criteria. Would not your software log something
somewhere also?
And there are about a bazillion freebies to download to find what you want,
easily formatted, in journal receivers.
And the price is right.
Rob Berendt
Group Dekko
From: "Milt" < <mailto:mhabeck@xxxxxxxxxx> mhabeck@xxxxxxxxxx>
To: "BPCS user group",
Date: 03/01/2012 02:27 PM
Subject: [BPCS-L] finding rogue updates to rate fields in LWK file
Sent by: <mailto:bpcs-l-bounces@xxxxxxxxxxxx>
bpcs-l-bounces@xxxxxxxxxxxx
<vendor>
Hi Rob ..... about your journaling e-note .....
Not everyone has a terabyte of hard drive available for Journal Receivers
(JRs). We've seen places past 90% DASD consumed because no-one actively
manages JR accumulation. Our Stitch-in-Time software has the functionality to
store only information the user defines as pertinent for a given file. That
translates to a DASD footprint +/- 92% to 98% smaller than JRs for an
equivalent retention period.
<
http://www.unbeatenpath.com/software/sit/Stitch-in-Time.pdf>
www.unbeatenpath.com/software/sit/Stitch-in-Time.pdf
Beyond using less DASD, Stitch-in-Time would also make it DRAMATICALLY
simpler to find the source of rogue database updates. Consider the
current-events LWK example:
If you were attempting to determine which program was making mysterious
changes in rate fields by using JR data, you'd start by getting a list of all
records in LWK that were potentially (but not necessarily) changed. Then
you'd wade through that streamed data dump, looking for data in columns x
through y that changed in consecutive journal records. That's a chore because
there are no visual divisions between fields and because only a single
journal entry is viewable at a time ... so you'd have to jump back and forth
between two screens to spot value changes.
To avoid eye strain, a sophisticated iSeries guy could extract JR data for
LWK into two identical external data files and then purchase a utility to
exclude records with no data change. Then he'd create a query or SQL process
that compared data in columns x through y between the two files to find rogue
data changes. Records ID'd that way would include the rogue program name.
The very sophisticated, less-eye-strain JR approach would consume 130 - 160
minutes. The same objective could be achieved in 2-4 minutes using
Stitch-in-Time software.
Now, If you wanted to get an email alert about a LWK data accident just
seconds after the bad data hit LWK, use Needle in a Haystack software. The
Needle alert would include the rogue program name plus all the other
information you'd need to fix the error immediately ... before it propagated
itself into CAP calculations.
<
http://www.unbeatenpath.com/software/needle/in-a-haystack.pdf>
www.unbeatenpath.com/software/needle/in-a-haystack.pdf
Warm regards,
Milt Habeck
Unbeaten Path
<mailto:mhabeck@xxxxxxxxxx> mhabeck@xxxxxxxxxx
(888) 874-8008
</vendor>
midrange.com
