Re: Trying to use long parm= in started task

2021-12-02 Thread Paul Gilmartin
On Thu, 2 Dec 2021 21:16:30 -0600, Dale R. Smith wrote: >... >To me. the biggest problem with not having a way to ignore a unused PROC >parameter is what do you do when you have a PROC parameter that is obsolete? >If you remove it from the PROC, then Jobs that specify that parameter will get

Re: Trying to use long parm= in started task

2021-12-02 Thread Dale R. Smith
On Thu, 2 Dec 2021 14:59:30 -0400, Peter Relson wrote: >I am surprised at the vitriole regarding >IEFC657I THE SYMBOL xxx WAS NOT USED > >Every time I have seen that message it was because the proc creator (me) >screwed up (sometimes in a subtle way). > >-- Ignoring that situation does not seem

Re: Catch-22 on z/OSMF under z/OS 2.4

2021-12-02 Thread Roger Bolan
Tom, You can avoid conflicts between Infoprint Server up and other requirements. See Customizing the IBM HTTP Server - Powered by Apache - IBM Documentation https://www.ibm.com/docs/en/zos/2.4.0?topic=

Re: Trying to use long parm= in started task

2021-12-02 Thread Paul Gilmartin
On Thu, 2 Dec 2021 23:01:27 +, Gibney, Dave wrote: >DSN=&TEMPDSN could be treated as an exception. Any other undefined symbols >could be identified and flagged as an error. > That profits little: o You need more than one. A programmer may have several temp DSNs active in a step. So, &TMP

Re: Trying to use long parm= in started task

2021-12-02 Thread Gibney, Dave
DSN=&TEMPDSN could be treated as an exception. Any other undefined symbols could be identified and flagged as an error. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Seymour J Metz > Sent: Thursday, December 02, 2021 2:58 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Su

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
FSVO show. The job will run and use the wrong dataset, with no warning. Because of the ambiguous ampersand, there is only one place at which IBM can catch the error. If you really want to complain, look at the CLIST change on OS/VS2 R3.6, with its massive increase in the number of apostrophes n

Re: Trying to use long parm= in started task

2021-12-02 Thread Paul Gilmartin
On Thu, 2 Dec 2021 13:38:17 -0800, Charles Mills wrote: >Okay, I get it, but this ship is not very ship-shape. > >Seeing as DSN=&MYPRM means what it means, then when IBM introduced variable >symbols they should have used && or % or something, not a single ampersand. >Yeah, yeah, that boat has dep

Re: Trying to use long parm= in started task

2021-12-02 Thread Charles Mills
Okay, I get it, but this ship is not very ship-shape. Seeing as DSN=&MYPRM means what it means, then when IBM introduced variable symbols they should have used && or % or something, not a single ampersand. Yeah, yeah, that boat has departed the dock. The IEFC657I does not really do the job though

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
It sailed; I didn't say it arrived at port. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Thursda

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
That text says nothing about rescanning after substitution. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.ed

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
SET may not be in the list, but this text is quite clear: Special characters and blanks : When a parameter value contains special characters or blanks, enclose the value in apostrophes. The enclosing apostrophes are not considered part of the value. For example: //SP2 SET PARM3='3400-6'

Re: Trying to use long parm= in started task

2021-12-02 Thread Paul Gilmartin
On Thu, 2 Dec 2021 20:26:49 +, Seymour J Metz wrote: > >//SYSBAR DDDSN=&MYPRM,DISP=(MOD,PASS) > >Is valid. At the time IBM defined the syntax, there were no symbolic >parameters. Changing that to invalid would break every job that used a single >ampersand for a temporary dataset name

Re: Trying to use long parm= in started task

2021-12-02 Thread Paul Gilmartin
On Thu, 2 Dec 2021 20:37:01 +, Seymour J Metz wrote: >> I've further perused the JCL Ref. which seems to imply: >> // SET NULL='' >> // SET ACTVAR=&NULL'&ACTION' > >Not this? > >// SET NULL='' >// SET ACTVAR='&NULL.&ACTION' > No: On parameters that are not in the list, t

Re: Trying to use long parm= in started task

2021-12-02 Thread Paul Gilmartin
On Thu, 2 Dec 2021 20:15:29 +, Seymour J Metz wrote: >> That doesn't work > >It should work with a shorter name: > Mutatis mutandis. > Special characters and blanks > : When a parameter value contains special characters or blanks, enclose > the value in apostrophes. The enclosing apostroph

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
> I've further perused the JCL Ref. which seems to imply: > // SET NULL='' > // SET ACTVAR=&NULL'&ACTION' Not this? // SET NULL='' // SET ACTVAR='&NULL.&ACTION' -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainfra

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
> // SET ACTVAR=&ACTION Should work. You don't need the apostrophes in this case, although they are valid. The &Q trick is for introducing an apostrophe into thr valur and should not work for delimiting the values. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
> 1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and then > mistakenly code &MYPRM instead of &MYPARM in the body of the PROC, then the > error is the undefined &MYPRM, //SYSBAR DDDSN=&MYPRM,DISP=(MOD,PASS) Is valid. At the time IBM defined the syntax, there were no sy

Re: Catch-22 on z/OSMF under z/OS 2.4

2021-12-02 Thread Carmen Vitullo
late to the game here, we were forced to move to TLS 1.2, once we did z/osmf services, notifications services stopped working, specifically JES2EDS, to fix this we had to add an LE parm I'm not sure this would help in you case but it may be worth a try. ENVAR("GSK_PROTOCOL_TLSV1_2=ON") and add

Re: Trying to use long parm= in started task

