So I have a dilemma. There is a callx set on a file called FM. I need to update the FM file with a program but if I do it calls the callx. Is there a way inside the program to write to the fm file but disable the callx that is set? I want to be able to update the file FM without triggering the callx.
Ideas?
Thanks
So I have a dilemma. There is a callx set on a file called FM. I need to update the FM file with a program but if I do it calls the callx. Is there a way inside the program to write to the fm file but disable the callx that is set? I want to be able to update the file FM without triggering the callx.
Ideas?
Thanks
Hi Craig,
Kinda. I've never done it; but there is a command 'callx-off' which must be executed from dm. It turns off callx's. I'm guessing that is a global setting.
The reverse is callx-on.
I suppose you could try to put that into your program; but depending upon the nature of your routine it may be easier to do so 'outside' running the routine. That is:
Your question does not elaborate; but in general you would only turn off callx whilst performing some kind of bulk maintenance routine rather than this being a regular 'application' routine. If the latter; one has the wonder why the callx should not run as callx's are often there for ancillary logic operations that must be performed according to business logic. Why would that business logic not apply?
Therefore, my answer may not be of assistance?
Hope it may help though.
Best wishes,
Hi Craig,
Kinda. I've never done it; but there is a command 'callx-off' which must be executed from dm. It turns off callx's. I'm guessing that is a global setting.
The reverse is callx-on.
I suppose you could try to put that into your program; but depending upon the nature of your routine it may be easier to do so 'outside' running the routine. That is:
Your question does not elaborate; but in general you would only turn off callx whilst performing some kind of bulk maintenance routine rather than this being a regular 'application' routine. If the latter; one has the wonder why the callx should not run as callx's are often there for ancillary logic operations that must be performed according to business logic. Why would that business logic not apply?
Therefore, my answer may not be of assistance?
Hope it may help though.
Best wishes,
Thanks David.
I was hoping there was a way to turn off just in the program. The callx is actually running a google api to map a distance. The program needs to run if the FM file changes since it is that file that contains the address. I was wanting to write the results to the fm file but that would cause a loop. :)
I can write the information to a seperate file so the loop doesn't occur and then create a dictionary in the FM. That is probably the solution but thought I would ask.
Thanks David.
I was hoping there was a way to turn off just in the program. The callx is actually running a google api to map a distance. The program needs to run if the FM file changes since it is that file that contains the address. I was wanting to write the results to the fm file but that would cause a loop. :)
I can write the information to a seperate file so the loop doesn't occur and then create a dictionary in the FM. That is probably the solution but thought I would ask.
Hi Craig,
I see, but consider altering the callx instead since it can INTERCEPT the write, do stuff, including getting the reults of the PAI call, update the record in memory and then exit; allowing the record to be written.
As the write has not yet occurred [it was intercepted] you will not get a loop.
There are a bunch of access() calls which retrieve the record about to be written. My fav is access(3). Refer to the manual as it explains be able to do bi-directional stuff which is neat.
HTH
Cheers,
+3Hi Craig,
I see, but consider altering the callx instead since it can INTERCEPT the write, do stuff, including getting the reults of the PAI call, update the record in memory and then exit; allowing the record to be written.
As the write has not yet occurred [it was intercepted] you will not get a loop.
There are a bunch of access() calls which retrieve the record about to be written. My fav is access(3). Refer to the manual as it explains be able to do bi-directional stuff which is neat.
HTH
Cheers,
So, CALLX. The biggest problem I see here is that the CALLX is calling an API, which is a bad idea for one reason: if the calling of the API fails and the CALLX fails, the write to the file will fail with no error or notification. I've seen this before where a CALLX failed on like a customer file, the application went on its merry way, three months later, the user says "hey, I thought I changed that customer's address!! What the heck??".
So I recommend that CALLXs do NOTHING but write to D3-local files, and if they need to trigger something, set up a mechanism where the CALLX updates a "to-do" file, a phantom process monitors that file and does the work instead of the CALLX. That way the CALLX and file writes don't fail. The failure would occur in the phantom, which is easier to monitor.
Perfect for your case (but first you'd need to modify the CALLX to not do anything if the only field being updated is that distance field):
CALLX logs the request for the API
Phantom picks up and processes the API, then writes only the new distance to the file.
Sound about right?
So, CALLX. The biggest problem I see here is that the CALLX is calling an API, which is a bad idea for one reason: if the calling of the API fails and the CALLX fails, the write to the file will fail with no error or notification. I've seen this before where a CALLX failed on like a customer file, the application went on its merry way, three months later, the user says "hey, I thought I changed that customer's address!! What the heck??".
So I recommend that CALLXs do NOTHING but write to D3-local files, and if they need to trigger something, set up a mechanism where the CALLX updates a "to-do" file, a phantom process monitors that file and does the work instead of the CALLX. That way the CALLX and file writes don't fail. The failure would occur in the phantom, which is easier to monitor.
Perfect for your case (but first you'd need to modify the CALLX to not do anything if the only field being updated is that distance field):
CALLX logs the request for the API
Phantom picks up and processes the API, then writes only the new distance to the file.
Sound about right?
Yup, Mr Cram you make an excellent point.
Too busy 'thinking' of how to get around Craig's issue and did not think it any farther than that!
De-coupling the concepts is a much better way.
Allows for 'better' logic in the callx too.
Cheers,
+3Yup, Mr Cram you make an excellent point.
Too busy 'thinking' of how to get around Craig's issue and did not think it any farther than that!
De-coupling the concepts is a much better way.
Allows for 'better' logic in the callx too.
Cheers,
Yeah, my perspective on this is based on years of sitting in my support chair answering calls about failed CALLXs. You sit in my chair long enough, you'll see a lot of crazy stuff, stuff I never saw or considered when I was out there writing application code for money...
Yeah, my perspective on this is based on years of sitting in my support chair answering calls about failed CALLXs. You sit in my chair long enough, you'll see a lot of crazy stuff, stuff I never saw or considered when I was out there writing application code for money...
+3Yes, good point. I guess great minds can sometimes think differently...
So I have a dilemma. There is a callx set on a file called FM. I need to update the FM file with a program but if I do it calls the callx. Is there a way inside the program to write to the fm file but disable the callx that is set? I want to be able to update the file FM without triggering the callx.
Ideas?
Thanks
For what it's worth, I got around this with a named common variable. Set it when I want the callx target NOT to process and modified that callx program to inspect and act on it.
So I have a dilemma. There is a callx set on a file called FM. I need to update the FM file with a program but if I do it calls the callx. Is there a way inside the program to write to the fm file but disable the callx that is set? I want to be able to update the file FM without triggering the callx.
Ideas?
Thanks
Hi Craig
We had a similar situation around 20 years ago. The code inside our CALLX was able to read where the changed data was coming from and simply exit for the one we wanted to ignore.
I have extracted the code from our routine that does this ...
! Check whether we are being called in context of the updating agent
if assigned(caller) then
if caller = 'MVMirror' then return
end
MVMirror was the calling routine we wanted to ignore. This was part of a real-time bidirectional mirroring of data to/from SQL.
"caller" came from a piece of C++ code that was installed via a "shim". That has worked really well on many D3 Windows sites over the last 20 years. I hope what I have shared gives you a clue of how you could do it! If stuck, please let me know and I will take a closer look at the C++ source. This bit of code was written by a developer I had working for me, so I am a bit vague.
Regards,
Alan.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
