FATAL ERROR IN(write cache not empty cannot use OFS globus manager)

Dear all,

When ever i call OFS.GLOBUS.MANAGER it shows the following error 'FATAL ERROR IN(write cache not empty cannot use OFS globus manager)', Its a mail line rtn.

Anybody's know why it happening......

Hi,

In which verion are you in?

Because from R7 onwards you cannot call GLOBUS.MANANGER. instead you have to call OFS.POST.MESSAGE.


regards,
saravanan

hey,

i am also facing same problem...
i am using ofs globus manager to reverse FT transaction...In first loop it reverse the transaction successfully but in next it gives an error:

* FATAL ERROR IN (Write Cache Not Empty Cannot use OFS.GLOBUS.MANAGER) **
Write Cache Not Empty Cannot use OFS.GLOBUS.MANAGER

I am using R7

Kindly help

Talha

hi,

the soultion is in previous reply itself. You have to use OFS.POST.MESSAGE in stead of OFS.GLOBUS.MANAGER.


regards,
saravanan

Dear Saravanan,

OFS.POST.MESSAGE takes a lot time to get the transations processed, as it first goes into the queue. Is there any efficient way to do this

thanks

talha

The only efficient way for doing this is to use OFS.POST.MESSAGE, when you call OFS.GLOBUS.MANAGER with in the transaction it calls the journal update which violate the txn boundry rule, to avoid this happening in local development temenos has restricted the use of OGM and introduce the OFS.POST.MESSAGE to process the all custom OFS messages.

rgds
Javed

Dear Javed,

I am updating the record on mm.money.market application on cob routine by using f.write. The record in debug mode shows the change although after routine is completed the change has not occured in the application.

But when i use journal.update after f.write it shows the change.
e.g.
CALL F.WRITE(FN.MM,MM.ID,R.MM)
CALL JOURNAL.UPDATE(R.CSE)
As you said that journal.update shouldn't b used so what should i do in this case.

regards,
Talha

Talha, why and what are you updating MM using f.write...? Please explain clearly what are you trying to achieve here so we can advise you the best possible solution.

rgds
Javed

Dear Javed,

I am updating a local ref which stores the date on which the cob routine is running

regards,
Talha

Do the simple write..!

Instead of doing this...

CALL F.WRITE(FN.MM,MM.ID,R.MM)
CALL JOURNAL.UPDATE(R.CSE)

do the following

WRITE R.MM TO F.MM, MM.ID

that's all you need to solve your problem, but don't make it practice to use WRITE, only use in COB routines.

By the way you don't need to store the date of COB as if MM contract is processed by COB then you are able to get the processing date of the contract from AUDIT fields (DATE.TIME)

rgds
Javed

You don't use journal update in batch jobs because the journal update will be automatically done when the COB agent finishes the job. For example if you write to a file in a single thread job program, it will not write anything until the program reaches the end, when the data will be flushed to disk at once.

You can bypass this COB journalling mechanism by adding .NTX in the ADDITIONAL.INFO field in the PGM.FILE of the job. But be careful, this is mostly appropriate for reporting jobs, because otherwise in case the agent is logged off due to locking time out or other reason, there is a risk of having duplicate transactions.


Regards
Chris

Please note that the use of OFS.GLOBUS.MANAGER is restricted not prohibited. We failed to understand conditions of using OFS.GLOBUS.MANAGER in R07 local routines.
On one hand in 'Subroutine guide.pdf' we found statement:
'OFS.GLOBUS.MANAGER Use of this subroutine is no-longer supported'
On the other hand in 'Delivery.pdf' we found: 'Processing Inward Messages using OFS.GLOBUS.MANAGER SWIFT Inward Message Subroutines and Local Development TEMPLATE.S Certain SWIFT payment messages are processed using the Inward Delivery OFS.GLOBUS.MANAGER method'
Here is explanation from Temenos PACS:
The use of OFS.GLOBUS.MANAGER in the INPUT.ROUTINE, BEFORE.AUTH.RTN, AUTH.ROUTINE levels is not allowed from G15. This applies to all the VERSION related routines and VERSION.CONTROL routines which try to use OFS.GLOBUS.MANAGER. The OFS.GLOBUS.MANAGER routine when called in version routines will cause the transaction to fatal out.

But it can be called while running any service.While processing delivery swift message OFS.GLOBUS.MANAGER can be called in the Out if routine or In if routine fields present in the DE.INTERFACE Record

Kindly refer to my 1st post dated 05 Nov for restricted vs prohibited. The fundamental problem with new T24 Technical consultants is that they do not understand that a application in T24 is not a standalone table and T24 is an application framework which is built around universe/ jbase database, and to ensure data integrity there is method of transactionality which ensures the data integrity in T24. Now if you violate this rule you will end-up with messed data into you database and that was what exactly happened in G14 release.

Now in more specific T24 term when you are with in the boundary of a financial transaction e.g. FT you are not allowed to use OFS.GLOBUS.MANAGER, because calling OGM within the transaction will violate the txn boundry, where when you are running a standalone service(TSA.SERVICE) you are not bound to a transactionality because it is the underline process which is defining the txn boundary for current process.

HTH
Javed

Hi have you solved this issue? i am getting the same problem.
If you solve this problem, can you share how to solve this problem?

Thank you

Hi
Even as 10 years passed, the solution would be only not to use OFS.GLOBUS.MANAGER inside T24 application transaction boundary, i.e. in VERSION or VERSION.CONTROL routines.

Technically you can use it in tSA service or in "RUN" routine of "W" application.

You might need to reconsider your technical architecture, and this I afraid is the only way.