Re: COBOL Question

[Joe Monk]

I think what you mean is this:

PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99
END-PERFORM

  1050-LOOP.
IF FIRST-NAME NOT = "ROBERT"
GO TO 1059-EXIT
END-IF
IF TYPE NOT = 195
GO TO 1059-EXIT
END-IF
IF NOT SO-ON
GO TO 1059-EXIT
END-IF
IF NOT SO-FORTH
GO TO 1059-EXIT
END-IF
PERFORM 1050-SUCH-AND-SUCH END-PERFORM

  1059-EXIT.
  EXIT.

In structured programming, it is perfectly acceptable to use GO TO within a
paragraph. It is NOT acceptable to use GO TO outside of a paragraph.

Joe

On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges  wrote:

> I realize this is a bit of a change in subject (and it's not as if we need
> yet another one), but I avoid this construction.  My phobia is based on an
> extreme example:  In their zeal never to use GOTOs, I've frequently seen
> programmers write paragraphs like this:
>
>   PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X < 1000
>   IF FIRST-NAME NOT = "ROBERT"
> IF TYPE = 195
>   IF SO-ON
> IF SO-FORTH
>   EXECUTE 1050-SUCH-AND-SUCH
>   END-IF
> END-IF
>   END-IF
> END-IF
>   END-IF
>
> Gives me a headache to try to evaluate that.  Much better, in my opinion,
> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this:
>
>   PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X > 999 GOTO 1059-LOOP.
> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP.
> IF TYPE <> 195 GOTO 1059-LOOP.
> IF NOT SO-ON GOTO 1059-LOOP.
> IF NOT SO-FORTH GOTO 1059-LOOP.
> EXECUTE 1050-SUCH-AND-SUCH
>   1059-LOOP.
>
> Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the
> syntax, I probably got part of it wrong nonetheless, and I'll bet there are
> easier ways to do it nowadays.  In REXX, for example, they have the ITERATE
> statement:
>
>   do jc=1 to 99
> if x>99 then iterate
> if firstname='ROBERT' then iterate
> if type<>195 then iterate
> if \soon then iterate
> if \soforth then iterate
> call suchandsuch
> end
>
> However you do it, I vastly prefer skip-to-next-item over nested Ifs.  But
> I confess that one single nested IF is not going to give me a headache; I
> just react when I see one.  Not your fault :).
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* In an emergency, a drawstring from a parka hood can be used to strangle
> a snoring tent mate.  -"Camping Tips" */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gibney, Dave
> Sent: Friday, June 5, 2020 16:17
>
> Using OP
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>  AND SMOD (IND1) = 'B' OR 'R'
>
> I would do
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>   IF SMOD (IND1) = 'B' OR 'R'
>   Do the stuff
>
> --
> 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: zSHOP order too large to download

[Dejan Cepetic]

Hi.

I ordered Db2 Query Monitor v3.3 a week ago and order is 24 GB large. It was 
strange to me so I called a colleague from another company and she had the same 
experience. She checked with IBM and it turns out that there is some CAE server 
that you can run on z/OS or Windows. If you plan to run it on Windows you have 
to download it from z/OS once you finish SMP/E installation. It looks like this 
is the reason why this order is so large.

I don't think it's optimal to put something you would run on Windows in SMP/E 
and having all the trouble with uploading and unpacking.
But it looks there is no other choice.

Regards,

Dejan Cepetic

Mob: +385 91 5178 535 | dcepe...@croz.net | CROZ d.o.o.
___
Lastovska 23 | 1 Zagreb | Hrvatska | www.croz.net

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

Re: zSHOP order too large to download

[Bill Giannelli]

Hi Dejan,
THANK YOU!!
Now I understand! I thought I was ordering incorrectly because I got 24gig 
also! I am having difficulty at my site getting that space on our sand box USS. 
Now the next question for me is, can we get IBM to package this differently so 
that the "CAE server" is optional?
thanks again for the info!
Bill

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

Re: COBOL Question

[Charles Mills]

The problem would seem to me to stem from having the same operator for Boolean 
Not and for Bit Complement. Apparently VBA uses ! for both.

I believe that in C or C++ if ( ! Result ) would evaluate as you expected: 
first Result would be evaluated as true or false, then that truth value would 
be logically inverted, and then that inversion evaluated as true or false. C 
has a separate operator for complement -- the tilde ~ -- and in C you would 
have to code if ( ~ Result ) to get the anomalous behavior you describe.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Bridges
Sent: Friday, June 5, 2020 11:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question

Reminds me of a situation I had some years ago while writing a VBA program that 
used a class (for FTP, I think) that had been written in some flavor of C.  I 
was testing a supposedly Boolean return code and getting unexpected results.  I 
tried several ways, and eventually proved to myself that the return code was 
both True and False.  That is:

  Result = Function(Argument)
  If Result Then MsgBox "True"
  If Not Result Then MsgBox "False"

...displayed ~both~ messages.  Maybe some of you already know what was 
happening here, but I had to examine the returned value in hex to catch on.  
VBA uses -1 ( b) for True and 0 ( b) for False, but evaluates 0 
as False and any non-zero number as True.  The Not operand uses two's 
complement to negate.  But C, I gather, uses 0 for False and 1 for True.  So in 
this case I was getting a 1 back from the function ( 0001b), which VBA 
evaluated as True - and when I said "Not Result", it negated 1 into -2 ( 
1110b) and evaluated that as True also.

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

Re: XCF/GRS question

[Jesse 1 Robinson]

