Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

>  E ...:
> //STEP  EXEC  PGM=IKJEFT01 ...

totally irrelevant.

> (But am I overlooking your "normally"?)

No, but you're overlooking "TSO commands" and "but use service routines"; it's 
the service routines for GETLINE, PUTGET and PUTLINE that do GET from SYSTSIN 
and PUT to SYSTSPRT, never the TSO command. See z/OS TSO/E Programming Service 
Version 2 Release 3, SA32-0973-30, "Using the TSO/E I/O service routines for 
terminal I/O" on p. 189.



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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 18, 2019 3:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Fri, 18 Jan 2019 19:20:43 +, Seymour J Metz wrote:
>
>Yes. Specifically,  WITH input_redir [output_redir] [error_redir] .
>
>>  Pointless for CMS or TSO since the concept of standard input/standard 
>> output is alien to each.
>
>Perhaps pointless for CMS, but the TSO stack has all of the necessary 
>facilities. TSO commands do not normally BSAM/QSAM or TGET/TPUT for line mode 
>terminal I/O, but use service routines.
>
E ...:
//STEP  EXEC  PGM=IKJEFT01 ...

(But am I overlooking your "normally"?)

The thing I find brilliant in UNIX design is (accidentally) implied by the
first three letters: a oneness.  Things work the same in foreground and batch.
There's no TGET versus LINEIN versus SYSTSIN versus SYSTERM versus SYSIN versus 
...
There were few enough designers that that they could reach a consensus.

Maybe it's Brooks's fault for underrating timesharing.

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

Gil,

I agree , I work VM for yrs then switched to MVS. I missed CMS and xedit,
sMSG.
I like Unix also, i.e.; Linux . A lot of flexibility and power

Scott

On Fri, Jan 18, 2019 at 3:14 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 18 Jan 2019 19:20:43 +, Seymour J Metz wrote:
> >
> >Yes. Specifically,  WITH input_redir [output_redir] [error_redir] .
> >
> >>  Pointless for CMS or TSO since the concept of standard input/standard
> output is alien to each.
> >
> >Perhaps pointless for CMS, but the TSO stack has all of the necessary
> facilities. TSO commands do not normally BSAM/QSAM or TGET/TPUT for line
> mode terminal I/O, but use service routines.
> >
> E ...:
> //STEP  EXEC  PGM=IKJEFT01 ...
>
> (But am I overlooking your "normally"?)
>
> The thing I find brilliant in UNIX design is (accidentally) implied by the
> first three letters: a oneness.  Things work the same in foreground and
> batch.
> There's no TGET versus LINEIN versus SYSTSIN versus SYSTERM versus SYSIN
> versus ...
> There were few enough designers that that they could reach a consensus.
>
> Maybe it's Brooks's fault for underrating timesharing.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Fri, 18 Jan 2019 19:20:43 +, Seymour J Metz wrote:
>
>Yes. Specifically,  WITH input_redir [output_redir] [error_redir] .
>
>>  Pointless for CMS or TSO since the concept of standard input/standard 
>> output is alien to each.
>
>Perhaps pointless for CMS, but the TSO stack has all of the necessary 
>facilities. TSO commands do not normally BSAM/QSAM or TGET/TPUT for line mode 
>terminal I/O, but use service routines.
> 
E ...:
//STEP  EXEC  PGM=IKJEFT01 ...

(But am I overlooking your "normally"?)

The thing I find brilliant in UNIX design is (accidentally) implied by the
first three letters: a oneness.  Things work the same in foreground and batch.
There's no TGET versus LINEIN versus SYSTSIN versus SYSTERM versus SYSIN versus 
...
There were few enough designers that that they could reach a consensus.

Maybe it's Brooks's fault for underrating timesharing.

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

> Are you thinking of constructs such as:
'ADDRESS' taken_constant [expression]  [ 'WITH' connection]]

Yes. Specifically,  WITH input_redir [output_redir] [error_redir] .

>  Pointless for CMS or TSO since the concept of standard input/standard output 
> is alien to each.

Perhaps pointless for CMS, but the TSO stack has all of the necessary 
facilities. TSO commands do not normally BSAM/QSAM or TGET/TPUT for line mode 
terminal I/O, but use service routines.

 > Perhaps from Amiga?  OS/2?  AIX?  SAA?

Certainly not from OS/2 or SAA, since they don't have that facility. OS/2 uses 
RXQUEUE and pipes for capturing command output, e.g.

  'DIR FOO.* | RXQUEUE'

Will put the file list in the stem associated with the active queue.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, January 17, 2019 11:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Tue, 15 Jan 2019 22:57:28 +, Seymour J Metz wrote:

>IBM never upgraded TSO/E for the REXX standard. I see nothing in z/OS TSO/E 
>REXX Reference Version2 Release3, SA32-0972-30 about built-in variables TRUE 
>and FALSE.
>
>More important, IMHO, is that IBM did not add the ANSI extensions to ADDRESS.
>>
>>http://secure-web.cisco.com/1ps8-jjITHM7k061aRsyP3fh7U59UdoVF9jCt1fPQ8_dweSsiSJqCd8sbAmQMpHeP3JSkqDOolCGSWsfeCEO_Y-MZtYSJCA8dwNbQ15TUjUYsi1rc1iV7yP9xIPXccg2LA_VLjlsHYkPODSd0-c6Fefjs9pbMZZLU-T0nl9Dz8JKqFLOKZtn_6VAzD47F1DpreW1rg-731MHOa3jVSYxGeJlPPc_soNCExHxZbsiYaSogAF0uLxjycVhm_pKwe9Thkf7Aa79emOg4o73k3NX3Ira_sSYTXGLXLIUQVV9x1osIrhh6TgQ2ERsW7idqwCptNLiWWQtJc1zzj19yytmcPPtKJJ_ThzeGnMnQWV5q2igUeNN-8Z6UfPs4GNY-wMzhWN3B515CJeSyXCzn5Qo63CoruahQy_LtecEgKEAg0NgDqy_gHCYk6HepOHLcNpVz/http%3A%2F%2Fwww.rexxla.org%2Frexxlang%2Fstandards%2F
>> has ordering information and links. At $125, I'd just go for the draft, but 
>>it's probably worth it if you're trying to implement ANSI-compliant Rexx 
>>(sic).
>>
>(direct link: 
>http://secure-web.cisco.com/18067JUtGA2FTOLLVQ2xoU5reLnjtcqfCMB4Zd392u73EzngVkpfI-8Yxc0gtDZ_GYtMieVO3mvl2qjqHzRmoFpHNClDcp-bVi5cNaZKT3RwfDoanek5Oj-rR8wVkkkTZ2zmoWlDcGqcgw3ivEwRHWnEvR5He5vJvUBdOUCkLvup6aH2yWkJcJfyBym-3kEMDW6LKLhXJvY0qsGkVkJoxb-G9sjieiFKU_An13kqMX25KGU9PTnfuB9xo1XvwLXNhgBr4MlmccL5C7J4hlAd8ROJpTOqRzYLtTGemhDD0PVAEYjuEETS3Q3S7zTq4BFVO7WQWtQ-0PDRhFa9FBTkPC-A3gJov3SMVfyKt9TwazzqKAI3lNoqgpLRIuvNcZKZoMisvDt4evC1QOgPoh2HCqiRKsoMECrLFGOm7sM3Ec-Jd0ReT-mUcbk3LNJ-PQi5c/http%3A%2F%2Fwww.rexxla.org%2Frexxlang%2Fstandards%2Fj18pub.pdf
>)
Are you thinking of constructs such as:
'ADDRESS' taken_constant [expression]  [ 'WITH' connection]]

Intriguing.  Seems to be specifying redirection.  Pointless for CMS or TSO
since the concept of standard input/standard output is alien to each.  Relevant,
of course, to OMVS, but OMVS was unable to exert much influence on the
design of z/OS Rexx.

I wonder how this made its way into the Standard since standards tend to
be descriptive and rarely innovate extensions except to resolve ambiguities
or inconsistencies.

Perhaps from Amiga?  OS/2?  AIX?  SAA?

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Tue, 15 Jan 2019 22:57:28 +, Seymour J Metz wrote:

>IBM never upgraded TSO/E for the REXX standard. I see nothing in z/OS TSO/E 
>REXX Reference Version2 Release3, SA32-0972-30 about built-in variables TRUE 
>and FALSE.
>
>More important, IMHO, is that IBM did not add the ANSI extensions to ADDRESS.
>>
>>http://www.rexxla.org/rexxlang/standards/ has ordering information and links. 
>>At $125, I'd just go for the draft, but it's probably worth it if you're 
>>trying to implement ANSI-compliant Rexx (sic).
>>
>(direct link: http://www.rexxla.org/rexxlang/standards/j18pub.pdf
>)
Are you thinking of constructs such as:
'ADDRESS' taken_constant [expression]  [ 'WITH' connection]]

Intriguing.  Seems to be specifying redirection.  Pointless for CMS or TSO
since the concept of standard input/standard output is alien to each.  Relevant,
of course, to OMVS, but OMVS was unable to exert much influence on the
design of z/OS Rexx.

I wonder how this made its way into the Standard since standards tend to
be descriptive and rarely innovate extensions except to resolve ambiguities
or inconsistencies.

Perhaps from Amiga?  OS/2?  AIX?  SAA?

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Wed, 16 Jan 2019 20:51:32 +, Seymour J Metz wrote:

>I don't recall ever seeing built-in variables TRUUE and FALSE, but I haven't 
>read the standard.
>
>http://www.rexxla.org/rexxlang/standards/ has ordering information and links. 
>At $125, I'd just go for the draft, but it's probably worth it if you're 
>trying to implement ANSI-compliant Rexx (sic).
>
(direct link: http://www.rexxla.org/rexxlang/standards/j18pub.pdf
)
"... This draft is functionally equivalent to the published Standard. ..."
And 100% cheaper.  Weird.  But, that's how it is:
https://www.explainxkcd.com/wiki/index.php/2085:_arXiv
https://www.explainxkcd.com/wiki/index.php/2025:_Peer_Review

I see no mention of TRUE, and only an incidental reference to FALSE, which does 
not
seem to be a built-in variable.

Thanks,
gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

I don't recall ever seeing built-in variables TRUUE and FALSE, but I haven't 
read the standard.

http://www.rexxla.org/rexxlang/standards/ has ordering information and links. 
At $125, I'd just go for the draft, but it's probably worth it if you're trying 
to implement ANSI-compliant Rexx (sic).


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, January 15, 2019 6:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Tue, 15 Jan 2019 22:57:28 +, Seymour J Metz wrote:

>IBM never upgraded TSO/E for the REXX standard. I see nothing in z/OS TSO/E 
>REXX Reference Version2 Release3, SA32-0972-30 about built-in variables TRUE 
>and FALSE.
>
Are these variables (like RC)?  Can the programmer assign to them?
(Consider compatibility.)

>More important, IMHO, is that IBM did not add the ANSI extensions to ADDRESS.
>
Where can I get the ANSI standard?  Would I have to pay for it?  (Years ago I 
had
a harcopy of a draft.  Semantics were explained in pseudo-Rexx.)

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Edward Finnell]

Sounds like a text Book for an assembler course. Guess my first assembly class 
was from:
'Machine, assembly, and systems programming for the IBM360' by William Payne.In 
a message dated 1/15/2019 8:09:23 PM Central Standard Time, 
000433f07816-dmarc-requ...@listserv.ua.edu writes:
Sounds like a Users Guide to

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Tue, 15 Jan 2019 21:46:03 +, Seymour J Metz wrote:

>Given the size of PoOps, perhaps an RFE for a separate manual containing well 
>commented examples for all of the complex instructions, including sort.
> 
Sounds like a Users Guide to me.

>
>From: Charles Mills
>Sent: Monday, January 14, 2019 6:48 PM
>
>Sounds like a SHARE presentation to me!

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Sun, 13 Jan 2019 14:06:51 -0800, Ed Jaffe wrote:
>
>> On 13/01/2019 7:06 pm, Tony Thigpen wrote:
>>> I have seen some reports that current C compilers, which understand
>>> the z-hardware pipeline, can actually produce object that is faster
>>> running than an assembler. Mainly because no sane assembler
>>> programmer would produce great pipe-line code because it would be
>>> un-maintanable.
>>>
>> It's well established that that's been true for a well over a decade
>> now. Not just C but all compilers including COBOL which got a new
>> optimizer a few releases back.
>
>Far, far less true now than it used to be.
>
>Back in the old days, things ran a lot faster if you interleaved
>unrelated things in an "unfriendly" way. ...

It appears that z machine code is evolving into a pseudo-language, akin to
Pascal P-code or Java byte code, to be translated JIT by hardware/firmware/
millicode.

Z wouldn't be my first choice for such a pseudo-language.  Except for an
enormous body of existing art.

So the need for delivery in source to be optimized by the translator for each
hardware target is shrinking.

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Tue, 15 Jan 2019 22:57:28 +, Seymour J Metz wrote:

>IBM never upgraded TSO/E for the REXX standard. I see nothing in z/OS TSO/E 
>REXX Reference Version2 Release3, SA32-0972-30 about built-in variables TRUE 
>and FALSE.
>
Are these variables (like RC)?  Can the programmer assign to them?
(Consider compatibility.)

>More important, IMHO, is that IBM did not add the ANSI extensions to ADDRESS.
>
Where can I get the ANSI standard?  Would I have to pay for it?  (Years ago I 
had
a harcopy of a draft.  Semantics were explained in pseudo-Rexx.)

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

What is absurd is that you don't understand the difference between popularity 
and quality. The fact that C is low level means that you have to write more 
code to do simple functions. That's not only an efficiency issue, it leads to 
less maintainable code. Give me Ada, ESPOL, PL/I or PL/S any day. 

BTW, problems with C have been discussed here many times over the years. I'm 
not going to rehash old threads.


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


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Saturday, January 12, 2019 2:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On 12/01/2019 4:08 am, Seymour J Metz wrote:
> despite being used frequently for the purpose, it's really not particularly 
> suited for writing operating systems

LOL! That's absurd! C has been ported to just about every architecture
worth mentioning and is well suited to low-level programming. It's also
incredibly
efficient and has a mature and well established tool chain for
debugging, profiling, code correctness etc. What do you consider a good
language for
writing operating systems?

--
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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

IBM never upgraded TSO/E for the REXX standard. I see nothing in z/OS TSO/E 
REXX Reference Version2 Release3, SA32-0972-30 about built-in variables TRUE 
and FALSE.

More important, IMHO, is that IBM did not add the ANSI extensions to ADDRESS.



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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, January 12, 2019 6:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Sat, 12 Jan 2019 22:58:13 +, Rupert Reynolds wrote:

