On Sunday, October 6, 2019, 08:10:44 AM PDT, Kirk Wolf 
<[email protected]> wrote:
 
 > I don't understand what you are saying.


I'm saying that IBM can't fix this problem because the problem lies with Unix 
shell design. This same exact problem exists in products that utilize "sh -c 
some-mangled-commands" (e.g. system automation). For those products, it's 
considered a bad practice to use script statements (e.g. IF) as part of the the 
mangled command. Even use of ";" command stacking should be limited. Instead, a 
script file is the preferred method. The BPXBATCH STDPARM example in this 
thread should be a script file because of it's complexity.

Copying STDPARM to FD0 ( Unix stdin or pipe to stdin) is not an acceptable 
solution because commands and programs may consume the script. Script files do 
not get consumed. The mangled command does not get consumed.

Creating a script file really is not a good option. Unique file names and 
finding a directory for the script file can be a problem. Ensuring the script 
file is deleted at script termination could be a problem. I'm sure there are 
other problems that would need to be resolved. 

Additionally, there are many shells available. All shells support passing a 
single line of commands which is the interface designed specifically for 
situations such as BPXBATCH. Sadly, shell design doesn't give us the best 
solution.

Jon.

On Sat, Oct 5, 2019 at 1:35 PM Jon Perryman <[email protected]> wrote:

> On Wednesday, October 2, 2019, 12:52:56 PM PDT, Kirk Wolf wrote:
>  > You really like all of this mangling of the shell syntax?
>
> In all Unix systems, we simply avoid situations where this mangling is
> needed (e.g. "sh -c some-mangled-statements"). Why do you think this a good
> practice in BPXBATCH when it's considered a bad practice in Unix? The
> commonly accepted solution is to create a proper script file and call it.
>
> What exactly are you referring to as good or bad practice?  I don't
understand your point here at all.


> By the way, "#" comments must be terminated by a newline. The ";" command
> terminator character is considered to be part of the comment which is why
> you cannot terminate comments properly.
>
> > For heaven's sake, why doesn't it just read the input from DD:STDIN
>
> IBM simply followed the Unix standard practice. They start the shell and
> pass STDPARM data as an argument. Probably "sh -c
> data-from-stdparm-as-a-string".  I suspect that newline is not supported
> because it's should be interpreted as end of the "sh" command.
>
> Which Unix standard practice?  You never seem to address why taking
DD:STDIN as stdin to /bin/sh isn't the most desirable way for it to work?

BTW: You are correct: the concatenated lines from STDPARM are passed as the
arg to "sh -c".  This is why all sorts of things work much differently
than if the script was in a file (either real or pipe).  Another example
is that an an error message that refers to a line number in the input is
lost since it appears as one line.


> For IBM to do as you suggest, the DD:STDIN would be copied to FD0 ( Unix
> stdin ) which introduces several much larger problems and would cause
> confusion for the user. Scripts should always be in a script file otherwise
> the behavior changes and will cause confusion.
>
> Exactly what problems do you refer to?


> If you truly need the newline feature from inline JCL data, then have
> STDPARM copy your script DD (including newlines) and execute this copied
> script..
>
> Alternatively, you could have an edit macro that submits a BPXBATCH job
> calling the script file you are currently editing.
>
> Jon.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
  

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to