Nested choosecase problem

We are using 24x7 Scheduler 3.4.27.

This has been happening for several versions of 24x7 that we've had. Sometimes when we run a job that has a "choosecase" statement within a "choosecase" statement, the 24x7 job jumps to random places within the script while executing. Even during debugging we've experienced this behavior. Also, it doesn't always happen. We do have some scripts with nested "case" statements that work fine. Anyway, once we change the inner case statement into an "if" statement, the problem goes away. I wasn't sure if SoftTree was aware of the bug or if they are currently working on it, but I just wanted you (so it could be fixed) and users (so they can workaround it) to be aware of it.

Please post your job script.

Code:

dim unique_num, string 16388
// Unique number parameter given to the job processor
dim creation_date, string 12/7/2007
// Creation date of this script
dim job_name, string Optix_Copy_Schedule_Script_16388
// Job name

job_started(job_num, job_name, unique_num, param_path)

//------------------------------------------------------------------------------
// Optix_Copy
//
// The job copies files from the "user data files\out\optix" directory to
// the Optix server. It also copies any files that it processes to a
// "sent files" directory.
//
/////////////////////////////////////////////////////////////////////////////////////
//dim error_code string
//dim param_path, string "08252004_TEST_13245.txt"
//dim job_num, number 963
//dim unique_num, string "13245"
//dim job_name, string "TEST_Test_13245"
//dim creation_date, string "25-Aug-04"
//messagebox "You forgot to comment out the calling variables"
//////////////////////////////////////////////////////////////////////////////////////

dim cut_length number
dim dir_mask string
dim dir_to_search, string
dim dummy string
dim error_code string
dim error_code_is_A, boolean
dim file_list, string
dim file_name, string
dim new_file_name string
dim out_file_name, string
dim path_new_file string
dim report_param string
dim report_name string

@SCRIPT:s:\24x7_scripts\PCC_DEFINES.JAL

//Get a list of all the files to send
concatex User_Data_Dir, "out\\optix\\", dir_to_search
Length( dir_to_search, cut_length )
concatex dir_to_search "*.txt", dir_mask
DirEx( dir_mask, file_list )
keep_parsing:

GetToken( ",", file_list, file_name )

set out_file_name file_name
Replace( out_file_name, 1, cut_length, "", out_file_name )
choosecase out_file_name end_of_check
case "" " "
goto end_optix_copy
end_of_check:

//Create a new file with a name free from spaces and -'s
ReplaceAll out_file_name " " "_" new_file_name
ReplaceAll new_file_name "-" "" new_file_name
concatex dir_to_search new_file_name path_new_file
filecopy file_name path_new_file

//Get the name of the report
filesplitname file_name, dummy, report_name
left report_name, 7, report_name

//Decide whether or not to execute fixoptixstmts.java
choosecase report_name, choose_to_run
case("MLG0671","PBO0110","PBO0111","PBO0810","PCC0534","PCC0545","PCC0845","PCC0925")
//Fix the temp file with correct format
concatex "\"", path_new_file " ", path_new_file, " ", "0", " OPTIX_PAGE_BREAK" "\"", report_param
remoterun("FixOptixStmt.bat", report_param, External_Exe_Path, " ", " ", error_code)

// This "if" statment works
match error_code, "A", error_code_is_A
if error_code_is_A, fixOptixStmt_could_not_run, fixOptixStmt_finished
fixOptixStmt_could_not_run:
   logaddmessageDB("INFO", job_num, job_name, "FixOptixStmt could not run")
   goto end_optix_copy
fixOptixStmt_finished:
   logaddmessageDB("INFO", job_num, job_name, "FixOptixStmt finished")

// The script does not work when this "choosecase" is uncommented.
//choosecase error_code, end_OF_FixOptixStmt_RUN
//case ("A")
// logaddmessageDB ("INFO", job_num, job_name, "FixOptixStmt could not run")
// goto end_optix_copy
//caseelse
// logaddmessageDB ("INFO", job_num, job_name,"FixOptixStmt finished")
//end_OF_FixOptixStmt_RUN:
caseelse
logaddmessageDB ("INFO", job_num, job_name, "FixOptixStmt skipped")
choose_to_run:

//Send to Optix
FTPPutFile( OPTIXIP, OPTIXUSERCODE, OPTIXPASSWORD, path_new_file, new_file_name )