>Fancy code? I remember once wanting to set a flag under certain circs, and
>I considered something like:
>
>/* Rexx */
>TRUE = 1=1
>FALSE = \TRUE
>. . .
>flag = TRUE
>
>I can't remember now whether I used it, or hated it.
>
More concisely:
TRUE  = 1
FALSE = 0

These are in he Rexx Standard; you may rely on them.  Nonetheless, you
may choose to assign those mnemonics for clarity.

I consider
if flag = TRUE  ...
and
if flag = FALSE ...
and
if A == B then flag = TRUE; else flag = false

... (which I've seen used) execrable expansions of
if flag ...
or
if \flag ...
or
flag = ( A == B )  /* Superfluous parentheses may enhance clarity.  )

)you might as well code:
if flag = TRUE = TRUE = TRUE ...

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

There have been compilers for more than half a century that produced better 
code for complex instructions than most programmers. Further, what is optimal 
for one processor might be slow on another. So best practice for assembler is 
to code for readability and maintainability, document well, and encapsulate any 
tricky optimization of frequently used functions in centralized macros, again 
well documented.

Don't C, COBOL and PL/I all use the same compiler back end these days?


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


From: IBM Mainframe Discussion List  on behalf of 
Tony Thigpen 
Sent: Sunday, January 13, 2019 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

I have seen some reports that current C compilers, which understand the
z-hardware pipeline, can actually produce object that is faster running
than an assembler. Mainly because no sane assembler programmer would
produce great pipe-line code because it would be un-maintanable.

I am an assembler programmer, not a C programmer, so I view the reports
with some speciesism.

Tony Thigpen

scott Ford wrote on 1/12/19 1:33 PM:
> I am speaking in terms of development cycle.
>
> On Sat, Jan 12, 2019 at 1:32 PM scott Ford  wrote:
>
>> David and Zman,
>>
>> Both good points, C is certainly faster than Assembler or maybe PL/S
>>
>> On Sat, Jan 12, 2019 at 2:17 AM David Crayford 
>> wrote:
>>
>>> On 12/01/2019 4:08 am, Seymour J Metz wrote:
>>>> despite being used frequently for the purpose, it's really not
>>> particularly suited for writing operating systems
>>>
>>> LOL! That's absurd! C has been ported to just about every architecture
>>> worth mentioning and is well suited to low-level programming. It's also
>>> incredibly
>>> efficient and has a mature and well established tool chain for
>>> debugging, profiling, code correctness etc. What do you consider a good
>>> language for
>>> writing operating systems?
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>> --
>> Scott Ford
>> IDMWORKS
>> z/OS Development
>>

--
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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

Given the size of PoOps, perhaps an RFE for a separate manual containing well 
commented examples for all of the complex instructions, including sort.


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


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, January 14, 2019 6:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

Sounds like a SHARE presentation to me!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, January 14, 2019 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

Ed,

I also participate in ASSEMBLER-LIST and I don't remember such a discussion.  
Can you pinpoint the approximate time period for that discussion?

My biggest complaint/concern with the vector instructions is the woeful lack of 
any example code showing how to use them for just the kind of functions you 
described.  It's hard to imagine how to use such complex instructions without 
at least some straight-forward examples.

--
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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[David Crayford]

On 15/01/2019 2:55 am, Ed Jaffe wrote:
In my experienced the two optimizations that make the most difference 
are function inlining and loop unrolling. I've taken to defining 
functions in header files to take advantage of both (we don't use IPA).



Yes. both are important. In HLASM one would use a macro to inline a 
function. Manual loop unrolling is something we do only in the 
performance path.


We do just that. We use macros for subroutines and stuff like moving 
data using unrolled MVC instructions. We copied the code from the 
optimizer and it's works great!




I've noticed (depending on compiler options) the C optimizer is 
starting to use vector instructions. They can be a bit hairy even for 
experienced assembler programmers. Best to leave that to a compiler IMO.



Haha! We were part of the z13s ESP and we started using vector 
instructions in our HLASM programs even before the machine was GA! We 
use them for all kinds of primitives including string FIND, bitmap 
manipulation, and other equally-simple, but important, stuff. Those 
"vectorized" routines perform literally orders of magnitude faster 
than their non-vector counterparts! Using them instead of SRST, we 
were able reduce the total CPU used by an (E)JES FIND across a 
multi-million line SPOOLed report by something in the neighborhood of 
23%! (And if you can imagine all of the other work being done -- such 
as calling numerous routines, stack manipulation, reading and 
deblocking of SPOOL records, etc. -- 23% is a HUGE amount!!!)


WOW! 23% is awesome!! That is one hell of a saving and your customers 
will love you for it.


Sadly, I've tried to convince the assembler programmers on 
ASSEMBLER-LIST that vector instructions are useful for such purposes, 
but have been met with a surprising level of skepticism (despite my 
real-world experience and glowing endorsement)  -- primarily due to 
flawed interpretation of what they've read in PoOp rather than just 
trying it out and seeing for themselves. Oh well... LOL 


Well they are daunting instructions! Not as hairy as transaction memory 
but still daunting. I suppose once you learn them it's happy days and 
you can wrap them up in routines.



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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Farley, Peter x23353]

Thanks Ed.  I do remember that first discussion now, I think I got busy at work 
and missed following the other longer one.

Hmm-m-m.  Maybe an RCF for PoOp complaining about the lack of examples for many 
of the more recent complex instructions, including vectors and the several 
newer "PERFORM . . . " instructions, at least the ones that aren't privileged.

I suppose one could use the C compiler with ARCH(Max value for your version of 
the compiler) and OPT(0) and METAL to generate relatively human-understandable 
examples, albeit not the very most efficient ones.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, January 14, 2019 6:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On 1/14/2019 11:18 AM, Farley, Peter x23353 wrote:
> I also participate in ASSEMBLER-LIST and I don't remember such a discussion.  
> Can you pinpoint the approximate time period for that discussion?
>
> My biggest complaint/concern with the vector instructions is the woeful lack 
> of any example code showing how to use them for just the kind of functions 
> you described.  It's hard to imagine how to use such complex instructions 
> without at least some straight-forward examples.


I first mentioned using vector instructions in place of SRST in October 
2016 in a thread entitled, "SRST Performance" with eight posts. The 
group was debating which was faster, TRT or SRST. My comment was:

"SRST is much, much faster than TRT but still orders of magnitude slower 
than the vector instructions."

to which you replied as you have here with a desire for good examples 
from the PoOp owners. No one else seemed interested...

Later, in October of last year in another thread entitled, "Count 
Words?" with nearly 50 posts, I once again recommended use of vector 
instructions to solve the issue under discussion and that time was met 
with serious push-back from some list participants (not you).

In the end, I smiled to myself content in the knowledge that I could 
solve the problem with a vector-based routine that would run circles 
around anything any of those "experts" could write using the alternative 
techniques being suggested.

Of course, such a routine would normally be written using dual-path code 
with fall back to Plan B if the vector instructions were not available. 
So discussing the best implementation for Plan B wasn't time wasted...

-- 


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


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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Charles Mills]

Sounds like a SHARE presentation to me!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, January 14, 2019 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

Ed,

I also participate in ASSEMBLER-LIST and I don't remember such a discussion.  
Can you pinpoint the approximate time period for that discussion?

My biggest complaint/concern with the vector instructions is the woeful lack of 
any example code showing how to use them for just the kind of functions you 
described.  It's hard to imagine how to use such complex instructions without 
at least some straight-forward examples.

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Ed Jaffe]

On 1/14/2019 11:18 AM, Farley, Peter x23353 wrote:

I also participate in ASSEMBLER-LIST and I don't remember such a discussion.  
Can you pinpoint the approximate time period for that discussion?

My biggest complaint/concern with the vector instructions is the woeful lack of 
any example code showing how to use them for just the kind of functions you 
described.  It's hard to imagine how to use such complex instructions without 
at least some straight-forward examples.



I first mentioned using vector instructions in place of SRST in October 
2016 in a thread entitled, "SRST Performance" with eight posts. The 
group was debating which was faster, TRT or SRST. My comment was:


"SRST is much, much faster than TRT but still orders of magnitude slower 
than the vector instructions."


to which you replied as you have here with a desire for good examples 
from the PoOp owners. No one else seemed interested...


Later, in October of last year in another thread entitled, "Count 
Words?" with nearly 50 posts, I once again recommended use of vector 
instructions to solve the issue under discussion and that time was met 
with serious push-back from some list participants (not you).


In the end, I smiled to myself content in the knowledge that I could 
solve the problem with a vector-based routine that would run circles 
around anything any of those "experts" could write using the alternative 
techniques being suggested.


Of course, such a routine would normally be written using dual-path code 
with fall back to Plan B if the vector instructions were not available. 
So discussing the best implementation for Plan B wasn't time wasted...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Farley, Peter x23353]

Ed,

I also participate in ASSEMBLER-LIST and I don't remember such a discussion.  
Can you pinpoint the approximate time period for that discussion?

My biggest complaint/concern with the vector instructions is the woeful lack of 
any example code showing how to use them for just the kind of functions you 
described.  It's hard to imagine how to use such complex instructions without 
at least some straight-forward examples.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, January 14, 2019 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On 1/13/2019 8:47 PM, David Crayford wrote:

Sadly, I've tried to convince the assembler programmers on 
ASSEMBLER-LIST that vector instructions are useful for such purposes, 
but have been met with a surprising level of skepticism (despite my 
real-world experience and glowing endorsement)  -- primarily due to 
flawed interpretation of what they've read in PoOp rather than just 
trying it out and seeing for themselves. Oh well... LOL
-- 


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


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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Charles Mills]

> I've taken to defining functions in header files to take advantage of both 
> (we don't use IPA).

Looking at the code generated by the XLC compiler, I see that it sometimes 
(often?) in-lines functions even when they are defined in the (same, obviously) 
implementation file.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Sunday, January 13, 2019 8:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On 14/01/2019 6:06 am, Ed Jaffe wrote:
> On 1/13/2019 4:08 AM, David Crayford wrote:
>> On 13/01/2019 7:06 pm, Tony Thigpen wrote:
>>> I have seen some reports that current C compilers, which understand 
>>> the z-hardware pipeline, can actually produce object that is faster 
>>> running than an assembler. Mainly because no sane assembler 
>>> programmer would produce great pipe-line code because it would be 
>>> un-maintanable.
>>>
>> It's well established that that's been true for a well over a decade 
>> now. Not just C but all compilers including COBOL which got a new 
>> optimizer a few releases back.
>
>
> Far, far less true now than it used to be.
>

Good to hear. The best optimization is done in hardware where you don't 
have to recompile. Followed by a JIT.


> Back in the old days, things ran a lot faster if you interleaved 
> unrelated things in an "unfriendly" way. For example, this code fragment:
>
> |LGF  R0,Field1   Increment Field1
> |AGHI R0,1(same)
> |ST   R0,Field1   (same)
> |LGF  R0,Field2   Increment Field2
> |AGHI R0,1(same)
> |ST   R0,Field2   (same)
> |LGF  R0,Field3   Increment Field3
> |AGHI R0,1(same)
> |ST   R0,Field3   (same)
> |LGF  R0,Field4   Increment Field4
> |AGHI R0,1(same)
> |ST   R0,Field4   (same)
>
> ran much faster when coded this way (which is not how a programmer 
> would usually write things):
>
> |LGF  R0,Field1   Increment Field1
> |LGF  R1,Field2   Increment Field2
> |LGF  R2,Field3   Increment Field3
> |LGF  R3,Field4   Increment Field4
> |AGHI R0,1(same)
> |AGHI R1,1(same)
> |AGHI R2,1(same)
> |AGHI R3,1(same)
> |ST   R0,Field1   (same)
> |ST   R1,Field2   (same)
> |ST   R2,Field3   (same)
> |ST   R3,Field5   (same)
>
> But once OOO execution came on the scene with z196, you could get the 
> same enhanced performance from this easy-to-code and easy-to-read 
> version:
>
> |LGF  R0,Field1   Increment Field1
> |AGHI R0,1(same)
> |ST   R0,Field1   (same)
> |LGF  R1,Field2   Increment Field2
> |AGHI R1,1(same)
> |ST   R1,Field2   (same)
> |LGF  R2,Field3   Increment Field3
> |AGHI R2,1(same)
> |ST   R2,Field3   (same)
> |LGF  R3,Field4   Increment Field4
> |AGHI R3,1(same)
> |ST   R3,Field4   (same)
>
> These days, many performance improvements are realized by the compiler 
> using newer instructions that replace older ones. For example, on z10 
> and higher, this very same code can be replaced with:
>
> |ASI  Field1,1Increment Field1
> |ASI  Field2,1Increment Field1
> |ASI  Field3,1Increment Field1
> |ASI  Field4,1Increment Field1
>

IIRC, the interleaved instruction scheduling was to mitigate the AGI 
problem?

In my experienced the two optimizations that make the most difference 
are function inlining and loop unrolling. I've taken to defining 
functions in header files to take advantage of both (we don't use IPA).

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Ed Jaffe]

On 1/13/2019 8:47 PM, David Crayford wrote:
IIRC, the interleaved instruction scheduling was to mitigate the AGI 
problem?



Yes. The AGI "problem" is still there, but with an OOO machine you can 
avoid it simply by using different registers rather than by completely 
reordering your code.



In my experienced the two optimizations that make the most difference 
are function inlining and loop unrolling. I've taken to defining 
functions in header files to take advantage of both (we don't use IPA).



Yes. both are important. In HLASM one would use a macro to inline a 
function. Manual loop unrolling is something we do only in the 
performance path.



I've noticed (depending on compiler options) the C optimizer is 
starting to use vector instructions. They can be a bit hairy even for 
experienced assembler programmers. Best to leave that to a compiler IMO.



Haha! We were part of the z13s ESP and we started using vector 
instructions in our HLASM programs even before the machine was GA! We 
use them for all kinds of primitives including string FIND, bitmap 
manipulation, and other equally-simple, but important, stuff. Those 
"vectorized" routines perform literally orders of magnitude faster than 
their non-vector counterparts! Using them instead of SRST, we were able 
reduce the total CPU used by an (E)JES FIND across a multi-million line 
SPOOLed report by something in the neighborhood of 23%! (And if you can 
imagine all of the other work being done -- such as calling numerous 
routines, stack manipulation, reading and deblocking of SPOOL records, 
etc. -- 23% is a HUGE amount!!!)


Sadly, I've tried to convince the assembler programmers on 
ASSEMBLER-LIST that vector instructions are useful for such purposes, 
but have been met with a surprising level of skepticism (despite my 
real-world experience and glowing endorsement)  -- primarily due to 
flawed interpretation of what they've read in PoOp rather than just 
trying it out and seeing for themselves. Oh well... LOL



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[David Crayford]

On 14/01/2019 6:06 am, Ed Jaffe wrote:

On 1/13/2019 4:08 AM, David Crayford wrote:

On 13/01/2019 7:06 pm, Tony Thigpen wrote:
I have seen some reports that current C compilers, which understand 
the z-hardware pipeline, can actually produce object that is faster 
running than an assembler. Mainly because no sane assembler 
programmer would produce great pipe-line code because it would be 
un-maintanable.


It's well established that that's been true for a well over a decade 
now. Not just C but all compilers including COBOL which got a new 
optimizer a few releases back.



Far, far less true now than it used to be.



Good to hear. The best optimization is done in hardware where you don't 
have to recompile. Followed by a JIT.



Back in the old days, things ran a lot faster if you interleaved 
unrelated things in an "unfriendly" way. For example, this code fragment:


|    LGF  R0,Field1   Increment Field1
|    AGHI R0,1    (same)
|    ST   R0,Field1   (same)
|    LGF  R0,Field2   Increment Field2
|    AGHI R0,1    (same)
|    ST   R0,Field2   (same)
|    LGF  R0,Field3   Increment Field3
|    AGHI R0,1    (same)
|    ST   R0,Field3   (same)
|    LGF  R0,Field4   Increment Field4
|    AGHI R0,1    (same)
|    ST   R0,Field4   (same)

ran much faster when coded this way (which is not how a programmer 
would usually write things):


|    LGF  R0,Field1   Increment Field1
|    LGF  R1,Field2   Increment Field2
|    LGF  R2,Field3   Increment Field3
|    LGF  R3,Field4   Increment Field4
|    AGHI R0,1    (same)
|    AGHI R1,1    (same)
|    AGHI R2,1    (same)
|    AGHI R3,1    (same)
|    ST   R0,Field1   (same)
|    ST   R1,Field2   (same)
|    ST   R2,Field3   (same)
|    ST   R3,Field5   (same)

But once OOO execution came on the scene with z196, you could get the 
same enhanced performance from this easy-to-code and easy-to-read 
version:


|    LGF  R0,Field1   Increment Field1
|    AGHI R0,1    (same)
|    ST   R0,Field1   (same)
|    LGF  R1,Field2   Increment Field2
|    AGHI R1,1    (same)
|    ST   R1,Field2   (same)
|    LGF  R2,Field3   Increment Field3
|    AGHI R2,1    (same)
|    ST   R2,Field3   (same)
|    LGF  R3,Field4   Increment Field4
|    AGHI R3,1    (same)
|    ST   R3,Field4   (same)

These days, many performance improvements are realized by the compiler 
using newer instructions that replace older ones. For example, on z10 
and higher, this very same code can be replaced with:


|    ASI  Field1,1    Increment Field1
|    ASI  Field2,1    Increment Field1
|    ASI  Field3,1    Increment Field1
|    ASI  Field4,1    Increment Field1



IIRC, the interleaved instruction scheduling was to mitigate the AGI 
problem?


In my experienced the two optimizations that make the most difference 
are function inlining and loop unrolling. I've taken to defining 
functions in header files to take advantage of both (we don't use IPA).



Of course, an HLASM programmer can do exactly the same thing. But 
changing old code to use new instructions requires 
relatively-expensive programmer resources whereas simply recompiling 
programs targeting a new machine is a relatively-inexpensive proposition.



I've noticed (depending on compiler options) the C optimizer is starting 
to use vector instructions. They can be a bit hairy even for experienced 
assembler programmers. Best to leave that to a compiler IMO.


Instead of using a SRST instruction strlen() generates the following:

  VLBB v0,str(r6,r9,0),2
  LCBB r7,str(r6,r9,0),2
  LR   r0,r6
  ALR  r6,r7
  VFENEB   v0,v0,v0,b'0010'
  VLGVB    r2,v0,7
  CLRJH    r7,r2,@2L33
  VLBB v0,str(r6,r9,0),2
  LCBB r7,str(r6,r9,0),2
  LR   r0,r6
  ALR  r6,r7
  VFENEB   v0,v0,v0,b'0010'
  VLGVB    r2,v0,7
  CLRJH    r7,r2,@2L33
  VLBB v0,str(r6,r9,0),2
  LCBB r7,str(r6,r9,0),2
  LR   r0,r6
  VFENEB   v0,v0,v0,b'0010'
  ALR  r6,r7
  VLGVB    r2,v0,7
  CLRJH    r7,r2,@2L33
  VLBB v0,str(r6,r9,0),2
  LCBB r7,str(r6,r9,0),2
  LR   r0,r6
  ALR  r6,r7
  VFENEB   v0,v0,v0,b'0010'
  VLGVB    r2,v0,7
  CLRJNH   r7,r2,@2L25

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Ed Jaffe]

On 1/13/2019 4:08 AM, David Crayford wrote:

On 13/01/2019 7:06 pm, Tony Thigpen wrote:
I have seen some reports that current C compilers, which understand 
the z-hardware pipeline, can actually produce object that is faster 
running than an assembler. Mainly because no sane assembler 
programmer would produce great pipe-line code because it would be 
un-maintanable.


It's well established that that's been true for a well over a decade 
now. Not just C but all compilers including COBOL which got a new 
optimizer a few releases back.



Far, far less true now than it used to be.

Back in the old days, things ran a lot faster if you interleaved 
unrelated things in an "unfriendly" way. For example, this code fragment:


|    LGF  R0,Field1   Increment Field1
|    AGHI R0,1    (same)
|    ST   R0,Field1   (same)
|    LGF  R0,Field2   Increment Field2
|    AGHI R0,1    (same)
|    ST   R0,Field2   (same)
|    LGF  R0,Field3   Increment Field3
|    AGHI R0,1    (same)
|    ST   R0,Field3   (same)
|    LGF  R0,Field4   Increment Field4
|    AGHI R0,1    (same)
|    ST   R0,Field4   (same)

ran much faster when coded this way (which is not how a programmer would 
usually write things):


|    LGF  R0,Field1   Increment Field1
|    LGF  R1,Field2   Increment Field2
|    LGF  R2,Field3   Increment Field3
|    LGF  R3,Field4   Increment Field4
|    AGHI R0,1    (same)
|    AGHI R1,1    (same)
|    AGHI R2,1    (same)
|    AGHI R3,1    (same)
|    ST   R0,Field1   (same)
|    ST   R1,Field2   (same)
|    ST   R2,Field3   (same)
|    ST   R3,Field5   (same)

But once OOO execution came on the scene with z196, you could get the 
same enhanced performance from this easy-to-code and easy-to-read version:


|    LGF  R0,Field1   Increment Field1
|    AGHI R0,1    (same)
|    ST   R0,Field1   (same)
|    LGF  R1,Field2   Increment Field2
|    AGHI R1,1    (same)
|    ST   R1,Field2   (same)
|    LGF  R2,Field3   Increment Field3
|    AGHI R2,1    (same)
|    ST   R2,Field3   (same)
|    LGF  R3,Field4   Increment Field4
|    AGHI R3,1    (same)
|    ST   R3,Field4   (same)

These days, many performance improvements are realized by the compiler 
using newer instructions that replace older ones. For example, on z10 
and higher, this very same code can be replaced with:


|    ASI  Field1,1    Increment Field1
|    ASI  Field2,1    Increment Field1
|    ASI  Field3,1    Increment Field1
|    ASI  Field4,1    Increment Field1

Of course, an HLASM programmer can do exactly the same thing. But 
changing old code to use new instructions requires relatively-expensive 
programmer resources whereas simply recompiling programs targeting a new 
machine is a relatively-inexpensive proposition.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

Steve,

Agree, I learned Assembler first then self-taught in C ...
Only played with Java, I actually like python...

Scott

On Sun, Jan 13, 2019 at 4:06 PM Steve Smith  wrote:

> I entirely agree.  The syntax for mapping C variables to in-line assembler
> code is hideous and error-prone (at least for me).  Conversely, the linkage
> for an assembler subroutine is very standard.  That's the way to go if the
> code requires more than a couple of variables.
>
> sas
>
> On Sun, Jan 13, 2019 at 7:08 AM David Crayford 
> wrote:
>
> > ...
>
>
>
> > I still maintain that some code
> > is still better written in assembler. I'm a C/C++ programmer these days
> > but for some subroutines an assembler program is much easier to
> > understand then lots of inlined  __asm() blocks.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Steve Smith]

I entirely agree.  The syntax for mapping C variables to in-line assembler
code is hideous and error-prone (at least for me).  Conversely, the linkage
for an assembler subroutine is very standard.  That's the way to go if the
code requires more than a couple of variables.

sas

On Sun, Jan 13, 2019 at 7:08 AM David Crayford  wrote:

> ...



> I still maintain that some code
> is still better written in assembler. I'm a C/C++ programmer these days
> but for some subroutines an assembler program is much easier to
> understand then lots of inlined  __asm() blocks.

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Rupert Reynolds]

On Sat, 12 Jan 2019, 23:43 Paul Gilmartin, <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

>
>
> More concisely:
> TRUE  = 1
> FALSE = 0
>
> These are in he Rexx Standard; you may rely on them.  Nonetheless, you
> may choose to assign those mnemonics for clarity.
>
Yes, in the standard. It was a long time ago. I can't remember now whether
I didn't know it at the time, or whether I was dealing with a dodgy
implementation on one of the platforms it might run on.


> I consider
> if flag = TRUE  ...
> and
> if flag = FALSE ...
> and
> if A == B then flag = TRUE; else flag = false
>
> ... (which I've seen used) execrable expansions of
> if flag ...
> or
> if \flag ...
> or
> flag = ( A == B )  /* Superfluous parentheses may enhance clarity.  )
>
> )you might as well code:
> if flag = TRUE = TRUE = TRUE ...
>

Yes, execrable, and a sure sign the programmer needs a basic course in
boolean :-)

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[David Crayford]

On 13/01/2019 7:06 pm, Tony Thigpen wrote:
I have seen some reports that current C compilers, which understand 
the z-hardware pipeline, can actually produce object that is faster 
running than an assembler. Mainly because no sane assembler programmer 
would produce great pipe-line code because it would be un-maintanable.


It's well established that that's been true for a well over a decade 
now. Not just C but all compilers including COBOL which got a new 
optimizer a few releases back.


The game changer for systems programming was Metal/C which can be used 
for AR mode stuff using __far pointers. I still maintain that some code 
is still better written in assembler. I'm a C/C++ programmer these days
but for some subroutines an assembler program is much easier to 
understand then lots of inlined  __asm() blocks.


I am an assembler programmer, not a C programmer, so I view the 
reports with some speciesism.


Tony Thigpen

scott Ford wrote on 1/12/19 1:33 PM:

I am speaking in terms of development cycle.

On Sat, Jan 12, 2019 at 1:32 PM scott Ford  wrote:


David and Zman,

Both good points, C is certainly faster than Assembler or maybe PL/S

On Sat, Jan 12, 2019 at 2:17 AM David Crayford 
wrote:


On 12/01/2019 4:08 am, Seymour J Metz wrote:

despite being used frequently for the purpose, it's really not

particularly suited for writing operating systems

LOL! That's absurd! C has been ported to just about every architecture
worth mentioning and is well suited to low-level programming. It's 
also

incredibly
efficient and has a mature and well established tool chain for
debugging, profiling, code correctness etc. What do you consider a 
good

language for
writing operating systems?

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


--
Scott Ford
IDMWORKS
z/OS Development



--
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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Tony Thigpen]

I have seen some reports that current C compilers, which understand the 
z-hardware pipeline, can actually produce object that is faster running 
than an assembler. Mainly because no sane assembler programmer would 
produce great pipe-line code because it would be un-maintanable.


I am an assembler programmer, not a C programmer, so I view the reports 
with some speciesism.


Tony Thigpen

scott Ford wrote on 1/12/19 1:33 PM:

I am speaking in terms of development cycle.

On Sat, Jan 12, 2019 at 1:32 PM scott Ford  wrote:


David and Zman,

Both good points, C is certainly faster than Assembler or maybe PL/S

On Sat, Jan 12, 2019 at 2:17 AM David Crayford 
wrote:


On 12/01/2019 4:08 am, Seymour J Metz wrote:

despite being used frequently for the purpose, it's really not

particularly suited for writing operating systems

LOL! That's absurd! C has been ported to just about every architecture
worth mentioning and is well suited to low-level programming. It's also
incredibly
efficient and has a mature and well established tool chain for
debugging, profiling, code correctness etc. What do you consider a good
language for
writing operating systems?

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


--
Scott Ford
IDMWORKS
z/OS Development



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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Sat, 12 Jan 2019 22:58:13 +, Rupert Reynolds wrote:

>Fancy code? I remember once wanting to set a flag under certain circs, and
>I considered something like:
>
>/* Rexx */
>TRUE = 1=1
>FALSE = \TRUE
>. . .
>flag = TRUE
>
>I can't remember now whether I used it, or hated it.
> 
More concisely:
TRUE  = 1
FALSE = 0

These are in he Rexx Standard; you may rely on them.  Nonetheless, you
may choose to assign those mnemonics for clarity.

I consider
if flag = TRUE  ...
and
if flag = FALSE ...
and
if A == B then flag = TRUE; else flag = false

... (which I've seen used) execrable expansions of
if flag ...
or
if \flag ...
or
flag = ( A == B )  /* Superfluous parentheses may enhance clarity.  )

)you might as well code:
if flag = TRUE = TRUE = TRUE ...

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Rupert Reynolds]

Fancy code? I remember once wanting to set a flag under certain circs, and
I considered something like:

/* Rexx */
TRUE = 1=1
FALSE = \TRUE
. . .
flag = TRUE

I can't remember now whether I used it, or hated it.

Rupert

On Sat, 12 Jan 2019, 18:42 scott Ford,  wrote:

> Tony,
>
> I used Rexx because it was easy and quick, especially when your short
> handed manpower wise because of bad decision making or money.
>
> Scott
>
> On Sat, Jan 12, 2019 at 1:33 PM scott Ford  wrote:
>
> > I am speaking in terms of development cycle.
> >
> > On Sat, Jan 12, 2019 at 1:32 PM scott Ford  wrote:
> >
> >> David and Zman,
> >>
> >> Both good points, C is certainly faster than Assembler or maybe PL/S
> >>
> >> On Sat, Jan 12, 2019 at 2:17 AM David Crayford 
> >> wrote:
> >>
> >>> On 12/01/2019 4:08 am, Seymour J Metz wrote:
> >>> > despite being used frequently for the purpose, it's really not
> >>> particularly suited for writing operating systems
> >>>
> >>> LOL! That's absurd! C has been ported to just about every architecture
> >>> worth mentioning and is well suited to low-level programming. It's also
> >>> incredibly
> >>> efficient and has a mature and well established tool chain for
> >>> debugging, profiling, code correctness etc. What do you consider a good
> >>> language for
> >>> writing operating systems?
> >>>
> >>> --
> >>> For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>>
> >> --
> >> Scott Ford
> >> IDMWORKS
> >> z/OS Development
> >>
> > --
> > Scott Ford
> > IDMWORKS
> > z/OS Development
> >
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

Tony,

I used Rexx because it was easy and quick, especially when your short
handed manpower wise because of bad decision making or money.

Scott

On Sat, Jan 12, 2019 at 1:33 PM scott Ford  wrote:

> I am speaking in terms of development cycle.
>
> On Sat, Jan 12, 2019 at 1:32 PM scott Ford  wrote:
>
>> David and Zman,
>>
>> Both good points, C is certainly faster than Assembler or maybe PL/S
>>
>> On Sat, Jan 12, 2019 at 2:17 AM David Crayford 
>> wrote:
>>
>>> On 12/01/2019 4:08 am, Seymour J Metz wrote:
>>> > despite being used frequently for the purpose, it's really not
>>> particularly suited for writing operating systems
>>>
>>> LOL! That's absurd! C has been ported to just about every architecture
>>> worth mentioning and is well suited to low-level programming. It's also
>>> incredibly
>>> efficient and has a mature and well established tool chain for
>>> debugging, profiling, code correctness etc. What do you consider a good
>>> language for
>>> writing operating systems?
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>> --
>> Scott Ford
>> IDMWORKS
>> z/OS Development
>>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

I am speaking in terms of development cycle.

On Sat, Jan 12, 2019 at 1:32 PM scott Ford  wrote:

> David and Zman,
>
> Both good points, C is certainly faster than Assembler or maybe PL/S
>
> On Sat, Jan 12, 2019 at 2:17 AM David Crayford 
> wrote:
>
>> On 12/01/2019 4:08 am, Seymour J Metz wrote:
>> > despite being used frequently for the purpose, it's really not
>> particularly suited for writing operating systems
>>
>> LOL! That's absurd! C has been ported to just about every architecture
>> worth mentioning and is well suited to low-level programming. It's also
>> incredibly
>> efficient and has a mature and well established tool chain for
>> debugging, profiling, code correctness etc. What do you consider a good
>> language for
>> writing operating systems?
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

David and Zman,

Both good points, C is certainly faster than Assembler or maybe PL/S

On Sat, Jan 12, 2019 at 2:17 AM David Crayford  wrote:

> On 12/01/2019 4:08 am, Seymour J Metz wrote:
> > despite being used frequently for the purpose, it's really not
> particularly suited for writing operating systems
>
> LOL! That's absurd! C has been ported to just about every architecture
> worth mentioning and is well suited to low-level programming. It's also
> incredibly
> efficient and has a mature and well established tool chain for
> debugging, profiling, code correctness etc. What do you consider a good
> language for
> writing operating systems?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[David Crayford]

On 12/01/2019 4:08 am, Seymour J Metz wrote:

despite being used frequently for the purpose, it's really not particularly 
suited for writing operating systems


LOL! That's absurd! C has been ported to just about every architecture 
worth mentioning and is well suited to low-level programming. It's also 
incredibly
efficient and has a mature and well established tool chain for 
debugging, profiling, code correctness etc. What do you consider a good 
language for

writing operating systems?

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[zMan]

Yeah, no. Very little in Rexx syntax is like C IMHO. I mean, both have
variables and keywords and semicolons, but that's about it.

On Thu, Jan 10, 2019 at 7:51 PM scott Ford  wrote:

> Maybe you should read about Mike who wrote rexx, which I have used since
> 1984...
> It’s the structure
>
> On Thu, Jan 10, 2019 at 7:31 PM zMan  wrote:
>
> > Semicolons?
> >
> > On Thu, Jan 10, 2019 at 6:48 PM Steve Smith  wrote:
> >
> > > REXX is lot like C?  I can't think of anything they have in common
> beyond
> > > the minimum basics of any procedural language.
> > >
> > > sas
> > >
> > > On Wed, Jan 9, 2019 at 8:43 PM scott Ford  wrote:
> > >
> > > > APL sounds painful unless your into pain. I learned Rexx after
> > Assembler,
> > > > Cobol and PL/1.
> > > > I always thought PL/1 was clever with the “dos” then I learned rexx
> > which
> > > > is a lot like C ..
> > > >
> > > > Regards,
> > > > Scott
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> >
> > --
> > zMan -- "I've got a mainframe and I'm not afraid to use it"
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

To be honest, every programming language or scripting languages have pros
and cons.
Except for Java, I kid .

On Fri, Jan 11, 2019 at 5:09 PM scott Ford  wrote:

> Wow, boys .I been at it 40+ yrs and after awhile it all runs together
> ...
>
>
>
> On Fri, Jan 11, 2019 at 4:57 PM Seymour J Metz  wrote:
>
>> > I'd much prefer that Rexx provide instream data, with  symbol
>> substitution,
>>
>> DATA ... END and DATA PROMPT ... END are very useful, much more useful
>> than here documents, IMHO.
>>
>> >I eschew STACK with any command that provides STEM as an alternative.
>>
>> STEM is nice for commands that support it, but most commands do not.
>>
>> > I'm phobic that a rogue subroutine will corrupt my stack, or even
>> DESBUF.
>>
>> That's harder than you might think; DESBUF only trashes stacks that REXX
>> created.
>>
>> > STACK is a crude circumvention for overly restrictive variable scoping.
>>
>> No. You might certainly use it that way, but I find that a good
>> screwdriver makes a bad hammer, and vice versa.
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf
>> of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
>> Sent: Friday, January 11, 2019 4:39 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue
>> multitasking issue)
>>
>> On Fri, 11 Jan 2019 21:15:20 +, Seymour J Metz  wrote:
>>
>> >> It's there, and other implementations of Rexx, such as Regina,
>> struggle to emulate it.
>> >
>> >All implementations of REXX provide a stack, but none of them even try
>> to provide the stack mechanisms that TSO has and CLIST DATA/DATA PROMPT
>> support.
>> >
>> I'd much prefer that Rexx provide instream data, with  symbol
>> substitution,
>> as POSIX shell and even JCL do.
>>
>> I eschew STACK with any command that provides STEM as an alternative.
>> I'm phobic that a rogue subroutine will corrupt my stack, or even DESBUF.
>>
>> I applaud ADDRESS SYSCALL for relying on STEM, never (AFAIK?) STACK.
>>
>> STACK is a crude circumvention for overly restrictive variable scoping.
>> CMS Piplines has YA chaotic circumvention.
>>
>> -- 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
>>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

Wow, boys .I been at it 40+ yrs and after awhile it all runs together
...



On Fri, Jan 11, 2019 at 4:57 PM Seymour J Metz  wrote:

> > I'd much prefer that Rexx provide instream data, with  symbol
> substitution,
>
> DATA ... END and DATA PROMPT ... END are very useful, much more useful
> than here documents, IMHO.
>
> >I eschew STACK with any command that provides STEM as an alternative.
>
> STEM is nice for commands that support it, but most commands do not.
>
> > I'm phobic that a rogue subroutine will corrupt my stack, or even DESBUF.
>
> That's harder than you might think; DESBUF only trashes stacks that REXX
> created.
>
> > STACK is a crude circumvention for overly restrictive variable scoping.
>
> No. You might certainly use it that way, but I find that a good
> screwdriver makes a bad hammer, and vice versa.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, January 11, 2019 4:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue
> multitasking issue)
>
> On Fri, 11 Jan 2019 21:15:20 +, Seymour J Metz  wrote:
>
> >> It's there, and other implementations of Rexx, such as Regina, struggle
> to emulate it.
> >
> >All implementations of REXX provide a stack, but none of them even try to
> provide the stack mechanisms that TSO has and CLIST DATA/DATA PROMPT
> support.
> >
> I'd much prefer that Rexx provide instream data, with  symbol substitution,
> as POSIX shell and even JCL do.
>
> I eschew STACK with any command that provides STEM as an alternative.
> I'm phobic that a rogue subroutine will corrupt my stack, or even DESBUF.
>
> I applaud ADDRESS SYSCALL for relying on STEM, never (AFAIK?) STACK.
>
> STACK is a crude circumvention for overly restrictive variable scoping.
> CMS Piplines has YA chaotic circumvention.
>
> -- 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

