Re: Suggestion for conditioning step on symbols

[Edward Gould]

> On May 16, 2016, at 7:23 AM, Elardus Engelbrecht 
>  wrote:
> 
> John McKown wrote:
> 
>>> You can always write a 3rd SORT system with a build in programming 
>>> language. Hopefully that system is sort of free...
> 
>> ​Oh, yeah. Perhaps based on Guile (big grin)
>> https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.
> 
> H, very very interesting part of the GNU project. I have bookmarked that! 
> Many thanks!
> 
> 
>> ​CA-Easytrieve Plus might fit your bill. Of course, being as how it's from 
>> CA, it is not free at all. But it is faster and easier to write than COBOL.​

I would disagree with that statement a lot. I could whip out SMF reports faster 
than management could ask. COBOL was OK (but not even close).

Ed

> 
> My purse (usually empty and made from scottish leather) will drop me real 
> faster than I write than COBOL or use that software ... 
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> 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: AW: Suggestion for conditioning step on symbols

[Elardus Engelbrecht]

John McKown wrote:

>​Well, I understand your comments on DFSORT's control language. ICETOOL + 
>SYMNAMES does a lot to enhance DFSORT. 

Indeed. ICETOOL is my friend.


>But a more "general purpose" language, building on these, might be nice.​

Agreed. I look at what is available, how that is suited for a problem at hand 
and then try out a solution or two. Sometimes off the shelf is enough, but 
sometime you need to re-invent the wheel and do your RYO thing...


>​... I'm a dumb old sysprog.

That makes two of us ... [1]  ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - Geez, I had to do a COBOL trace another day, and... I had to relook at a 
source code twice just to get a grasp on what that was supposed to do... 
Previously, only a fast skim on the source was needed and I'm finished and 
ready for debugging.

Getting old is not for sissies...

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

Re: AW: Suggestion for conditioning step on symbols

[John McKown]

On Mon, May 16, 2016 at 7:23 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> John McKown wrote:
>
> >> You can always write a 3rd SORT system with a build in programming
> language. Hopefully that system is sort of free...
>
> >​Oh, yeah. Perhaps based on Guile (big grin)
> >https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.
>
> H, very very interesting part of the GNU project. I have bookmarked
> that! Many thanks!
>
>
> >​CA-Easytrieve Plus might fit your bill. Of course, being as how it's
> from CA, it is not free at all. But it is faster and easier to write than
> COBOL.​
>
> My purse (usually empty and made from scottish leather) will drop me real
> faster than I write than COBOL or use that software ...
>
> Groete / Greetings
> Elardus Engelbrecht
>
>
​Well, I understand your comments on DFSORT's control language. ICETOOL +
SYMNAMES does a lot to enhance DFSORT. But a more "general purpose"
language, building on these, might be nice.​

​I can imagine such a thing, even though I don't have the talent to
actually design it. ​I'm not an application programmer, I'm a dumb old
sysprog.


-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

Maranatha! <><
John McKown

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

Re: AW: Suggestion for conditioning step on symbols

[Elardus Engelbrecht]

John McKown wrote:

>> You can always write a 3rd SORT system with a build in programming language. 
>> Hopefully that system is sort of free...

>​Oh, yeah. Perhaps based on Guile (big grin)
>https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.

H, very very interesting part of the GNU project. I have bookmarked that! 
Many thanks!


>​CA-Easytrieve Plus might fit your bill. Of course, being as how it's from CA, 
>it is not free at all. But it is faster and easier to write than COBOL.​

My purse (usually empty and made from scottish leather) will drop me real 
faster than I write than COBOL or use that software ... 

Groete / Greetings
Elardus Engelbrecht

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

Re: AW: Suggestion for conditioning step on symbols

[John McKown]

On Mon, May 16, 2016 at 4:31 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Peter Hunkeler wrote:
>
> >Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt;
> it's control statements (I intentionally don't called it "language") are a
> nightmare, no doubt. Hopefully noone will ever consider the above as
> something suitable for production. Overkill; not maintainable.
>
> Perhaps, this is why ICETOOL is in place. That is a great tool.
>
> You can always write a 3rd SORT system with a build in programming
> language. Hopefully that system is sort of free...
>

​Oh, yeah. Perhaps based on Guile (big grin)
https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.


