× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: CMD-parm in SBMJOB
  • From: John.Earl@xxxxxxx (John Earl)
  • Date: Wed, 07 May 1997 16:45:20 -0700
  • Organization: Recreational Equipment Incorporated ( REI )

Christian Zander (KMZ AG) wrote:
> 
> Hello everybody,
> 
> I want to inform you that since V3R2 and V3R7 there is a nice little problem
> with long text-variables in CL-Programs submitted with SBMJOB CMD(Call xxx
> ('jshdfks')).
> 

Christian,

This little piece of excitement has been around a lot longer than V3.  I
ran into it hard under V2R1, and I vaguely recall seeing the problem (or
a similar incarnation) in S/38 CPF.


>  I found this problem using a 40 character long variable used as an
> input-parameter for an cl-program submitted. The variable contains at the
> moment of the SBMJOB only blanks. The submitted program gets 34 blanks and
> some data! If one would always read the fu... manuals, one would have known

I'm surprised that you got _34_ blanks.  As I understand it, when a
character parameter that is longer than 32 bytes is passed from a SBMJOB
CMD parm, bytes 33 though the end of string will not be intiialized by
the OS/400.  

Yes it's a goofy implementation, but there must be a really good reason
for it, because it has been an issue for a long time and IBM has not
seen fit to fix it.

The work-around is, as you quoted:

>       For CL character variables larger than 32 characters where trailing
>        blanks are significant, create a variable that is one character larger
>        than needed and substring a non-blank character into the last
>        position.  This prevents the significant blanks from being truncated.
>        The called program should ignore the extra character because it is
>        beyond the length expected.
> 

Hoakey?  yes, but so is the problem that the solution addresses.


jte


*************************************************
*                                               *
* John Earl             - Gig Harbor, Washington*
* johnearl@blarg.net    - Home                  *
* jearl@rei.com         - Work                  *
*                                               *
*************************************************

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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.