> I'd much prefer that Rexx provide instream data, with  symbol substitution,

DATA ... END and DATA PROMPT ... END are very useful, much more useful than 
here documents, IMHO.

>I eschew STACK with any command that provides STEM as an alternative.

STEM is nice for commands that support it, but most commands do not.

> I'm phobic that a rogue subroutine will corrupt my stack, or even DESBUF.

That's harder than you might think; DESBUF only trashes stacks that REXX 
created.

> STACK is a crude circumvention for overly restrictive variable scoping.

No. You might certainly use it that way, but I find that a good screwdriver 
makes a bad hammer, and vice versa.

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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 11, 2019 4:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Fri, 11 Jan 2019 21:15:20 +, Seymour J Metz  wrote:

>> It's there, and other implementations of Rexx, such as Regina, struggle to 
>> emulate it.
>
>All implementations of REXX provide a stack, but none of them even try to 
>provide the stack mechanisms that TSO has and CLIST DATA/DATA PROMPT support.
>
I'd much prefer that Rexx provide instream data, with  symbol substitution,
as POSIX shell and even JCL do.

I eschew STACK with any command that provides STEM as an alternative.
I'm phobic that a rogue subroutine will corrupt my stack, or even DESBUF.

I applaud ADDRESS SYSCALL for relying on STEM, never (AFAIK?) STACK.

