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.