When we were transforming our environment from separate CPUs/LPARs to sysplex, 
we did so by subdividing existing systems into sysplex members rather than 
combining systems into sysplexes. Resulting sysplexes were based on traditional 
workloads. We ended up with one sysplex that only one member. No other system 
had the same workload, and no one could justify subdividing it just on 
principle. No problem.

There was one scheduled housekeeping job that did heavy ICF catalog reading. On 
all sysplexes it ran with x resource utilization except for this one sysplex, 
where the same job used 2x or 3x resources. I finally asked the question, how 
is this sysplex different from all other sysplexes? It was also the only 
parallel sysplex that was still running traditional ring GRS only because with 
a single system, it didn't seem worth additional CF structure overhead. IBM at 
the time said for up to four members, GRS ring was adequate. I'm not much into 
measuring and micro analyzing, so on a hunch I converted this single member 
sysplex to GRS star. The change was dramatic. Suddenly, with no other changes, 
the catalog housekeeping job dropped to x resource utilization. 

This was quite a few years ago. Things may have changed, but I still recommend 
GRS star for any parallel sysplex regardless of the number of members.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Edgington, Jerry
Sent: Tuesday, June 2, 2020 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):XCF/GRS question

CAUTION EXTERNAL EMAIL

We are running on single SYSPlex with two LPARs (Prod and Test) with 2 ICFs, 
all running on the GPs.  We are experiencing slowdowns, due to PROC-GRS on 
Test, PROC-XCFAS on Prod.  Weights are 20/20/20/80 for ICF1/ICF2/Test/Prod.  We 
have setup XCF Structures and FCTC for GRS Star

Higher Weight:
PROC-GRS3.4 users
PROC-GRS2.4 users
ENQ -ACF2ACB  100.0 % delay LOGONIDS
PROC-GRS   99.0 % delay
PROC-GRS   13.0 % delay

Lower weight:
PROC-XCFAS 14.1 users
PROC-XCFAS 13.1 users
PROC-XCFAS 99.0 % delay
PROC-XCFAS 45.0 % delay
PROC-XCFAS 16.0 % delay
PROC-XCFAS 11.0 % delay
PROC-XCFAS 33.0 % delay
PROC-XCFAS 77.0 % delay
PROC-XCFAS 45.0 % delay

GRSCNFxx:
GRSDEF MATCHSYS(*)
   SYNCHRES (YES)
   GRSQ (CONTENTION)
   ENQMAXA(25)
   ENQMAXU(16384)
   AUTHQLVL(2)
   RESMIL(5)
   TOLINT(180)

IEASYSxx:
GRS=STAR, JOIN GRS STAR
GRSCNF=00,GRS INITIALIZATION MEMBER
GRSRNL=00,GRS RESOURCE LIST

D GRS:
RESPONSE=TEST
 ISG343I 13.38.49 GRS STATUS 604
 SYSTEMSTATE   SYSTEMSTATE
 MVSZ  CONNECTED   TEST  CONNECTED
 GRS STAR MODE INFORMATION
   LOCK STRUCTURE (ISGLOCK) CONTAINS 1048576 LOCKS.
   THE CONTENTION NOTIFYING SYSTEM IS TEST
   SYNCHRES:  YES
   ENQMAXU: 16384
   ENQMAXA:25
   GRSQ:   CONTENTION
   AUTHQLVL:1
   MONITOR:NO

Any advice or help on what I can do about these delays, would be great?

Thanks,
Jerry

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

RACF Administration the Easy Way using an Open Source ISPF Dialog

[Lionel B Dyck]

A group of us have been working on an open source project to simplify RACF
Administration - it is called RACFADM and is available in File 417 at
www.cbttape.org   (check the updates page for the
latest) or on GitHub at https://github.com/lbdyck/racfadm.  This has been a
benefit to each of the installations who have contributed and it is
something that, if you're using RACF and don't have a vendor solution, will
find very useful. 

 

To borrow from the old Alka-Seltzer commercial - "Try it, You'll Like it! .
Oh what a relief it is."

 

An extract from the ISPF Tutorial pane provides some insight into the
dialog:

 

==

 

RACF Administration makes many security tasks simple.  It lists user, group,
data set and general resource profiles by means of a user-friendly,
menu-driven interface; it provides interactive modification of most fields.

   

Among its features are: connecting groups to a user, adding permissions,
user authorization searching across classes, and displaying the group from
which an authorization is granted.

   

Adding a new TSO user will create the alias and necessary datasets.

==

 

 

Lionel B. Dyck <
Website:   https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

 


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

Re: COBOL Question

[Bob Bridges]

Oh, you need an END-IF even for a single-statement IF?  I forgot; I've been 
thinking in REXX too long.  In that case you're close; I guess I really meant

   PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99

   1050-LOOP.
 IF X > 999 GOTO 1050-EXIT END-IF.
 IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF.
 IF TYPE <> 195 GOTO 1050-EXIT END-IF.
 IF NOT SO-ON GOTO 1050-EXIT END-IF.
 IF NOT SO-FORTH GOTO 1050-EXIT END-IF.
 [do such and such]
   1050-EXIT.

I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ 
circumstances.  In my old shop I argued for GOTOs in three very strictly 
limited circumstances, the other two being end-of-section and end-of-program.  
Some languages allow for this by including some flavor of "leave" statement; 
all I want to do with a GOTO is to simulate that part of structured 
programming.  But at the particular shop I have in mind, none of that could be 
contemplated, because all GOTOs are evil.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #21 of combat operations: The important things are always simple; the 
simple things are always hard. */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Monk
Sent: Saturday, June 6, 2020 04:49