STACK is a crude circumvention for overly restrictive variable scoping.
CMS Piplines has YA chaotic circumvention.

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Fri, 11 Jan 2019 21:15:20 +, Seymour J Metz  wrote:

>> It's there, and other implementations of Rexx, such as Regina, struggle to 
>> emulate it.
>
>All implementations of REXX provide a stack, but none of them even try to 
>provide the stack mechanisms that TSO has and CLIST DATA/DATA PROMPT support.
> 
I'd much prefer that Rexx provide instream data, with  symbol substitution,
as POSIX shell and even JCL do.

I eschew STACK with any command that provides STEM as an alternative.
I'm phobic that a rogue subroutine will corrupt my stack, or even DESBUF.

I applaud ADDRESS SYSCALL for relying on STEM, never (AFAIK?) STACK.

STACK is a crude circumvention for overly restrictive variable scoping.
CMS Piplines has YA chaotic circumvention.

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

The point is that signal does both more and less than a PL/I goto and maximally 
violates the law of least astonishment. It's one of the pitfalls I warn about 
in my Safe REXX papers.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 11, 2019 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Fri, 11 Jan 2019 20:58:51 +, Seymour J Metz wrote:

>FSVO goto that lives in a different universe from PL/I. The REXX signal 
>statement trashes the stack rather than simply popping it appropriately. 
>Consider
>
SIGNAL trashes the DO nest but it does not update the CALL/RETURN stack.  I 
encountered
this to my dismay working with code of a co-worker  who relied on SIGNAL to 
exit a
funtion by branching to the top of a DO on an error condition.   Worked when he 
tested
it; overflowed CALL/RETURN stack on a large production data set.

Rexx sorely lacks LONGJUMP for this purpose.  (An extension to ITERATE/LEAVE 
would
suffice and be better structured.)

>do I=1 to n
>   do j=1 to m
>  ...
>  if foo then signal bar
>  ...
>  end
>   ...
>   bar:
>   ...
>   end

Rather, I'd propose:

do I=1 to n
   do j=1 to m
  ...
  call F
  ...
  end j  /* I label ENDs whenever possible.  */
   ...
   bar:
   ...
   end I
return

F: procedure expose I
...
if foo then iterate I
...
return

--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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Fri, 11 Jan 2019 20:58:51 +, Seymour J Metz wrote:

>FSVO goto that lives in a different universe from PL/I. The REXX signal 
>statement trashes the stack rather than simply popping it appropriately. 
>Consider
> 
SIGNAL trashes the DO nest but it does not update the CALL/RETURN stack.  I 
encountered
this to my dismay working with code of a co-worker  who relied on SIGNAL to 
exit a
funtion by branching to the top of a DO on an error condition.   Worked when he 
tested
it; overflowed CALL/RETURN stack on a large production data set.

Rexx sorely lacks LONGJUMP for this purpose.  (An extension to ITERATE/LEAVE 
would
suffice and be better structured.)

>do I=1 to n
>   do j=1 to m
>  ...
>  if foo then signal bar
>  ...
>  end
>   ...
>   bar:
>   ...
>   end

Rather, I'd propose:

do I=1 to n
   do j=1 to m
  ...
  call F
  ...
  end j  /* I label ENDs whenever possible.  */
   ...
   bar:
   ...
   end I
return

F: procedure expose I
...
if foo then iterate I
...
return

--gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

> It's there, and other implementations of Rexx, such as Regina, struggle to 
> emulate it.

All implementations of REXX provide a stack, but none of them even try to 
provide the stack mechanisms that TSO has and CLIST DATA/DATA PROMPT support.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 11, 2019 4:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Fri, 11 Jan 2019 12:49:07 -0800, Ed Jaffe wrote:

>On 1/11/2019 12:35 PM, David Spiegel wrote:
>> (I've never encountered a TSO stack (outside of Rexx) in my 43 years of
>> using TSO.)
>
It's there, and other implementations of Rexx, such as Regina, struggle
to emulate it.

>I suspect this is a reference to REXX's total lack of interactive
>command processor support like you get with CLIST.
>
That's different.

>In REXX, you must place all subcommands ahead of time on the stack and
>then invoke the command processor. You cannot interrogate intermediate
>results and modify/change the remaining subcommands as might be needed.
>Your REXX does not get control back until the stack is exhausted and the
>command processor ends.
>
An alternative *provided* that the command processor supports a SUBCOM
interface is for the invoking EXEC to pass another EXEC (or itself) as an
initial macro (profile).  Then it can access results from individual subcomands
(but it can not access variables in the calling instance).

>If you have 43 years of experience, I'm sure you know exactly what I'm
>trying to describe here...

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

Block structure. Use of /* and */ as comments delimiters. Use of : for labels.

But they're still very different.


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


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Thursday, January 10, 2019 6:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

