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



Both the dspjrn command AND rcvjrne OPTIONALLY allow the entry of up to 300
physical files for conversion of output (in the case of dspjrn) or whose
journal entries are received (in the case of rcvjrne). So, it would seem
that the exit program which is specified to receive the journal entries
would only actually be called if the journal entry is for one of the
specified files. That is not the case. It apparently gets called whenever
ANY entry is placed in the journal.

The bottom line here is this. If you are watching the system activity for
these RCVJRNE exit programs, it looks like both programs are using the same
amount of system resources, when only one is actually doing anything.

Trigger programs don't provide all the information needed by this
application (like file level activity).

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Friday, October 26, 2012 4:38 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Multiple RCVJRNE firing

Explain what you are trying to do.

If you are collecting change info at EOD to summarize daily activity, have
you considered DSPJRN to an outfile? Then you CAN name a physical file to
filter journal records.

If you are monitoring for changes to do updates to another file or send an
email because someone looked at private info, have you considered trigger
pgms? Then you can attach trigger pgms only to the files of interest.





-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Thomas Garvey
Sent: Friday, October 26, 2012 4:04 PM
To: 'Midrange Systems Technical Discussion'
Subject: Multiple RCVJRNE firing

I'm trying to determine if there is a parameter or two I might be missing on
the RCVJRNE command, or maybe just don't fully understand it.

I'm using the RCVJRNE command to receive journal entries for a physical
file. Then set up another RCVJRNE to do the same on a different physical
file, calling a different exit program. When a change happens to one of the
files and a journal entry is placed in the file's journal receiver, BOTH
exit programs actually execute. I've proved this using debug.

The RCVJRNE command parameters specifies the file name for which the exit
program should be receiving entries and the exit program is indeed only
getting entries for the specified file. The exit program for the other file
ALSO executes at the same time but simply gets the parameter values passed
to it that convey nothing is being passed. Again, I've isolated this using
debug. The only common denominator is that both files are journaled to the
same journal.

This is certainly non-intuitive, given that the files desired are specified
in the RCVJRNE command execution. It seems to imply that a single RCVJRNE
should be applied to a journal and the exit program should decide what to do
with the journal entry based on the file for which the entry is. That is,
check the values in the incoming parms to determine which file the entry
actually pertains, then perform the function necessary and intended for that
file. In my case, the purposes are different.

I guess I'm saying that the RCVJRNE command merely sets up a 'chain' of exit
programs to call whenever a journal entry is written to the named journal.
It doesn't really restrict calls to the exit program based on the file
designations given in the RCVJRNE command.

Anyone else run into this?

Tom Garvey
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


________________________________________________________________________
This inbound email has been scanned for all viruses by the MessageLabs
SkyScan
service.
________________________________________________________________________

______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs
Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.