Toggle DEBUG_LOGGING On/Off on the fly

Hi Adrian,

You need to create the BSFN the "long" way through OMW, i.e. create the data structure with Data Structure design Tool to match the sample, then create the BSFN skeleton through OMW specifying your data structure, then edit the BSFN where if you are careful you can paste the body of my bsfn over the body of the skeleton BSFN. You should just accept the default CCUSTOM.DLL when creating the BSFN definition.

Let me know how it goes.

I really should rewrite the app so that it doesn't use a BSFN at all... I was just lazy as the BSFN was already deployed on our system. However, I'll just have to test that it will still work properly that way!

Cheers,
JohnO
 
Re: RE: Toggle DEBUG_LOGGING On/Off on the fly

Howdy Alex,

Good question - as far as I know, it should not really matter if the code in the BSFN was coded directly into the app instead,. That would make it far easier to deploy this thing. If I get a chance today I'll try it out.

As far as you second question is concerned, I expect the other user would find their system is suddenly logging! Haven't tried that. Even more interesting would be to build the BSFN on the enterprise server and OCM it to run there. Could blow it up so please everybody, don't try that on your prod box! If you do try it on a dev enterprise server please let me know what happens.

Cheers,
JohnO
 
Re: RE: Toggle DEBUG_LOGGING On/Off on the fly

John,

I would be interested to know the outcome: I believe it will not work without a BSFN wrapper (you cannot just jdeCallBSFN it since it has no OL name), but if it does, it's going to be a ten times shorter way than mine...

For the WTS, I think your version will only work in your session. MS even created special blocks against the API's I used to prevent people from affecting other session processes.

I have an idea which, if works, could give me a way of enhancing my version to let the WTS admin person to toggle logging in any given OneWorld process in the system, but it's hard to say without first testing it...

Regards,
Alex.
 
Re: RE: Toggle DEBUG_LOGGING On/Off on the fly

Well, I recoded the BSFN code directly into the app but it doesn't quite work and needs a little further investigation. If I get time I'll look into it later...

TTFN,
JohnO
 
Zakeer and Alex,

When I call the API to toggle logging from my app, I.e. not from within a BSFN, it only works on the externap app's process (you referred to this Zakeer). If you call the api from within a BSFN it applies to all the OW process.

The reason for this is that the api sets a global variable i.e. in-process. I *really* hoped it would use a windows message like any "proper" program would! :-( . The way standalone apps work using the interop api's is to send jdenet messages to OW either on the client or the server. A listener on the OW process then handles the message... in our case, a request to run a BSFN.

I think I can see what Alex's program is doing: attaching to OW as a debugger so it can change the global logging variable... clever stuff!

Cheers,
JohnO
 
John,

It's what I thought would happen.

The problem (or rather the brick wall) I'm banging my head at is doing the same under WTS. This appears to be blocked dead, the idea I mentioned (in short, I was trying to relay my hacking through a service application, the idea being that if session-2-session communications are blocked, service-2-any_session may not be) failed miserably.

This raises another issue for me: now that I cannot do it for another session, I need to know which PID is mine, so that I set the value in the process which I do have access to...

Stupid Windows.

BEWARE: my current implementation attempts to set the logging flag to the first (or the last - now that I think of it, it's actually using a different algorithm for W2000 and NT4) PID of OneWorld it can find which on WTS almost necessarily is not the one you're running - I'll be fixing this shortly.

Regards,
Alex.
 
Yes JohnO, I've got that, thank you very much, this is precisely what I'm doing now, the "long" way. I did create the DS, I've created the BSFN skeleton, I copied carefully your bsfn body over my bsfn body, BUT my BDA does NOT accept the default CCUSTOM.dll; it says it is invalid!
Therefore my questions relate to this MISSING dll from my Xe.
And I want to know if this is something NEW to you, OR is it not (you did see it missing when being at other sites, and you ... fixed it)?

Waiting for your reply, I already adopted the LONGER way, creating my own dll. Now I have a problem here, the build function gives me a fatal error (the sCCUSTMFP.dll is missing ... and I'm looking for that OW/Xe Documentation about C BSFN ...)
Thanks,
Adrian Chimirel
PS Re-writing the application without using a BSFN may be fit for a non-technical person, but the way I see it, it is not going to SHARE knowledge on BSFN writing (and, what's a DS/BSFN/dll, piece of cake, as Darren jdeWhippingBoy was - so elegantly - putting it).
 
I am attempting to compile your source (from the download) and am to the
point were I have two (2) link errors. Functions __imp__jdeErrorSetEx &
__imp__jdeErrorClear are not found (LNK2001). I have included jdekrnl.lib
and jdel.lib in the link list. I can see both these functions in the
jdekrnl.lib.

All I can think of is that the signatures (parameter lists) for these
functions are different than the entry in jdekrnl.lib.

Anyone have an idea what I am doing wrong?

Thanks,

Tom Davidson
Xe Update 1 SP 17.1; CO on SQL 7; AS/400; TSE



OW 7332 SP 11.3VER, NT 4.0 SP 5, TSE 4.0 SP 4, Metrframe 1.8, CO SQL 7.0
 
Tom, cannot see anything wrong there.

You could try just deleting these calls from the source as they are not really needed.

Cheers,
JohnO
 
Adrian,

Check the new version - I made a few enhancements...

Regards,
Alex.
 
Is everyone aware that you can stop OneWorld from
writing to the debug log on the fly by setting the
properties of jdedebug.log to READ-ONLY?

I jumped into this one kinda late so forgive me if
this has already been mentioned.



__________________________________________________
 
This works very Nice.....one comment though whenever you modify the file can you include a minimize feature.....your source code will also be nice....but it works like a dream.
 
Unfortunately, it does not make it any faster - it's still attempting to log messages...
 
A new version is now available: I implemented the minimize button and made a couple of other improvements...

Regards,
Alex.
 
Ooups! - Didn't test the mods enough, please wait until I fix the bugs... = Alex.
 
Updated version 5 (5.0.0.10) is now available: I have fixed some bugs and did some testing under NT4 to make sure it works.

Thanks to everybody who reported bugs!

regards,
Alex.
 
New version of Commander fixes some NT4 and B732 compatibility issues.

Thanks to those who brought these bugs to my attention.

Regards,
Alex.
 
Thanks everybody, especially to JohnO, who, patiently, guided my novice steps through developing C BSFN.
1 - His application works fine now.
2 - I found a workaround for my dll creation; I just copied an existing one!
3 - I migrated the application to OW; cool!
Warm regards,
Adrian Chimirel
PS A wish I made to Santa is that Alex would share the details of his findings (not just his executables), too. But he may be too busy these days. I'll wait, patiently. Shared knowledge = Better knowledge, this is what this List is all about, Alex.
 
Back
Top