The skipping of remaining 4NT job steps

[William Siu]

We upgraded the 4NT to 8.02.105 since October 4, 2008 and reinstalled again on Feb 22, 2009. I have the following findings and would like to seek your comment or confirmation:-
1. As we searched through the application and system event logs in Windows, It looks like the 4NT shell is not abending and we suspect that the skipping of remaining 4NT job steps might be caused by the memory holding the remaining job steps were messed up for some reasons. As a result, 4NT can still go back to it's parent CMD with '0' exit code as if it is normal completion (PS we tweak this case zero exit code to 8888 to allow Control_M to report this error case) .
2. As we have a lot of jobs running concurrently, once a job has the problem, those others running will have the same problems.
3. Searching through the possible interactions among the jobs, I found that there are parameters at 4NT.INI, we set as below and use the default (e.g. DIRHISTORY is 1024).
LocalAliases=Yes
LocalDirHistory=No
LocalFunctions=No
LocalHistory=No

I would like to your confirmation of the possibility that the setting with "No" (i.e shared memory) to the above parameters will cause the problem if the memory buffer allocated overflows by globally sharing the memory? The overflow, say may be we have a great number job steps and concurrent jobs.
Do you think we should set those to "YES"? or are there any other memory sharing scenarios that the jobs have interfering the others?

 

[Charles Dye]

This is all terribly vague. Can you give an example of a specific command which causes a problem for you, and explain clearly what that problem is?

 

[epement]

We upgraded the 4NT to 8.02.105 since October 4, 2008 and reinstalled again on Feb 22, 2009. I have the following findings and would like to seek your comment or confirmation:-
1. As we searched through the application and system event logs in Windows, It looks like the 4NT shell is not abending and we suspect that the skipping of remaining 4NT job steps might be caused by the memory holding the remaining job steps were messed up for some reasons.

As Charles Dye wrote, your email is very vague. However, I came across your complaint of "the skipping of remaining 4NT job steps."

Are you saying that you are running a batch file, and that the batch ends prematurely, with an exit status of zero?

If this is what you are saying, I suspect that your parent (main) batch file may be using another batch file within it, and the command is not prefixed with the word "CALL". If I am executing a series of commands within a batch file, I sometimes forget that one of those commands may be another batch file. If I fail to prefix the internal batch file name with "CALL", the parent batch file will end right away with a normal exit code.

Type "help call" from the 4NT command prompt for information on using CALL.