Re: Piping under ISPF

[Seymour J Metz]

The lack of  an escape  convention for command  separators is bad, but 
otherwise the syntax is decent.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, November 10, 2021 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Piping under ISPF

On Wed, 10 Nov 2021 11:16:06 -0600, Hobart Spitz wrote:

>Cross posted to IBM-MAIN, TSO REXX, and Pipelines.
>
> The ISPF stacking character can be set to "|", but TSO tries to execute
>the passed stack data after each command.  If that could be disabled, data
>could be passed from program to program, providing a stack based piping
>capability.
>Does anyone know how to disable stack data being executed?
>Could it be a viable requirement candidate to have two command
>delimiters, one that executed the stack and one that didn't?
>
TSO lexical syntax is a misdesign.  Other languages I use such as
Rexx, POSIX shell, C, ... use ';' as a command separator.  If it occurs
in a quoted string it behaves as ordinary text.  TSO/ISPF provides
no such way of escaping metacharacters; only choice of an
alternative separator.  (I've used '¾', keeping one on my desktop
so I can copy/paste it.)

CMS Pipelines is worse, motivated by the impoverished lexical
syntax and tokenization of CP and CMS.

-- gil

--
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: Moron of the day -- me!

[Seymour J Metz]

> we all see what we expect to see

\That;s one of the reasons for code and design reviews.