REXX is lot like C?  I can't think of anything they have in common beyond
the minimum basics of any procedural language.

sas

On Wed, Jan 9, 2019 at 8:43 PM scott Ford  wrote:

> APL sounds painful unless your into pain. I learned Rexx after Assembler,
> Cobol and PL/1.
> I always thought PL/1 was clever with the “dos” then I learned rexx which
> is a lot like C ..
>
> Regards,
> Scott

--
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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Fri, 11 Jan 2019 12:49:07 -0800, Ed Jaffe wrote:

>On 1/11/2019 12:35 PM, David Spiegel wrote:
>> (I've never encountered a TSO stack (outside of Rexx) in my 43 years of
>> using TSO.)
> 
It's there, and other implementations of Rexx, such as Regina, struggle
to emulate it.

>I suspect this is a reference to REXX's total lack of interactive
>command processor support like you get with CLIST.
>
That's different.

>In REXX, you must place all subcommands ahead of time on the stack and
>then invoke the command processor. You cannot interrogate intermediate
>results and modify/change the remaining subcommands as might be needed.
>Your REXX does not get control back until the stack is exhausted and the
>command processor ends.
> 
An alternative *provided* that the command processor supports a SUBCOM
interface is for the invoking EXEC to pass another EXEC (or itself) as an
initial macro (profile).  Then it can access results from individual subcomands
(but it can not access variables in the calling instance).

>If you have 43 years of experience, I'm sure you know exactly what I'm
>trying to describe here...

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

FSVO goto that lives in a different universe from PL/I. The REXX signal 
statement trashes the stack rather than simply popping it appropriately. 
Consider

do I=1 to n
   do j=1 to m
  ...
  if foo then signal bar
  ...
  end
   ...
   bar:
   ...
   end


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


From: IBM Mainframe Discussion List  on behalf of 
David Spiegel 
Sent: Friday, January 11, 2019 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

Hi R'Shmuel,
"... signal is not a goto ..." ?!
It is also true that Signal has other operands, but, in its most basic
form it is EXACTLY a goto.

Regards,
David

On 2019-01-11 15:32, Seymour J Metz wrote:
> A lot of the syntax comes from PL/I, although not the use of a continuation 
> character and not the use of labels (no, signal is not a goto.)
>
>
> --
> Shmuel (Seymour J.) Metz
> https://eur01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Cf91df8aa05b2424ac21808d67804058f%7C84df9e7fe9f640afb435%7C1%7C0%7C636828356004192153sdata=R4qBf6zROqkxfRibpdhnLSMnoo%2B7e4w1mJo7zxJ7F80%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Thursday, January 10, 2019 9:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
> multitasking issue)
>
> On Thu, 10 Jan 2019 19:30:41 -0500, zMan wrote:
>
>> Semicolons?
>>
> (My laptop doesn't speak emoji.)
>
> Semicolons, yes, but:
>  do <=> {
>  end<=> }
>  switch <=> SELECT
>  ...
> I think Rexx got much of its lexical flavor from PL/I.  But that's easy for
> me to say becase I don't know PL/I.
>
>> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
>>
>>> REXX is lot like C?  I can't think of anything they have in common beyond
>>> the minimum basics of any procedural language.
> Bless Rexx for making ';' and newline very nearly interchangeable, in contrast
> to POSIX Shell script, where they aren't.
>
> -- 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

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

> secure-web is offensive

If I had some way to turn it off, or to jail the guy that thought it was a good 
idea, ...


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 11, 2019 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Fri, 11 Jan 2019 20:27:30 +, Seymour J Metz wrote:

>Keep in mind that wiki is a mixed bag; its emphasis of secondary sources over 
>primary sources tends to damage its reliability. Also, the URL you gave was 
>for PL/I rather than for REXX.
>
>
>From: David Crayford
>Sent: Thursday, January 10, 2019 10:17 PM
>
> From Wiki "Rexx was also intended by its creator to be a simplified and
>easier to learn version of the PL/I 
><https://secure-web.cisco.com/1T_zgNKTuiHHGZ-wMhMaY_Aq4goia3Y_0KIobX6TulyJSMMRpbNpl1BiSRozYv5QnZ4qXwAfPti4QlNm3jf6HtWswKG1xmXYLtRhUjMO0-JCZCDtOl_K_8wkSiHk10oiTsbp-aIQVHijMmECoAVrxktx-DswOhB0oEYg_Ct-6VQNyrYDTdcKX0F7h0eelJePTAzG_E7rW-K6KM6ngnOnJ1QWSvNtaYKO9nzsjOWB57W2p794YBikUCJIrNK3QmAtPU6w4uEESwor3KDkeh3-PERBKoJeex8DWg2m6VURvVuCccl6E7-zaO9Akap-x56aaoE5KvrHG8nNNIFVrof74ze8UNI7rvSX210wS9wR148bhlNmArH-p82RCei8JArZMVAqqY0vMeEDhPzU8OAn2E5He3DqyxHjAU77Ds2kpCug2WVxiUU4bKnKdykTwtR5b/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FPL%2FI>
>
secure-web is offensive.  Another way of tracking browsing.

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Ed Jaffe]

On 1/11/2019 12:35 PM, David Spiegel wrote:

R'Shmuel,
Can you please explain what you mean by "... TSO stack mechanism ..."
and where the documentation is?
(I've never encountered a TSO stack (outside of Rexx) in my 43 years of
using TSO.)


I suspect this is a reference to REXX's total lack of interactive 
command processor support like you get with CLIST.


A CLIST can invoke a command processor, issue a subcommand to it, and -- 
based on the results of that subcommand or others that follow -- issue 
additional subcommands. The entire command processor session is 
programmatically controlled by the CLIST.


In REXX, you must place all subcommands ahead of time on the stack and 
then invoke the command processor. You cannot interrogate intermediate 
results and modify/change the remaining subcommands as might be needed. 
Your REXX does not get control back until the stack is exhausted and the 
command processor ends.


If you have 43 years of experience, I'm sure you know exactly what I'm 
trying to describe here...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

See the DATA and DATA PROMPT commands in z/OS TSO/E CLISTs Version2 Release3, 
SA32-0978-30, 
https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sa320978/$file/ikjb800_v2r3.pdf


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


From: IBM Mainframe Discussion List  on behalf of 
David Spiegel 
Sent: Friday, January 11, 2019 3:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

R'Shmuel,
Can you please explain what you mean by "... TSO stack mechanism ..."
and where the documentation is?
(I've never encountered a TSO stack (outside of Rexx) in my 43 years of
using TSO.)

Thanks and regards,
David

On 2019-01-11 15:17, Seymour J Metz wrote:
> REXX was certainly a great improvement over EXEC, EXEC 2 and *TSO* CLIST, but 
> there is no "VM CLIST". There are a couple of edge cases where REXX is 
> missing something present in the old languages, e.g., integration with the 
> TSO stack mechanism.
>
> As for the PL/I likeness, it is more of a hindrance  than a help; lures you 
> into expecting PL/I behavior in cases where the semantics are very different.
>
> Don't forget SELECT, which came from PL/I and helps to make code more 
> readable.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://nam05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C3330927d53d94a866fc408d67801df78%7C84df9e7fe9f640afb435%7C1%7C0%7C636828346803059565sdata=BgckSUWvHzqVglLz0%2BGIVc2ZoZUsxw5DAZF%2FNsFutVg%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> scott Ford 
> Sent: Friday, January 11, 2019 7:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
> multitasking issue)
>
> You can argue anything is or isn’t , I think what matters is ease of usage
> , platform interchangeability , I.E., Linux and windows for Oorexx.
> The advent of rexx, I started on VM/SP 3 , I think, was a huge improvement
> over the old VM clist language. The old clist to me being more
> clunky . Rexx was easy to learn and have up and running  . This was a g pus
> at least for me.
>
> The PL/1 likeness is the “ if then do” , I wrote a bunch of PL/1 on
> OS/VS2/HASP,  back to n the dark ages.
>
> On Thu, Jan 10, 2019 at 10:18 PM David Crayford  wrote:
>
>> On 11/01/2019 10:27 am, Paul Gilmartin wrote:
>>> Semicolons, yes, but:
>>>   do <=> {
>>>   end<=> }
>>>   switch <=> SELECT
>>>   ...
>>> I think Rexx got much of its lexical flavor from PL/I.  But that's easy
>> for
>>> me to say becase I don't know PL/I.
>>   From Wiki "Rexx was also intended by its creator to be a simplified and
>> easier to learn version of the PL/I 
>> <https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1KuZ2_QAj-lIiZ0vsi9R7gP9mYWbAUVCS6akTtgvJS-DnqovyZRmdGrqGoMWgm7EwiLqZ8ej0c17Tofsf9DD5B582eGmRcLPeB42We7J2CwsGr27oIgC9UZc9zBK4j2mZxtNpOlmdC4InFhP0Xlye-VZLwEL-IgqK4BhM7QZYJj9FCOjyMK9hbLcfq--Wa4hX_N52qg_DnWzLP2tmZWLd3HeVV-waWkQRLA7SqKrJ6501hh0ixJeOyKM4Wma75IglYYp0kYXcZEeTzWomm0sEj0c12DFY6uQMUS33RRK0HmEdAe4HJoBZVOX5LMgjOGI24msdRSkQCUXw3et8tcAawG9lWNzi1WMy0UNhmb1uJmnvtS6lMJnCAXMBQcfss45S1rTrUmhqplcGA_F4zr3nCXWxp1IbgUoT2mfZgTiXGAF2Y_jm3l7SzYcoVvwOhTl3%2Fhttps%253A%252F%252Fen.wikipedia.org%252Fwiki%252FPL%252FIdata=02%7C01%7C%7C3330927d53d94a866fc408d67801df78%7C84df9e7fe9f640afb435%7C1%7C0%7C636828346803059565sdata=QqU92DnewZKJ%2FAxNqRpOiyMZmRVB%2FxMK7YjT4a3tZJ4%3Dreserved=0>
>> programming language"
>>
>> I agree with Steve. There is very little similarity between REXX and C.
>> A case in point would be short circuit evaluation which is fundamental
>> to C and
>> sadly lacking in REXX. There are some similarities between a language
>> like JavaScript and C because of the lineage of most curly bracket
>> languages.
>>
>>
>>>> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
>>>>
>>>>> REXX is lot like C?  I can't think of anything they have in common
>> beyond
>>>>> the minimum basics of any procedural language.
>>> Bless Rexx for making ';' and newline very nearly interchangeable, in
>> contrast
>>> to POSIX Shell script, where they aren't.
>>>
>>> -- gil
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with th

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Fri, 11 Jan 2019 20:27:30 +, Seymour J Metz wrote:

>Keep in mind that wiki is a mixed bag; its emphasis of secondary sources over 
>primary sources tends to damage its reliability. Also, the URL you gave was 
>for PL/I rather than for REXX.
>
>
>From: David Crayford 
>Sent: Thursday, January 10, 2019 10:17 PM
>
> From Wiki "Rexx was also intended by its creator to be a simplified and
>easier to learn version of the PL/I 
>
>
secure-web is offensive.  Another way of tracking browsing.

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[David Spiegel]

Hi R'Shmuel,
"... signal is not a goto ..." ?!
It is also true that Signal has other operands, but, in its most basic 
form it is EXACTLY a goto.

Regards,
David

On 2019-01-11 15:32, Seymour J Metz wrote:
> A lot of the syntax comes from PL/I, although not the use of a continuation 
> character and not the use of labels (no, signal is not a goto.)
>
>
> --
> Shmuel (Seymour J.) Metz
> https://eur01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Cf91df8aa05b2424ac21808d67804058f%7C84df9e7fe9f640afb435%7C1%7C0%7C636828356004192153sdata=R4qBf6zROqkxfRibpdhnLSMnoo%2B7e4w1mJo7zxJ7F80%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Thursday, January 10, 2019 9:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
> multitasking issue)
>
> On Thu, 10 Jan 2019 19:30:41 -0500, zMan wrote:
>
>> Semicolons?
>>
> (My laptop doesn't speak emoji.)
>
> Semicolons, yes, but:
>  do <=> {
>  end<=> }
>  switch <=> SELECT
>  ...
> I think Rexx got much of its lexical flavor from PL/I.  But that's easy for
> me to say becase I don't know PL/I.
>
>> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
>>
>>> REXX is lot like C?  I can't think of anything they have in common beyond
>>> the minimum basics of any procedural language.
> Bless Rexx for making ';' and newline very nearly interchangeable, in contrast
> to POSIX Shell script, where they aren't.
>
> -- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[David Spiegel]

R'Shmuel,
Can you please explain what you mean by "... TSO stack mechanism ..." 
and where the documentation is?
(I've never encountered a TSO stack (outside of Rexx) in my 43 years of 
using TSO.)

Thanks and regards,
David

On 2019-01-11 15:17, Seymour J Metz wrote:
> REXX was certainly a great improvement over EXEC, EXEC 2 and *TSO* CLIST, but 
> there is no "VM CLIST". There are a couple of edge cases where REXX is 
> missing something present in the old languages, e.g., integration with the 
> TSO stack mechanism.
>
> As for the PL/I likeness, it is more of a hindrance  than a help; lures you 
> into expecting PL/I behavior in cases where the semantics are very different.
>
> Don't forget SELECT, which came from PL/I and helps to make code more 
> readable.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://nam05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C3330927d53d94a866fc408d67801df78%7C84df9e7fe9f640afb435%7C1%7C0%7C636828346803059565sdata=BgckSUWvHzqVglLz0%2BGIVc2ZoZUsxw5DAZF%2FNsFutVg%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> scott Ford 
> Sent: Friday, January 11, 2019 7:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
> multitasking issue)
>
> You can argue anything is or isn’t , I think what matters is ease of usage
> , platform interchangeability , I.E., Linux and windows for Oorexx.
> The advent of rexx, I started on VM/SP 3 , I think, was a huge improvement
> over the old VM clist language. The old clist to me being more
> clunky . Rexx was easy to learn and have up and running  . This was a g pus
> at least for me.
>
> The PL/1 likeness is the “ if then do” , I wrote a bunch of PL/1 on
> OS/VS2/HASP,  back to n the dark ages.
>
> On Thu, Jan 10, 2019 at 10:18 PM David Crayford  wrote:
>
>> On 11/01/2019 10:27 am, Paul Gilmartin wrote:
>>> Semicolons, yes, but:
>>>   do <=> {
>>>   end<=> }
>>>   switch <=> SELECT
>>>   ...
>>> I think Rexx got much of its lexical flavor from PL/I.  But that's easy
>> for
>>> me to say becase I don't know PL/I.
>>   From Wiki "Rexx was also intended by its creator to be a simplified and
>> easier to learn version of the PL/I 
>> <https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1KuZ2_QAj-lIiZ0vsi9R7gP9mYWbAUVCS6akTtgvJS-DnqovyZRmdGrqGoMWgm7EwiLqZ8ej0c17Tofsf9DD5B582eGmRcLPeB42We7J2CwsGr27oIgC9UZc9zBK4j2mZxtNpOlmdC4InFhP0Xlye-VZLwEL-IgqK4BhM7QZYJj9FCOjyMK9hbLcfq--Wa4hX_N52qg_DnWzLP2tmZWLd3HeVV-waWkQRLA7SqKrJ6501hh0ixJeOyKM4Wma75IglYYp0kYXcZEeTzWomm0sEj0c12DFY6uQMUS33RRK0HmEdAe4HJoBZVOX5LMgjOGI24msdRSkQCUXw3et8tcAawG9lWNzi1WMy0UNhmb1uJmnvtS6lMJnCAXMBQcfss45S1rTrUmhqplcGA_F4zr3nCXWxp1IbgUoT2mfZgTiXGAF2Y_jm3l7SzYcoVvwOhTl3%2Fhttps%253A%252F%252Fen.wikipedia.org%252Fwiki%252FPL%252FIdata=02%7C01%7C%7C3330927d53d94a866fc408d67801df78%7C84df9e7fe9f640afb435%7C1%7C0%7C636828346803059565sdata=QqU92DnewZKJ%2FAxNqRpOiyMZmRVB%2FxMK7YjT4a3tZJ4%3Dreserved=0>
>> programming language"
>>
>> I agree with Steve. There is very little similarity between REXX and C.
>> A case in point would be short circuit evaluation which is fundamental
>> to C and
>> sadly lacking in REXX. There are some similarities between a language
>> like JavaScript and C because of the lineage of most curly bracket
>> languages.
>>
>>
>>>> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
>>>>
>>>>> REXX is lot like C?  I can't think of anything they have in common
>> beyond
>>>>> the minimum basics of any procedural language.
>>> Bless Rexx for making ';' and newline very nearly interchangeable, in
>> contrast
>>> to POSIX Shell script, where they aren't.
>>>
>>> -- 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
>>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

