Re: CL Problems

[bmorris@xxxxxxxxxx]

>Date: Thu, 17 May 2001 02:53:51 -0400
>From: "Jim Franz" <franz400@triad.rr.com>
>
>No, the os does not ignore the asterisk. This is a "work-a-round" to keep
>the
>os from creating the problem. What's missing from the prev referenced
post,
>is that your submitted job needs to remove the asterick (or make your var
>1 char more than needed, put something other than blank in it, and remove
>in the submitted job.
>jim

Jim, if you pass 1 byte more than the program expects, the called program
_doesn't_ have to add an extra byte so it can then ignore it.  The extra
byte gets ignored automatically by the called program.

How this works:
The called program gets a pointer to the parameter.  This pointer points
to the beginning of probably thousands of bytes of storage, but if the
parameter is declared as 50 bytes, that's all the program sees.  Whether
you explicitly put an asterisk in the 51st byte or whether there's some
other junk there (maybe other parameters) won't be apparent to the
called program.  The problem only occurs when the program gets passed
less than it expects (either because the parameters are declared wrong
or because of this oddity with SBMJOB).

But even easier than passing the extra byte is to define a command
interface
for the program.  Then your CL just submits the command instead of
submitting
a call to the program, and the program always gets the right parameters.

Here's an example of command source for a program that expects two
parameters
char(50) and dec(5,2).

/* crtcmd yourlib/yourcmd pgm(yourlib/yourpgm) */
cmd
parm kwd(p1) type(*char) len(50) prompt('the first parm')
parm kwd(p2) type(*dec) len(5,2) prompt('the second parm')

Barbara Morris

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