//clean up the original and the sent file and continue parsing the other files
concatex User_Data_Dir, "out\\optix\\", "sent files\\original\\" out_file_name out_file_name
filemove file_name out_file_name
concatex User_Data_Dir, "out\\optix\\", "sent files\\" new_file_name out_file_name
filemove path_new_file out_file_name
choosecase file_list end_of_file_list
case "" " "
//No more files to parse
caseelse
goto keep_parsing
end_of_file_list:

end_optix_copy:

job_completed(16388, error_code)

On a first look there are no obvious syntax errors or incorrect function usages, as far as I can tell. Because of several custom function calls and dynamic "include" of an external script, it is hard to see how exactly this script works in run-time. It would be nice to see several traces of this job to identify various run-time scenarios and figure out why it doesn't always work as expected. I suggest checking 2 things:

1. This is a complex job. It should not have "ignore errors" turned on the job-level because if it continues after an error it is going to be very difficult to troubleshoot it or even find exact place of an error.

2. Enable tracing on the scheduler level (Tools/Options; Trace enabled). Let the job run several times and compare traces of that job after several runs. The traces should show the execution path and give you an idea what makes them different. Note that the traces for this job, including all nested function calls, will appear in the Performance Data subfolder in a file named [n].log where [n] is the ID of this job

Well, now we're using version 3.4.30. We've also discovered that the problem doesn't cause scripts to jump to a random place, but to jump back to the very beginning. We know that we could change the code (and have in a few scripts) to get around the problem, but we have hundreds of scripts, and almost all of them have nested "choosecase" statements. It would take an unrealistic amount of time to change all of them at once.

Because of the complexity of the previous job, I have written a very simplified, pointless job to demonstrate the behavior. Here's the code:

Code:

dim test_var1, string
dim test_var2, string
dim test_var3, string

set test_var1, "This variable is useless"
set test_var2, test_var1
set test_var3, test_var2

messagebox "We're in the main job."

@SCRIPT:S:\24X7_SCRIPTS\EXTERNAL_SCRIPTS\BjyTest.jal

//----------------------------------------------------------------------
// Below is the code that is executed in the above @SCRIPT
//----------------------------------------------------------------------
dim user_input, string

get_user_input_again:
inputbox "0. Enter \"A\" or \"B\". It doesn't matter which.", "Edit", user_input
choosecase user_input, end_user_input0_check
case "A"
messagebox "You entered A."
case "B"
messagebox "You entered B."
end_user_input0_check:

inputbox "1. Enter \"A\" - Abort or \"C\" - Continue", "Edit", user_input
choosecase user_input, end_user_input1_check
case "A"
messagebox "The user chose to abort the script. It's aborting..."
goto end_bjy_test
caseelse
inputbox "2. Enter \"Q\" - Quit or \"K\" - Keep Running", "Edit", user_input
choosecase user_input, end_user_input2_check
case "K"
   choosecase user_input, Htermck_end
   case "K"
      messagebox "Innermost case 1"
   caseelse
      messagebox "Innermost case 2"
   Htermck_end:
   messagebox "The user chose to keep running the script. It's going to ask user for input again."
   goto get_user_input_again
caseelse
   goto end_bjy_test
end_user_input2_check:
end_user_input1_check:

end_bjy_test:

If this script behaves the same for you as it does for me, here's what should happen:
1. For the first input box give, A or B.
2. For the second input box, give C.
3. For the third input box, give K.
4. It should loop back around and ask for A or B, again. Answer either one.
5. Next, the script (If it is behaving the same as for me, which is incorrectly) will display the message box indicating that it's in the parent 24x7 job ("We're in the main job.") When I debug it, it jumps all the way back to the very first line, "dim test_var1, string".

It works fine for me. I tried running it in debugger 3 times ina row and also twice in Run Now mode. It doesn't get out of the loop and I get "We're in the main job" message only once when the job starts.

Is the BjyTest.jal file a regular text file with ASCII encoding? If you open that file in Notepad and choose Save As, what is displayed in the Encoding drop-down?

I'm puzzled by the strange behavior of this script running on your system. Can you post a trace demonstrating an abnormal run of the script? I would like to see the line before it jumps to the very beginning of the job. Maybe I will see something in the trace that provides the clue to the jump.

Is the BjyTest.jal file a regular text file with ASCII encoding? If you open that file in Notepad and choose Save As, what is displayed in the Encoding drop-down?
"ANSI"

Can you post a trace demonstrating an abnormal run of the script?
Here is the text produced in the script.log file when tracing is enabled:

