Raymond Kingsbury wrote: > > It's quite possible that the COBOL program is passing bad data (or > > more data than it was designed to handle) to the Pascal routine. > > Almost every time I've seen this (assuming the SL procedure has > been more or less debugged), it comes from a procedure that expects > a character string parameter by reference and a length parameter > by value. COBOL, however, likes to pass everything by reference, > so unless you explicitly pass the length parameter by value (by > enclosing it in back-slashes in COBOLII), COBOL passes it's address > (which rarely turns out to also be the length). Another thing to > look out for is the Pascal procedure expecting a byte-address > instead of a word-address (COBOL likes to pass everything as > word-addresses). This, however, generally seems to cause a bounds > violation instead of a subscript range violation. Also he described the problem as intermittent, so if the cause were something blatantly wrong like this I would expect it to fail all the time. Another possible cause (thinking back to Pascal/V days) is that Pascal/V does not initialize STRING type variables automatically, so the length of the string (stored as a separate 16bit value) starts out undefined. As long as you initialize the string by assigning it an entire new value, everything works great. But if you try to use something like STRMOVE to initialize the string you find out that STRMOVE requires the string to already be initialized. So watch out for code that STRMOVEs into a string without initializing the length first. G.