I guess I should have included a bit more detail. The callx does z googlemap so the api call is done in the googlemap program. The problem I caused this week is that I decided to grab a lat lng and save to the fm file. Well that triggered another job and another and another ..... when I noticed what I had done it was 180000 jobs later. Since the callx is global I am guessing the best solution is to write lat lng to a different file. :)
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... -posted to the "Rocket D3 | mvBase" forum
Original Message:
Sent: 6/7/2024 10:29:00 AM
From: Brian Cram
Subject: RE: callx set on file - how to turn off inside program
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...
------------------------------
Brian S. Cram
Principal Technical Support Engineer
Rocket Software
------------------------------
Original Message:
Sent: 06-07-2024 10:18
From: David Knight
Subject: callx set on file - how to turn off inside program
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,
------------------------------
David Knight
Senior Software Engineer
H3O Business Technologies Limited
Original Message:
Sent: 06-07-2024 10:11
From: Brian Cram
Subject: callx set on file - how to turn off inside program
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?
------------------------------
Brian S. Cram
Principal Technical Support Engineer
Rocket Software
Original Message:
Sent: 06-06-2024 11:37
From: David Knight
Subject: callx set on file - how to turn off inside program
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,
------------------------------
David Knight
Senior Software Engineer
H3O Business Technologies Limited
Original Message:
Sent: 06-06-2024 11:30
From: craig curtis
Subject: callx set on file - how to turn off inside program
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.
------------------------------
craig curtis
System Programmer
Sevier Valley School District
Richfield UT US
Original Message:
Sent: 06-06-2024 11:20
From: David Knight
Subject: callx set on file - how to turn off inside program
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:
- Logon to dm
- Run callx-off at TCL
- Logto somewhere.
- Run your routine.
- Log back to dm.
- Run callx-on from TCL
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,
------------------------------
David Knight
Senior Software Engineer
H3O Business Technologies Limited
Original Message:
Sent: 06-06-2024 11:01
From: craig curtis
Subject: callx set on file - how to turn off inside program
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
------------------------------
craig curtis
System Programmer
Sevier Valley School District
Richfield UT US
------------------------------
</mail@forum.rocketsoftware.com>