I think what you mean is this:

PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99
END-PERFORM

  1050-LOOP.
IF FIRST-NAME NOT = "ROBERT"
GO TO 1059-EXIT
END-IF
IF TYPE NOT = 195
GO TO 1059-EXIT
END-IF
IF NOT SO-ON
GO TO 1059-EXIT
END-IF
IF NOT SO-FORTH
GO TO 1059-EXIT
END-IF
PERFORM 1050-SUCH-AND-SUCH END-PERFORM

  1059-EXIT.
  EXIT.

In structured programming, it is perfectly acceptable to use GO TO within a
paragraph. It is NOT acceptable to use GO TO outside of a paragraph.

--- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges  wrote:
> I realize this is a bit of a change in subject (and it's not as if we need
> yet another one), but I avoid this construction.  My phobia is based on an
> extreme example:  In their zeal never to use GOTOs, I've frequently seen
> programmers write paragraphs like this:
>
>   PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X < 1000
>   IF FIRST-NAME NOT = "ROBERT"
> IF TYPE = 195
>   IF SO-ON
> IF SO-FORTH
>   EXECUTE 1050-SUCH-AND-SUCH
>   END-IF
> END-IF
>   END-IF
> END-IF
>   END-IF
>
> Gives me a headache to try to evaluate that.  Much better, in my opinion,
> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this:
>
>   PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X > 999 GOTO 1059-LOOP.
> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP.
> IF TYPE <> 195 GOTO 1059-LOOP.
> IF NOT SO-ON GOTO 1059-LOOP.
> IF NOT SO-FORTH GOTO 1059-LOOP.
> EXECUTE 1050-SUCH-AND-SUCH
>   1059-LOOP.
>
> Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the
> syntax, I probably got part of it wrong nonetheless, and I'll bet there are
> easier ways to do it nowadays.  In REXX, for example, they have the ITERATE
> statement:
>
>   do jc=1 to 99
> if x>99 then iterate
> if firstname='ROBERT' then iterate
> if type<>195 then iterate
> if \soon then iterate
> if \soforth then iterate
> call suchandsuch
> end
>
> However you do it, I vastly prefer skip-to-next-item over nested Ifs.  But
> I confess that one single nested IF is not going to give me a headache; I
> just react when I see one.  Not your fault :).
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gibney, Dave
> Sent: Friday, June 5, 2020 16:17
>
> Using OP
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>  AND SMOD (IND1) = 'B' OR 'R'
>
> I would do
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>   IF SMOD (IND1) = 'B' OR 'R'
>   Do the stuff

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

Re: Gratuitous EXECIO Documentation

[Paul Gilmartin]

On Fri, 5 Jun 2020 17:13:58 +, Seymour J Metz wrote:

>foo = value('BAR',,baz)
>
>From: Charles Mills
>Sent: Friday, June 5, 2020 12:27 PM
>
>It is SO counter-intuitive to put the name of a variable in quotes. You would 
>not code ENQ ('MYMAJOR','MYMINOR',E,8).
>Once you realize that EXECIO is an external command, not a language keyword, 
>you start to get it.
>
Rexx grammar is a glorious context-sensitive chaos. As when
I tried to understand the ANSI spec for ADDRESS and failed.

MFC's intent was to be intuitive rather than axiomatic.

Perhaps Rexx General Concepts should contain a section
on use of symbol names with an incomplete list:

PROCEDURE EXPOSE
not quoted

ADDRESS
sometimes not quoted

VALUE(); SYMBOL();
quoted

ADDRESS LINK*/ATTCH*
arguments quoted in separate strings

EXECIO ... ( STEM )
quoted

Documented elsewhere:
BPXWDYN( ... MSG() )
stem, descriptor, keyword lexically distinguished

BPXWUNIX( stdin, stdout, stderr )
stem, ddname lexically distinguished

ADDRESS SYSCALL
quoted ( symbol name )

ADDRESS ISPEXEC/ISREDIT
shared variable references

ADDRESS SDSF
various stems

And your favorites?

-- gil

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

Re: COBOL Question

[Bob Bridges]

Really, a different operator?  I didn't know; I bought a C compiler once, a 
couple decades ago, but then never used it.

Now I'm wondering whether VBA has such a distinction and I simply assumed, and 
never looked for it.  I don't think so, but I should remember to look.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Good teaching is one-fourth preparation and three-fourths good theatre.  
-Gail Godwin */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Saturday, June 6, 2020 11:35

The problem would seem to me to stem from having the same operator for Boolean 
Not and for Bit Complement. Apparently VBA uses ! for both.

I believe that in C or C++ if ( ! Result ) would evaluate as you expected: 
first Result would be evaluated as true or false, then that truth value would 
be logically inverted, and then that inversion evaluated as true or false. C 
has a separate operator for complement -- the tilde ~ -- and in C you would 
have to code if ( ~ Result ) to get the anomalous behavior you describe.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Bridges
Sent: Friday, June 5, 2020 11:00 PM

Reminds me of a situation I had some years ago while writing a VBA program that 
used a class (for FTP, I think) that had been written in some flavor of C.  I 
was testing a supposedly Boolean return code and getting unexpected results.  I 
tried several ways, and eventually proved to myself that the return code was 
both True and False.  That is:

  Result = Function(Argument)
  If Result Then MsgBox "True"
  If Not Result Then MsgBox "False"

