PM> Fair enough that it should take longer to compile, but 8 
 PM> minutes is ridiculous. If the bottle neck is on one line, 
 PM> how is C Set++ generating the code that makes it quicker?

By optimizing the other stuff, which is only executed 20% of the time?

 PM> running since the machine was set up. The PC I'm using 
 PM> currently isn't mine, so I won't get any chance to use 
 PM> square brackets on the mainframe. Besides, there are other 
 PM> programmers that need to maintain the code on a dumb 
 PM> terminal.

So?  I used to convert all my stuff to hex even when I was using a dumb
terminal.  I had macros to convert from/to trigraphs or SAS style brackets.
 I always ended up putting it into the single character, so that it could
print, it could be downloaded to the PC, 
and only took up the room that I expected it to take up.  

 PM> I though you were into C++ now. I figured that even though 
 PM> I probably woulnd't be using C++ at work, I'd make the 
 PM> change now just in case since I'd forget about it later.

With the amount of publicity, I won't forget it if I come across a problem.
 You see, I think there is a hole in C/C++ regarding NULL.  NULL is
normally (void *)0, which means it will convert 0 into a full pointer, so
you can pass this to a function, without requiring a prototype (if you just
passed 0, on a 16-bit machine, it would go to the function as 16-bit,
instead of 32-bit if you were using the large memory model).  However, C++
doesn't allow you to go from (void *) to (int *) etc.  I haven't looked
into it very far.
Paul

---