'-c ' in STDOUT of BPXBATCH

Ronin. · Posted: Fri Jul 11, 2014 6:09 am

I am trying to execute BPXBATCH step for one of SFTP processing.

But my unix commands doesnt seem to be working. All i can see in STDOUT is: -c XXXXXX

Where XXXXXX is parameters which I pass in STDPARM.

STDERR also doent indicate error.

MY step is ending with RC = 0 but no files are being transferred.

Ex of STDPARM i tested.

1. SH ls /AAA/BBB
2. sh echo $HOME

Ex of STDOUT
1. -c ls /AAA/BBB
2. -c echo $HOME

I couldnt get any reference to what '-c' indicates in manual or google.

I am new to unix scripts. So hope my question is not foolish.[/code]

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

I'm going to take a wild guess and say that you are passing more than one parm on a line in the STDPARM DD:

BPXBATCH now supports a parameter string up to 32754 characters when called from a TSO command environment. Also from both a batch and TSO environment, up to 65,536 characters can now be supplied via the a new input DD named stdparm. When the stdparm DD is allocated BPXBATCH will use the data found in the z/OS UNIX file or MVS data set associated with this DD rather that what is found on the parameter string or in the stdin DD. As a warning to the user, an informational message BPXM079I will be displayed indicating that this is occurring.

The stdparm DD will allow either a z/OS UNIX file, or an MVS SYSIN PDS, PDSE or sequential data set. The following are characteristics of the parameter data that can be supplied in the stdparm DD, if a z/OS UNIX file is specified:

It must be a text file defined with read access only
Specify one argument per line
The file cannot have sequence numbers in it.

Tip: If you use the ISPF editor to create the file, set the sequence numbers off by typing number off on the command line before you begin typing data. If sequence numbers already exist, type UNNUM to remove them and then type number off.

If a MVS data set is specified:

Specify one argument per line. If the parameter string for an argument spans more than one line of a data set or file, this string will be divided into two or more arguments that are passed to the corresponding shell script or program.
The maximum length of a single argument supplied to the program is 32,760, which is the same as the maximum LRECL for an unspanned non-VSAM data set.
The record format of the data set can fixed or variable (unspanned).
The data set cannot have sequence numbers in it. If you use the ISPF editor to edit the data set, set the sequence numbers off by typing number off on the command line before you begin typing in the data. If sequence numbers already exist, type UNNUM to remove them and set number mode off.
Trailing blanks are truncated for SYSIN and variable block data sets, but not for fixed block data sets. For a fixed block data set, trailing blanks will be included in the parameter text for a given argument up to the end of the record.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

Sorry...I hit submit.

The reason this might show with a -c is that your parm has a -c on the line above it.

Ronin. · Posted: Mon Jul 14, 2014 9:39 pm

Thanks a lot for your time and helping me with the wisdom you process.

I didnt have any luck SO FAR.

NUM is turned off. I made sure sure there are no seqnum at end.
I tried the instream parameters in STDPARM too.
I tried with and without STDIN statement.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

geez...I run that same JCL and it works fine. is the ENTIRE step?

I can NOT recreate your problem. I'm starting to wonder if the BPXBATCH installation has a missing piece. (I'm thinking the 'sh' script is messed up)

Try going into Unix itself and running the 'echo $HOME' command.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

There is a sentence in the manual that I don't know how to read: "Specifies that the shell designated in your TSO/E user ID’s security product profile is to be started and is to run shell commands or scripts provided from stdin or the specified program_name."

I don't know how to check the designated shell.

My information for BPXBATCH:

pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.bpxa500%2Fbpxbatr.htm

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

More info:

There is a setup for users using the UNIX shell. One of the parms is the name/location of the shell to start:

pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.bpxb200%2Fcusrp.htm

That referenced the 'PROGRAM' command, which is explained here:

pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.bpxb200%2Fsecser.htm

Now, notice that you can short circuit the use of the shell in that program command by actually just putting an echo statement in there.

If I go to OMVS and enter:
>echo -c gggg

I get this output
-c gggg

This may be happening to you! Please try going to OMVS by entering 'TSO OMVS' at the TSO command line (get out by using 'exit')

If you can get in and do a few echo commands, then it is probably something else.

Ronin. · Posted: Wed Jul 16, 2014 9:16 am

Thank you so much for your help. It turned out to be ACF/2 issue. May be RC= 0 and absence of JES messages slightly delayed debugging process. Also, I have read many of your prior post which had helped others. Thanks again for all the great work and for your precious time.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

I'm learning this stuff too!

So you're able to run it OK now? That's great.

Can you tell us what the ACF/2 issue was? Maybe it will help the next poor programmer figure out their problem.