This discussion is archived
2 Replies Latest reply: Oct 7, 2010 8:56 AM by Todd Little RSS

FML operation fails when TSAM policy is enabled

652903 Explorer
Currently Being Moderated
I have come across an interesting problem while using TSAM. I am running on Windows 7 which is not supported, so I am not able to raise a support request, but I would appreciate some guidance (see later).

In the client program I set up an FML buffer with tpalloc, and loaded a string field using Fchg32. I then executed a tpacall which worked fine. I did not clear the buffer, used Fchg32 to load the same field occurrence again, and executed a second tpacall to a different service. Everything worked fine (note that there was no intervening tpgetrply). The TSAM manager was fired up at the time, and the LMS was booted, but I had not enabled the single TSAM monitoring policy I had defined.

I then enabled the monitoring policy, and ran the same client operations again. The first tpacall was successful, but the subsequent Fchg32 failed with what appears to be a protection fault in LIBFML32.dll (I also got the same result using Fchgs32):

Problem signature:
Problem Event Name:     APPCRASH
Application Name:     training.exe
Application Version:     0.0.0.0
Application Timestamp:     4c6bd8a6
Fault Module Name:     LIBFML32.dll
Fault Module Version:     0.0.0.0
Fault Module Timestamp:     4bac3744
Exception Code:     c0000005
Exception Offset:     000058c2
OS Version:     6.1.7600.2.0.0.256.48
Locale ID:     7177
Additional Information 1:     0a9e
Additional Information 2:     0a9e372d3b4ad19135b953a78882e789
Additional Information 3:     0a9e
Additional Information 4:     0a9e372d3b4ad19135b953a78882e789

I subsequently disabled the policy, and everything worked OK. The policy was as follows:

+<monpolicy>+
+<policy name="test" domainid="TUXEDOTRAINING:johannesburg:44000" description="">+
+<callpath>+
+<ratio>1</ratio>+
+<dynfilter>(TA_MONPROCTYPE==0)&&(TA_CLTNAME%%'training')</dynfilter>+
+</callpath>+
+</policy>+
+</monpolicy>+

I overcame the problem by using Finit32 to clear the buffer after executing the first tpacall.

My questions are as follows:

1. I've always assumed it is permissable to reuse a buffer in this manner (e.g. sending the same buffer to different services) and that it was possible to add/change the buffer contents when doing so. Am I correct?

2. It would appear that TSAM, when enabled, loads information into the message buffer prior to executing the call to the service, and that this might have some bearing on the problem. Could someone explain exactly what happens here, and whether it would be good practice to initialise the buffer prior to using it again?

Thanks & regards,

Malcolm.
  • 1. Re: FML operation fails when TSAM policy is enabled
    652903 Explorer
    Currently Being Moderated
    After further testing I have discovered that reindexing the buffer using Findex32 also solves the problem - this allows the buffer contents to be preserved, which was not possible with Finit32. It looks as if there is some kind of index corruption.

    I would be grateful for any feedback/suggestions (see my earlier post).

    Regards,
    Malcolm.
  • 2. Re: FML operation fails when TSAM policy is enabled
    Todd Little Expert
    Currently Being Moderated
    Hi Malcolm,

    Can you put together a reproducer on a supported platform? This sounds like a bug, although a very weird one to say the least. TSAM itself uses FML32 buffers to report the monitoring data to the TSAM plug-in, but that shouldn't interfere with application use of FML/FML32 buffers. If you can reproduce this, I'd suggest opening a support request. Although it's possible it is a platform specific problem, it seems a bit unlikely.

    Regards,
    Todd Little
    Oracle Tuxedo Chief Architect

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points