Re: multi-line STDPARM shell script for BPXBATCH
Jon, I don't understand what you are saying. On Sat, Oct 5, 2019 at 1:35 PM Jon Perryman 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Clist dataset
CANCEL command should do it. Date:Sat, 5 Oct 2019 03:29:26 -0500 From:Bill Giannelli Subject: how to force a free of ispf allocated Dataset I am trying to rename a CLIST library allocated to users for ISPF. how do I force users to deallocate the dataset so I can rename it? I have been sending tso messages but more users keep allocating it. thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clist dataset
As OP indicated at some point, CANCEL does not always work. I've run into the same problem. It's not only TSU but even a batch job will sometimes fail to go away after 'CANCEL COMMAND ACCEPTED'. If this condition persists for even a few minutes, FORCE is the only way to make the task actually go away. If you're skittish and you can afford to wait till the next scheduled IPL, then do so. Personally I have not seen a system-level problem after FORCE in many, many moons. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Donald Blake Sent: Sunday, October 6, 2019 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Clist dataset CANCEL command should do it. Date:Sat, 5 Oct 2019 03:29:26 -0500 From:Bill Giannelli Subject: how to force a free of ispf allocated Dataset I am trying to rename a CLIST library allocated to users for ISPF. how do I force users to deallocate the dataset so I can rename it? I have been sending tso messages but more users keep allocating it. thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Sunday, October 6, 2019, 08:10:44 AM PDT, Kirk Wolf 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 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
configure zos explorer
Hi Would anyone know how to configure z/os explorer (gui client of debug tool) What I mean is were would I enter the Z/OS TCPIP ADDRESS AND/OR PORT # Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A List Server for OE/OMVS
Dear, Has there been any change on IBM LIst Server for OpenEdition? Getting faded in my memory, it was lists...@vm.marist.edu for mvs-oe. Now noticed the IBM MAIN list server also accepts/covers all OMVS events here in IBM-MAIN@LISTSERV.UA.EDU (foramlly known lists...@bama.ua.edu). I am ok with this IBM MAIN but want to know some IBM ListServer for allowing only OMVS events still there? Thanks in adv. Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Sun, 6 Oct 2019 18:06:16 +, Jon Perryman wrote:
>
>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.
>
Why?
The problem lies with JCL design, namely JCL's inability to pass a multi-line
PARM.
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.
>
So, you want it to persist rather than be 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.
>
You're arguing against yourself. Here you seem to want that script
to be consumed rather than persist.
(sh invisibly creates and deletes temp files for constructs such as
command substitution and here-documents.)
>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.
>
UNIX commands, including shell, accept multiple arguments. The problem
lies in BPXBATCH's (in fact all of JCL's) inability to pass multiple arguments.
I can't even pass an alternate DDNAME list to a classic utility.
POSIX shell allows great complexity in a single line. An example:
695 $ cat x
#! /bin/sh
: Define a multiple command string:
S="p() { echo; echo \"The argument passed was:\"; echo \"\$1\"; return; };
p foo; p bar"
: Execute it with sh:
/bin/sh -c "$S"
696 $ ./x
The argument passed was:
foo
The argument passed was:
bar
697 $
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A List Server for OE/OMVS
On Sun, 6 Oct 2019 14:00:48 -0500, Steve Lee wrote: > >Has there been any change on IBM LIst Server for OpenEdition? > I continue to use http://vm.marist.edu/htbin/wlvindex?MVS-OE >Getting faded in my memory, it was lists...@vm.marist.edu for mvs-oe. Now >noticed the IBM MAIN list server also accepts/covers all OMVS events here in >IBM-MAIN@LISTSERV.UA.EDU (foramlly known lists...@bama.ua.edu). >I am ok with this IBM MAIN but want to know some IBM ListServer for allowing >only OMVS events still there? Thanks in adv. > LISTSERVs largely eschew such censorship; they're unmoderated. But bigoted condemnation of UNIX might be resented. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A List Server for OE/OMVS
As far as I know, this list is still active MVS OE http://vm.marist.edu/archives/mvs-oe.html Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Steve Lee > Sent: Sunday, October 06, 2019 12:01 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: A List Server for OE/OMVS > > Dear, > > Has there been any change on IBM LIst Server for OpenEdition? > > Getting faded in my memory, it was lists...@vm.marist.edu for mvs-oe. Now > noticed the IBM MAIN list server also accepts/covers all OMVS events here in > IBM-MAIN@LISTSERV.UA.EDU (foramlly known lists...@bama.ua.edu). > I am ok with this IBM MAIN but want to know some IBM ListServer for allowing > only OMVS events still there? Thanks in adv. > > Steve > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A List Server for OE/OMVS
All IBM mainframe topics aon topic for IBM-MAIN. However, there may be specialists who are subscribed only to more specialized lists, so it's a tradeoff between the size of the pool and the concentration of expertise. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Lee Sent: Sunday, October 6, 2019 3:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: A List Server for OE/OMVS Dear, Has there been any change on IBM LIst Server for OpenEdition? Getting faded in my memory, it was lists...@vm.marist.edu for mvs-oe. Now noticed the IBM MAIN list server also accepts/covers all OMVS events here in IBM-MAIN@LISTSERV.UA.EDU (foramlly known lists...@bama.ua.edu). I am ok with this IBM MAIN but want to know some IBM ListServer for allowing only OMVS events still there? Thanks in adv. Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clist dataset
ARM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Sunday, October 6, 2019 1:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Clist dataset As OP indicated at some point, CANCEL does not always work. I've run into the same problem. It's not only TSU but even a batch job will sometimes fail to go away after 'CANCEL COMMAND ACCEPTED'. If this condition persists for even a few minutes, FORCE is the only way to make the task actually go away. If you're skittish and you can afford to wait till the next scheduled IPL, then do so. Personally I have not seen a system-level problem after FORCE in many, many moons. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Donald Blake Sent: Sunday, October 6, 2019 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Clist dataset CANCEL command should do it. Date:Sat, 5 Oct 2019 03:29:26 -0500 From:Bill Giannelli Subject: how to force a free of ispf allocated Dataset I am trying to rename a CLIST library allocated to users for ISPF. how do I force users to deallocate the dataset so I can rename it? I have been sending tso messages but more users keep allocating it. thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to force a free of ispf allocated Dataset
That depends on installation policy. The last time I had such a problem, I set users to 0, told everybody to log off and cancelled those that din't log off in a reasonable period of time. Don'try it without management buy-in. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Bill Giannelli Sent: Saturday, October 5, 2019 4:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: how to force a free of ispf allocated Dataset I am trying to rename a CLIST library allocated to users for ISPF. how do I force users to deallocate the dataset so I can rename it? I have been sending tso messages but more users keep allocating it. thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to force a free of ispf allocated Dataset
On 10/5/2019 1:29 AM, Bill Giannelli wrote: I am trying to rename a CLIST library allocated to users for ISPF. how do I force users to deallocate the dataset so I can rename it? I have been sending tso messages but more users keep allocating it. In a busy environment, you will never be able to keep up with canceling all of the jobs and/or users that might be accessing this file. Like a "Whack-a-Mode" game. Each time you cancel one, another pops up to take its place. Besides, canceling users is DISRUPTIVE! The best way is to rename the data set while holding an exclusive ENQ on it. Submit this job before you go to sleep and when you wake up the next morning, the data set should be renamed. //RENAME JOB 1,JAFFE,CLASS=A,MSGCLASS=T,NOTIFY=&SYSUID //RENAME EXEC PGM=IDCAMS //ENQOLD DD DSN=old.data.set.name,DISP=OLD //SYSPRINT DD SYSOUT=* //SYSIN DD * ALTER old.data.set.name - NEWNAME(new.data.set.name) - FILE(ENQOLD) // -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to force a free of ispf allocated Dataset
Haha! I meant to write Whack-a-Mole! On 10/6/2019 1:47 PM, Ed Jaffe wrote: On 10/5/2019 1:29 AM, Bill Giannelli wrote: I am trying to rename a CLIST library allocated to users for ISPF. how do I force users to deallocate the dataset so I can rename it? I have been sending tso messages but more users keep allocating it. In a busy environment, you will never be able to keep up with canceling all of the jobs and/or users that might be accessing this file. Like a "Whack-a-Mode" game. Each time you cancel one, another pops up to take its place. Besides, canceling users is DISRUPTIVE! The best way is to rename the data set while holding an exclusive ENQ on it. Submit this job before you go to sleep and when you wake up the next morning, the data set should be renamed. //RENAME JOB 1,JAFFE,CLASS=A,MSGCLASS=T,NOTIFY=&SYSUID //RENAME EXEC PGM=IDCAMS //ENQOLD DD DSN=old.data.set.name,DISP=OLD //SYSPRINT DD SYSOUT=* //SYSIN DD * ALTER old.data.set.name - NEWNAME(new.data.set.name) - FILE(ENQOLD) // This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to force a free of ispf allocated Dataset
Hi Ed, I don't think that the FILE Parameter is necessary. Regards, David On 2019-10-06 16:47, Ed Jaffe wrote: > On 10/5/2019 1:29 AM, Bill Giannelli wrote: >> I am trying to rename a CLIST library allocated to users for ISPF. >> how do I force users to deallocate the dataset so I can rename it? I >> have been sending tso messages but more users keep allocating it. > > In a busy environment, you will never be able to keep up with > canceling all of the jobs and/or users that might be accessing this > file. Like a "Whack-a-Mode" game. Each time you cancel one, another > pops up to take its place. Besides, canceling users is DISRUPTIVE! > > The best way is to rename the data set while holding an exclusive ENQ > on it. Submit this job before you go to sleep and when you wake up the > next morning, the data set should be renamed. > > //RENAME JOB 1,JAFFE,CLASS=A,MSGCLASS=T,NOTIFY=&SYSUID > //RENAME EXEC PGM=IDCAMS > //ENQOLD DD DSN=old.data.set.name,DISP=OLD > //SYSPRINT DD SYSOUT=* > //SYSIN DD * > ALTER old.data.set.name - > NEWNAME(new.data.set.name) - > FILE(ENQOLD) > // > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to force a free of ispf allocated Dataset
On 10/6/2019 2:25 PM, David Spiegel wrote: Hi Ed, I don't think that the FILE Parameter is necessary. Just tried it and, of course, you are correct. Works either way -- with or without... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
The Unix concept of line implies the new line character which is not standard
z/OS. Multi-line JCL parm does not make sense in this context.
JCL does in fact pass multiple arguments but it is not compatible with Unix
(PARM=(A,B) ).
Specifying alternate DD names has nothing to do with JCL. If I remember
correctly there are several utilities that allow this. BPXBATCH could easily
support this if needed.
Ask yourself why there are so many variations on running a shell in batch.
First, they are extremely easy to create. Second, everyone has their own idea
what is needed.
As for FD0 (stdin) being consumed, I could care less. I'm just stating that
implementing this in BPXBATCH would cause confusion. A command or readline
could potentially be reading part of the script as if it were data.
I don't know where you get the idea I'm arguing against myself. Using a file as
a possible solution poses a unique set of problems. Ultimately you don't want a
command to use the script as data.
Creating complex commands is not a problem as such but do they make sense to
use in STDPARM outside of personal use? I would think it's less desirable for
production where operations makes changes that could easily be error prone and
difficult for those with less experience.
Jon.
On Sunday, October 6, 2019, 12:10:09 PM PDT, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
On Sun, 6 Oct 2019 18:06:16 +, Jon Perryman wrote:
>
>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.
>
Why?
The problem lies with JCL design, namely JCL's inability to pass a multi-line
PARM.
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.
>
So, you want it to persist rather than be 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.
>
You're arguing against yourself. Here you seem to want that script
to be consumed rather than persist.
(sh invisibly creates and deletes temp files for constructs such as
command substitution and here-documents.)
>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.
>
UNIX commands, including shell, accept multiple arguments. The problem
lies in BPXBATCH's (in fact all of JCL's) inability to pass multiple arguments.
I can't even pass an alternate DDNAME list to a classic utility.
POSIX shell allows great complexity in a single line. An example:
695 $ cat x
#! /bin/sh
: Define a multiple command string:
S="p() { echo; echo \"The argument passed was:\"; echo \" \$1\"; return; };
p foo; p bar"
: Execute it with sh:
/bin/sh -c "$S"
696 $ ./x
The argument passed was:
foo
The argument passed was:
bar
697 $
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On 2019-10-07 2:06 AM, Jon Perryman wrote: I'm saying that IBM can't fix this problem because the problem lies with Unix shell design. I have no idea what you're talking about! IBM can and have fixed the problem! BPXBATCH is so bad they wrote a replacement AOPBATCH which works just as Kirk describes. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.aokfa00/batdd.htm#batdd https://dovetail.com/products/cozbatch.html 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Phoenix Software International Announces IBM® JES3 Licensing Agreement
Ed Jaffe wrote: >It's not every day someone acquires a core z/OS component from IBM (has >that EVER happened?) so you can be sure we will treat it with the >respect it deserves. How would you classify the two examples The New York Times reported on November 5, 1983? Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Phoenix Software International Announces IBM(R) JES3 Licensing Agreement
https://www.nytimes.com/1983/11/05/business/the-publicity-effect-of-ibm-sting.html On Mon, Oct 7, 2019 at 3:15 AM Timothy Sipples wrote: > > Ed Jaffe wrote: > >It's not every day someone acquires a core z/OS component from IBM (has > >that EVER happened?) so you can be sure we will treat it with the > >respect it deserves. > > How would you classify the two examples The New York Times reported on > November 5, 1983? > > > Timothy Sipples > IT Architect Executive, Industry Solutions, IBM Z & LinuxONE > E-Mail: sipp...@sg.ibm.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: configure zos explorer
Joseph Reichman wrote: >Would anyone know how to configure z/os explorer (gui client of >debug tool) What I mean is were would I enter the Z/OS TCPIP ADDRESS >AND/OR PORT # I believe this page in the IBM Knowledge Center should answer your questions: https://www.ibm.com/support/knowledgecenter/en/SSBDYH_3.2/com.ibm.zexpl.config.client.doc/topics/tzdcmn032.html If that's not exactly the correct page, the main IBM Knowledge Center entry page for Explorer for z/OS is here: https://www.ibm.com/support/knowledgecenter/en/SSBDYH Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
