"bob" wrote:

FSI is often confused with OSFI just because of the common letters,
but they are different things.

FSI = File System Interface which is D3 files stored as native OS
files rather than in the blob. Most MV environments support this
concept these days. D3 supports the Virtual Machine Environment
(blob) plus the FSI in D3NT but only the VME in *nix.

OSFI = Open Systems File Interface allows D3 to exchange data with the
host OS and with other D3 environments. All D3 platforms support
OSFI.


My suggestion was to use a trigger to do something like this:
execute "sselect triggers by timestamp"
execute "copy triggers" : @am : "(remote:acct,file,"
Then in the remote system you run a process to integrate the new data
into the existing dataset.

Only the triggers file is located on the production system and updates
are not done "live" (synchronously), they are done whenever you want,
like after hours (asynchronously). I don't care if you use triggers
on your files or if you have the application write updates to a
tickler/trigger file. The benefit of using triggers (which I rarely
do BTW) is that you can "set that dirty bit" no matter what process
does the update.


Maybe you're not understanding the incremental save process. Here is
a more complete suggestion which can be used instead of the
trigger/OSFI concept. Since this is the sort of information I provide
to my clients for a living I'd prefer to not get into too much detail:

1) Do an account-save on system1.
2) Do an account-restore on system2.
3) On system2 in a different account, write a process that will
extract what you want from the restored account. Do not make changes
to the account in system2.
4) On system1 do an incremental save whenever you wish.
5) On system2 restore that incremental so that the account in system2
is now updated to the same state as system1.
6) Run your program(s) to extract updates. You need to have some
process that can figure out what updates have been made, handle this
any way you want, with a tickler file, checking timestamps, whatever.

Any subsequent incremental save on system1 might only contain a few
items. The data volume is trivial after the initial restore. If the
accounts get out of sync then just go back to step 1, get a new save,
delete the account in system2 and do the restore...

You can do this process in an automated fashion with pseudo floppies.
You can use named pipes to restore from a tape at the same time it's
being saved - this eliminates any disk consumption in the host OS.


Funny but I haven't touched txlog in so long I've forgotten the
details but I believe your understanding is correct. You can use
transaction log directly from one system to another and completely
bypass any manual processes. Barring any communications issues, the
account in system2 will always be in sync with system1, the system
will track all dirty bits, no triggers required. But you still need
something on the receiving end to let you know when something of
significance has changed. You could overlay the ED, UP, or other
commands so that it checks to see if your developer copy and your
production copy are different, and if they are, do a substitution and
present you with the latest version.

Anything is possible here, lots of ways to skin this poor kitty.


This is an administration issue for which it's good to have a VAR. In
short there are two ways:
First, create a file in the host OS.
Now:
1) chg-device an existing device to point to that file.
or 2) create a tape entry in pick0 which is always available.

No prob really. It seems like you're asking good questions that
should be handled by a "Value-Add" Reseller.

Good luck.

T