...displayed ~both~ messages.  Maybe some of you already know what was 
happening here, but I had to examine the returned value in hex to catch on.  
VBA uses -1 ( b) for True and 0 ( b) for False, but evaluates 0 
as False and any non-zero number as True.  The Not operand uses two's 
complement to negate.  But C, I gather, uses 0 for False and 1 for True.  So in 
this case I was getting a 1 back from the function ( 0001b), which VBA 
evaluated as True - and when I said "Not Result", it negated 1 into -2 ( 
1110b) and evaluated that as True also.

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

SMPe download, unpack, receive

[Bill Giannelli]

previously I had a SMPe environment that required me to run the download from 
IBM (GIMSMP) to mu USS. Then unpack the files from USS. And then run a receive 
against those unpacked files.
Now I have a new SMPe environment (new CSI,etc) that was setup by someone else. 
And when I run the IBM download (GIMSMP) the FMIDs and PTFs appeared to already 
be received.
What am I not understanding here?
Do I NOT need to unpack the files from USS and run the receive separately?
thanks
Bill

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

Re: SMPe download, unpack, receive

[Paul Gilmartin]

On Sat, 6 Jun 2020 13:06:07 -0500, Bill Giannelli wrote:

>previously I had a SMPe environment that required me to run the download from 
>IBM (GIMSMP) to mu USS. Then unpack the files from USS. And then run a receive 
>against those unpacked files.
>Now I have a new SMPe environment (new CSI,etc) that was setup by someone 
>else. And when I run the IBM download (GIMSMP) the FMIDs and PTFs appeared to 
>already be received.
>What am I not understanding here?
>Do I NOT need to unpack the files from USS and run the receive separately?
>
Will RECEIVE FROMNTS suffice?

What do the instructions say?

Are there instructions?

I once packaged a product for RECEIVE FROMNTS but encountered
a compulsive customer who tried GIMUNZIP; RECEIVE from data
sets.  Failed; I hadn't expected or tested that path.  Had to tell
customer, "Not supported; not documented."  But fixed it to work
in next release.

-- gi

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

Re: COBOL Question

[Clark Morris]

[Default] On 6 Jun 2020 10:53:44 -0700, in bit.listserv.ibm-main
robhbrid...@gmail.com (Bob Bridges) wrote:

>Oh, you need an END-IF even for a single-statement IF?  I forgot; I've been 
>thinking in REXX too long.  In that case you're close; I guess I really meant
In your example the END-IF is not needed.  However beginning with VS
COBOL IIV4 (1985 standard) it became better practice to eliminate all
but the last period in a paragraph and terminate all conditional with
end statements such as END-IF.  With Enterprise COBOL 5.2 and later
(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO
TOs replaced with EXIT PARAGRAPH.  This allow simpler code generation
for the PERFORM and the PERFORMed paragraph be moved inline to in
effect replace the PERFORM statement.  Also look up inline PERFORMs.
In general, because of code optimization starting with VS COBOL II
release 4 (1985 standard) GO TO became a bad idea.

Clark Morris 
>
>   PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X > 999 GOTO 1050-EXIT END-IF.
> IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF.
> IF TYPE <> 195 GOTO 1050-EXIT END-IF.
> IF NOT SO-ON GOTO 1050-EXIT END-IF.
> IF NOT SO-FORTH GOTO 1050-EXIT END-IF.
> [do such and such]
>   1050-EXIT.
>
>I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ 
>circumstances.  In my old shop I argued for GOTOs in three very strictly 
>limited circumstances, the other two being end-of-section and end-of-program.  
>Some languages allow for this by including some flavor of "leave" statement; 
>all I want to do with a GOTO is to simulate that part of structured 
>programming.  But at the particular shop I have in mind, none of that could be 
>contemplated, because all GOTOs are evil.
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>/* Law #21 of combat operations: The important things are always simple; the 
>simple things are always hard. */
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Joe Monk
>Sent: Saturday, June 6, 2020 04:49
>
>I think what you mean is this:
>
>PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99
>END-PERFORM
>
>  1050-LOOP.
>IF FIRST-NAME NOT = "ROBERT"
>GO TO 1059-EXIT
>END-IF
>IF TYPE NOT = 195
>GO TO 1059-EXIT
>END-IF
>IF NOT SO-ON
>GO TO 1059-EXIT
>END-IF
>IF NOT SO-FORTH
>GO TO 1059-EXIT
>END-IF
>PERFORM 1050-SUCH-AND-SUCH END-PERFORM
>
>  1059-EXIT.
>  EXIT.
>
>In structured programming, it is perfectly acceptable to use GO TO within a
>paragraph. It is NOT acceptable to use GO TO outside of a paragraph.
>
>--- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges  wrote:
>> I realize this is a bit of a change in subject (and it's not as if we need
>> yet another one), but I avoid this construction.  My phobia is based on an
>> extreme example:  In their zeal never to use GOTOs, I've frequently seen
>> programmers write paragraphs like this:
>>
>>   PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99
>>
>>   1050-LOOP.
>> IF X < 1000
>>   IF FIRST-NAME NOT = "ROBERT"
>> IF TYPE = 195
>>   IF SO-ON
>> IF SO-FORTH
>>   EXECUTE 1050-SUCH-AND-SUCH
>>   END-IF
>> END-IF
>>   END-IF
>> END-IF
>>   END-IF
>>
>> Gives me a headache to try to evaluate that.  Much better, in my opinion,
>> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this:
>>
>>   PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99
>>
>>   1050-LOOP.
>> IF X > 999 GOTO 1059-LOOP.
>> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP.
>> IF TYPE <> 195 GOTO 1059-LOOP.
>> IF NOT SO-ON GOTO 1059-LOOP.
>> IF NOT SO-FORTH GOTO 1059-LOOP.
>> EXECUTE 1050-SUCH-AND-SUCH
>>   1059-LOOP.
>>
>> Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the
>> syntax, I probably got part of it wrong nonetheless, and I'll bet there are
>> easier ways to do it nowadays.  In REXX, for example, they have the ITERATE
>> statement:
>>
>>   do jc=1 to 99
>> if x>99 then iterate
>> if firstname='ROBERT' then iterate
>> if type<>195 then iterate
>> if \soon then iterate
>> if \soforth then iterate
>> call suchandsuch
>> end
>>
>> However you do it, I vastly prefer skip-to-next-item over nested Ifs.  But
>> I confess that one single nested IF is not going to give me a headache; I
>> just react when I see one.  Not your fault :).
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Gibney, Dave
>> Sent: Friday, June 5, 2020 16:17
>>
>> Using OP
>>  IF TVOLL (IND1) NOT = HIGH-VALUE
>>  AND SMOD (IND1) = 'B' OR 'R'
>>
>> I would do
>>  IF TVOLL (IND1) NOT = HIGH-VALUE
>>   IF SMOD (IND1) = 'B' OR 'R'
>>   Do the stuf