Quote:

JAL
**** 5/20/2008 15:22:22 ****

JAL 1: DIM
JAL 1: Executing DIM("TEST_VAR1", "STRING")
JAL 2: DIM
JAL 2: Executing DIM("TEST_VAR2", "STRING")
JAL 3: DIM
JAL 3: Executing DIM("TEST_VAR3", "STRING")
JAL 5: SET
JAL 5: Executing SET("test_var1", "This variable is useless")
JAL 6: SET
JAL 6: Executing SET("test_var2", "test_var1")
JAL 7: SET
JAL 7: Executing SET("test_var3", "test_var2")
JAL 9: MESSAGEBOX
JAL 9: Executing MESSAGEBOX("We're in the main job.")
JAL
JAL 11: DIM
JAL 11: Executing DIM("USER_INPUT", "STRING")
JAL 14: INPUTBOX
JAL 14: Executing INPUTBOX("0. Enter "A" or "B". It doesn't matter which.", "Edit", "")
JAL Return "A"
JAL 15: CHOOSECASE
JAL 15: Executing CHOOSECASE("user_input", "END_USER_INPUT0_CHECK")
JAL 16: CASE
JAL 16: Executing CASE("A")
JAL 17: MESSAGEBOX
JAL 17: Executing MESSAGEBOX("You entered A.")
JAL
JAL 18: CASE
JAL 18: Executing CASE("B")
JAL 22: INPUTBOX
JAL 22: Executing INPUTBOX("1. Enter "A" - Abort or "C" - Continue", "Edit", "A")
JAL Return "C"
JAL 23: CHOOSECASE
JAL 23: Executing CHOOSECASE("user_input", "END_USER_INPUT1_CHECK")
JAL 24: CASE
JAL 24: Executing CASE("A")
JAL 27: CASEELSE
JAL 27: Executing CASEELSE()
JAL 28: INPUTBOX
JAL 28: Executing INPUTBOX("2. Enter "Q" - Quit or "K" - Keep Running", "Edit", "C")
JAL Return "K"
JAL 29: CHOOSECASE
JAL 29: Executing CHOOSECASE("user_input", "END_USER_INPUT2_CHECK")
JAL 30: CASE
JAL 30: Executing CASE("K")
JAL 31: CHOOSECASE
JAL 31: Executing CHOOSECASE("user_input", "HTERMCK_END")
JAL 32: CASE
JAL 32: Executing CASE("K")
JAL 33: MESSAGEBOX
JAL 33: Executing MESSAGEBOX("Innermost case 1")
JAL
JAL 34: CASEELSE
JAL 34: Executing CASEELSE()
JAL 37: MESSAGEBOX
JAL 37: Executing MESSAGEBOX("The user chose to keep running the script. It's going to ask user for input again.")
JAL
JAL 38: GOTO
JAL 13: Executing GOTO("GET_USER_INPUT_AGAIN")
JAL 14: INPUTBOX
JAL 14: Executing INPUTBOX("0. Enter "A" or "B". It doesn't matter which.", "Edit", "K")
JAL Return "B"
JAL 15: CHOOSECASE
JAL 15: Executing CHOOSECASE("user_input", "END_USER_INPUT0_CHECK")
JAL 16: CASE
JAL 16: Executing CASE("A")
JAL 1: DIM
JAL 1: Executing DIM("TEST_VAR1", "STRING")
JAL 2: DIM
JAL 2: Executing DIM("TEST_VAR2", "STRING")
JAL 3: DIM
JAL 3: Executing DIM("TEST_VAR3", "STRING")
JAL 5: SET
JAL 5: Executing SET("test_var1", "This variable is useless")
JAL 6: SET
JAL 6: Executing SET("test_var2", "test_var1")
JAL 7: SET
JAL 7: Executing SET("test_var3", "test_var2")
JAL 9: MESSAGEBOX
JAL 9: Executing MESSAGEBOX("We're in the main job.")

I see what I did differently. I can reproduce this issue now. This looks like a bug to me. Something is not right with the JAL interpreter. Something is confusing it and making it jump to the beginning of the script rather then beginning of the first CHOOSE. Somehow it doesn't understand where the combined code actually starts; I mean which part of the code owns nested CHOOSE constructs. I'll confirm this issue tomorrow.

This issue has bee fixed in version 3.4.32

This issue has bee fixed in version 3.4.32