Re: COBOL Question
Forgot the quotes!
On Mon, Jun 8, 2020 at 3:07 PM Wayne Bickerdike wrote:
> Or to be controversial:
>
> tab.T = countt=countT+1
> tab.U = countU=countU+1
> tab.V = countV=countV+1
> tab.W = countW=countW+1
>
> INTERPRET tab.idx
>
> On Mon, Jun 8, 2020 at 3:01 PM Wayne Bickerdike wrote:
>
>> CA-IDEAL has SELECT FIRST ACTION AND SELECT EVERY ACTION. That I like.
>>
>> On Mon, Jun 8, 2020 at 2:59 PM Wayne Bickerdike
>> wrote:
>>
>>> For brevity, if you don't like DO END.
>>>
>>> select
>>> when idx="T" then countt=countt+1
>>> when idx="U" then countu=countu+1
>>> when idx="V" then countv=countv+1
>>> when idx="W" then countw=countw+1
>>> otherwise countx=countx+1; end
>>>
>>> Could be :
>>> SELECT( idx)
>>> when ("T") then countt=countt+1
>>> when ("U") then countu=countu+1
>>> when ("V") then countv=countv+1
>>> when ("W") then countw=countw+1
>>> otherwise countx=countx+1; end
>>>
>>>
>>>
>>> On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges
>>> wrote:
>>>
No, I wasn't complaining about the SELECT statement, only about using
lots of DO/statement/ENDs when there's only a single statement. I would
code the same thing like this:
select
when idx="T" then countt=countt+1
when idx="U" then countu=countu+1
when idx="V" then countv=countv+1
when idx="W" then countw=countw+1
otherwise countx=countx+1; end
(Of course if that were a real example I would probably have found a
way to use a stem variable instead:
count.idx=count.idx+1
But in this case I was just talking about coding style, as Mr Metz
said.)
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* If a problem has a single neck, it has a simple solution. */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Lou Losee
Sent: Sunday, June 7, 2020 14:38
Would you rather code the select as a series of nested if-then-else?
--- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
wrote:
> The only language I can think of off-hand that doesn't require some
sort
> of END to close a DO (I'm sure there are others) is ISPF. But, in
REXX at
> least, I never use single-statement DOs. I see them all the time,
and I
> don't get it. Like this:
>
> if x=0 then do
> x=x+1
> end
>
> Or, more painfully:
>
> select
> when idx="T" then
> do
> countt=countt+1
> end
> when idx="U" then
> do
> countu=countu+1
> end
> when idx="V" then
> do
> countv=countv+1
> end
> when idx="W" then
> do
> countw=countw+1
> end
> otherwise
> do
> countx=countx+1
> end
> end
>
> Why? If it were easier to read, I might sympathize. But it's
harder, not
> easier.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On
> Behalf Of Paul Gilmartin
> Sent: Saturday, June 6, 2020 14:40
>
> But in Rexx similarly, END is required even for a single-statement DO.
> Good for Rexx. I like strong closure.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>>
>>> --
>>> Wayne V. Bickerdike
>>>
>>>
>>
>> --
>> Wayne V. Bickerdike
>>
>>
>
> --
> Wayne V. Bickerdike
>
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Or to be controversial:
tab.T = countt=countT+1
tab.U = countU=countU+1
tab.V = countV=countV+1
tab.W = countW=countW+1
INTERPRET tab.idx
On Mon, Jun 8, 2020 at 3:01 PM Wayne Bickerdike wrote:
> CA-IDEAL has SELECT FIRST ACTION AND SELECT EVERY ACTION. That I like.
>
> On Mon, Jun 8, 2020 at 2:59 PM Wayne Bickerdike wrote:
>
>> For brevity, if you don't like DO END.
>>
>> select
>> when idx="T" then countt=countt+1
>> when idx="U" then countu=countu+1
>> when idx="V" then countv=countv+1
>> when idx="W" then countw=countw+1
>> otherwise countx=countx+1; end
>>
>> Could be :
>> SELECT( idx)
>> when ("T") then countt=countt+1
>> when ("U") then countu=countu+1
>> when ("V") then countv=countv+1
>> when ("W") then countw=countw+1
>> otherwise countx=countx+1; end
>>
>>
>>
>> On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges wrote:
>>
>>> No, I wasn't complaining about the SELECT statement, only about using
>>> lots of DO/statement/ENDs when there's only a single statement. I would
>>> code the same thing like this:
>>>
>>> select
>>> when idx="T" then countt=countt+1
>>> when idx="U" then countu=countu+1
>>> when idx="V" then countv=countv+1
>>> when idx="W" then countw=countw+1
>>> otherwise countx=countx+1; end
>>>
>>> (Of course if that were a real example I would probably have found a way
>>> to use a stem variable instead:
>>>
>>> count.idx=count.idx+1
>>>
>>> But in this case I was just talking about coding style, as Mr Metz said.)
>>>
>>> ---
>>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>>
>>> /* If a problem has a single neck, it has a simple solution. */
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Lou Losee
>>> Sent: Sunday, June 7, 2020 14:38
>>>
>>> Would you rather code the select as a series of nested if-then-else?
>>>
>>> --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
>>> wrote:
>>> > The only language I can think of off-hand that doesn't require some
>>> sort
>>> > of END to close a DO (I'm sure there are others) is ISPF. But, in
>>> REXX at
>>> > least, I never use single-statement DOs. I see them all the time, and
>>> I
>>> > don't get it. Like this:
>>> >
>>> > if x=0 then do
>>> > x=x+1
>>> > end
>>> >
>>> > Or, more painfully:
>>> >
>>> > select
>>> > when idx="T" then
>>> > do
>>> > countt=countt+1
>>> > end
>>> > when idx="U" then
>>> > do
>>> > countu=countu+1
>>> > end
>>> > when idx="V" then
>>> > do
>>> > countv=countv+1
>>> > end
>>> > when idx="W" then
>>> > do
>>> > countw=countw+1
>>> > end
>>> > otherwise
>>> > do
>>> > countx=countx+1
>>> > end
>>> > end
>>> >
>>> > Why? If it were easier to read, I might sympathize. But it's harder,
>>> not
>>> > easier.
>>> >
>>> > -Original Message-
>>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On
>>> > Behalf Of Paul Gilmartin
>>> > Sent: Saturday, June 6, 2020 14:40
>>> >
>>> > But in Rexx similarly, END is required even for a single-statement DO.
>>> > Good for Rexx. I like strong closure.
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>
>>
>> --
>> Wayne V. Bickerdike
>>
>>
>
> --
> Wayne V. Bickerdike
>
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
CA-IDEAL has SELECT FIRST ACTION AND SELECT EVERY ACTION. That I like.
On Mon, Jun 8, 2020 at 2:59 PM Wayne Bickerdike wrote:
> For brevity, if you don't like DO END.
>
> select
> when idx="T" then countt=countt+1
> when idx="U" then countu=countu+1
> when idx="V" then countv=countv+1
> when idx="W" then countw=countw+1
> otherwise countx=countx+1; end
>
> Could be :
> SELECT( idx)
> when ("T") then countt=countt+1
> when ("U") then countu=countu+1
> when ("V") then countv=countv+1
> when ("W") then countw=countw+1
> otherwise countx=countx+1; end
>
>
>
> On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges wrote:
>
>> No, I wasn't complaining about the SELECT statement, only about using
>> lots of DO/statement/ENDs when there's only a single statement. I would
>> code the same thing like this:
>>
>> select
>> when idx="T" then countt=countt+1
>> when idx="U" then countu=countu+1
>> when idx="V" then countv=countv+1
>> when idx="W" then countw=countw+1
>> otherwise countx=countx+1; end
>>
>> (Of course if that were a real example I would probably have found a way
>> to use a stem variable instead:
>>
>> count.idx=count.idx+1
>>
>> But in this case I was just talking about coding style, as Mr Metz said.)
>>
>> ---
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>
>> /* If a problem has a single neck, it has a simple solution. */
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Lou Losee
>> Sent: Sunday, June 7, 2020 14:38
>>
>> Would you rather code the select as a series of nested if-then-else?
>>
>> --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
>> wrote:
>> > The only language I can think of off-hand that doesn't require some sort
>> > of END to close a DO (I'm sure there are others) is ISPF. But, in REXX
>> at
>> > least, I never use single-statement DOs. I see them all the time, and I
>> > don't get it. Like this:
>> >
>> > if x=0 then do
>> > x=x+1
>> > end
>> >
>> > Or, more painfully:
>> >
>> > select
>> > when idx="T" then
>> > do
>> > countt=countt+1
>> > end
>> > when idx="U" then
>> > do
>> > countu=countu+1
>> > end
>> > when idx="V" then
>> > do
>> > countv=countv+1
>> > end
>> > when idx="W" then
>> > do
>> > countw=countw+1
>> > end
>> > otherwise
>> > do
>> > countx=countx+1
>> > end
>> > end
>> >
>> > Why? If it were easier to read, I might sympathize. But it's harder,
>> not
>> > easier.
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On
>> > Behalf Of Paul Gilmartin
>> > Sent: Saturday, June 6, 2020 14:40
>> >
>> > But in Rexx similarly, END is required even for a single-statement DO.
>> > Good for Rexx. I like strong closure.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> Wayne V. Bickerdike
>
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
For brevity, if you don't like DO END.
select
when idx="T" then countt=countt+1
when idx="U" then countu=countu+1
when idx="V" then countv=countv+1
when idx="W" then countw=countw+1
otherwise countx=countx+1; end
Could be :
SELECT( idx)
when ("T") then countt=countt+1
when ("U") then countu=countu+1
when ("V") then countv=countv+1
when ("W") then countw=countw+1
otherwise countx=countx+1; end
On Mon, Jun 8, 2020 at 2:08 PM Bob Bridges wrote:
> No, I wasn't complaining about the SELECT statement, only about using lots
> of DO/statement/ENDs when there's only a single statement. I would code
> the same thing like this:
>
> select
> when idx="T" then countt=countt+1
> when idx="U" then countu=countu+1
> when idx="V" then countv=countv+1
> when idx="W" then countw=countw+1
> otherwise countx=countx+1; end
>
> (Of course if that were a real example I would probably have found a way
> to use a stem variable instead:
>
> count.idx=count.idx+1
>
> But in this case I was just talking about coding style, as Mr Metz said.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* If a problem has a single neck, it has a simple solution. */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lou Losee
> Sent: Sunday, June 7, 2020 14:38
>
> Would you rather code the select as a series of nested if-then-else?
>
> --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges
> wrote:
> > The only language I can think of off-hand that doesn't require some sort
> > of END to close a DO (I'm sure there are others) is ISPF. But, in REXX
> at
> > least, I never use single-statement DOs. I see them all the time, and I
> > don't get it. Like this:
> >
> > if x=0 then do
> > x=x+1
> > end
> >
> > Or, more painfully:
> >
> > select
> > when idx="T" then
> > do
> > countt=countt+1
> > end
> > when idx="U" then
> > do
> > countu=countu+1
> > end
> > when idx="V" then
> > do
> > countv=countv+1
> > end
> > when idx="W" then
> > do
> > countw=countw+1
> > end
> > otherwise
> > do
> > countx=countx+1
> > end
> > end
> >
> > Why? If it were easier to read, I might sympathize. But it's harder,
> not
> > easier.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Paul Gilmartin
> > Sent: Saturday, June 6, 2020 14:40
> >
> > But in Rexx similarly, END is required even for a single-statement DO.
> > Good for Rexx. I like strong closure.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
No, I wasn't complaining about the SELECT statement, only about using lots of DO/statement/ENDs when there's only a single statement. I would code the same thing like this: select when idx="T" then countt=countt+1 when idx="U" then countu=countu+1 when idx="V" then countv=countv+1 when idx="W" then countw=countw+1 otherwise countx=countx+1; end (Of course if that were a real example I would probably have found a way to use a stem variable instead: count.idx=count.idx+1 But in this case I was just talking about coding style, as Mr Metz said.) --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* If a problem has a single neck, it has a simple solution. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lou Losee Sent: Sunday, June 7, 2020 14:38 Would you rather code the select as a series of nested if-then-else? --- On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges wrote: > The only language I can think of off-hand that doesn't require some sort > of END to close a DO (I'm sure there are others) is ISPF. But, in REXX at > least, I never use single-statement DOs. I see them all the time, and I > don't get it. Like this: > > if x=0 then do > x=x+1 > end > > Or, more painfully: > > select > when idx="T" then > do > countt=countt+1 > end > when idx="U" then > do > countu=countu+1 > end > when idx="V" then > do > countv=countv+1 > end > when idx="W" then > do > countw=countw+1 > end > otherwise > do > countx=countx+1 > end > end > > Why? If it were easier to read, I might sympathize. But it's harder, not > easier. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Saturday, June 6, 2020 14:40 > > But in Rexx similarly, END is required even for a single-statement DO. > Good for Rexx. I like strong closure. -- 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
It does, but FOO could be a variable symbol in which case it woud be
evaluated ADDRESS ({variable symbol})
Like:
FOO ="TSO"
ADDRESS (FOO) =>> sets host environment to "TSO"
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Phil Smith III
Sent: Saturday, June 6, 2020 23:44
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Gratuitous EXECIO Documentation
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
--
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
Wrong again. As with any other expression, quotes are for string literals, not variables, and it is legitimate to use variables either by themselves or as part of a more complex expression, e.g., address value 'FOO'bar -- 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: Sunday, June 7, 2020 8:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Gratuitous EXECIO Documentation Gil: Yeah, of course in "address value" you'd need quotes. I see that as different from what you asserted, though I sure can't defend that! -- 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
Gil: Yeah, of course in "address value" you'd need quotes. I see that as different from what you asserted, though I sure can't defend that! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
Or DTL. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@copper.net] Sent: Sunday, June 7, 2020 4:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question Don’t forget the SKELETON language. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Jun 7, 2020, at 4:30 PM, Seymour J Metz wrote: > > 1. ISPF is not a language.If you are referring to panel definition > statements, > ELSE uses indentation to control scope. Python does the same thing. I > don't like it, but it is what it is. > > 2. SO/END blocks containing only a single statement are useful if you > may be adding code in the future. It's a stylistic issue about which > you will never achieve consensus. > > > -- > 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: Sunday, June 7, 2020 2:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL Question > > The only language I can think of off-hand that doesn't require some sort of > END to close a DO (I'm sure there are others) is ISPF. But, in REXX at > least, I never use single-statement DOs. I see them all the time, and I > don't get it. Like this: > > if x=0 then do >x=x+1 > end > > Or, more painfully: > > select >when idx="T" then > do >countt=countt+1 > end >when idx="U" then > do >countu=countu+1 -- 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
Don’t forget the SKELETON language. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Jun 7, 2020, at 4:30 PM, Seymour J Metz wrote: > > 1. ISPF is not a language.If you are referring to panel definition > statements, > ELSE uses indentation to control scope. Python does the same thing. I > don't like it, but it is what it is. > > 2. SO/END blocks containing only a single statement are useful if you > may be adding code in the future. It's a stylistic issue about which > you will never achieve consensus. > > > -- > 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: Sunday, June 7, 2020 2:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL Question > > The only language I can think of off-hand that doesn't require some sort of > END to close a DO (I'm sure there are others) is ISPF. But, in REXX at > least, I never use single-statement DOs. I see them all the time, and I > don't get it. Like this: > > if x=0 then do >x=x+1 > end > > Or, more painfully: > > select >when idx="T" then > do >countt=countt+1 > end >when idx="U" then > do >countu=countu+1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
Well, if I were writing COBOL today I would eschew PERFORm foo THRU bar in favor of more structured constructs. You have a similar problem with assembler; code optimized for one model may run poorly on another. The NASPA magazine was Technical Support. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Clark Morris [cfmt...@uniserve.com] Sent: Sunday, June 7, 2020 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Goto Statements (was: COBOL Question) [Default] On 7 Jun 2020 03:33:44 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >I generally get by with control structures like case (select/when), >if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the >cleanest way to do something; I refuse to avoid a useful construct just >because it is not politically correct. In the case of COBOL, I consider the >out of line PERFORM to be far more dangerous. I have a similar issue with >REXX; it does not have lexical scope, and you can fall into a procedure. With any supported IBM COBOL, it can and should be written such that there are no fall throughs and without PERFORM ... THRU ... statements. By use of only PERFORM statements (without THRU) code movement is possible such that PERFORMED paragraphs can be moved inline which can be important in this era of cache and instruction look ahead. In order to maintain the ability for the compiler to do code optimizing I have coded PERFORMs of catastrophe paragraphs which have terminating STOP RUN, GOBACK or calls to an ABEND routine. Code which was optimal under OS/VS COBOL (1974 standard) became poor under VS COBOL 2.4 and later (1985 standard and later). As someone who coded programs ALTER xxx TO yyy instead of PERFORM to save 16 bytes in order to fit into a 16K DOS 360 background partition or 6K DOS 360 foreground partition, this represents a drastic change in philosophy. In the late 1980s I drastically rewrote a program to substantially reduce both CPU and run time in the late 1980s or early 1990s in the OS/VS COBOL available to me. ALL PERFORM xxx VARYING statements were eliminated and PERFORM xxx THRU xxx-EXIT statements were used where GO TO xxx and GO TO xxx-EXIT statements were used to do the iteration of the loop and the exiting of the loop. I submitted an article to the NAASPA magazine (the name escapes me at the moment) regarding all of the optimizations which was published. I did put in the caveat that the VS COBOL II compiler would make some of those optimizations counter-productive. Indeed to accomplish the same goal the rewrite would have had to have been substantially different for VS COBOL 2.4 and later. Clark Morris -- 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
1. ISPF is not a language.If you are referring to panel definition statements, ELSE uses indentation to control scope. Python does the same thing. I don't like it, but it is what it is. 2. SO/END blocks containing only a single statement are useful if you may be adding code in the future. It's a stylistic issue about which you will never achieve consensus. -- 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: Sunday, June 7, 2020 2:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question The only language I can think of off-hand that doesn't require some sort of END to close a DO (I'm sure there are others) is ISPF. But, in REXX at least, I never use single-statement DOs. I see them all the time, and I don't get it. Like this: if x=0 then do x=x+1 end Or, more painfully: select when idx="T" then do countt=countt+1 end when idx="U" then do countu=countu+1 end when idx="V" then do countv=countv+1 end when idx="W" then do countw=countw+1 end otherwise do countx=countx+1 end end Why? If it were easier to read, I might sympathize. But it's harder, not easier. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* It's a good thing Lincoln wrote the Gettysburg Address the year that he did, or else that "fourscore and seven years" part would have just been plain wrong. -Paul Paternoster */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, June 6, 2020 14:40 But in Rexx similarly, END is required even for a single-statement DO. Good for Rexx. I like strong closure. >--- 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 -- 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
There's no XOR mentioned there, confused or otherwise. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Sunday, June 7, 2020 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question You could not be more correct. You wrote NOT and I translated that in my head to the exclamation point. (My C is showing.) And yes, absolutely, as you say, the problem is the merging of logical not and XOR operations. The link below says "NOT -- Called Logical NOT Operator. Used to reverse the logical state of its operand. If a condition is true, then Logical NOT operator will make false." But as you saw, that is not so. If foo is X'01' then NOT foo is X'FE' and both are true. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Sunday, June 7, 2020 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question You must have misread me somehow, Mr Mills; I didn't say there's a '!' operator in VBA. You spoke of a '!' operator in C, but I've never heard of that operator in VBA; all I meant is that maybe I should look in VBA for another Boolean operator that is different from NOT as you say '!' is different from '~' in C. -- 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
You could not be more correct. You wrote NOT and I translated that in my head to the exclamation point. (My C is showing.) And yes, absolutely, as you say, the problem is the merging of logical not and XOR operations. The link below says "NOT -- Called Logical NOT Operator. Used to reverse the logical state of its operand. If a condition is true, then Logical NOT operator will make false." But as you saw, that is not so. If foo is X'01' then NOT foo is X'FE' and both are true. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Sunday, June 7, 2020 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Question You must have misread me somehow, Mr Mills; I didn't say there's a '!' operator in VBA. You spoke of a '!' operator in C, but I've never heard of that operator in VBA; all I meant is that maybe I should look in VBA for another Boolean operator that is different from NOT as you say '!' is different from '~' in C. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
You must have misread me somehow, Mr Mills; I didn't say there's a '!' operator in VBA. You spoke of a '!' operator in C, but I've never heard of that operator in VBA; all I meant is that maybe I should look in VBA for another Boolean operator that is different from NOT as you say '!' is different from '~' in C. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* That sort of wit which employs itself insolently in criticizing and censuring the words and sentiments of others in conversation is absolute folly; for it answers none of the ends of conversation. He who uses it neither improves others, is improved himself, nor pleases anyone. -Poor Richard’s Almanack, 1756 */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, June 6, 2020 15:34 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 -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 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. -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
Re: COBOL Question
Bob, Would you rather code the select as a series of nested if-then-else? Lou On Sun, Jun 7, 2020 at 1:35 PM Bob Bridges wrote: > The only language I can think of off-hand that doesn't require some sort > of END to close a DO (I'm sure there are others) is ISPF. But, in REXX at > least, I never use single-statement DOs. I see them all the time, and I > don't get it. Like this: > > if x=0 then do > x=x+1 > end > > Or, more painfully: > > select > when idx="T" then > do > countt=countt+1 > end > when idx="U" then > do > countu=countu+1 > end > when idx="V" then > do > countv=countv+1 > end > when idx="W" then > do > countw=countw+1 > end > otherwise > do > countx=countx+1 > end > end > > Why? If it were easier to read, I might sympathize. But it's harder, not > easier. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* It's a good thing Lincoln wrote the Gettysburg Address the year that he > did, or else that "fourscore and seven years" part would have just been > plain wrong. -Paul Paternoster */ > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Saturday, June 6, 2020 14:40 > > But in Rexx similarly, END is required even for a single-statement DO. > Good for Rexx. I like strong closure. > > >--- 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Please excuse spelling - sent from my mobile. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
The only language I can think of off-hand that doesn't require some sort of END to close a DO (I'm sure there are others) is ISPF. But, in REXX at least, I never use single-statement DOs. I see them all the time, and I don't get it. Like this: if x=0 then do x=x+1 end Or, more painfully: select when idx="T" then do countt=countt+1 end when idx="U" then do countu=countu+1 end when idx="V" then do countv=countv+1 end when idx="W" then do countw=countw+1 end otherwise do countx=countx+1 end end Why? If it were easier to read, I might sympathize. But it's harder, not easier. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* It's a good thing Lincoln wrote the Gettysburg Address the year that he did, or else that "fourscore and seven years" part would have just been plain wrong. -Paul Paternoster */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, June 6, 2020 14:40 But in Rexx similarly, END is required even for a single-statement DO. Good for Rexx. I like strong closure. >--- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
[Default] On 7 Jun 2020 03:33:44 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >I generally get by with control structures like case (select/when), >if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the >cleanest way to do something; I refuse to avoid a useful construct just >because it is not politically correct. In the case of COBOL, I consider the >out of line PERFORM to be far more dangerous. I have a similar issue with >REXX; it does not have lexical scope, and you can fall into a procedure. With any supported IBM COBOL, it can and should be written such that there are no fall throughs and without PERFORM ... THRU ... statements. By use of only PERFORM statements (without THRU) code movement is possible such that PERFORMED paragraphs can be moved inline which can be important in this era of cache and instruction look ahead. In order to maintain the ability for the compiler to do code optimizing I have coded PERFORMs of catastrophe paragraphs which have terminating STOP RUN, GOBACK or calls to an ABEND routine. Code which was optimal under OS/VS COBOL (1974 standard) became poor under VS COBOL 2.4 and later (1985 standard and later). As someone who coded programs ALTER xxx TO yyy instead of PERFORM to save 16 bytes in order to fit into a 16K DOS 360 background partition or 6K DOS 360 foreground partition, this represents a drastic change in philosophy. In the late 1980s I drastically rewrote a program to substantially reduce both CPU and run time in the late 1980s or early 1990s in the OS/VS COBOL available to me. ALL PERFORM xxx VARYING statements were eliminated and PERFORM xxx THRU xxx-EXIT statements were used where GO TO xxx and GO TO xxx-EXIT statements were used to do the iteration of the loop and the exiting of the loop. I submitted an article to the NAASPA magazine (the name escapes me at the moment) regarding all of the optimizations which was published. I did put in the caveat that the VS COBOL II compiler would make some of those optimizations counter-productive. Indeed to accomplish the same goal the rewrite would have had to have been substantially different for VS COBOL 2.4 and later. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements (was: COBOL Question)
Ah, but SIGNAL does clean up resources., Not always the appropriate resources, but resources. do i=1 to 100 foo SIGNAL bar baz bar: j=1 end That's part of "it does not have lexical scope," -- 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: Sunday, June 7, 2020 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Goto Statements (was: COBOL Question) On Sun, 7 Jun 2020 10:33:34 +, Seymour J Metz wrote: >I generally get by with control structures like case (select/when), >if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the >cleanest way to do something; I refuse to avoid a useful construct just >because it is not politically correct. In the case of COBOL, > Alas, Rexx lacks GOTO and SIGNAL fails to clean up resources, largely a consequence of lacking lexical scope. >I consider the out of line PERFORM to be far more dangerous. I have a similar >issue with REXX; it does not have lexical scope, and you can fall into a >procedure. > A noteworthy 1976 paper (behind a paywall): Software malpractice — a distasteful experience† https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 ... describes the pitfall set by a (too) clever programmer's relying on optimization by falling into procedures. † In the day, I read it free in the University library. -- 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: Goto Statements (was: COBOL Question)
On Sun, 7 Jun 2020 10:33:34 +, Seymour J Metz wrote: >I generally get by with control structures like case (select/when), >if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the >cleanest way to do something; I refuse to avoid a useful construct just >because it is not politically correct. In the case of COBOL, > Alas, Rexx lacks GOTO and SIGNAL fails to clean up resources, largely a consequence of lacking lexical scope. >I consider the out of line PERFORM to be far more dangerous. I have a similar >issue with REXX; it does not have lexical scope, and you can fall into a >procedure. > A noteworthy 1976 paper (behind a paywall): Software malpractice — a distasteful experience† https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 ... describes the pitfall set by a (too) clever programmer's relying on optimization by falling into procedures. † In the day, I read it free in the University library. -- 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
If you really believe this nonsense then you have never programmed systems level code which requires cleanup of system resources such as locks. In 2020 we should not be having this conversation any more - it's bogus! Nobody emulates structured programming constructs such as loops using goto anymore. It's used to exit a routine and cleanup resources and younger programmers don't have the silly bias that seems to stick around here! On 2020-06-07 1:53 AM, 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 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
I've posted this before many times before! The conversation has got boring now - yawn! I would challenge anybody to refactor this code without goto's. https://github.com/eclipse/omr/blob/e9b85117d18c369108a9ddb790023103c35b4379/thread/common/omrthread.c#L246 On 2020-06-07 1:53 AM, 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 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: zSHOP order too large to download
You are welcome Bill. I agree they should have the option to just download the installation file for CAE server if you want to install it on distributed. Like for Db2 Query Workload Tuner. It can be ordered on Shop z and you get the link to download the file to PC. 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: Goto Statements (was: COBOL Question)
I generally get by with control structures like case (select/when), if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the cleanest way to do something; I refuse to avoid a useful construct just because it is not politically correct. In the case of COBOL, I consider the out of line PERFORM to be far more dangerous. I have a similar issue with REXX; it does not have lexical scope, and you can fall into a procedure. -- 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: Sunday, June 7, 2020 6:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Goto Statements (was: COBOL Question) Thank you very much for the link to that article; I did not know that before. When I started to work on the Stanford Pascal compiler in 2011, it had about 20 to 30 labels and Gotos (6000 lines of source code). http://secure-web.cisco.com/1pX2kW19qrUp9yyoP4cfhRRs2ehNXyOiR8ZzrLZPfjVUIuBM5B0cu5ExeRn-gVhTqtsFmQqRCeX1kWt8GVLJyqBetd-We06QY6gkbVWv3QC1o-NEVdaqRH6t2DH39gZvw0-3Jihs-F5wMJmmJUpgr5TRe-YayUTWUwX8Ei1zyTXm3YUVjbqPmkwLafqSKfBfd7dffvaXZkRLue6QQlmtfeaQ2d1GitnaBXNkNX9uaLzv2H5RvX0D-L61XkawFX-Eek9LsXAx0ycMXFpGNImgy5z9eMSon1P95x3V9wTqj1Pw6li8X2jwgFaZf1K_OkHNP4J_e51OIlCSPmnr61YIXw_-N0KKbOmQDuxiLobG46E7__kPTDeUP6oVHTPSdfvi8bQ6hhgm0MAe1y0jWiSnvezjXncFaNcNhThLUdm5bv1vkXAAvMM89ntcCkUAiNb44/http%3A%2F%2Fbernd-oppolzer.de%2Fjob9.htm In the meantime, I omitted most of them, but this was only possible, after I added CONTINUE and BREAK (for all three types of loops) and RETURN (to do early returns from procedures), which are not present in Standard Pascal. http://secure-web.cisco.com/1Km_bU1ZhlXrKXvTgabvFbHyaYXnzrcmk29Sl8AEjRAtYm4DFVcOJwHT6UIto3Tv4KffE0e3UQGWhHuGzdbAd-m2WCw4XJOZavBvuPWSV9525c1v_HDcAvHJIHIA6np8gqeDNP9bJFESQpyaSyQivd7HdNVnZTzfPKzWC2Bcv82b4oS_eTA6_H7fYXeBcHDP76oBOMOyB-kYDewa6mzanpF2bWJDRsXBYrQsW5qSE7Fk3sggZqGbEAYcJlLHNrF8IZSg3UmLFP_nCC5K9ftu_qXhfj-mM8dDUC52sS0YD1lON2dpIK7GgMzQ9WudkLKf-Z43IOBnRltKuxHzXUiTetyx7siAqIytTDFJ5C-29z1pojvBmeRIHtb0-K74gMS83Q9i2y7Sj7nPydr_ou22wlo62sHVFJ4yS9RU4NANqxMEEbsrJuWL_ZM1qQjZPEuRa/http%3A%2F%2Fbernd-oppolzer.de%2Fjob9i004.htm The compiler now has 22000 lines of code (much more function than the 2011 version), but much less gotos. Back to Cobol: IMO, many of the observations of the 1960s are still valid for today's modern COBOL: if you use (for example) inline PERFORM and all the possibilities to do structured programming in COBOL and try to reduce the use of Gotos to an absolute minimum (for example: leave the program in case of catastrophic errors), then your programs will be easier to read and maintain; at least that's what I am experiencing. BTW: I added so much function to the New Stanford Pascal compiler in the years since 2011 (and I ported it to Windows and Linux etc.), that I recently was able to use it to write a COBOL source code formatter using this compiler, which is very helpful when doing maintenance work on (large old) COBOL programs. I am thinking about enhancing this source code formatter (which does COBOL parsing to some degree) to get meta information out of the COBOL source code, for example file usage or to throw warnings about strange logic constructs - much the same way as my PL/1 tool from 2007 did it (this was written in C). If someone is interested, I will share the Pascal source of the COBOL source code formatter ... contact me offlline. But you will need the New Stanford Compiler to use it (available from GitHub and from the WebSite above). Kind regards Bernd Am 07.06.2020 um 02:26 schrieb Seymour J Metz: > https://secure-web.cisco.com/1Ly5ugowEV6ot4gbUyw07wld8pVo5RD7yYuLNdHEOf-3il63S7RNh5Uhz3z3qoKCTFZWHjCdAd9NWtRND2NeuvtUodK8xswKDI8qCbark0s6SJ5nXm7-R2ftSd_nYVROosKE8L-PHT1wEeBiCnX_EoOBsN2JcXxfXFq_MNEEfAfs5I_hk6jaQfOdPfRC6_TLwm_g1xb0iM3ICYM0c8XPwUqrA4rLqXyfU-rIz4Dp8LJp_b5--XwmHIh5kl8_oQTbAGn4lksD2k0ehk9-HzYrQGjendQbb39rTwPrLGGng14e9Sx46KhwhyhYMz-stXs2kjIore_VyCD4j1FFWmlNBTVSYtOHijv6gCOsLEv9maQADfq2W7D_-_-XYWu4mAPz3Wu3h15kosqbDyPRuDf-xcCtA_dJ3oB55h5QETpelVe2_CuvHD-y2_nREcy5rpp4t/https%3A%2F%2Fwww.cs.sjsu.edu%2F%7Emak%2FCS185C%2FKnuthStructuredProgrammingGoTo.pdf > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 -- 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
Goto Statements (was: COBOL Question)
Thank you very much for the link to that article; I did not know that before. When I started to work on the Stanford Pascal compiler in 2011, it had about 20 to 30 labels and Gotos (6000 lines of source code). http://bernd-oppolzer.de/job9.htm In the meantime, I omitted most of them, but this was only possible, after I added CONTINUE and BREAK (for all three types of loops) and RETURN (to do early returns from procedures), which are not present in Standard Pascal. http://bernd-oppolzer.de/job9i004.htm The compiler now has 22000 lines of code (much more function than the 2011 version), but much less gotos. Back to Cobol: IMO, many of the observations of the 1960s are still valid for today's modern COBOL: if you use (for example) inline PERFORM and all the possibilities to do structured programming in COBOL and try to reduce the use of Gotos to an absolute minimum (for example: leave the program in case of catastrophic errors), then your programs will be easier to read and maintain; at least that's what I am experiencing. BTW: I added so much function to the New Stanford Pascal compiler in the years since 2011 (and I ported it to Windows and Linux etc.), that I recently was able to use it to write a COBOL source code formatter using this compiler, which is very helpful when doing maintenance work on (large old) COBOL programs. I am thinking about enhancing this source code formatter (which does COBOL parsing to some degree) to get meta information out of the COBOL source code, for example file usage or to throw warnings about strange logic constructs - much the same way as my PL/1 tool from 2007 did it (this was written in C). If someone is interested, I will share the Pascal source of the COBOL source code formatter ... contact me offlline. But you will need the New Stanford Compiler to use it (available from GitHub and from the WebSite above). Kind regards Bernd Am 07.06.2020 um 02:26 schrieb Seymour J Metz: https://www.cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