>
> Something like this, sort of, but ...
>
> PROGRAM Sort-it-Yourself
>
> Declaration fiels left to programmer as an exercise...
>
> OPEN IN
> OPEN OUT
>
> For records 1 - last do
>  sort by surname
>  output name, surname, phone number
> end for
>
> SHOW records 'Records sorted by surname.'
>
> Close everything;
>
> SHOW ' You're sorted out!'
>

​CA-Easytrieve Plus might fit your bill. Of course, being as how it's from
CA, it is not free at all. But it is faster and easier to write than COBOL.​



>
> Groete / Greetings
> Elardus Engelbrecht
>
>
-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

Maranatha! <><
John McKown

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

Re: AW: Suggestion for conditioning step on symbols

[Elardus Engelbrecht]

Peter Hunkeler wrote:

>Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt; it's 
>control statements (I intentionally don't called it "language") are a 
>nightmare, no doubt. Hopefully noone will ever consider the above as something 
>suitable for production. Overkill; not maintainable.

Perhaps, this is why ICETOOL is in place. That is a great tool.

You can always write a 3rd SORT system with a build in programming language. 
Hopefully that system is sort of free...

Something like this, sort of, but ...

PROGRAM Sort-it-Yourself

Declaration fiels left to programmer as an exercise...

OPEN IN
OPEN OUT

For records 1 - last do
 sort by surname
 output name, surname, phone number
end for

SHOW records 'Records sorted by surname.'

Close everything;

SHOW ' You're sorted out!'

Groete / Greetings
Elardus Engelbrecht

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

AW: Suggestion for conditioning step on symbols

[Peter Hunkeler]

>So, changed those to non-printable. That would fix it up, but the code is 
>still suffering from having to change >horses in mid-stream. And there's the 
>fat-fingering, which is an all-too-common issue.
 >
>Leads to sort symbols, WHEN=INIT, two FINDREPs with STARTPOS and DO=1 and 
>SHIFT=NO.
 >
>//CHEKPARM EXEC PGM=SORT,PARM='JP1"",JP2""'
>//SYMNAMES DD *
>* RECORD FIELDS TO CREATE AND MANIPLUATE
>FIRST-COMPARATOR,*,80,CH
>SECOND-COMPARATOR,*,=,=
>* CONSTANTS
>DUMMY-VALUE1-TO-REPLACE,X'FD'
>DUMMY-VALUE2-TO-REPLACE,X'FE'
>//SYMNOUT  DD SYSOUT=*
>//SYSOUT   DD SYSOUT=*
>//SORTOUT  DD SYSOUT=*
>//SYSINDD *
>OPTION COPY,STOPAFT=1
>
>INREC  IFTHEN=(WHEN=INIT,
>OVERLAY=(FIRST-COMPARATOR:
>DUMMY-VALUE1-TO-REPLACE,
>79X,
>SECOND-COMPARATOR:
>DUMMY-VALUE2-TO-REPLACE,
>79X)),
>IFTHEN=(WHEN=INIT,
>FINDREP=(IN=DUMMY-VALUE1-TO-REPLACE,
>OUT=JP1,
>STARTPOS=1,
>DO=1,
>SHIFT=NO)),
>IFTHEN=(WHEN=INIT,
>FINDREP=(IN=DUMMY-VALUE2-TO-REPLACE,
>OUT=JP2,
>STARTPOS=81,
>DO=1,
>SHIFT=NO))
>OUTFIL INCLUDE=(FIRST-COMPARATOR,
>EQ,
>SECOND-COMPARATOR),
>NULLOFL=RC4
>//SORTIN   DD *
>CONTENT IMMATERIAL
 >
>If concerned that it is overly wordy (some people have a problem with that), 
>...



Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt; it's 
control statements (I intentionally don't called it "language") are a 
nightmare, no doubt. Hopefully noone will ever consider the above as something 
suitable for production. Overkill; not maintainable.


--
Peter Hunkeler


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

Suggestion for conditioning step on symbols

[Bill Woodger]

Well, Friday was a long week, and that often leads to fatal mistakes. Here the 
mistake is using "printable" items as the source-data for the FINDREP. This 
would be a problem if the value was a subset of the PARM.

So, changed those to non-printable. That would fix it up, but the code is still 
suffering from having to change horses in mid-stream. And there's the 
fat-fingering, which is an all-too-common issue.

Leads to sort symbols, WHEN=INIT, two FINDREPs with STARTPOS and DO=1 and 
SHIFT=NO.

//CHEKPARM EXEC PGM=SORT,PARM='JP1"",JP2""'
//SYMNAMES DD * 
* RECORD FIELDS TO CREATE AND MANIPLUATE 
 FIRST-COMPARATOR,*,80,CH 
 SECOND-COMPARATOR,*,=,= 
* CONSTANTS 
 DUMMY-VALUE1-TO-REPLACE,X'FD' 
 DUMMY-VALUE2-TO-REPLACE,X'FE' 
//SYMNOUT  DD SYSOUT=* 
//SYSOUT   DD SYSOUT=* 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY,STOPAFT=1 
   
  INREC  IFTHEN=(WHEN=INIT, 
 OVERLAY=(FIRST-COMPARATOR: 
 DUMMY-VALUE1-TO-REPLACE, 
 79X, 
  SECOND-COMPARATOR: 
 DUMMY-VALUE2-TO-REPLACE, 
 79X)), 
 IFTHEN=(WHEN=INIT, 
 FINDREP=(IN=DUMMY-VALUE1-TO-REPLACE, 
  OUT=JP1, 
  STARTPOS=1, 
  DO=1, 
  SHIFT=NO)), 
 IFTHEN=(WHEN=INIT, 
 FINDREP=(IN=DUMMY-VALUE2-TO-REPLACE, 
  OUT=JP2, 
  STARTPOS=81, 
  DO=1, 
  SHIFT=NO)) 
  OUTFIL INCLUDE=(FIRST-COMPARATOR, 
 EQ, 
  SECOND-COMPARATOR), 
  NULLOFL=RC4 
//SORTIN   DD * 
CONTENT IMMATERIAL 

If concerned that it is overly wordy (some people have a problem with that), 
this is after DFSORT has resolved all the symbols (including the matching JCL 
symbol values I used for this particular run):

OPTION COPY,STOPAFT=1   
  
   INREC 
IFTHEN=(WHEN=INIT,OVERLAY=(1:X'FD',79X,81:X'FE',79X)),IFTHEN=(WH*
 
EN=INIT,FINDREP=(IN=X'FD',OUT=C'AC',STARTPOS=1,DO=1,SHIF*
 
T=NO)),IFTHEN=(WHEN=INIT,FINDREP=(IN=X'FE',OUT=C'AC',STA*
 RTPOS=81,DO=1,SHIFT=NO))   
  
   OUTFIL INCLUDE=(1,80,CH,EQ,81,80,CH),NULLOFL=RC4 
  

For me there are lots of advantages to using sort symbols, including adding an 
element of "self-documentation" and sparing the fat fingers from a run that 
gets RC=0 but had a typo. With symbols, a typo will generally get RC=16. With 
naked control cards, it'll often get a run, just the wrong one.

On Saturday, 14 May 2016 00:08:27 UTC+2, Bill Woodger  wrote:
> DFSORT using JPn symbols:
> 
> // SET PARM1=XY 
> // SET PARM2=AB 
> //STEP0100 EXEC PGM=SORT,PARM='JP1"",JP2""'
> //SYMNOUT  DD SYSOUT=* 
> //SYSOUT   DD SYSOUT=* 
> //SORTOUT  DD SYSOUT=* 
> //SYSINDD * 
>   OPTION COPY,STOPAFT=1 
>
>   INREC  OVERLAY=(01:C'A', 
>  80X, 
>   80:C'B', 
>  80X) 
>   OUTREC FINDREP=(INOUT=(C'A', 
>   JP1, 
>  C'B', 
>   JP2)) 
>   OUTFIL  INCLUDE=(01,80,CH, 
>   EQ, 
>81,80,CH), 
>   NULLOFL=RC4 
> //SORTIN   DD * 
> CONTENT IMMATERIAL 
> 
> 
> Will work prior to z/OS 2.x for anyone who needs that.
> 
> The actual values of the symbols are automatically documents on the SYMNOUT 
> dataset.
> 
> NULLOFL allows the setting of some specific RC values when the OUTFIL dataset 
> has no records.
> 
> Original code was shorter, but testing (failed) with null symbols required 
> changes.
> 
> Code may be different with a later DFSORT, but then you'd have access to the 
> EXPORT anyway (which could be used directly in a SORT step anyway).
> 
> --
> 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: Suggestion for conditioning step on symbols

[Charles Mills]

It worked, once I un-fat-fingered it. Thanks again,

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Godfrey
Sent: Friday, May 13, 2016 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Suggestion for conditioning step on symbols

On Fri, 13 May 2016 09:39:43 -0700, Charles Mills wrote:

>I know this has been kicked around before but I don't have a good 
>answer off the top of my head and I don't know exactly how to Google for the 
>answer.
>
>Does anyone have suggestions for conditioning a jobstep on  != 
>? I know that COND= and IF are only on return codes and similar 
>things, not character strings.
>
>I could write Rexx that would compare two symbols (or evaluate a 
>complex
>expression) and set a return code -- is that the best approach? Or is 
>there something off the shelf that would have the same effect? I have a 
>feeling someone here knows a clever hack.
>
>Complicating life is that part of what I need to bypass if  ==
> is a DD with DISP=NEW. Can IF bypass an entire step including 
>DDs (such that DISP=NEW for an existing dataset will not cause errors)? 
>The examples do not show that. If not, do I solve that by putting the 
>DD (and EXEC PGM=) in a PROC and IF/ELSE executing one of two 
>alternative PROCs? Or ... ?

One way to set a return code, on systems that allow in-stream substitution 
(z/OS 2.x JES2)

// EXPORT SYMLIST=(PARM1,PARM2)
// SET PARM1=FOO
// SET PARM2=BAR
//COMPARE EXEC PGM=IEBCOMPR
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD *,SYMBOLS=JCLONLY

//SYSUT2   DD *,SYMBOLS=JCLONLY

//SYSINDD DUMMY

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

Suggestion for conditioning step on symbols

[Bill Woodger]

DFSORT using JPn symbols:

// SET PARM1=XY 
// SET PARM2=AB 
//STEP0100 EXEC PGM=SORT,PARM='JP1"",JP2""'
//SYMNOUT  DD SYSOUT=* 
//SYSOUT   DD SYSOUT=* 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY,STOPAFT=1 
   
  INREC  OVERLAY=(01:C'A', 
 80X, 
  80:C'B', 
 80X) 
  OUTREC FINDREP=(INOUT=(C'A', 
  JP1, 
 C'B', 
  JP2)) 
  OUTFIL  INCLUDE=(01,80,CH, 
  EQ, 
   81,80,CH), 
  NULLOFL=RC4 
//SORTIN   DD * 
CONTENT IMMATERIAL 


Will work prior to z/OS 2.x for anyone who needs that.

The actual values of the symbols are automatically documents on the SYMNOUT 
dataset.

NULLOFL allows the setting of some specific RC values when the OUTFIL dataset 
has no records.

Original code was shorter, but testing (failed) with null symbols required 
changes.

Code may be different with a later DFSORT, but then you'd have access to the 
EXPORT anyway (which could be used directly in a SORT step anyway).

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

Re: Suggestion for conditioning step on symbols

[Charles Mills]

Now you're talking! Great! Simple, and real obvious what is going on there. 
Thanks. That's the kind of hack I was hoping for. Yes, I would be running on 
JES2/V2R1.

Darn! I was looking forward to writing a Rexx script that would do an INTERPRET 
on PARM= 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Godfrey
Sent: Friday, May 13, 2016 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Suggestion for conditioning step on symbols

On Fri, 13 May 2016 09:39:43 -0700, Charles Mills wrote:

>I know this has been kicked around before but I don't have a good 
>answer off the top of my head and I don't know exactly how to Google for the 
>answer.
>
>Does anyone have suggestions for conditioning a jobstep on  != 
>? I know that COND= and IF are only on return codes and similar 
>things, not character strings.
>
>I could write Rexx that would compare two symbols (or evaluate a 
>complex
>expression) and set a return code -- is that the best approach? Or is 
>there something off the shelf that would have the same effect? I have a 
>feeling someone here knows a clever hack.
>
>Complicating life is that part of what I need to bypass if  ==
> is a DD with DISP=NEW. Can IF bypass an entire step including 
>DDs (such that DISP=NEW for an existing dataset will not cause errors)? 
>The examples do not show that. If not, do I solve that by putting the 
>DD (and EXEC PGM=) in a PROC and IF/ELSE executing one of two 
>alternative PROCs? Or ... ?

One way to set a return code, on systems that allow in-stream substitution 
(z/OS 2.x JES2)

// EXPORT SYMLIST=(PARM1,PARM2)
// SET PARM1=FOO
// SET PARM2=BAR
//COMPARE EXEC PGM=IEBCOMPR
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD *,SYMBOLS=JCLONLY

//SYSUT2   DD *,SYMBOLS=JCLONLY

//SYSINDD DUMMY

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

Re: Suggestion for conditioning step on symbols

[Bill Godfrey]

On Fri, 13 May 2016 09:39:43 -0700, Charles Mills wrote:

>I know this has been kicked around before but I don't have a good answer off
>the top of my head and I don't know exactly how to Google for the answer.
>
>Does anyone have suggestions for conditioning a jobstep on  !=
>? I know that COND= and IF are only on return codes and similar
>things, not character strings.
>
>I could write Rexx that would compare two symbols (or evaluate a complex
>expression) and set a return code -- is that the best approach? Or is there
>something off the shelf that would have the same effect? I have a feeling
>someone here knows a clever hack.
>
>Complicating life is that part of what I need to bypass if  ==
> is a DD with DISP=NEW. Can IF bypass an entire step including DDs
>(such that DISP=NEW for an existing dataset will not cause errors)? The
>examples do not show that. If not, do I solve that by putting the DD (and
>EXEC PGM=) in a PROC and IF/ELSE executing one of two alternative PROCs? Or
>... ?

One way to set a return code, on systems that allow in-stream substitution 
(z/OS 2.x JES2)

// EXPORT SYMLIST=(PARM1,PARM2)
// SET PARM1=FOO
// SET PARM2=BAR
//COMPARE EXEC PGM=IEBCOMPR
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD *,SYMBOLS=JCLONLY

//SYSUT2   DD *,SYMBOLS=JCLONLY

//SYSINDD DUMMY

Bill

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

Re: Suggestion for conditioning step on symbols

[Nims,Alva John (Al)]

You may want to set:

AOP_MVS_RETURN_CODES
Specifies whether the afpxpcl, afpxpdf, and afpxps commands return MVS 
return codes or UNIX exit values:

Value
Meaning
YES
MVS return codes:

0
Successful. 
4
A warning occurred during the transform. 
8
The command was not accepted, a data stream error occurred during 
the transform, or the transform failed. 

NO
UNIX exit values:

0
Successful. However, a warning or data stream error might have 
occurred during the transform. 
1
The command was not accepted, or the transform failed. 

Also AOPBATCH is part of the INFOPrint service (or whatever it is called) and 
instead  you may want to use BPXBATCH (or BPXBATSL) which are part of base 
z/OS.  This you may have to test, because in your AWK example, I believe "Exit 
4" will generate 256*4 or 1024, I think.  The doc says:

"other multiples of 256
A return code greater than 255, unless explicitly documented as a return 
code from BPXBATCH (32000 or 32512), is actually an exit status being returned 
from the program that was invoked by BPXBATCH. The exit status can be 
determined by dividing the value of BPXYWAST by 256."

"BPXYWAST
BPXBATCH invoked the BPX1FRK (fork) callable service. This is usually 
invoked only by a TSO/E user. Processing was successful with wait() status 
containing a nonzero value. The wait status was mapped by BPXYWAST and returned 
by BPX1WAT (wait)."

The above information is from z/OS 1.13 documentation, I am going to z/OS 2.02, 
but not there yet, so I did not check to see if there are any differences.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, May 13, 2016 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Suggestion for conditioning step on symbols

I don't have a solution for the string comparison issue, but the DISP=NEW issue 
I can tell you with confidence "just works" under JES2.  For either a COND= or 
an IF bypass of a step, all of the DD's are bypassed and no allocation error 
occurs.  I use this feature all the time in my testing.

For JES3 I'm not sure if it works the same, someone with JES3 experience will 
have to advise you on that.

HTH

Peter

P.S. -- I tried the following trick for string compares but the return code is 
still 0 and not 4 as one might hope:

// SET S1=ABCD   
// SET S2=DEFG   
//*  
//TESTSTR  EXEC PGM=AOPBATCH,REGION=32M, 
// PARM='awk BEGIN {if ("" == "") exit 0; else exit 4}'
//STDOUTDD SYSOUT=*,RECFM=VA,LRECL=250,BLKSIZE=254   
//STDERRDD SYSOUT=*  
//STDIN DD DUMMY 
//*  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, May 13, 2016 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Suggestion for conditioning step on symbols

I know this has been kicked around before but I don't have a good answer off 
the top of my head and I don't know exactly how to Google for the answer.

Does anyone have suggestions for conditioning a jobstep on  != 
? I know that COND= and IF are only on return codes and similar things, 
not character strings.

I could write Rexx that would compare two symbols (or evaluate a complex
expression) and set a return code -- is that the best approach? Or is there 
something off the shelf that would have the same effect? I have a feeling 
someone here knows a clever hack.

Complicating life is that part of what I need to bypass if  ==
 is a DD with DISP=NEW. Can IF bypass an entire step including DDs 
(such that DISP=NEW for an existing dataset will not cause errors)? The 
examples do not show that. If not, do I solve that by putting the DD (and EXEC 
PGM=) in a PROC and IF/ELSE executing one of two alternative PROCs? Or ... ?

Charles
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-

Re: Suggestion for conditioning step on symbols

[Charles Mills]

Thanks. I do NOT need JES3. This is for internal use, not a product, and our
datacenter is all JES2.

Thanks for your experiment below. That's the right idea even if it did not
work. I always forget about the UNIX tools from batch.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Friday, May 13, 2016 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Suggestion for conditioning step on symbols

I don't have a solution for the string comparison issue, but the DISP=NEW
issue I can tell you with confidence "just works" under JES2.  For either a
COND= or an IF bypass of a step, all of the DD's are bypassed and no
allocation error occurs.  I use this feature all the time in my testing.

For JES3 I'm not sure if it works the same, someone with JES3 experience
will have to advise you on that.

HTH

Peter

P.S. -- I tried the following trick for string compares but the return code
is still 0 and not 4 as one might hope:

// SET S1=ABCD   
// SET S2=DEFG   
//*  
//TESTSTR  EXEC PGM=AOPBATCH,REGION=32M, 
// PARM='awk BEGIN {if ("" == "") exit 0; else exit 4}'
//STDOUTDD SYSOUT=*,RECFM=VA,LRECL=250,BLKSIZE=254   
//STDERRDD SYSOUT=*  
//STDIN DD DUMMY 

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

Re: Suggestion for conditioning step on symbols

[Elardus Engelbrecht]

Charles Mills wrote:

>I know this has been kicked around before but I don't have a good answer off 
>the top of my head and I don't know exactly how to Google for the answer.

Can you search IBM-MAIN archives itself? Of course, you may try out different 
search arguments...


>Does anyone have suggestions for conditioning a jobstep on  != 
>? I know that COND= and IF are only on return codes and similar 
>things, not character strings.

Ouch, that's a hard one... If I get that baby, I will not sleep for a long 
time...


>I could write Rexx that would compare two symbols (or evaluate a complex 
>expression) and set a return code -- is that the best approach? Or is there 
>something off the shelf that would have the same effect?

Automation and REXX can do that. Or you can program something to check 
something and set a RC based on what you find.


>I have a feeling someone here knows a clever hack.

Careful, you may get spam with expensive solutions ...


>Complicating life is that part of what I need to bypass if  == 
> is a DD with DISP=NEW. Can IF bypass an entire step including DDs 
>(such that DISP=NEW for an existing dataset will not cause errors)? The 
>examples do not show that. If not, do I solve that by putting the DD (and EXEC 
>PGM=) in a PROC and IF/ELSE executing one of two alternative PROCs? Or
... ?

Try this fun thing to check if a DSN is there or not, not exactly what you want 
but you should get a start for now:

//SPFPDF   EXEC PGM=IKJEFT01
//SYSPRINT DD  SYSOUT=* 
//SYSTERM  DD  SYSOUT=* 
//SYSTSPRT DD  SYSOUT=* 
//SYSTSIN  DD  *
 PROF NOPREF
 LISTDS ???.JCL 
   IF ('???.JCL') = OK THEN   +  
DO  
 WRITE DATASET FOUND
 SET  = 0
END 
   ELSE  +  
DO  
 WRITE DATA SET NOT FOUND   
 SET  = 4
END 

HTH!

Groete / Greetings
Elardus Engelbrecht

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

Re: Suggestion for conditioning step on symbols

[Farley, Peter x23353]

I don't have a solution for the string comparison issue, but the DISP=NEW issue 
I can tell you with confidence "just works" under JES2.  For either a COND= or 
an IF bypass of a step, all of the DD's are bypassed and no allocation error 
occurs.  I use this feature all the time in my testing.

For JES3 I'm not sure if it works the same, someone with JES3 experience will 
have to advise you on that.

HTH

Peter

P.S. -- I tried the following trick for string compares but the return code is 
still 0 and not 4 as one might hope:

// SET S1=ABCD   
// SET S2=DEFG   
//*  
//TESTSTR  EXEC PGM=AOPBATCH,REGION=32M, 
// PARM='awk BEGIN {if ("" == "") exit 0; else exit 4}'
//STDOUTDD SYSOUT=*,RECFM=VA,LRECL=250,BLKSIZE=254   
//STDERRDD SYSOUT=*  
//STDIN DD DUMMY 
//*  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, May 13, 2016 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Suggestion for conditioning step on symbols

I know this has been kicked around before but I don't have a good answer off 
the top of my head and I don't know exactly how to Google for the answer.

Does anyone have suggestions for conditioning a jobstep on  != 
? I know that COND= and IF are only on return codes and similar things, 
not character strings.

I could write Rexx that would compare two symbols (or evaluate a complex
expression) and set a return code -- is that the best approach? Or is there 
something off the shelf that would have the same effect? I have a feeling 
someone here knows a clever hack.

Complicating life is that part of what I need to bypass if  ==
 is a DD with DISP=NEW. Can IF bypass an entire step including DDs 
(such that DISP=NEW for an existing dataset will not cause errors)? The 
examples do not show that. If not, do I solve that by putting the DD (and EXEC 
PGM=) in a PROC and IF/ELSE executing one of two alternative PROCs? Or ... ?

Charles 
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Suggestion for conditioning step on symbols

[Paul Gilmartin]

On Fri, 13 May 2016 09:39:43 -0700, Charles Mills wrote:

>I know this has been kicked around before but I don't have a good answer off
>the top of my head and I don't know exactly how to Google for the answer.
>
>Does anyone have suggestions for conditioning a jobstep on  !=
>? I know that COND= and IF are only on return codes and similar
>things, not character strings.
> 
Sigh.  And there are many constructs which documentation calls unsupported
but work intuitively, such as:

IF ( FALSE ) THEN
EXEC PGM= ...  (The step is skipped.)
ENDIF

I consider this specification a grievous misapplication of Postel's principle.

>I could write Rexx that would compare two symbols (or evaluate a complex
>expression) and set a return code -- is that the best approach? Or is there
>something off the shelf that would have the same effect? I have a feeling
>someone here knows a clever hack.
> 
If I were writing Rexx, I'd tailor the entire job, up front.  But I prefer
shell scripts because sh provides instream data.

Or use ISPF file tailoring; not in my skill set.

In simpler cases IDCAMS is the simplest way to set a return code.

>Complicating life is that part of what I need to bypass if  ==
> is a DD with DISP=NEW. Can IF bypass an entire step including DDs
>(such that DISP=NEW for an existing dataset will not cause errors)? The
>
Sigh.  This looks like a JES3 constraint.  I've sometimes resorted to (not JES3)

//HANDLE  DD  DISP=(MOD,CATLG),...
//SYSUT2  DD  DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE

Or, sprinkle in steps with COND=(0,LE) to fool JES3

>examples do not show that. If not, do I solve that by putting the DD (and
>EXEC PGM=) in a PROC and IF/ELSE executing one of two alternative PROCs? Or
>... ?
>
And selecting the PROC by a JCL SET symbol?  I haven't tried it; I hope it 
works.

-- gil

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

Suggestion for conditioning step on symbols

[Charles Mills]

I know this has been kicked around before but I don't have a good answer off
the top of my head and I don't know exactly how to Google for the answer.

Does anyone have suggestions for conditioning a jobstep on  !=
? I know that COND= and IF are only on return codes and similar
things, not character strings.

I could write Rexx that would compare two symbols (or evaluate a complex
expression) and set a return code -- is that the best approach? Or is there
something off the shelf that would have the same effect? I have a feeling
someone here knows a clever hack.

Complicating life is that part of what I need to bypass if  ==
 is a DD with DISP=NEW. Can IF bypass an entire step including DDs
(such that DISP=NEW for an existing dataset will not cause errors)? The
examples do not show that. If not, do I solve that by putting the DD (and
EXEC PGM=) in a PROC and IF/ELSE executing one of two alternative PROCs? Or
... ?

Charles 

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