Vern described the problem you're seeing exactly. Now I'd like to share
a little trick to help you get around it when you simply must pass more
than 32 bytes on a call.

In the calling program, define the variable to be passed to the called
program one byte longer than necessary and put an "*" or something in
the LAST byte. For example, if I want to pass 100 bytes, I define it as
101 and put "*" in position 101 on the sending side. The receiving side
defines the variable as 100 bytes, ignores the extra byte, and
everybody's happy. 

Z

> -----Original Message-----
> From: Vern Hamberg [mailto:vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, February 19, 2003 9:52 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: SBMJOB inserting nulls
> 
> 
> Dan, this is known behavior ever since the beginning (of the 
> 38 & 400, that 
> is). IBM knows of the problem because it is by design. Here 
> are a couple 
> bits from the CL Programming manual:
> 
> >When you use the CALL command, character string constants of 
> 32 bytes or 
> >less are always passed with a length of 32 bytes. If the 
> string is longer 
> >than 32, you must specify the exact number of bytes, and 
> pass exactly that 
> >number.
NOTICE: This E-mail may contain confidential information. If you are not
the addressee or the intended recipient please do not read this E-mail
and please immediately delete this e-mail message and any attachments
from your workstation or network mail system. If you are the addressee
or the intended recipient and you save or print a copy of this E-mail,
please place it in an appropriate file, depending on whether
confidential information is contained in the message.


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.