A lot of the syntax comes from PL/I, although not the use of a continuation 
character and not the use of labels (no, signal is not a goto.)


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, January 10, 2019 9:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Thu, 10 Jan 2019 19:30:41 -0500, zMan wrote:

>Semicolons?
>
(My laptop doesn't speak emoji.)

Semicolons, yes, but:
do <=> {
end<=> }
switch <=> SELECT
...
I think Rexx got much of its lexical flavor from PL/I.  But that's easy for
me to say becase I don't know PL/I.

>On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
>
>> REXX is lot like C?  I can't think of anything they have in common beyond
>> the minimum basics of any procedural language.

Bless Rexx for making ';' and newline very nearly interchangeable, in contrast
to POSIX Shell script, where they aren't.

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

Keep in mind that wiki is a mixed bag; its emphasis of secondary sources over 
primary sources tends to damage its reliability. Also, the URL you gave was for 
PL/I rather than for REXX.


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


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Thursday, January 10, 2019 10:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On 11/01/2019 10:27 am, Paul Gilmartin wrote:
> Semicolons, yes, but:
>  do <=> {
>  end<=> }
>  switch <=> SELECT
>  ...
> I think Rexx got much of its lexical flavor from PL/I.  But that's easy for
> me to say becase I don't know PL/I.

 From Wiki "Rexx was also intended by its creator to be a simplified and
easier to learn version of the PL/I 
<https://secure-web.cisco.com/1T_zgNKTuiHHGZ-wMhMaY_Aq4goia3Y_0KIobX6TulyJSMMRpbNpl1BiSRozYv5QnZ4qXwAfPti4QlNm3jf6HtWswKG1xmXYLtRhUjMO0-JCZCDtOl_K_8wkSiHk10oiTsbp-aIQVHijMmECoAVrxktx-DswOhB0oEYg_Ct-6VQNyrYDTdcKX0F7h0eelJePTAzG_E7rW-K6KM6ngnOnJ1QWSvNtaYKO9nzsjOWB57W2p794YBikUCJIrNK3QmAtPU6w4uEESwor3KDkeh3-PERBKoJeex8DWg2m6VURvVuCccl6E7-zaO9Akap-x56aaoE5KvrHG8nNNIFVrof74ze8UNI7rvSX210wS9wR148bhlNmArH-p82RCei8JArZMVAqqY0vMeEDhPzU8OAn2E5He3DqyxHjAU77Ds2kpCug2WVxiUU4bKnKdykTwtR5b/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FPL%2FI>
programming language"

I agree with Steve. There is very little similarity between REXX and C.
A case in point would be short circuit evaluation which is fundamental
to C and
sadly lacking in REXX. There are some similarities between a language
like JavaScript and C because of the lineage of most curly bracket
languages.


>> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
>>
>>> REXX is lot like C?  I can't think of anything they have in common beyond
>>> the minimum basics of any procedural language.
> Bless Rexx for making ';' and newline very nearly interchangeable, in contrast
> to POSIX Shell script, where they aren't.
>
> -- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

REXX was certainly a great improvement over EXEC, EXEC 2 and *TSO* CLIST, but 
there is no "VM CLIST". There are a couple of edge cases where REXX is missing 
something present in the old languages, e.g., integration with the TSO stack 
mechanism.

As for the PL/I likeness, it is more of a hindrance  than a help; lures you 
into expecting PL/I behavior in cases where the semantics are very different.

Don't forget SELECT, which came from PL/I and helps to make code more readable.


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


From: IBM Mainframe Discussion List  on behalf of 
scott Ford 
Sent: Friday, January 11, 2019 7:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

You can argue anything is or isn’t , I think what matters is ease of usage
, platform interchangeability , I.E., Linux and windows for Oorexx.
The advent of rexx, I started on VM/SP 3 , I think, was a huge improvement
over the old VM clist language. The old clist to me being more
clunky . Rexx was easy to learn and have up and running  . This was a g pus
at least for me.

The PL/1 likeness is the “ if then do” , I wrote a bunch of PL/1 on
OS/VS2/HASP,  back to n the dark ages.

On Thu, Jan 10, 2019 at 10:18 PM David Crayford  wrote:

> On 11/01/2019 10:27 am, Paul Gilmartin wrote:
> > Semicolons, yes, but:
> >  do <=> {
> >  end<=> }
> >  switch <=> SELECT
> >  ...
> > I think Rexx got much of its lexical flavor from PL/I.  But that's easy
> for
> > me to say becase I don't know PL/I.
>
>  From Wiki "Rexx was also intended by its creator to be a simplified and
> easier to learn version of the PL/I 
> <https://secure-web.cisco.com/1KuZ2_QAj-lIiZ0vsi9R7gP9mYWbAUVCS6akTtgvJS-DnqovyZRmdGrqGoMWgm7EwiLqZ8ej0c17Tofsf9DD5B582eGmRcLPeB42We7J2CwsGr27oIgC9UZc9zBK4j2mZxtNpOlmdC4InFhP0Xlye-VZLwEL-IgqK4BhM7QZYJj9FCOjyMK9hbLcfq--Wa4hX_N52qg_DnWzLP2tmZWLd3HeVV-waWkQRLA7SqKrJ6501hh0ixJeOyKM4Wma75IglYYp0kYXcZEeTzWomm0sEj0c12DFY6uQMUS33RRK0HmEdAe4HJoBZVOX5LMgjOGI24msdRSkQCUXw3et8tcAawG9lWNzi1WMy0UNhmb1uJmnvtS6lMJnCAXMBQcfss45S1rTrUmhqplcGA_F4zr3nCXWxp1IbgUoT2mfZgTiXGAF2Y_jm3l7SzYcoVvwOhTl3/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FPL%2FI>
> programming language"
>
> I agree with Steve. There is very little similarity between REXX and C.
> A case in point would be short circuit evaluation which is fundamental
> to C and
> sadly lacking in REXX. There are some similarities between a language
> like JavaScript and C because of the lineage of most curly bracket
> languages.
>
>
> >> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
> >>
> >>> REXX is lot like C?  I can't think of anything they have in common
> beyond
> >>> the minimum basics of any procedural language.
> > Bless Rexx for making ';' and newline very nearly interchangeable, in
> contrast
> > to POSIX Shell script, where they aren't.
> >
> > -- 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
>
--
Scott Ford
IDMWORKS
z/OS Development

--
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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

Actually, C was deigned to compile on a PDP-7; despite being used frequently 
for the purpose, it's really not particularly suited for writing operating 
systems. But, of course, even Fortran can, and has, be used for the purpose if 
you're perverse enough.


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


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Friday, January 11, 2019 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

I wasn't arguing I was just stating the fact that REXX is nothing like
C. To state the bloody obvious it's a scripting language and
C was designed to write operating systems. They have different design
goals and both have their strengths and weaknesses.

On 11/01/2019 8:56 pm, scott Ford wrote:
> You can argue anything is or isn’t , I think what matters is ease of usage
> , platform interchangeability , I.E., Linux and windows for Oorexx.
> The advent of rexx, I started on VM/SP 3 , I think, was a huge improvement
> over the old VM clist language. The old clist to me being more
> clunky . Rexx was easy to learn and have up and running  . This was a g pus
> at least for me.
>
> The PL/1 likeness is the “ if then do” , I wrote a bunch of PL/1 on
> OS/VS2/HASP,  back to n the dark ages.
>
> On Thu, Jan 10, 2019 at 10:18 PM David Crayford  wrote:
>
>> On 11/01/2019 10:27 am, Paul Gilmartin wrote:
>>> Semicolons, yes, but:
>>>   do <=> {
>>>   end<=> }
>>>   switch <=> SELECT
>>>   ...
>>> I think Rexx got much of its lexical flavor from PL/I.  But that's easy
>> for
>>> me to say becase I don't know PL/I.
>>   From Wiki "Rexx was also intended by its creator to be a simplified and
>> easier to learn version of the PL/I 
>> <https://secure-web.cisco.com/140VKzEWVR9btwxy-t5ao75tQvXI7HOOImLD_BljTMZawmuPRYZ79xVL4aQDFtwZFlqUYIk3aEZhQwfFkXKDHhuTY5GkOPoB9mVxF9uoKjkp1KTrVXYt-ZHwIeYkGEX2qQAyyJ7t5KrObPqzGRGNYLI1HYWwZ3859pUdV8QCmSwZLeEDNj696ELw4A3mjrGVr6jeXyu6cpX9LnuwsFYHRHvODEsoGVwURlHY8PCKaGz6m_M_pd76uacojs-aaeRJNUdQeUXZyqru-u_BXWBT4naq_fT2gKS3ZaD5Cx2HKfVa5UVw8H2PlX8hByYb21VZ7e9yFStKcVVgHFkY0nShNw29DdElNvVFo7bIizPPljXPuibqbL6H6zojrDBzHA2eD/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FPL%2FI>
>> programming language"
>>
>> I agree with Steve. There is very little similarity between REXX and C.
>> A case in point would be short circuit evaluation which is fundamental
>> to C and
>> sadly lacking in REXX. There are some similarities between a language
>> like JavaScript and C because of the lineage of most curly bracket
>> languages.
>>
>>
>>>> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
>>>>
>>>>> REXX is lot like C?  I can't think of anything they have in common
>> beyond
>>>>> the minimum basics of any procedural language.
>>> Bless Rexx for making ';' and newline very nearly interchangeable, in
>> contrast
>>> to POSIX Shell script, where they aren't.
>>>
>>> -- 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

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

David,

Agreed. No argument here.

On Fri, Jan 11, 2019 at 9:39 AM David Crayford  wrote:

> I wasn't arguing I was just stating the fact that REXX is nothing like
> C. To state the bloody obvious it's a scripting language and
> C was designed to write operating systems. They have different design
> goals and both have their strengths and weaknesses.
>
> On 11/01/2019 8:56 pm, scott Ford wrote:
> > You can argue anything is or isn’t , I think what matters is ease of
> usage
> > , platform interchangeability , I.E., Linux and windows for Oorexx.
> > The advent of rexx, I started on VM/SP 3 , I think, was a huge
> improvement
> > over the old VM clist language. The old clist to me being more
> > clunky . Rexx was easy to learn and have up and running  . This was a g
> pus
> > at least for me.
> >
> > The PL/1 likeness is the “ if then do” , I wrote a bunch of PL/1 on
> > OS/VS2/HASP,  back to n the dark ages.
> >
> > On Thu, Jan 10, 2019 at 10:18 PM David Crayford 
> wrote:
> >
> >> On 11/01/2019 10:27 am, Paul Gilmartin wrote:
> >>> Semicolons, yes, but:
> >>>   do <=> {
> >>>   end<=> }
> >>>   switch <=> SELECT
> >>>   ...
> >>> I think Rexx got much of its lexical flavor from PL/I.  But that's easy
> >> for
> >>> me to say becase I don't know PL/I.
> >>   From Wiki "Rexx was also intended by its creator to be a simplified
> and
> >> easier to learn version of the PL/I  >
> >> programming language"
> >>
> >> I agree with Steve. There is very little similarity between REXX and C.
> >> A case in point would be short circuit evaluation which is fundamental
> >> to C and
> >> sadly lacking in REXX. There are some similarities between a language
> >> like JavaScript and C because of the lineage of most curly bracket
> >> languages.
> >>
> >>
>  On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
> 
> > REXX is lot like C?  I can't think of anything they have in common
> >> beyond
> > the minimum basics of any procedural language.
> >>> Bless Rexx for making ';' and newline very nearly interchangeable, in
> >> contrast
> >>> to POSIX Shell script, where they aren't.
> >>>
> >>> -- 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[David Crayford]

I wasn't arguing I was just stating the fact that REXX is nothing like 
C. To state the bloody obvious it's a scripting language and
C was designed to write operating systems. They have different design 
goals and both have their strengths and weaknesses.


On 11/01/2019 8:56 pm, scott Ford wrote:

You can argue anything is or isn’t , I think what matters is ease of usage
, platform interchangeability , I.E., Linux and windows for Oorexx.
The advent of rexx, I started on VM/SP 3 , I think, was a huge improvement
over the old VM clist language. The old clist to me being more
clunky . Rexx was easy to learn and have up and running  . This was a g pus
at least for me.

The PL/1 likeness is the “ if then do” , I wrote a bunch of PL/1 on
OS/VS2/HASP,  back to n the dark ages.

On Thu, Jan 10, 2019 at 10:18 PM David Crayford  wrote:


On 11/01/2019 10:27 am, Paul Gilmartin wrote:

Semicolons, yes, but:
  do <=> {
  end<=> }
  switch <=> SELECT
  ...
I think Rexx got much of its lexical flavor from PL/I.  But that's easy

for

me to say becase I don't know PL/I.

  From Wiki "Rexx was also intended by its creator to be a simplified and
easier to learn version of the PL/I 
programming language"

I agree with Steve. There is very little similarity between REXX and C.
A case in point would be short circuit evaluation which is fundamental
to C and
sadly lacking in REXX. There are some similarities between a language
like JavaScript and C because of the lineage of most curly bracket
languages.



On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:


REXX is lot like C?  I can't think of anything they have in common

beyond

the minimum basics of any procedural language.

Bless Rexx for making ';' and newline very nearly interchangeable, in

contrast

to POSIX Shell script, where they aren't.

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[David Spiegel]

VM CLIST?! ... No! ... EXEC and EXEC2

On 2019-01-11 07:56, scott Ford wrote:
> You can argue anything is or isn’t , I think what matters is ease of usage
> , platform interchangeability , I.E., Linux and windows for Oorexx.
> The advent of rexx, I started on VM/SP 3 , I think, was a huge improvement
> over the old VM clist language. The old clist to me being more
> clunky . Rexx was easy to learn and have up and running  . This was a g pus
> at least for me.
>
> The PL/1 likeness is the “ if then do” , I wrote a bunch of PL/1 on
> OS/VS2/HASP,  back to n the dark ages.
>
> On Thu, Jan 10, 2019 at 10:18 PM David Crayford  wrote:
>
>> On 11/01/2019 10:27 am, Paul Gilmartin wrote:
>>> Semicolons, yes, but:
>>>   do <=> {
>>>   end<=> }
>>>   switch <=> SELECT
>>>   ...
>>> I think Rexx got much of its lexical flavor from PL/I.  But that's easy
>> for
>>> me to say becase I don't know PL/I.
>>   From Wiki "Rexx was also intended by its creator to be a simplified and
>> easier to learn version of the PL/I 
>> 
>> programming language"
>>
>> I agree with Steve. There is very little similarity between REXX and C.
>> A case in point would be short circuit evaluation which is fundamental
>> to C and
>> sadly lacking in REXX. There are some similarities between a language
>> like JavaScript and C because of the lineage of most curly bracket
>> languages.
>>
>>
 On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:

> REXX is lot like C?  I can't think of anything they have in common
>> beyond
> the minimum basics of any procedural language.
>>> Bless Rexx for making ';' and newline very nearly interchangeable, in
>> contrast
>>> to POSIX Shell script, where they aren't.
>>>
>>> -- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

You can argue anything is or isn’t , I think what matters is ease of usage
, platform interchangeability , I.E., Linux and windows for Oorexx.
The advent of rexx, I started on VM/SP 3 , I think, was a huge improvement
over the old VM clist language. The old clist to me being more
clunky . Rexx was easy to learn and have up and running  . This was a g pus
at least for me.

The PL/1 likeness is the “ if then do” , I wrote a bunch of PL/1 on
OS/VS2/HASP,  back to n the dark ages.

On Thu, Jan 10, 2019 at 10:18 PM David Crayford  wrote:

> On 11/01/2019 10:27 am, Paul Gilmartin wrote:
> > Semicolons, yes, but:
> >  do <=> {
> >  end<=> }
> >  switch <=> SELECT
> >  ...
> > I think Rexx got much of its lexical flavor from PL/I.  But that's easy
> for
> > me to say becase I don't know PL/I.
>
>  From Wiki "Rexx was also intended by its creator to be a simplified and
> easier to learn version of the PL/I 
> programming language"
>
> I agree with Steve. There is very little similarity between REXX and C.
> A case in point would be short circuit evaluation which is fundamental
> to C and
> sadly lacking in REXX. There are some similarities between a language
> like JavaScript and C because of the lineage of most curly bracket
> languages.
>
>
> >> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
> >>
> >>> REXX is lot like C?  I can't think of anything they have in common
> beyond
> >>> the minimum basics of any procedural language.
> > Bless Rexx for making ';' and newline very nearly interchangeable, in
> contrast
> > to POSIX Shell script, where they aren't.
> >
> > -- 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[David Crayford]

On 11/01/2019 10:27 am, Paul Gilmartin wrote:

Semicolons, yes, but:
 do <=> {
 end<=> }
 switch <=> SELECT
 ...
I think Rexx got much of its lexical flavor from PL/I.  But that's easy for
me to say becase I don't know PL/I.


From Wiki "Rexx was also intended by its creator to be a simplified and 
easier to learn version of the PL/I  
programming language"


I agree with Steve. There is very little similarity between REXX and C. 
A case in point would be short circuit evaluation which is fundamental 
to C and
sadly lacking in REXX. There are some similarities between a language 
like JavaScript and C because of the lineage of most curly bracket 
languages.




On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:


REXX is lot like C?  I can't think of anything they have in common beyond
the minimum basics of any procedural language.

Bless Rexx for making ';' and newline very nearly interchangeable, in contrast
to POSIX Shell script, where they aren't.

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Thu, 10 Jan 2019 19:30:41 -0500, zMan wrote:

>Semicolons?
> 
(My laptop doesn't speak emoji.)

Semicolons, yes, but:
do <=> {
end<=> }
switch <=> SELECT
...
I think Rexx got much of its lexical flavor from PL/I.  But that's easy for
me to say becase I don't know PL/I.

>On Thu, Jan 10, 2019 at 6:48 PM Steve Smith wrote:
>
>> REXX is lot like C?  I can't think of anything they have in common beyond
>> the minimum basics of any procedural language.

Bless Rexx for making ';' and newline very nearly interchangeable, in contrast
to POSIX Shell script, where they aren't.

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

I like the semicolons ..lol

On Thu, Jan 10, 2019 at 7:51 PM scott Ford  wrote:

> Maybe you should read about Mike who wrote rexx, which I have used since
> 1984...
> It’s the structure
>
> On Thu, Jan 10, 2019 at 7:31 PM zMan  wrote:
>
>> Semicolons?
>>
>> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith  wrote:
>>
>> > REXX is lot like C?  I can't think of anything they have in common
>> beyond
>> > the minimum basics of any procedural language.
>> >
>> > sas
>> >
>> > On Wed, Jan 9, 2019 at 8:43 PM scott Ford  wrote:
>> >
>> > > APL sounds painful unless your into pain. I learned Rexx after
>> Assembler,
>> > > Cobol and PL/1.
>> > > I always thought PL/1 was clever with the “dos” then I learned rexx
>> which
>> > > is a lot like C ..
>> > >
>> > > Regards,
>> > > Scott
>> >
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> >
>>
>>
>> --
>> zMan -- "I've got a mainframe and I'm not afraid to use it"
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

Maybe you should read about Mike who wrote rexx, which I have used since
1984...
It’s the structure

On Thu, Jan 10, 2019 at 7:31 PM zMan  wrote:

> Semicolons?
>
> On Thu, Jan 10, 2019 at 6:48 PM Steve Smith  wrote:
>
> > REXX is lot like C?  I can't think of anything they have in common beyond
> > the minimum basics of any procedural language.
> >
> > sas
> >
> > On Wed, Jan 9, 2019 at 8:43 PM scott Ford  wrote:
> >
> > > APL sounds painful unless your into pain. I learned Rexx after
> Assembler,
> > > Cobol and PL/1.
> > > I always thought PL/1 was clever with the “dos” then I learned rexx
> which
> > > is a lot like C ..
> > >
> > > Regards,
> > > Scott
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[zMan]

Semicolons?

On Thu, Jan 10, 2019 at 6:48 PM Steve Smith  wrote:

> REXX is lot like C?  I can't think of anything they have in common beyond
> the minimum basics of any procedural language.
>
> sas
>
> On Wed, Jan 9, 2019 at 8:43 PM scott Ford  wrote:
>
> > APL sounds painful unless your into pain. I learned Rexx after Assembler,
> > Cobol and PL/1.
> > I always thought PL/1 was clever with the “dos” then I learned rexx which
> > is a lot like C ..
> >
> > Regards,
> > Scott
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Steve Smith]

REXX is lot like C?  I can't think of anything they have in common beyond
the minimum basics of any procedural language.

sas

On Wed, Jan 9, 2019 at 8:43 PM scott Ford  wrote:

> APL sounds painful unless your into pain. I learned Rexx after Assembler,
> Cobol and PL/1.
> I always thought PL/1 was clever with the “dos” then I learned rexx which
> is a lot like C ..
>
> Regards,
> Scott

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[scott Ford]

APL sounds painful unless your into pain. I learned Rexx after Assembler,
Cobol and PL/1.
I always thought PL/1 was clever with the “dos” then I learned rexx which
is a lot like C ..

Regards,
Scott

On Tue, Jan 8, 2019 at 6:53 PM Schuffenhauer, Mark 
wrote:

> APL was miserable on the QWERTY card punch.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Gibney, Dave
> Sent: Tuesday, January 08, 2019 5:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue
> multitasking issue)
>
> Careful, *@$$! Probably does something in APL :)
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Pew, Curtis G
> > Sent: Tuesday, January 08, 2019 1:01 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch
> > issue multitasking issue)
> >
> > On Jan 8, 2019, at 2:48 PM, Paul Gilmartin <000433f07816-dmarc-
> > requ...@listserv.ua.edu> wrote:
> > >
> > >> Pew, Curtis G wrote on 1/8/19 3:05 PM:
> > >>> On Jan 8, 2019, at 2:03 PM, Tony Thigpen wrote:
> > >>>>
> > >>>> "C is the first write-once, read-never language."
> > >>>
> > >>> Not even close; APL was around nearly a decade before C.
> > >>>
> > > Assembler?
> > >
> >
> > While it’s not easy or much fun, I’ve read and even understood a lot
> > of assembler code.
> >
> > Now, I’ll admit that my only real exposure to APL was a two or three
> > week module in my undergraduate physics lab in 1980 or ’81, but I do
> > vividly remember working for hours on a program and then coming back
> > the next day, looking at the two or three lines I’d written, and
> > wondering what the *@$$! they were supposed to do.
> >
> >
> > --
> > Pew, Curtis G
> > curtis@austin.utexas.edu
> > ITS Systems/Core/Administrative Services
> >
> >
> > --
> > 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
> DISCLAIMER: This email and any attachments may contain confidential
> information that is intended solely for use by the intended recipient(s).
> If you are not the intended recipient, you are strictly prohibited from
> disclosing, copying, distributing or using any of the information contained
> in the communication. If you received this email in error, please contact
> the sender by reply email and immediately delete the communication.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Schuffenhauer, Mark]

