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>






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.