Winbatch performance issue Severity-1

[Vasan]

We're using licenced version of WinBatch product since last 2 months.

Presently we have a major performance issue, would like to know how to fix this issue. Please see the details given below
WinBatch Version: 2018B
Winbatch DLL version: 6.18 BRB
Issue Description: Sending files to OpenText via WinBatch is running late by 4 hours which is a major performance issue (normally it takes 19 minutes)

Please Help  us to fix the issue ASAP, this is affecting our production work

[ChuckC]

Uh... Let me make sure my understanding of the vaguely described "performance issue" is correct:

1)  You have a license for WinBatch.

2)  You are using a WinBatch script [compiled to a .EXE file?  running just as a .WBT file?] to upload some files [by what method/protocol?].

3)  After 2 months of working properly, now, without any changes to the installed version of WinBatch [please confirm this], and with no changes having been made to your script [please confirm this], the file upload/transfer process is suddenly taking significantly longer than usual.


If that description is accurate, I'm failing to see how what you have described qualifies as a WinBatch problem.  It is highly likely that there is another element in the overall computer & network environment [including network & system resources out on the 'Net] that has been changed/modified in some way, or is otherwise experiencing a temporary problem of some sort.

Please fill in the blanks in terms of answering the above listed questions as well as explaining in more detail how you are making use of WinBatch and what the troubleshooting methodology is that you are using that makes you think this is somehow a WinBatch problem.

[Vasan]

Hi Chuck

Thanks for the reply. Please see my inline reply given below.

1)  You have a license for WinBatch.
RRD] Yes

2)  You are using a WinBatch script [compiled to a .EXE file?  running just as a .WBT file?] to upload some files [by what method/protocol?].
RRD] Complied to an .EXE file upload files by - run/hide/wait method

3)  After 2 months of working properly, now, without any changes to the installed version of WinBatch [please confirm this], and with no changes having been made to your script [please confirm this], the file upload/transfer process is suddenly taking significantly longer than usual.

RRD] There is a miscommunication here. We're first time using this in production without any changes to the installed version of WinBatch and no changes made to the script

Actually the process is, we are invoking OpenText Exstream engine from winbatch to run a process. This is taking more time.

Please assist us

[td]

As Chuck pointed out, there is absolutely no indication that this is a WinBatch issue.  Your problem lies elsewhere.  You will need to examine your execution environment and any changes that have occurred in it.  Since you may be dealing with network communication of some kind,  the problem could easily reside with the remote target or targets of your communication.   You might consider contacting the providers of your "OpenText Exstream" software for help.   

[ChuckC]

3)  After 2 months of working properly, now, without any changes to the installed version of WinBatch [please confirm this], and with no changes having been made to your script [please confirm this], the file upload/transfer process is suddenly taking significantly longer than usual.

RRD] There is a miscommunication here. We're first time using this in production without any changes to the installed version of WinBatch and no changes made to the script

Actually the process is, we are invoking OpenText Exstream engine from winbatch to run a process. This is taking more time.

The next step you need to take in troubleshooting your environment is to decouple WinBatch from the "OpenText Exstream engine" and run that 2nd part manually and observe how it performs.  Is it what is taking an excessively long period of time to complete the upload/transfer?  Additionally, have your WinBatch script launch something like notepad.exe and see how quickly Notepad appears on the desktop [assuming your script isn't being run in the native NT service environment w/o access to the interactive desktop].

[td]

The next step you need to take in troubleshooting your environment is to decouple WinBatch from the "OpenText Exstream engine" and run that 2nd part manually and observe how it performs.  Is it what is taking an excessively long period of time to complete the upload/transfer?  Additionally, have your WinBatch script launch something like notepad.exe and see how quickly Notepad appears on the desktop [assuming your script isn't being run in the native NT service environment w/o access to the interactive desktop].

Such steps could eliminate WinBatch as a cause but it cannot implicate WinBatch as the cause.  What it may do is narrow down the environmental change possibilities to consider.

[ChuckC]

Agreed.

As always, when troubleshooting a complex assembly of disparate pieces of software that are not working together harmoniously, dividing & conquering is necessary until the root cause has been identified.  I would fully expect that such an approach puts WinBatch in the clear and gets the OP moving in the right direction in terms of finding out what is misbehaving in their environment.

[Vasan]

Thanks Team.

We got the solution. The issue is that OpenText is 64bit whereas WinBatch is 32 bit. Hence we have upgraded the WinBatch with 64 bit and batch is running as expected.

Monitored today and confirmed that batch is running as expected. The issue is set to be closed.

[td]

64-bit WinBatch isn't an "upgrade".  It is just a part of the WinBatch installation unless you deliberately decline its installation when running WinBatch's setup.

You only gave a very vague description of how you were using WinBatch but generally, simply starting a 64-bit executable from either 32-bit or 64-bit WinBatch all most always doesn't make any difference.  Things like file and registry redirection can cause bitness related problems but that affects the scripts themselves.  It rarely affects programs started by WinBatch scripts.  This suggests that your script was not coded correctly to account for file and registry redirection in the first place.  Instead of fixing your script, your solution was to switch to 64-bit WinBatch instead. There is basically nothing wrong with switching exe bitness but unless you get a grasp on how bitness affects script behavior, you will likely encounter this issue again.