D3 and mvBase

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:

1. Logon to dm
2. Run callx-off at TCL
3. Logto somewhere.
4. Run your routine.
5. Log back to dm.
6. 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,

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

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,

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:

1. Logon to dm
2. Run callx-off at TCL
3. Logto somewhere.
4. Run your routine.
5. Log back to dm.
6. 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,

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,

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,

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,

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:

1. Logon to dm
2. Run callx-off at TCL
3. Logto somewhere.
4. Run your routine.
5. Log back to dm.
6. 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,

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, 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?

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,

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,

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:

1. Logon to dm
2. Run callx-off at TCL
3. Logto somewhere.
4. Run your routine.
5. Log back to dm.
6. 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,

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

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,

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?

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,

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,

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:

1. Logon to dm
2. Run callx-off at TCL
3. Logto somewhere.
4. Run your routine.
5. Log back to dm.
6. 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,

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

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...

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,

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?

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,

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,

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:

1. Logon to dm
2. Run callx-off at TCL
3. Logto somewhere.
4. Run your routine.
5. Log back to dm.
6. 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,

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

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...

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,

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?

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,

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,

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:

1. Logon to dm
2. Run callx-off at TCL
3. Logto somewhere.
4. Run your routine.
5. Log back to dm.
6. 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,

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

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