APL was miserable on the QWERTY card punch.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Tuesday, January 08, 2019 5:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

Careful, *@$$! Probably does something in APL :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Pew, Curtis G
> Sent: Tuesday, January 08, 2019 1:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch
> issue multitasking issue)
>
> On Jan 8, 2019, at 2:48 PM, Paul Gilmartin <000433f07816-dmarc-
> requ...@listserv.ua.edu> wrote:
> >
> >> Pew, Curtis G wrote on 1/8/19 3:05 PM:
> >>> On Jan 8, 2019, at 2:03 PM, Tony Thigpen wrote:
> >>>>
> >>>> "C is the first write-once, read-never language."
> >>>
> >>> Not even close; APL was around nearly a decade before C.
> >>>
> > Assembler?
> >
>
> While it’s not easy or much fun, I’ve read and even understood a lot
> of assembler code.
>
> Now, I’ll admit that my only real exposure to APL was a two or three
> week module in my undergraduate physics lab in 1980 or ’81, but I do
> vividly remember working for hours on a program and then coming back
> the next day, looking at the two or three lines I’d written, and
> wondering what the *@$$! they were supposed to do.
>
>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services
>
>
> --
> 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
DISCLAIMER: This email and any attachments may contain confidential information 
that is intended solely for use by the intended recipient(s). If you are not 
the intended recipient, you are strictly prohibited from disclosing, copying, 
distributing or using any of the information contained in the communication. If 
you received this email in error, please contact the sender by reply email and 
immediately delete the communication.

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Gibney, Dave]

Careful, *@$$! Probably does something in APL :) 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Pew, Curtis G
> Sent: Tuesday, January 08, 2019 1:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue
> multitasking issue)
> 
> On Jan 8, 2019, at 2:48 PM, Paul Gilmartin <000433f07816-dmarc-
> requ...@listserv.ua.edu> wrote:
> >
> >> Pew, Curtis G wrote on 1/8/19 3:05 PM:
> >>> On Jan 8, 2019, at 2:03 PM, Tony Thigpen wrote:
> >>>>
> >>>> "C is the first write-once, read-never language."
> >>>
> >>> Not even close; APL was around nearly a decade before C.
> >>>
> > Assembler?
> >
> 
> While it’s not easy or much fun, I’ve read and even understood a lot of
> assembler code.
> 
> Now, I’ll admit that my only real exposure to APL was a two or three week
> module in my undergraduate physics lab in 1980 or ’81, but I do vividly
> remember working for hours on a program and then coming back the next
> day, looking at the two or three lines I’d written, and wondering what the
> *@$$! they were supposed to do.
> 
> 
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services
> 
> 
> --
> 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

"You can write Fortran in any language."


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


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Tuesday, January 8, 2019 6:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

Any programming language can be "write only" in the hands of the wrong person.  
:-(


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Tuesday, January 8, 2019 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

REXX write only? I beg to differ. Yes, it has a few quirks, but I find it 
eminently readable.


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


From: IBM Mainframe Discussion List  on behalf of 
Tony Thigpen 
Sent: Tuesday, January 8, 2019 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

FYI, I also put REXX into that category if someone tries to be 'fancy'.
And I use REXX a lot.

I remember a programmer, back in '81, that was told that he could no
longer use RPG, but must use COBOL. He was upset so started using
Spanish variable names. This was not California, but was North Alabama,
where few spoke it. (Yes, management did catch him after a month or so.)

Tony Thigpen

Pew, Curtis G wrote on 1/8/19 3:05 PM:
> On Jan 8, 2019, at 2:03 PM, Tony Thigpen  wrote:
>>
>> "C is the first write-once, read-never language."
>>
>
> Not even close; APL was around nearly a decade before 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

--
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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Frank Swarbrick]