Re: COBOL Question

[Paul Gilmartin]

On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote:

>On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote:
>
>>Oh, you need an END-IF even for a single-statement IF?  I forgot; I've been 
>>thinking in REXX too long.  In that case you're close; I guess I really meant
>
But in Rexx similarly, END is required even for a single-statement DO.
Good for Rexx.  I like strong closure.

>In your example the END-IF is not needed.  However beginning with VS
>COBOL IIV4 (1985 standard) it became better practice to eliminate all
>but the last period in a paragraph and terminate all conditional with
>end statements such as END-IF.  With Enterprise COBOL 5.2 and later
>(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO
>TOs replaced with EXIT PARAGRAPH.  This allow simpler code generation
>for the PERFORM and the PERFORMed paragraph be moved inline to in
>effect replace the PERFORM statement.  Also look up inline PERFORMs.
>In general, because of code optimization starting with VS COBOL II
>release 4 (1985 standard) GO TO became a bad idea.
>
Always a bad idea, or just usually?

-- gil

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

Re: SMPe download, unpack, receive

[Bill Giannelli]

This is command I am currently using:
  SET  BOUNDARY (GLOBAL) .  
  RECEIVE   
FROMNETWORK(
  SERVER(SERVINFO)  
  CLIENT(CLNTINFO)  

  ) 
   .

So because I am NOT specifying "transferonly" all the downloaded software is 
received into my Global?
thanks
Bill

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

Re: COBOL Question

[Charles Mills]

https://www.tutorialspoint.com/cprogramming/c_operators.htm for C operators

I don't know VBA at all, only some VB. Are you sure about the ! operator being 
"complement"?

https://bytecomb.com/the-bang-exclamation-operator-in-vba/
https://www.tutorialspoint.com/vba/vba_operators.htm 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Bridges
Sent: Saturday, June 6, 2020 10:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question

Really, a different operator?  I didn't know; I bought a C compiler once, a 
couple decades ago, but then never used it.

Now I'm wondering whether VBA has such a distinction and I simply assumed, and 
never looked for it.  I don't think so, but I should remember to look.

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

Re: COBOL Question

[Joe Monk]

Granted its been awhile since ive done application code, but if you
dont end-if they become a nested condition, which I dont think was the
original intent.

Joe

On Sat, Jun 6, 2020 at 1:40 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote:
>
> >On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote:
> >
> >>Oh, you need an END-IF even for a single-statement IF?  I forgot; I've
> been thinking in REXX too long.  In that case you're close; I guess I
> really meant
> >
> But in Rexx similarly, END is required even for a single-statement DO.
> Good for Rexx.  I like strong closure.
>
> >In your example the END-IF is not needed.  However beginning with VS
> >COBOL IIV4 (1985 standard) it became better practice to eliminate all
> >but the last period in a paragraph and terminate all conditional with
> >end statements such as END-IF.  With Enterprise COBOL 5.2 and later
> >(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO
> >TOs replaced with EXIT PARAGRAPH.  This allow simpler code generation
> >for the PERFORM and the PERFORMed paragraph be moved inline to in
> >effect replace the PERFORM statement.  Also look up inline PERFORMs.
> >In general, because of code optimization starting with VS COBOL II
> >release 4 (1985 standard) GO TO became a bad idea.
> >
> Always a bad idea, or just usually?
>
> -- 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: SMPe download, unpack, receive

[Paul Gilmartin]

On Sat, 6 Jun 2020 13:53:27 -0500, Bill Giannelli wrote:

>This is command I am currently using:
>  SET  BOUNDARY (GLOBAL) . 
>  
>  RECEIVE  
>  
>FROMNETWORK(   
>  
>  SERVER(SERVINFO) 
>  
>  CLIENT(CLNTINFO) 
>  
>  )
>  
>   .
>
>So because I am NOT specifying "transferonly" all the downloaded software is 
>received into my Global?
>
That should work.  You should supply data sets/DD statements
for SERVINFO, CLNTINFO, GLOBAL, SMPNTS; define DLIB and
TARGET zones (unless placing the order supplies JCL for that).

If it succeeds and you try it again, SHA-1 checksums will tell
you there's nothing to do.

You could then do a RECEIVE FROMNTS with a different GLOBAL
zone.

I have supplied my customers tailoring scripts for installation  jobs.
Your vendor may have done that for you.

-- gil

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

Re: COBOL Question

[Clark Morris]

[Default] On 6 Jun 2020 12:43:09 -0700, in bit.listserv.ibm-main
joemon...@gmail.com (Joe Monk) wrote:

>Granted its been awhile since ive done application code, but if you
>dont end-if they become a nested condition, which I dont think was the
>original intent.

A conditional statement in COBOL is terminated either by a period or
an END-xx statement.  The arithmetic statements become conditional if
there is an "ON SIZE ERROR" clause so that there are END-ADD,
END-SUBTRACT, END-COMPUTE, etc. statements.  I-O statements such as
READ and WRITE become conditional if there are "AT END", INVALID KEY"
or similar statements so there are END-READ and END-WRITE statements.

Clark Morris   
>
>Joe
>
>On Sat, Jun 6, 2020 at 1:40 PM Paul Gilmartin <
>000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote:
>>
>> >On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote:
>> >
>> >>Oh, you need an END-IF even for a single-statement IF?  I forgot; I've
>> been thinking in REXX too long.  In that case you're close; I guess I
>> really meant
>> >
>> But in Rexx similarly, END is required even for a single-statement DO.
>> Good for Rexx.  I like strong closure.
>>
>> >In your example the END-IF is not needed.  However beginning with VS
>> >COBOL IIV4 (1985 standard) it became better practice to eliminate all
>> >but the last period in a paragraph and terminate all conditional with
>> >end statements such as END-IF.  With Enterprise COBOL 5.2 and later
>> >(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO
>> >TOs replaced with EXIT PARAGRAPH.  This allow simpler code generation
>> >for the PERFORM and the PERFORMed paragraph be moved inline to in
>> >effect replace the PERFORM statement.  Also look up inline PERFORMs.
>> >In general, because of code optimization starting with VS COBOL II
>> >release 4 (1985 standard) GO TO became a bad idea.
>> >
>> Always a bad idea, or just usually?
>>
>> -- 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

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

Re: Gratuitous EXECIO Documentation

[Mike Schwab]

I like syntax diagrams.

On Fri, Jun 5, 2020 at 4:46 PM Charles Mills  wrote:
>
> The documentation is written to aid human beings. It is not a hard-core 
> exercise in logic.
>
> In writing doc I am often struck by a contrast to coding. In coding, if you 
> had to do the same three-line sequence at ten places in your code the right 
> thing would be to factor it out into a subroutine and invoke it ten times. In 
> writing doc OTOH the reader might be better served by your repeating the same 
> three sentences ten times rather than ten times saying "See the note at the 
> top of page 17" (which is roughly the documentation analog of a subroutine 
> call).
>
> It's a judgment call as to what will best help the reader. Sometimes 
> following logic rigorously is what best serves the reader. Probably better to 
> use a link to the JCL reference rather than doing a halfway job of explaining 
> DD statements in a COBOL manual. But as @Tony says, EXECIO is a particular 
> landmine for inexperienced Rexx coders. It is not wrong to make their lives 
> easier.
>
> And no, "therefore every technically similar feature should get the same 
> note" is not a valid corollary.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Friday, June 5, 2020 9:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Gratuitous EXECIO Documentation
>
> On Fri, 5 Jun 2020 12:01:18 -0400, Tony Thigpen wrote:
>
> >In my experience, over 30 years of using REXX on first VM, then VSE and
> >now z/OS, I can't tell you how many times I have had to help people with
> >the EXECIO syntax as it relates to "what is a keyword" and "what is a
> >variable". I would put it at the top of the "common programming errors
> >in REXX" list.
> >
> >I have seen the following error S many times:
> >... "STEM" line.
> >Which should be:
> >... "STEM LINE."
> >
> >I would not consider this "gratuitous" documentation.
> >
> I'm outvoted.  I  shall submit one RCF for each command description
> that does not contain such a caution asking that one be added.
>
> (I haven't checked.  Perhaps they already exist.)
>
> -- 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



-- 
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: Gratuitous EXECIO Documentation

[Phil Smith III]

I'm expect this got added because people, especially non-VMers*, seem to get 
confused about whether EXECIO is part of Rexx or not,
leading to the confusing scenarios others have described.

 

...phsiii 

 

*In VM, EXECIO predates Rexx, so old-timers, at least, don't get confused. And 
on some platforms, it IS part of the Rexx distro,
though still not part of the language, IIRC.


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

Re: Gratuitous EXECIO Documentation

[Seymour J Metz]

It doesn't matter whether it's part of REXX or not; the rules for expressions 
are the same whether the environment is built in or addon. I've been on the 
other side of this, where the tech writer's prose was much cleaner than mine, 
but no longer described the product I was building.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Saturday, June 6, 2020 6:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Gratuitous EXECIO Documentation

I'm expect this got added because people, especially non-VMers*, seem to get 
confused about whether EXECIO is part of Rexx or not,
leading to the confusing scenarios others have described.



...phsiii



*In VM, EXECIO predates Rexx, so old-timers, at least, don't get confused. And 
on some platforms, it IS part of the Rexx distro,
though still not part of the language, IIRC.


--
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: COBOL Question

[Seymour J Metz]

OTOH, REXX does not have an ENDIF, although SELECT does require an END.


--
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: Saturday, June 6, 2020 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question

On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote:

>On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote:
>
>>Oh, you need an END-IF even for a single-statement IF?  I forgot; I've been 
>>thinking in REXX too long.  In that case you're close; I guess I really meant
>
But in Rexx similarly, END is required even for a single-statement DO.
Good for Rexx.  I like strong closure.

>In your example the END-IF is not needed.  However beginning with VS
>COBOL IIV4 (1985 standard) it became better practice to eliminate all
>but the last period in a paragraph and terminate all conditional with
>end statements such as END-IF.  With Enterprise COBOL 5.2 and later
>(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO
>TOs replaced with EXIT PARAGRAPH.  This allow simpler code generation
>for the PERFORM and the PERFORMed paragraph be moved inline to in
>effect replace the PERFORM statement.  Also look up inline PERFORMs.
>In general, because of code optimization starting with VS COBOL II
>release 4 (1985 standard) GO TO became a bad idea.
>
Always a bad idea, or just usually?

-- 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: COBOL Question

[Seymour J Metz]

https://www.cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Saturday, June 6, 2020 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question

Oh, you need an END-IF even for a single-statement IF?  I forgot; I've been 
thinking in REXX too long.  In that case you're close; I guess I really meant

   PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99

   1050-LOOP.
 IF X > 999 GOTO 1050-EXIT END-IF.
 IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF.
 IF TYPE <> 195 GOTO 1050-EXIT END-IF.
 IF NOT SO-ON GOTO 1050-EXIT END-IF.
 IF NOT SO-FORTH GOTO 1050-EXIT END-IF.
 [do such and such]
   1050-EXIT.

I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ 
circumstances.  In my old shop I argued for GOTOs in three very strictly 
limited circumstances, the other two being end-of-section and end-of-program.  
Some languages allow for this by including some flavor of "leave" statement; 
all I want to do with a GOTO is to simulate that part of structured 
programming.  But at the particular shop I have in mind, none of that could be 
contemplated, because all GOTOs are evil.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #21 of combat operations: The important things are always simple; the 
simple things are always hard. */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Monk
Sent: Saturday, June 6, 2020 04:49

I think what you mean is this:

PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99
END-PERFORM

  1050-LOOP.
IF FIRST-NAME NOT = "ROBERT"
GO TO 1059-EXIT
END-IF
IF TYPE NOT = 195
GO TO 1059-EXIT
END-IF
IF NOT SO-ON
GO TO 1059-EXIT
END-IF
IF NOT SO-FORTH
GO TO 1059-EXIT
END-IF
PERFORM 1050-SUCH-AND-SUCH END-PERFORM

  1059-EXIT.
  EXIT.

In structured programming, it is perfectly acceptable to use GO TO within a
paragraph. It is NOT acceptable to use GO TO outside of a paragraph.

--- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges  wrote:
> I realize this is a bit of a change in subject (and it's not as if we need
> yet another one), but I avoid this construction.  My phobia is based on an
> extreme example:  In their zeal never to use GOTOs, I've frequently seen
> programmers write paragraphs like this:
>
>   PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X < 1000
>   IF FIRST-NAME NOT = "ROBERT"
> IF TYPE = 195
>   IF SO-ON
> IF SO-FORTH
>   EXECUTE 1050-SUCH-AND-SUCH
>   END-IF
> END-IF
>   END-IF
> END-IF
>   END-IF
>
> Gives me a headache to try to evaluate that.  Much better, in my opinion,
> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this:
>
>   PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X > 999 GOTO 1059-LOOP.
> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP.
> IF TYPE <> 195 GOTO 1059-LOOP.
> IF NOT SO-ON GOTO 1059-LOOP.
> IF NOT SO-FORTH GOTO 1059-LOOP.
> EXECUTE 1050-SUCH-AND-SUCH
>   1059-LOOP.
>
> Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the
> syntax, I probably got part of it wrong nonetheless, and I'll bet there are
> easier ways to do it nowadays.  In REXX, for example, they have the ITERATE
> statement:
>
>   do jc=1 to 99
> if x>99 then iterate
> if firstname='ROBERT' then iterate
> if type<>195 then iterate
> if \soon then iterate
> if \soforth then iterate
> call suchandsuch
> end
>
> However you do it, I vastly prefer skip-to-next-item over nested Ifs.  But
> I confess that one single nested IF is not going to give me a headache; I
> just react when I see one.  Not your fault :).
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gibney, Dave
> Sent: Friday, June 5, 2020 16:17
>
> Using OP
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>  AND SMOD (IND1) = 'B' OR 'R'
>
> I would do
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>   IF SMOD (IND1) = 'B' OR 'R'
>   Do the stuff

--
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: COBOL Question

[Seymour J Metz]

BIT(1) and BINARY are two different things in PL/I. The coercion of bit strings 
into FIXED BINARY looked good at the time, but I believe that it was a bad 
decision, as your example shows. OTOH, it's even worse to treat numerical or 
character data as boolean.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Friday, June 5, 2020 7:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question

This triggered me once more, sorry :-)

I recall that we once did a larger project, checking all the PL/1 sources
at a customer of mine, looking for errors in program logic, using a tool
that I wrote (sort of a light weight, yet powerful, PL/1 parser).

The parser threw errors (observations) on about ten percent of the
source codes.

One program had this coding:

IF 9 < ZZ < 20 THEN DO;

no error from the compiler, no warning :-)

the condition turned out to be always true, because

(9 < ZZ) < 20

the left part is evaluated and gives a binary result (BIT(1) in PL/1
speech);
this is converted to decimal, and no matter what the value of ZZ is,
the BIT(1) is always lower than 20 (be it '0'B or '1'B).

This was of course not what the author intended; this was at an insurance
company where most of the programmers had a math background, so this
kind of expression was natural to them. The compiler didn't complain.

Kind regards

Bernd


Am 05.06.2020 um 23:26 schrieb Paul Gilmartin:
> On Fri, 5 Jun 2020 20:54:37 +, Seymour J Metz wrote:
>
>> SMOD (IND1) = 'B' OR 'R' means (SMOD (IND1) = 'B') OR (SMOD (IND1) = 'R'); 
>> syntax for implied comparands exists in other languages as well.
>>
> I have dealt with a language (Mainsail) that had a ternary compare:
>  A <= B < C
> I don't know whether it avoided side effects of evaluating B twice.
> It probably (I'm not sure) short-circuited to avoid evaluating C
> needlessly.
>
> I like semi-open intervals, especially in loops.
>
> -- 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

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

Re: Gratuitous EXECIO Documentation

[Phil Smith III]

Gil wrote, in part:

> ADDRESS
>sometimes not quoted

 

Um. When would it be quoted? You *can* but you never need to:

address banana /* Always sets the environment to BANANA */

address 'banana' /* Also sets the environment to BANANA */

fruit='KIWI' 

address value fruit /* Sets the environment to KIWI */

 

Common confusion.

 

...phsiii (being pedantic, but this is a pedantic thread!)


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

Re: Gratuitous EXECIO Documentation

[Seymour J Metz]

Gil is correct. Sometimes you need to quote. Read the *full* description of 
ADDRESS.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Saturday, June 6, 2020 10:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Gratuitous EXECIO Documentation

Gil wrote, in part:

> ADDRESS
>sometimes not quoted



Um. When would it be quoted? You *can* but you never need to:

address banana /* Always sets the environment to BANANA */

address 'banana' /* Also sets the environment to BANANA */

fruit='KIWI'

address value fruit /* Sets the environment to KIWI */



Common confusion.



...phsiii (being pedantic, but this is a pedantic thread!)


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

PCRE2 10.35 with LE and Rexx API is available

[Ze'ev Atlas]

Hi AllPCRE2 10.35 with LE and Rexx API is available in CBTTAPE.org, file939

Please try the Rexx API which really is simple and smooth and bring Regular 
Expressions to TSO-Rexx
Ze'ev Atlas


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

Re: Gratuitous EXECIO Documentation

[Seymour J Metz]

There really is nothing that needs to be quoted. The requirement is that the 
various expressions have the correct value, and there is not much practical 
difference between

foo='BAR'
baz=value(foo,,env)

and

   baz=value('BAR',,env)

WRT ADDRESS, the command is the value of one string expression. The arguments 
are part of that value. 

In general, the documentation should have a correct description followed by 
some examples. The examples could include using a single string literal and 
using a more complicated expression.


--
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: Saturday, June 6, 2020 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Gratuitous EXECIO Documentation

On Fri, 5 Jun 2020 17:13:58 +, Seymour J Metz wrote:

>foo = value('BAR',,baz)
>
>From: Charles Mills
>Sent: Friday, June 5, 2020 12:27 PM
>
>It is SO counter-intuitive to put the name of a variable in quotes. You would 
>not code ENQ ('MYMAJOR','MYMINOR',E,8).
>Once you realize that EXECIO is an external command, not a language keyword, 
>you start to get it.
>
Rexx grammar is a glorious context-sensitive chaos. As when
I tried to understand the ANSI spec for ADDRESS and failed.

MFC's intent was to be intuitive rather than axiomatic.

Perhaps Rexx General Concepts should contain a section
on use of symbol names with an incomplete list:

PROCEDURE EXPOSE
not quoted

ADDRESS
sometimes not quoted

VALUE(); SYMBOL();
quoted

ADDRESS LINK*/ATTCH*
arguments quoted in separate strings

EXECIO ... ( STEM )
quoted

Documented elsewhere:
BPXWDYN( ... MSG() )
stem, descriptor, keyword lexically distinguished

BPXWUNIX( stdin, stdout, stderr )
stem, ddname lexically distinguished

ADDRESS SYSCALL
quoted ( symbol name )

ADDRESS ISPEXEC/ISREDIT
shared variable references

ADDRESS SDSF
various stems

And your favorites?

-- 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: Gratuitous EXECIO Documentation

[Phil Smith III]

Wow, cool. Never noticed that ADDRESS (foo) evaluates FOO, but of course in 
retrospect it should. A good day!


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

Re: Gratuitous EXECIO Documentation

[Paul Gilmartin]

On Sat, 6 Jun 2020 22:16:02 -0400, Phil Smith III wrote:

>Gil wrote, in part:
>
>> ADDRESS
>>sometimes not quoted
>Um. When would it be quoted? You *can* but you never need to:
>
>fruit='KIWI'
>address value fruit /* Sets the environment to KIWI */
>
But that's different from:
 address value 'fruit' /* Sets the environment to FRUIT */
Quoting makes a difference, and is often prudent.

BTW, in CMS, IIRC:
 address value 'fruit' /* Sets the environment to fruit */

I don't know what ANSI has to say about this.  I feel that
case of quoted strings should be preserved.

-- gil

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

Re: Gratuitous EXECIO Documentation

[Paul Gilmartin]

On Sat, 6 Jun 2020 23:43:57 -0400, Phil Smith III wrote:

>Wow, cool. Never noticed that ADDRESS (foo) evaluates FOO, but of course in 
>retrospect it should. A good day!
>
... and it's way hard to put in a formal syntax.  Chaotically intuitive.

-- gil

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