Re: Parm Issues

["Jim Franz" <jfranz@xxxxxxxxxxxx>]

see response below
> Scott
> 1) It's not a bug.
> 2) It's not "compression."  (where did you get THAT from?)
>
> This topic has been discussed extensively here, and has been beaten
> to death.   A "reasonable answer as to why" has been posted here at
> least ten times!
> Check the archives!
>
> On Tue, 17 Apr 2001, Jim Franz wrote:
> > this has been a problem forever on the 400 (maybe 38 too). IBM uses
> > some compression routine on sbmjob.Put a single non-blank char at the
end of
> > the parm (which stops the compression). I have never heard a reasonable
> > answer as to why ibm can't/won't fix this. It's a bug!
> > jim

Scott - checked the archives - below is a clip from one that explains it
very clearly.
The "compression" term came from an IBM developer when I opened a support
issue on this many years ago. The below term "trailing blanks removed" and
the
developer's term (not mine) compression are similar enough for me. At the
time,
their response was "we are not going to open up that code ..." To me, and
the customer, who believed in the idea that code for older releases would
not
break in future releases, we were pretty upset. Cost me about a 1 week
retro-fit. To me, it needs a big red label-WARNING-DATA MAY BE LOST.
jim

archives

Subject: CMD-parm in SBMJOB
From: "Christian Zander (KMZ AG)" <100070.2407@xxxxxxxxxxxxxx>
Date: 07 May 97 14:55:27 EDT

----------------------------------------------------------------------------
----

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')).

 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
this problem. Since this is due to the informtaion from software-support a
new
one, I would have very much appreciated it, if IBM had decided to put this
change in behaviour in their "Important Changes in V3R2" memo. Hm, actually
I
found the following excerpt in CL Programming V3R1. If this has been new to
V3R1, I haven't known it either?

I have copied an excerpt from the Control-language-programming manual for
your information.

 3.4.2.1  Date Type Errors Using the CALL Command
   The total length of the command string includes the command name, spaces,
   parameter names, parentheses, contents of variables and apostrophes used.
   For most commands, the command string initiates the command processing
   program as expected.  However, for some commands some variables may not
be
   passed as expected.  For more information on the topic of variables, see
   "Working with Variables" in topic 2.4.

   When the CALL command is used with the CMD parameter on the SBMJOB
   command, unexpected results may occur.  Syntactically, the CALL command
   appears the same when used with the CMD parameter as it does when used as
   the compiler directive for the CALL command.  When used with the CMD
   parameter, the CALL command is converted to a command string that is run
   at a later time when the batch subsystem initiates it.  When the CALL
   command is used by itself, the CL compiler generates code to perform the
   call.

   Common problems with decimal constants and character variables often
   occur.  In the following cases, the command string is not constructed as
   needed:

      When decimal numbers are converted to decimal constants.

       When the command string is run, the decimal constant is passed in a
       packed form with a length of LEN(15 5).  It is not passed in the form
       specified by the CL variable.
      When a character variable is declared longer than 32 characters.

   The contents of the character variable is passed as described previously,
   usually as a quoted character constant with the trailing blanks removed.
   As a result, the called program may not be passed enough data.

   The following methods can be used to correct errors in constructing
   command strings:

      Create the CALL command string to be submitted by concatenating the
       various portions of the command together into one CL variable.
Submit
       the command string using the request data (RQSDTA) parameter of the
       SBMJOB command.

      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.

      Create a command that will initiate the program to be called.  Submit
       the new command instead of using the CALL command.  The command
       definition ensures the parameters are passed to the command
processing
       program as expected.

Bye

 Chris



+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---