CMD: Calling internal procedures in a batch file

I think a lot of Windows command batch scripters are not aware that you can call an internal procedure within a batch file. I sure did not find out about it until about 3-4 years ago.

Anyway, to get this work, first you must create a procedure. A procedure is like any standard batch script except that you must enclose it with a label at the head and goto label at the foot.

:MyProc

set myname=%1

@echo this is my first procedure

@echo my name is %1

goto :EOF

The start of the procedure is defined by the label :MyProc. A label always begins with a semi-colon. If you are accepting arguments in your procedure, you should treat it like a normal arguments, i.e. %1, %2, etc. You must end the procedure with a goto :EOF statement, if you don’t the procedure will continue running any commands below it.

CMD: Scripting Windows drive creation

For some reasons, our newly published (by our engineering team) server build program missed creating and formating the D drives on Windows 2000 servers. Of course, the simple solution it to just logon to the servers and format D: as normal to resolve this problem. But what if you have 30 or 100 servers that had the D: missing? This gives me another opportunity to test my scripting skills agian.

To create and partition the disk, I used DISPART.exe, which is a free MS util that you can download from, where else, MS website.

I used the following commands to create an new D partition:

SELECT Disk 1
Create Partition Primary
Assign letter=D

Unfortunately diskpart does not have a format function. For that, you have to use your old trusty FORMAT.EXE.

In command prompt, I typed the following command:

Format d: /fs:ntfs /v:DataD

But it gave me an error saying the volume or drive could not be found. I realise what happened quickly, I was logged on via terminal session and Windows 2000 did not refresh my session with the new drive information that FORMAT can use. I had to log off and log on again and rerun the command, which works. Now… I am even more determined to script this as I neither want to logon to console to do this one-by-one, nor log on, off and on just to create a D drive.

The problem with the FORMAT command is that it will prompt you with warning that you are going to erase all data. There are not quiet mode around this. To script it, you have to send the text “Y” to the command. Hence, the improved command is now:

type %~dp0ANS.txt | format d: /fs:ntfs /v:DataD

ANS.txt just contains “Y” with a carriage return.

For those who don’t know it %~dp0 is a variable substitution that substitutes the full path where your script is being run.

So I started up my task scheduling script and changed it so that it schedules diskpart to run first, then 2 minutes later, another task runs the format command. The 2nd task should get the new drive as it logs on to run the task.

REM slowing down BAT execution

This may come to a surprise to some of us, but about 2 years back engineering guys implemented a batch logon script which is run on in Windows XP workstations. The domain controllers are centralised to Singapore and the small branches (e.g. Thailand) logon to the DC in Singapore.

A strange thing happened at logon, it was taking a few minutes to execution. We all thought that it was the bandwidth was causing the problem, it couldn’t be the XP machines, since they are new and no way would execute a simple logon script that slowly. However, the bandwidth was found to be acceptable and so I had a look at the logon script. Nothing unusual with it, its a few lines and calls some other routines.

So I modified the logon file and piped “time /t” commands between codes to see where it was slowing down. The result was interesting, it took a few minutes to execute the starting portion of the logon script. When I looked at it, there was no routines or programs being executed, only REM as part of documentation and change history. It was just too weird, I had thought that REM would not cause any penalties to the execution cycles. Disbelieving myself, I took all the REM statements out and the logon script went through at normal speed!

This was 2 years ago, so I don’t know if it has changed much, but my conclusion went something like this:

• REM statements are evaluated in Windows and takes up cycle time.We don’t notice them most of the time because of the speed of execution. However, because the batch file was run from a moderate to low bandwidth location across a WAN, this becomes obvious.

• The execution engine for BAT (legacy DOS) and CMD are different. The logon file was running as a BAT file uses possibly a 16-bit DOS engine, whereas CMD used the 32-bit engine. I tested the same batch file by renaming it to CMD and it ran perfectly. (I cannot find any reference for this, so I might be wrong).