another is that explaining code to someone else seems to use different mental 
pathways than proofreading it. I've lost count of how many times I've spotted 
bad code asking someone else to look at it and explaining it to them :-(


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Matt Hogstrom [m...@hogstrom.org]
Sent: Wednesday, November 10, 2021 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Moron of the day -- me!

Nice, reminds me back in ‘88 when I was assembling the COBOL default (IKFCBL00 
IIRC) and the defaults weren’t taking.  Looked for missing continuations, 
commas, … and finally opened a ticket.  After getting to a developer he saw the 
missing continuation.   Sometimes its not you; we all see what we expect to see 
most of the time.  Glad you found it.

Matt Hogstrom
PGP key 0F143BC1

> On Nov 10, 2021, at 09:47, Phil Smith III  wrote:
>
> Yesterday I needed to run a quick test of a USS-resident program from batch,
> which I certainly knew was possible but had never done before. Found various
> pages talking about how to use BPXBATCH, tried it. RC=0 but no program
> output. None. Zero. Nada. Tinkered with DDs for STDOUT and STDERR
> (SYSOUT=*), no joy. Tried routing to DASD, no joy. Scratched head, gave up
> for the day.
>
>
>
> Looked at it again this morning and saw the problem instantly. Now, as we
> all know, there is no new JCL: every bit of JCL is descended from a fragment
> found on a stone tablet on the side of a mountain near Poughkeepsie back in
> the early 1960s. Every "new" job is just an old job, modified.
>
>
>
> And it happened that the job I'd taken as my template had TYPRUN=SCAN.
> Wasn't even aware I had any such.!
>
>
>
> Presumably I won't make that mistake again.*
>
>
>
> ...phsiii
>
>
>
> *This week
>
>
> --
> 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

Re: Orphaned SYSDSN Enqueue

[Roger Suhr]

You may have an address space with that ASID still in the system.  You should 
be able to display it, CANCEL it and FORCE it, (with ARM).  Removing that ASID 
on the system where it exists, should clear the ENQ.

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android

From: IBM Mainframe Discussion List  on behalf of 
Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, November 10, 2021 8:57:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Orphaned SYSDSN Enqueue

We have an orphaned SYSDSN enqueue that's preventing CICS from starting. GRS 
shows it enqueued by the CICS STC that we're trying to startup. The ASID that's 
being displayed is currently in use by a a different STC. Outside of an IPL is 
there anyway to remove the enqueue from the sysplex?

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

--
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: Moron of the day -- me!

[Roger Suhr]

LOL, Good one 

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android

From: IBM Mainframe Discussion List  on behalf of 
Steve Horein 
Sent: Wednesday, November 10, 2021 5:03:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Moron of the day -- me!

Why didn't this PTF go on?
Oh yeah, forgot to remove "CHECK".

--
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: Moron of the day -- me!

[Steve Horein]

Why didn't this PTF go on?
Oh yeah, forgot to remove "CHECK".

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Moron of the day -- me!

[Tom Brennan]

Funny!  Now I don't feel so bad about my own silly mistakes.  Maybe it's 
something to do with "sleeping on it".  I spent 2 hours last night 
wondering why the remote email server my C program was talking to would 
not respond to a command line.  This morning I got up and thought - 
wait, it can't be that easy, and added a CRLF to the end of the command. 
 Duh...


On 11/10/2021 9:47 AM, Phil Smith III wrote:

Yesterday I needed to run a quick test of a USS-resident program from batch,
which I certainly knew was possible but had never done before. Found various
pages talking about how to use BPXBATCH, tried it. RC=0 but no program
output. None. Zero. Nada. Tinkered with DDs for STDOUT and STDERR
(SYSOUT=*), no joy. Tried routing to DASD, no joy. Scratched head, gave up
for the day.

  


Looked at it again this morning and saw the problem instantly. Now, as we
all know, there is no new JCL: every bit of JCL is descended from a fragment
found on a stone tablet on the side of a mountain near Poughkeepsie back in
the early 1960s. Every "new" job is just an old job, modified.

  


And it happened that the job I'd taken as my template had TYPRUN=SCAN.
Wasn't even aware I had any such.!

  


Presumably I won't make that mistake again.*

  


...phsiii

  


*This week


--
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: Moron of the day -- me!

[Scott Barry]

On Wed, 10 Nov 2021 12:47:17 -0500, Phil Smith III  wrote:

>Yesterday I needed to run a quick test of a USS-resident program from batch,
>which I certainly knew was possible but had never done before. Found various
>pages talking about how to use BPXBATCH, tried it. RC=0 but no program
>output. None. Zero. Nada. Tinkered with DDs for STDOUT and STDERR
>(SYSOUT=*), no joy. Tried routing to DASD, no joy. Scratched head, gave up
>for the day.
>
>
>
>Looked at it again this morning and saw the problem instantly. Now, as we
>all know, there is no new JCL: every bit of JCL is descended from a fragment
>found on a stone tablet on the side of a mountain near Poughkeepsie back in
>the early 1960s. Every "new" job is just an old job, modified.
>
>
>
>And it happened that the job I'd taken as my template had TYPRUN=SCAN.
>Wasn't even aware I had any such.!
>
>
>
>Presumably I won't make that mistake again.*
>
>
>
>...phsiii
>
>
>
>*This week
>
>


Yep, simply sounds like a DD DUMMY moment.I can raise my mouse-cursor to 
that happening in my world, way too often !!

Scott Barry
SBBTech LLC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Piping under ISPF

[Paul Gilmartin]

On Wed, 10 Nov 2021 11:16:06 -0600, Hobart Spitz wrote:

>Cross posted to IBM-MAIN, TSO REXX, and Pipelines.
>
> The ISPF stacking character can be set to "|", but TSO tries to execute
>the passed stack data after each command.  If that could be disabled, data
>could be passed from program to program, providing a stack based piping
>capability.
>Does anyone know how to disable stack data being executed?
>Could it be a viable requirement candidate to have two command
>delimiters, one that executed the stack and one that didn't?
>
TSO lexical syntax is a misdesign.  Other languages I use such as
Rexx, POSIX shell, C, ... use ';' as a command separator.  If it occurs
in a quoted string it behaves as ordinary text.  TSO/ISPF provides
no such way of escaping metacharacters; only choice of an
alternative separator.  (I've used '¾', keeping one on my desktop
so I can copy/paste it.)

CMS Pipelines is worse, motivated by the impoverished lexical
syntax and tokenization of CP and CMS.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Moron of the day -- me!

[Cameron Conacher]

Thank you! Thank you!!

…….Cameron




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, November 10, 2021 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Moron of the day -- me!

Yesterday I needed to run a quick test of a USS-resident program from batch, 
which I certainly knew was possible but had never done before. Found various 
pages talking about how to use BPXBATCH, tried it. RC=0 but no program output. 
None. Zero. Nada. Tinkered with DDs for STDOUT and STDERR (SYSOUT=*), no joy. 
Tried routing to DASD, no joy. Scratched head, gave up for the day.



Looked at it again this morning and saw the problem instantly. Now, as we all 
know, there is no new JCL: every bit of JCL is descended from a fragment found 
on a stone tablet on the side of a mountain near Poughkeepsie back in the early 
1960s. Every "new" job is just an old job, modified.



And it happened that the job I'd taken as my template had TYPRUN=SCAN.
Wasn't even aware I had any such.!



Presumably I won't make that mistake again.*



...phsiii



*This week


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: conditional JCL - Reinvent the wheel?

[Paul Gilmartin]

On Wed, 10 Nov 2021 12:29:37 +, Colin Paice  wrote:

>I'm looking at ways of doing customisation, and want an easy way to
>run/omit steps.
>For example
>ADDUSER  ZZZ NAME('COLINS')NOPASSWORD -
>   OMVS(AUTOUID  ASSIZE(25600)  THREADS(512))
>
>being a good person, I also want to provide a delete step
>DELUSER Z.
>My fantasy JCL looks like
>// SET DELUSER='NO'
>// SET DEFUSER=YES
>// SET...
>
>//IF  (DELUSER='YES')
>..
Be careful.  The JCL Ref. states some peculiarly harsh syntax rules, then:
Relational-expression keywords
The following keywords are the only keywords supported by IBM and
recommended for use in relational- expressions. Any other keywords,
even if accepted by the system, are not intended or supported keywords.

It's hard to avoid constructs such as yours that "are not intended
or supported" but appear quite intuitive and are not flagged by
the JCL reader/converter.

Do prevalent JCL checkers reliably flag such unsupported constructs?

Alternatives might be:

o Use of SET symbols in other constructs such as COND=,
  or in DD DATA,SYMBOLS=JCLONLY.

o File tailoring.

Since prion to the availability of DD DATA,SYMBOLS=... I have
kept JCL as here-documents in POSIX shell scripts where I
could employ symbol substitution and process substitution simply
because POSIX shells are what I know better.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Moron of the day -- me!

[Matt Hogstrom]

Nice, reminds me back in ‘88 when I was assembling the COBOL default (IKFCBL00 
IIRC) and the defaults weren’t taking.  Looked for missing continuations, 
commas, … and finally opened a ticket.  After getting to a developer he saw the 
missing continuation.   Sometimes its not you; we all see what we expect to see 
most of the time.  Glad you found it.

Matt Hogstrom
PGP key 0F143BC1

> On Nov 10, 2021, at 09:47, Phil Smith III  wrote:
> 
> Yesterday I needed to run a quick test of a USS-resident program from batch,
> which I certainly knew was possible but had never done before. Found various
> pages talking about how to use BPXBATCH, tried it. RC=0 but no program
> output. None. Zero. Nada. Tinkered with DDs for STDOUT and STDERR
> (SYSOUT=*), no joy. Tried routing to DASD, no joy. Scratched head, gave up
> for the day.
> 
> 
> 
> Looked at it again this morning and saw the problem instantly. Now, as we
> all know, there is no new JCL: every bit of JCL is descended from a fragment
> found on a stone tablet on the side of a mountain near Poughkeepsie back in
> the early 1960s. Every "new" job is just an old job, modified.
> 
> 
> 
> And it happened that the job I'd taken as my template had TYPRUN=SCAN.
> Wasn't even aware I had any such.!
> 
> 
> 
> Presumably I won't make that mistake again.*
> 
> 
> 
> ...phsiii
> 
> 
> 
> *This week
> 
> 
> --
> 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

Moron of the day -- me!

[Phil Smith III]

Yesterday I needed to run a quick test of a USS-resident program from batch,
which I certainly knew was possible but had never done before. Found various
pages talking about how to use BPXBATCH, tried it. RC=0 but no program
output. None. Zero. Nada. Tinkered with DDs for STDOUT and STDERR
(SYSOUT=*), no joy. Tried routing to DASD, no joy. Scratched head, gave up
for the day.

 

Looked at it again this morning and saw the problem instantly. Now, as we
all know, there is no new JCL: every bit of JCL is descended from a fragment
found on a stone tablet on the side of a mountain near Poughkeepsie back in
the early 1960s. Every "new" job is just an old job, modified.

 

And it happened that the job I'd taken as my template had TYPRUN=SCAN.
Wasn't even aware I had any such.!

 

Presumably I won't make that mistake again.*

 

...phsiii

 

*This week


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Orphaned SYSDSN Enqueue

[Mark Jacobs]

It's not. I checked that first thing. We wound up needing to IPL the system.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐

On Wednesday, November 10th, 2021 at 12:12 PM, Mickey Virdi  
wrote:

> Is the owning ASID an INIT ASID, have you attempted to drain the init if it 
> is?
>
> > We have an orphaned SYSDSN enqueue that's preventing CICS from starting. 
> > GRS shows it enqueued by the CICS STC that we're trying to startup. The 
> > ASID that's being displayed is currently in use by a a different STC. 
> > Outside of
> >
> > an IPL is there anyway to remove the enqueue from the sysplex?
>
> > Mark Jacobs
>
> 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

Piping under ISPF

[Hobart Spitz]

Cross posted to IBM-MAIN, TSO REXX, and Pipelines.

 The ISPF stacking character can be set to "|", but TSO tries to execute
the passed stack data after each command.  If that could be disabled, data
could be passed from program to program, providing a stack based piping
capability.
Does anyone know how to disable stack data being executed?
Could it be a viable requirement candidate to have two command
delimiters, one that executed the stack and one that didn't?

Thanks!!

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Orphaned SYSDSN Enqueue

[Mickey Virdi]

Is the owning ASID an INIT ASID, have you attempted to drain the init if it is?


> We have an orphaned SYSDSN enqueue that's preventing CICS from starting. GRS 
> shows it enqueued by the CICS STC that we're trying to startup. The ASID 
> that's being displayed is currently in use by a a different STC. Outside of 
> an IPL is there anyway to remove the enqueue from the sysplex?

>Mark Jacobs

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: conditional JCL - Reinvent the wheel?

[Colin Paice]

Billy,
great - thank you

I'll get the JCL manual updates, as it does not describe this way of doing
things - I read it as only supporting RC, ABEND etc., not variables

Colin

On Wed, 10 Nov 2021 at 15:59, Billy Ashton  wrote:

> Here is a neat little trick I learned from a guy at CA, using SET and
> IF. I use this a lot now, and other than needing a dummy step if I am
> testing the first step in a job, it works great. I have been able to
> nest my IF statements sometimes 3 deep when I have complex processing
> that I want to switch on or off.
>
> Billy
>
> //*
> //* Run the TEST1 process? Set to 1 if yes, 0 if no:
> //  SET RUNTEST1=0
> //*
> //FIRSTSTP  EXEC PGM=IEFBR14Dummy first step for IF tests
> //*
> //I@TEST1  IF =1 THEN  "IF" cannot be used before 1st step
> //TEST1PGM  EXEC PGM=IEFBR14
> //*
> //L@TEST1  ELSE
> //TEST1OTH  EXEC PGM=IEFBR14
> //*
> //E@TEST1  ENDIF
> //
>
> --
> 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: conditional JCL - Reinvent the wheel?

[Billy Ashton]

Here is a neat little trick I learned from a guy at CA, using SET and 
IF. I use this a lot now, and other than needing a dummy step if I am 
testing the first step in a job, it works great. I have been able to 
nest my IF statements sometimes 3 deep when I have complex processing 
that I want to switch on or off.


Billy

//*
//* Run the TEST1 process? Set to 1 if yes, 0 if no:
//  SET RUNTEST1=0
//*
//FIRSTSTP  EXEC PGM=IEFBR14    Dummy first step for IF tests
//*
//I@TEST1  IF =1 THEN  "IF" cannot be used before 1st step
//TEST1PGM  EXEC PGM=IEFBR14
//*
//L@TEST1  ELSE
//TEST1OTH  EXEC PGM=IEFBR14
//*
//E@TEST1  ENDIF
//

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Orphaned SYSDSN Enqueue

[Mark Jacobs]

We have an orphaned SYSDSN enqueue that's preventing CICS from starting. GRS 
shows it enqueued by the CICS STC that we're trying to startup. The ASID that's 
being displayed is currently in use by a a different STC. Outside of an IPL is 
there anyway to remove the enqueue from the sysplex?

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: conditional JCL - Reinvent the wheel?

[Sri h Kolusu]

Colin,

Why not use IEBCOMPR to compare the symbols and set the return code? If
both symbols match RC= 0 else RC =8.  something like this (I used COND ,
but you can use IF ELSE after the first compare.)

// EXPORT SYMLIST=*
// SET DELUSER='NO'
// SET DEFUSER='YES'
/*
//**
//* Peform a compare of the set parms  *
//**
//COMPARE  EXEC PGM=IEBCOMPR
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD *,SYMBOLS=JCLONLY

//SYSUT2   DD *,SYMBOLS=JCLONLY

//SYSINDD DUMMY
/*
//**
//* SKIP delete user if compare step returns RC = 8*
//**
//DELUSER  EXEC PGM=IKJEFT01,COND=(8,EQ,COMPARE)
//SYSTSPRT DD SYSOUT=*,DCB=BLKSIZE=121
//SYSPRINT DD SYSOUT=*
//SYSTSIN  DD *,SYMBOLS=JCLONLY
/*


Thanks,
Kolusu


"IBM Mainframe Discussion List"  wrote on
11/10/2021 05:29:37 AM:

> From: "Colin Paice" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/10/2021 05:31 AM
> Subject: [EXTERNAL] conditional JCL - Reinvent the wheel?
> Sent by: "IBM Mainframe Discussion List" 
>
> I'm looking at ways of doing customisation, and want an easy way to
> run/omit steps.
> For example
> ADDUSER  ZZZ NAME('COLINS')NOPASSWORD -
>OMVS(AUTOUID  ASSIZE(25600)  THREADS(512))
>
> being a good person, I also want to provide a delete step
> DELUSER Z.
> My fantasy JCL looks like
> // SET DELUSER='NO'
> // SET DEFUSER=YES
> // SET...
>
> //IF  (DELUSER='YES')
> ..
> DELUSER 
> //ENDIF
> //IF  (DEFUSER='YES')
> ..
> ADDUSER  ..
> //ENDIF
> ...
>
> So the first time,  you set DELUSER=NO, DEFUSER=YES... and run it. the
> second time
> you set DELUSER=YES, DEFUSER=YES, and to give up,and clean up you set
> DELUSER=YES, DEFUSER=NO.
>
> What is the best way of doing this?
>
> The JCL 'IF' statement uses RC, or ABEND, and not on set variables.
>
> Ive set up a small program "COND",PARM='A = ' which sets RC = 0 if
they
> are the same,
> so now I can use
> //DELUSER EXEC PGM=COND,PARM='DELUSER = YES'
> //DEFUSER EXEC PGM=COND,PARM='DEFUSER = YES'
> //DELETE EXEC PGM=... ,COND=(0,NE,DELUSER)
> //DEFINE  EXEC PGM=...,COND=(0,NE,DEFUSER)
>
> Is there a better way of doing this?   I would prefer one job, because I
> want to do global edit of myuserid to Z etc
>
> In the past Ive put the deletes inline with the define, but the output
> looks messy, because the  first time delete fails.
>
> Colin
>
> --
> 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: conditional JCL - Reinvent the wheel?

[David Spiegel]

Hi Colin,
Add a TSO Step in which a CLIST/Rexx does a "LU Userid", trap the output 
and if your program "sees" ICH30001I UNABLE TO LOCATE USER ENTRY, avoid 
the DELUSER.


Regards,
David

On 2021-11-10 07:29, Colin Paice wrote:

I'm looking at ways of doing customisation, and want an easy way to
run/omit steps.
For example
ADDUSER  ZZZ NAME('COLINS')NOPASSWORD -
OMVS(AUTOUID  ASSIZE(25600)  THREADS(512))

being a good person, I also want to provide a delete step
DELUSER Z.
My fantasy JCL looks like
// SET DELUSER='NO'
// SET DEFUSER=YES
// SET...

//IF  (DELUSER='YES')
..
DELUSER 
//ENDIF
//IF  (DEFUSER='YES')
..
ADDUSER  ..
//ENDIF
...

So the first time,  you set DELUSER=NO, DEFUSER=YES... and run it. the
second time
you set DELUSER=YES, DEFUSER=YES, and to give up,and clean up you set
DELUSER=YES, DEFUSER=NO.

What is the best way of doing this?

The JCL 'IF' statement uses RC, or ABEND, and not on set variables.

Ive set up a small program "COND",PARM='A = ' which sets RC = 0 if they
are the same,
so now I can use
//DELUSER EXEC PGM=COND,PARM='DELUSER = YES'
//DEFUSER EXEC PGM=COND,PARM='DEFUSER = YES'
//DELETE EXEC PGM=... ,COND=(0,NE,DELUSER)
//DEFINE  EXEC PGM=...,COND=(0,NE,DEFUSER)

Is there a better way of doing this?   I would prefer one job, because I
want to do global edit of myuserid to Z etc

In the past Ive put the deletes inline with the define, but the output
looks messy, because the  first time delete fails.

Colin

--
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

conditional JCL - Reinvent the wheel?

[Colin Paice]

I'm looking at ways of doing customisation, and want an easy way to
run/omit steps.
For example
ADDUSER  ZZZ NAME('COLINS')NOPASSWORD -
   OMVS(AUTOUID  ASSIZE(25600)  THREADS(512))

being a good person, I also want to provide a delete step
DELUSER Z.
My fantasy JCL looks like
// SET DELUSER='NO'
// SET DEFUSER=YES
// SET...

//IF  (DELUSER='YES')
..
DELUSER 
//ENDIF
//IF  (DEFUSER='YES')
..
ADDUSER  ..
//ENDIF
...

So the first time,  you set DELUSER=NO, DEFUSER=YES... and run it. the
second time
you set DELUSER=YES, DEFUSER=YES, and to give up,and clean up you set
DELUSER=YES, DEFUSER=NO.

What is the best way of doing this?

The JCL 'IF' statement uses RC, or ABEND, and not on set variables.

Ive set up a small program "COND",PARM='A = ' which sets RC = 0 if they
are the same,
so now I can use
//DELUSER EXEC PGM=COND,PARM='DELUSER = YES'
//DEFUSER EXEC PGM=COND,PARM='DEFUSER = YES'
//DELETE EXEC PGM=... ,COND=(0,NE,DELUSER)
//DEFINE  EXEC PGM=...,COND=(0,NE,DEFUSER)

Is there a better way of doing this?   I would prefer one job, because I
want to do global edit of myuserid to Z etc

In the past Ive put the deletes inline with the define, but the output
looks messy, because the  first time delete fails.

Colin

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN