I would like to request a fix. When I use the CD statement in a JAL script and then run that script in debug mode to check out the script the next time I save the changes to the script they appear to go into the directory that I pointed to with the CD statement in the JAL script. The default directory for 24x7 should not change when I run debug. 24x7 should point back to its default directories when debug is terminated so when you go into edit to make any changes and then save those changes they go to 24x7 directory insted of some server out in never never land.

It can happen both in debug and normal mode. Every time you open or save files in another directory Windows changes the current directory to the last used one.
By Windows design one application can have only one current directory. If you are running some jobs in background you should be very careful when opening and saving files because Windows can change the current directory and this may affect the background jobs.
That's why using the CD statement is not a good idea. Consider two jobs A and B running simultaneously. Job A uses CD (Current Directory) to set current directory to c:\abc and prepares to execute the next statement. In this moment job B uses CD to set current directory to c:\bcd and this may cause job A to fail. Please whenever possible use full file names to make your jobs directory independent.

: I would like to request a fix. When I use the CD statement in a JAL script
: and then run that script in debug mode to check out the script the next
: time I save the changes to the script they appear to go into the directory
: that I pointed to with the CD statement in the JAL script. The default
: directory for 24x7 should not change when I run debug. 24x7 should point
: back to its default directories when debug is terminated so when you go
: into edit to make any changes and then save those changes they go to 24x7
: directory insted of some server out in never never land.

If you created your own CD command you could accomplish this without effecting other processes. Your own CD Statement could store the current scripts directory in memory and append this to subsequent directory and file commands. When that script has terminated the memory slot would be freed up for other scripts. Using a global that is created by 24x7 using the JAL script name or process ID as part of the global name could accomplish this. If you built this into 24x7 the CD statement would be harmless to other processes and your customers could could use CD statement to their hearts content.

: It can happen both in debug and normal mode. Every time you open or save
: files in another directory Windows changes the current directory to the
: last used one.
: By Windows design one application can have only one current directory. If you
: are running some jobs in background you should be very careful when
: opening and saving files because Windows can change the current directory
: and this may affect the background jobs.
: That's why using the CD statement is not a good idea. Consider two jobs A and
: B running simultaneously. Job A uses CD (Current Directory) to set current
: directory to c:\abc and prepares to execute the next statement. In this
: moment job B uses CD to set current directory to c:\bcd and this may cause
: job A to fail. Please whenever possible use full file names to make your
: jobs directory independent.