2021-12-02 Thread Paul Gilmartin
On Thu, 2 Dec 2021 11:48:11 -0800, Charles Mills wrote: >Does > >// SET ACTVAR=&ACTION > >work? Or do you indeed need to quote &ACTION? (If you do, I heartily endorse >@Gil's &Q trick. I have used that.) > Did I copy that from you? It may fail ifi &ACTION contains an unbalanced apostrophe. JCL s

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
> That doesn't work It should work with a shorter name: Special characters and blanks : When a parameter value contains special characters or blanks, enclose the value in apostrophes. The enclosing apostrophes are not considered part of the value. For example: //SP2 SET PARM3='3400-6'

Re: Catch-22 on z/OSMF under z/OS 2.4

2021-12-02 Thread Tom Longfellow
>You might have a look at this also: >https://www.ibm.com/support/pages/node/6518654 >It basically a timing issue with the start of Pagent and z/OSMF using AT-TLS. Sadly, that is not my problem - No Java.IO exception. And PAGENT is up and working. I have recycled the zOSMF tasks several time

Re: Trying to use long parm= in started task

2021-12-02 Thread Charles Mills
Peter, fools rush in. I will give it a shot. Apologies if I was vitriolic. It's just a language detail! Peace and Joy! I see the situation as exactly analogous to most languages I use. If I declare a variable in C++ and do not ever use it then it is a non-event. If I declare a method (subroutine)

Re: Trying to use long parm= in started task

2021-12-02 Thread Paul Gilmartin
On Thu, 2 Dec 2021 14:59:30 -0400, Peter Relson wrote: >I am surprised at the vitriole regarding >IEFC657I THE SYMBOL xxx WAS NOT USED > >Every time I have seen that message it was because the proc creator (me) >screwed up (sometimes in a subtle way). > ... >Sure, one could ask for an option

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
An error message for an unused symbolic parameter may be reasonable; throwing away everything to the right of a bad symbol, with no warning, is not. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LI

Re: Trying to use long parm= in started task

2021-12-02 Thread Charles Mills
Does // SET ACTVAR=&ACTION work? Or do you indeed need to quote &ACTION? (If you do, I heartily endorse @Gil's &Q trick. I have used that.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, Dec

Re: Trying to use long parm= in started task

2021-12-02 Thread Peter Relson
I am surprised at the vitriole regarding IEFC657I THE SYMBOL xxx WAS NOT USED Every time I have seen that message it was because the proc creator (me) screwed up (sometimes in a subtle way). -- Ignoring that situation does not seem to be in the user's best interest. -- Warning about that situ

Re: ZFS colony address spaces

2021-12-02 Thread Mark Jacobs
AFAIK it was required to run ZFS processes in it's own address space until z/OS V2.1 when it became 64 bit capable. At $previousjob I took out the ASNAME option and ZFS processes/services are now running within the OMVS address space. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted emai

Re: Trying to use long parm= in started task

2021-12-02 Thread Paul Gilmartin
On Thu, 2 Dec 2021 10:29:00 +, Seymour J Metz wrote: >I believe that the problem is a combination of an error in your JCL and an >error in the Converter. &ACTION is a symbolic parameter but not a symbol. Try > >// SET ACTIONVAR='&ACTION' >... That doesn't work:

ZFS colony address spaces

2021-12-02 Thread Lennie Dymoke-Bradshaw
Does anyone run colony address spaces for OMVS file systems? I am running one as follows (from BPXPRM00), FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM) ASNAME(ZFS,'SUB=MSTR') PARM('PRM=(00)') This sta

Re: Catch-22 on z/OSMF under z/OS 2.4

2021-12-02 Thread David Follis
You might have a look at this also: https://www.ibm.com/support/pages/node/6518654 It basically a timing issue with the start of Pagent and z/OSMF using AT-TLS. David Follis -- For IBM-MAIN subscribe / signoff / archive access i

Re: Trying to use long parm= in started task

2021-12-02 Thread Colin Paice
Hi Seymour, Thanks for your reply - I originally used symbols (wrongly). .. Your solution does not require the dummy step because you suggested // SET AV=&ACTION without the quotes... When I used // SET AV='&ACTION' it didnt work Old dogs, new tricks... thank you Colin On Thu, 2 Dec

Re: Trying to use long parm= in started task

2021-12-02 Thread Seymour J Metz
I believe that the problem is a combination of an error in your JCL and an error in the Converter. &ACTION is a symbolic parameter but not a symbol. Try // SET ACTIONVAR='&ACTION' ... //PARMDD DD *,SYMBOLS=JCLONLY SH /u/mqweb3/conf/ccc.sh aa &T2 x &ACTIONVAR y &ACTIONVAR z /* Note that you don

Re: Trying to use long parm= in started task

2021-12-02 Thread Colin Paice
I have set up a script with echo "$1 $2 $3 $4 $5 $6 $7" echo "all $*" and //COLWEB PROC ACTION='start' // EXPORT SYMLIST=* // SET T2='T2T2' //IHS EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD //PARMDD DD *,SYMBOLS=JCLONLY SH /u/mqweb3/conf/ccc.sh aa &T2 x &ACTION. y &ACTION z /* //STDOUT

Re: z/OS 2.5 install with z/OSMF

2021-12-02 Thread Seymour J Metz
> wasn't easy to port Would OOREXX 5 pose the same porting issues? > A couple of years later I ported Lua I believe that is the implementation language for much of wiki. > I don't think ooRexx supports functions as first class objects? Alas, no. Also, while OOREXX 5 has regexen, it's missing