In article <[log in to unmask]>, Michael Anderson
<[log in to unmask]> writes
>Frank's right, Samba/iX and/or NFS would work. However to achieve the
>real-time effect I think each transaction would need to be in a separate
>file. Another option would be ODBC, or better still IPC sockets. Using IPC
>sockets you could write/code directly into an existing process on the client
>(9k) side to send a transaction record to the server (3k). This would
>require you to write a server process on the 3k that is always ready and
>willing to receive and process transactions, and send acknowledgements back
>to the 9k client in real-time!
>
<Snip>

>Ewart North wrote:
>
>> Dear Friends,
>>
>> I have an application running on an HP9000 which needs to post data into
>> a financial system running on the HP3000.  I can create files of posting
>> transactions on the 9k, ftp them to the 3k and post them, all in batch
>> mode, no problem.
>>
>> My user is now saying "why can't we do this on a transaction by
>> transaction basis?"  I think what he means is to closely link the two
>> systems so that the SOP (9k) checks codes which exist in Image on the 3k
>> so that mis-postings can be eliminated earlier in the processing cycle.
>>
>> My questions-
>> Is this scenario possible?  If so what do I need on each machine to
>> accomplish this?
>> What are the consequences (if any) for response on either or both
>> machines?
>>
>> Help really appreciated.

It's a b*gger when they love your HP3000 app so much they won't move
your HP9000 version, even though HPUX is where the SOP is, isn't it?

And when they had gotten used to your unique interactive online
validation?

Assuming you need to call IASLINK with this, you are going to need a
process on the HP3000 to do it. SQLing straight into IASDB just bypasses
all that lovely validation - seems a shame.

We reckon:

Create a new TRANDB on the HP3000 to hold the IAS postings. Socket (as
above) or ODBC into this from the HP9000.

Have a Doer job on the 3000 that reads TRANDB, gives the postings to
IASLINK, and put the results back in TRANDB.

Have the 9000 process poll for these results, socketing or ODBCing, and
reporting back to the 9000 app.

If you can encapsulate the processing on the HP9000 side as well,
without too much of a performance hit. you can generalise the UX side of
the interface so that the SOP calls a 9000 process with its transaction,
and gets the result back from there.

Then you can call the whole HP9000 <=> HP3000 transfer process IASBridge
(TM), and offer it to *any* customer in the same boat....

--
Roy Brown               Phone : (01684) 291710     Fax : (01684) 291712
Affirm Ltd              Email : [log in to unmask]
The Great Barn, Mill St 'Have nothing on your systems that you do not
TEWKESBURY GL20 5SB (UK) know to be useful, or believe to be beautiful.'