Any programming language can be "write only" in the hands of the wrong person.  
:-(


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Tuesday, January 8, 2019 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

REXX write only? I beg to differ. Yes, it has a few quirks, but I find it 
eminently readable.


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


From: IBM Mainframe Discussion List  on behalf of 
Tony Thigpen 
Sent: Tuesday, January 8, 2019 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

FYI, I also put REXX into that category if someone tries to be 'fancy'.
And I use REXX a lot.

I remember a programmer, back in '81, that was told that he could no
longer use RPG, but must use COBOL. He was upset so started using
Spanish variable names. This was not California, but was North Alabama,
where few spoke it. (Yes, management did catch him after a month or so.)

Tony Thigpen

Pew, Curtis G wrote on 1/8/19 3:05 PM:
> On Jan 8, 2019, at 2:03 PM, Tony Thigpen  wrote:
>>
>> "C is the first write-once, read-never language."
>>
>
> Not even close; APL was around nearly a decade before 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

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[ronjhawkins1]

Bernd,

I'm guessing that being an English-like language did not help the original
coders.

Ron

Ron Hawkins
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) | m: +61 400029610 | h: +61
387399252 | email: ron.hawk...@ipsicsopt.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Bernd Oppolzer
Sent: Wednesday, 9 January 2019 07:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Unreadable code (Was: Concurrent Server Task
Dispatch issue multitasking issue)

Very nice. I once got a task to rewrite or migrate some programs which
originated in Poland; they were full of polish variable names. This was very
hard because I had no idea what that variables meant ...

I remember KONIEC, which, IIRC, means end-of-file :-)

after a week or so, I understood at least some polish words, the word for
counter etc. (which I forgot).

This first gave me an idea how important natural language is for the
understanding of source code (even if there are no comments).

Kind regards

Bernd


Am 08.01.2019 um 21:19 schrieb Tony Thigpen:
> FYI, I also put REXX into that category if someone tries to be 
> 'fancy'. And I use REXX a lot.
>
> I remember a programmer, back in '81, that was told that he could no 
> longer use RPG, but must use COBOL. He was upset so started using 
> Spanish variable names. This was not California, but was North 
> Alabama, where few spoke it. (Yes, management did catch him after a 
> month or so.)
>
> Tony Thigpen
>
> Pew, Curtis G wrote on 1/8/19 3:05 PM:
>> On Jan 8, 2019, at 2:03 PM, Tony Thigpen  wrote:
>>>
>>> "C is the first write-once, read-never language."
>>>
>>
>> Not even close; APL was around nearly a decade before 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Tony Thigpen]

By fancy, I mean stuff like 10 nested functions.

(from the top of my head and I bet I missed a paren)

if 
h2d(right(strip(substr(x,5,10)),'B')+strip(right(substr(,5,10),5),'B') 
= strip(right(substr(input.4,5,10),6),'B')

  then do

Tony Thigpen

Paul Gilmartin wrote on 1/8/19 3:48 PM:

On Tue, 8 Jan 2019 15:19:28 -0500, Tony Thigpen wrote:


FYI, I also put REXX into that category if someone tries to be 'fancy'.
And I use REXX a lot.


(To what are you replying?  Did this thread come from BITNET?)

What do you consider "fancy" or "unreadable" Rexx?  I know a FORTRAN
programmer who was overjoyed when I showed him how to use associative
arrays to simplify his code.  But I read comments from Rexx programmers
who yet insist that compound symbols must have positive integer tails and
the upper bound in the 0th member.

How about using TRANSLATE() to re-order a string?

Relying on PROCEDURE to reset ADDRESS, SIGNAL ON, etc.?

Using relational expressions as arithmetic terms?

Others worse?


I remember a programmer, back in '81, that was told that he could no
longer use RPG, but must use COBOL. He was upset so started using
Spanish variable names. This was not California, but was North Alabama,
where few spoke it. (Yes, management did catch him after a month or so.)




Pew, Curtis G wrote on 1/8/19 3:05 PM:

On Jan 8, 2019, at 2:03 PM, Tony Thigpen wrote:


"C is the first write-once, read-never language."


Not even close; APL was around nearly a decade before C.


Assembler?

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

The address after F: might actually be necessary; the address before return, 
not so much.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, January 8, 2019 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Tue, 8 Jan 2019 20:59:26 +, Seymour J Metz wrote:

>> But I read comments from Rexx programmers who yet insist that compound
>>symbols must have positive integer tails and the upper bound in the 0th 
>>member.
>
>What is a "Rexx programmer"? It doesn't sound like they actually know REXX.
>
FOTRAN refugees?

>> Relying on PROCEDURE to reset ADDRESS, SIGNAL ON, etc.?
>
>Reset? AFAIK, the environment is intact after return. Or do you mean falling 
>into a procedure statement, which I had assume was invalid.
>
I've seen such as:
F: procedure
ADDRESS ISREDIT
[ ... code ... ]
ADDRESS TSO
RETURN

Or similarly inserting a needless ADDRESS after the call to F.

>> Using relational expressions as arithmetic terms?
>
>Perfectly reasonable if you're used to a language with bit or Boolean data 
>types.
>
I'll confess to having replaced:
if A==B then X = 'FooBar'; else X = ''
with:
X = copies( 'FooBar', A==B )
>______
>From: Paul Gilmartin
>Sent: Tuesday, January 8, 2019 3:48 PM

>Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
>multitasking issue)
>...
>(To what are you replying?  Did this thread come from BITNET?)
>
I was misled because someone started the first ply of a changed subject with:
Subject: Re: Unreadable ...

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Tue, 8 Jan 2019 20:59:26 +, Seymour J Metz wrote:

>> But I read comments from Rexx programmers who yet insist that compound 
>>symbols must have positive integer tails and the upper bound in the 0th 
>>member.
>
>What is a "Rexx programmer"? It doesn't sound like they actually know REXX.
> 
FOTRAN refugees?

>> Relying on PROCEDURE to reset ADDRESS, SIGNAL ON, etc.?
>
>Reset? AFAIK, the environment is intact after return. Or do you mean falling 
>into a procedure statement, which I had assume was invalid.
>
I've seen such as:
F: procedure
ADDRESS ISREDIT
[ ... code ... ]
ADDRESS TSO
RETURN

Or similarly inserting a needless ADDRESS after the call to F.

>> Using relational expressions as arithmetic terms?
>
>Perfectly reasonable if you're used to a language with bit or Boolean data 
>types.
>
I'll confess to having replaced:
if A==B then X = 'FooBar'; else X = ''
with:
X = copies( 'FooBar', A==B )
>__
>From: Paul Gilmartin 
>Sent: Tuesday, January 8, 2019 3:48 PM

>Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
>multitasking issue)
>...
>(To what are you replying?  Did this thread come from BITNET?)
>
I was misled because someone started the first ply of a changed subject with:
Subject: Re: Unreadable ...

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Pew, Curtis G]

On Jan 8, 2019, at 2:48 PM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> Pew, Curtis G wrote on 1/8/19 3:05 PM:
>>> On Jan 8, 2019, at 2:03 PM, Tony Thigpen wrote:
 
 "C is the first write-once, read-never language."
>>> 
>>> Not even close; APL was around nearly a decade before C.
>>> 
> Assembler?
> 

While it’s not easy or much fun, I’ve read and even understood a lot of 
assembler code.

Now, I’ll admit that my only real exposure to APL was a two or three week 
module in my undergraduate physics lab in 1980 or ’81, but I do vividly 
remember working for hours on a program and then coming back the next day, 
looking at the two or three lines I’d written, and wondering what the *@$$! 
they were supposed to do.


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

> But I read comments from Rexx programmers who yet insist that compound 
>symbols must have positive integer tails and the upper bound in the 0th member.

What is a "Rexx programmer"? It doesn't sound like they actually know REXX.

> How about using TRANSLATE() to re-order a string?

I'd at it needs a comment.

> Relying on PROCEDURE to reset ADDRESS, SIGNAL ON, etc.?

Reset? AFAIK, the environment is intact after return. Or do you mean falling 
into a procedure statement, which I had assume was invalid.

> Using relational expressions as arithmetic terms?

Perfectly reasonable if you're used to a language with bit or Boolean data 
types.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, January 8, 2019 3:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Tue, 8 Jan 2019 15:19:28 -0500, Tony Thigpen wrote:

>FYI, I also put REXX into that category if someone tries to be 'fancy'.
>And I use REXX a lot.
>
(To what are you replying?  Did this thread come from BITNET?)

What do you consider "fancy" or "unreadable" Rexx?  I know a FORTRAN
programmer who was overjoyed when I showed him how to use associative
arrays to simplify his code.  But I read comments from Rexx programmers
who yet insist that compound symbols must have positive integer tails and
the upper bound in the 0th member.

How about using TRANSLATE() to re-order a string?

Relying on PROCEDURE to reset ADDRESS, SIGNAL ON, etc.?

Using relational expressions as arithmetic terms?

Others worse?

>I remember a programmer, back in '81, that was told that he could no
>longer use RPG, but must use COBOL. He was upset so started using
>Spanish variable names. This was not California, but was North Alabama,
>where few spoke it. (Yes, management did catch him after a month or so.)


>Pew, Curtis G wrote on 1/8/19 3:05 PM:
>> On Jan 8, 2019, at 2:03 PM, Tony Thigpen wrote:
>>>
>>> "C is the first write-once, read-never language."
>>
>> Not even close; APL was around nearly a decade before C.
>>
Assembler?

-- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

It's not enough to know the language; if the programmer doesn't include the 
necessary comments to provide context then you're in trouble.


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


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, January 8, 2019 3:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

Very nice. I once got a task to rewrite or migrate
some programs which originated in Poland; they were
full of polish variable names. This was very hard because
I had no idea what that variables meant ...

I remember KONIEC, which, IIRC, means end-of-file :-)

after a week or so, I understood at least some polish words,
the word for counter etc. (which I forgot).

This first gave me an idea how important natural language is
for the understanding of source code (even if there are
no comments).

Kind regards

Bernd


Am 08.01.2019 um 21:19 schrieb Tony Thigpen:
> FYI, I also put REXX into that category if someone tries to be
> 'fancy'. And I use REXX a lot.
>
> I remember a programmer, back in '81, that was told that he could no
> longer use RPG, but must use COBOL. He was upset so started using
> Spanish variable names. This was not California, but was North
> Alabama, where few spoke it. (Yes, management did catch him after a
> month or so.)
>
> Tony Thigpen
>
> Pew, Curtis G wrote on 1/8/19 3:05 PM:
>> On Jan 8, 2019, at 2:03 PM, Tony Thigpen  wrote:
>>>
>>> "C is the first write-once, read-never language."
>>>
>>
>> Not even close; APL was around nearly a decade before 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

Well, I wouldn't call it English-like, and the semantics of signal are 
confusing, but if you're familiar with any other block-oriented language than 
REXX shouldn't be confusing, except for things like being used to different 
nomenclature, e.g., case rather than select.


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


From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Tuesday, January 8, 2019 3:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

On Tue, Jan 8, 2019 at 3:42 PM Seymour J Metz  wrote:

>REXX write only? I beg to differ. Yes, it has a few quirks, but I find it 
>eminently readable.



Indeed. It's English-like and about as readable as any programming language 
gets. Unless Tony meant "Because it Just Works, I never have to go back and 
look at it again"?


--
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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Bernd Oppolzer]

Very nice. I once got a task to rewrite or migrate
some programs which originated in Poland; they were
full of polish variable names. This was very hard because
I had no idea what that variables meant ...

I remember KONIEC, which, IIRC, means end-of-file :-)

after a week or so, I understood at least some polish words,
the word for counter etc. (which I forgot).

This first gave me an idea how important natural language is
for the understanding of source code (even if there are
no comments).

Kind regards

Bernd


Am 08.01.2019 um 21:19 schrieb Tony Thigpen:
FYI, I also put REXX into that category if someone tries to be 
'fancy'. And I use REXX a lot.


I remember a programmer, back in '81, that was told that he could no 
longer use RPG, but must use COBOL. He was upset so started using 
Spanish variable names. This was not California, but was North 
Alabama, where few spoke it. (Yes, management did catch him after a 
month or so.)


Tony Thigpen

Pew, Curtis G wrote on 1/8/19 3:05 PM:

On Jan 8, 2019, at 2:03 PM, Tony Thigpen  wrote:


"C is the first write-once, read-never language."



Not even close; APL was around nearly a decade before C.






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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Paul Gilmartin]

On Tue, 8 Jan 2019 15:19:28 -0500, Tony Thigpen wrote:

>FYI, I also put REXX into that category if someone tries to be 'fancy'.
>And I use REXX a lot.
> 
(To what are you replying?  Did this thread come from BITNET?)

What do you consider "fancy" or "unreadable" Rexx?  I know a FORTRAN
programmer who was overjoyed when I showed him how to use associative
arrays to simplify his code.  But I read comments from Rexx programmers
who yet insist that compound symbols must have positive integer tails and
the upper bound in the 0th member.

How about using TRANSLATE() to re-order a string?

Relying on PROCEDURE to reset ADDRESS, SIGNAL ON, etc.?

Using relational expressions as arithmetic terms?

Others worse?

>I remember a programmer, back in '81, that was told that he could no
>longer use RPG, but must use COBOL. He was upset so started using
>Spanish variable names. This was not California, but was North Alabama,
>where few spoke it. (Yes, management did catch him after a month or so.)


>Pew, Curtis G wrote on 1/8/19 3:05 PM:
>> On Jan 8, 2019, at 2:03 PM, Tony Thigpen wrote:
>>>
>>> "C is the first write-once, read-never language."
>>
>> Not even close; APL was around nearly a decade before C.
>> 
Assembler?

-- gil

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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Phil Smith III]

On Tue, Jan 8, 2019 at 3:42 PM Seymour J Metz  wrote:

>REXX write only? I beg to differ. Yes, it has a few quirks, but I find it 
>eminently readable.

 

Indeed. It's English-like and about as readable as any programming language 
gets. Unless Tony meant "Because it Just Works, I never have to go back and 
look at it again"?


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

Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)

[Seymour J Metz]

REXX write only? I beg to differ. Yes, it has a few quirks, but I find it 
eminently readable.


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


From: IBM Mainframe Discussion List  on behalf of 
Tony Thigpen 
Sent: Tuesday, January 8, 2019 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unreadable code (Was: Concurrent Server Task Dispatch issue 
multitasking issue)

FYI, I also put REXX into that category if someone tries to be 'fancy'.
And I use REXX a lot.

I remember a programmer, back in '81, that was told that he could no
longer use RPG, but must use COBOL. He was upset so started using
Spanish variable names. This was not California, but was North Alabama,
where few spoke it. (Yes, management did catch him after a month or so.)

Tony Thigpen

Pew, Curtis G wrote on 1/8/19 3:05 PM:
> On Jan 8, 2019, at 2:03 PM, Tony Thigpen  wrote:
>>
>> "C is the first write-once, read-never language."
>>
>
> Not even close; APL was around nearly a decade before 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