Re: IBM Announces the z/OS Container Platform

[Timothy Sipples]

The documentation for IBM z/OS Container Platform is now available here:

https://www.ibm.com/docs/en/zoscp/1.1.0

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: Learning one's tools

[Bob Bridges]

Boy, ain't THAT the truth!, he says sadly, thinking of an app he didn't write 
and is now responsible for maintaining.

This thing passes multiple values between programs using (if I understand it 
correctly) a single character string consisting of many assignment statements, 
which are then parsed and evaluated upon returning to the calling program.  Me, 
I probably would've used ISPF pool variables, but I'm not sure that would be 
easier to follow.  So far I don't mess with it much; it works.

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

/* Every year, on April 15, all members of Congress would be placed in 
individual prison cells with the necessary tax forms and a copy of the Tax 
Code. They would remain locked in the cells, without food or water, until they 
had completed their tax returns and successfully undergone a full IRS audit. Of 
course this system would probably result in a severe shortage of 
congresspersons. But there might also be some drawbacks. -Dave Barry's plan to 
simplify the tax code, 2000-04-09 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, March 17, 2024 18:46

Expect the code to be modified by someone with significantly less knowledge of 
the problem domain, even if they are an expert in the language.

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

Re: With IBM planning (planned) dropping support for SNA / 802.3

[Timothy Sipples]

Binyamin Dissen wrote:
>With IBM planning (planned) dropping support for SNA / 802.3, does that
>mean that application code using LU6.2 will stop working?
>Or will VTAM continue to support LU6.2 code?

IBM is dropping support for “classic” SNA and pre-SNA “wire” protocols 
effective with z/OS 3.1 and the machine models after the IBM z16 models, 
whichever you deploy first. One important reason is that it’s impossible to 
secure these classic wire protocols without breaking compatibility. The best 
SNA can do on its own is TDES session-level encryption, and that’s just not 
good enough (and hasn’t been for a while).

IBM is *NOT* dropping support for SNA! Just use Enterprise Extender (EE), also 
known as SNA over UDP and IETF RFC 2353. Enterprise Extender was first 
introduced in OS/390 2.7 in 1999 — a quarter century ago. Every z/OS release 
includes Enterprise Extender in the base operating system. Enterprise Extender 
can be well secured (we recommend it!), and often you’ll get some performance 
benefits. It also supports every link type that UDP supports (pretty much 
everything).

SNA also remains available via FICON Channel-to-Channel (CTC) links. FICON CTC 
links can be well secured using Fibre Channel Endpoint Security.

Use z/OS Health Check APAR OA62208 to determine whether your z/OS network 
configuration needs to be adjusted so that you’re only using Enterprise 
Extender, other forms of TCP/IP, and/or FICON CTC links. The PTFs for this APAR 
are available for z/OS 2.3, 2.4, and 2.5.

https://www.ibm.com/support/pages/apar/OA62208

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Mike Schwab]

https://github.com/CBTTape/CBT993

Probably other CBT tape members to process.

On Sun, Mar 17, 2024 at 7:11 PM Rupert Reynolds  wrote:
>
> SMF logging of data for management information? I never did much with SMF,
> but I can't see why not.
>
> I did briefly consider being able to parse existing mapping macros, but
> that's bound to be a bigger job than it seems, especially now I'm a bit
> rusty and only have Hercules to play with.
>
> Structures (maybe 'map' because 'str' is already short for the most basic
> type of 'string'). And pointers to them, yes. Wouldn't be without them :-)
>
> I'll probably be old and slow, or losing my concentration, before it's even
> half finished. Still, it keeps me out of mischief when I'm not at work or
> converting the van for mobile glamping  :-)
>
> Roops
>
> On Sun, 17 Mar 2024, 18:31 Seymour J Metz,  wrote:
>
> > I probably would use ":=" for assignment and "=" for equality.
> >
> > Are you supporting SMF-like structures?
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> > עַם יִשְׂרָאֵל חַי
> > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Rupert Reynolds 
> > Sent: Sunday, March 17, 2024 2:08 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> > question
> >
> > It's too soon to publish much, especially when I have a full time job doing
> > something else. To be honest I probably never will, because it only suits
> > my pet bigotries :-)
> >
> > But briefly, I looked at day 1 notes (on back of a gas bill). They included
> > these, not all of which will ever make it into use of course:
> >
> > . fairly terse {} syntax, borrowing from 'C' etc.
> >
> > . strongly typed by default
> >
> > . one type is bignum--arbitrary precision and base arithmetic, trig, logs
> >
> > . correctness and flexibility more important than speed (like external
> > functions in Rexx scripts, for example)
> >
> > . project to include thorough test cases, and any bugs/unintended quirks in
> > either impl or tests will be fixed ruthlessly, not supported. If it fails
> > the test, it is not the real thing.
> >
> > . compiled code could include interpreter for scripting
> >
> > . preserves case, but keywords and functions etc. not case sensitive
> >
> > . all keywords can be abbreviated (eg. if min abbreviation is 3, 'fun' is
> > same as 'function')
> >
> > . '=' not required for assignment!
> >
> > . ability to convert 'C' style strings and call 'C' code
> >
> > . all built-in functions for handling null-terminated data and UTF-16 to be
> > prefixed gk_ (short for "ghastly kludge" ;-) )
> >
> > Feel free to laugh/crjticise, but please be kind--I was drinking during
> > lockdown when I finished that list :-)
> >
> > I made some progress on the bignum logarithms and trig early, borrowing
> > heavily on the external Rexx functions I used under Windows.
> >
> > It does basics such as finding and moving files interpreted, so I can use
> > it to test my Rexx admin scripts, and vice versa, but there are *huge*
> > gaps, and I'm moving house this year, so... :-)
> >
> > Roops
> >
> >
> > On Sun, 17 Mar 2024, 16:58 Seymour J Metz,  wrote:
> >
> > > >  I'm developing a language
> > >
> > > Have you published any details?
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > > עַם יִשְׂרָאֵל חַי
> > > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on behalf
> > > of Rupert Reynolds 
> > > Sent: Saturday, March 16, 2024 9:07 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> > > question
> > >
> > > My experience of modern scripting languages, compared with classic Rexx,
> > is
> > > that they all do something new more easily, but also I can't think of one
> > > that doesn't have an obvious pitfall (such as, for example, stumbling
> > badly
> > > over certain byte values such as NUL in strings).
> > >
> > > Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
> > > certain old-fashioned quirks, are still sometimes what I reach for when I
> > > want to process some data while avoiding those pitfalls.
> > >
> > > The differences are so strong to me that I'm developing a language which
> > is
> > > effectively the best bits (IMHO) of Rexx, C and even older languages such
> > > as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
> > > that much effort without reason :-)
> > >
> > > By definition it works the same interpreted or compiled, which brings a
> > > couple of restrictions I'm willing to live with :-)
> > >
> > > Roops
> > > p.s. I'm not convinced that that familiarity is a reason to criticise
> > > choosing a language. Using something you know well is often a way of
> > giving
> > > bettet value and rel

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Rupert Reynolds]

SMF logging of data for management information? I never did much with SMF,
but I can't see why not.

I did briefly consider being able to parse existing mapping macros, but
that's bound to be a bigger job than it seems, especially now I'm a bit
rusty and only have Hercules to play with.

Structures (maybe 'map' because 'str' is already short for the most basic
type of 'string'). And pointers to them, yes. Wouldn't be without them :-)

I'll probably be old and slow, or losing my concentration, before it's even
half finished. Still, it keeps me out of mischief when I'm not at work or
converting the van for mobile glamping  :-)

Roops

On Sun, 17 Mar 2024, 18:31 Seymour J Metz,  wrote:

> I probably would use ":=" for assignment and "=" for equality.
>
> Are you supporting SMF-like structures?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Rupert Reynolds 
> Sent: Sunday, March 17, 2024 2:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> question
>
> It's too soon to publish much, especially when I have a full time job doing
> something else. To be honest I probably never will, because it only suits
> my pet bigotries :-)
>
> But briefly, I looked at day 1 notes (on back of a gas bill). They included
> these, not all of which will ever make it into use of course:
>
> . fairly terse {} syntax, borrowing from 'C' etc.
>
> . strongly typed by default
>
> . one type is bignum--arbitrary precision and base arithmetic, trig, logs
>
> . correctness and flexibility more important than speed (like external
> functions in Rexx scripts, for example)
>
> . project to include thorough test cases, and any bugs/unintended quirks in
> either impl or tests will be fixed ruthlessly, not supported. If it fails
> the test, it is not the real thing.
>
> . compiled code could include interpreter for scripting
>
> . preserves case, but keywords and functions etc. not case sensitive
>
> . all keywords can be abbreviated (eg. if min abbreviation is 3, 'fun' is
> same as 'function')
>
> . '=' not required for assignment!
>
> . ability to convert 'C' style strings and call 'C' code
>
> . all built-in functions for handling null-terminated data and UTF-16 to be
> prefixed gk_ (short for "ghastly kludge" ;-) )
>
> Feel free to laugh/crjticise, but please be kind--I was drinking during
> lockdown when I finished that list :-)
>
> I made some progress on the bignum logarithms and trig early, borrowing
> heavily on the external Rexx functions I used under Windows.
>
> It does basics such as finding and moving files interpreted, so I can use
> it to test my Rexx admin scripts, and vice versa, but there are *huge*
> gaps, and I'm moving house this year, so... :-)
>
> Roops
>
>
> On Sun, 17 Mar 2024, 16:58 Seymour J Metz,  wrote:
>
> > >  I'm developing a language
> >
> > Have you published any details?
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> > עַם יִשְׂרָאֵל חַי
> > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Rupert Reynolds 
> > Sent: Saturday, March 16, 2024 9:07 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> > question
> >
> > My experience of modern scripting languages, compared with classic Rexx,
> is
> > that they all do something new more easily, but also I can't think of one
> > that doesn't have an obvious pitfall (such as, for example, stumbling
> badly
> > over certain byte values such as NUL in strings).
> >
> > Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
> > certain old-fashioned quirks, are still sometimes what I reach for when I
> > want to process some data while avoiding those pitfalls.
> >
> > The differences are so strong to me that I'm developing a language which
> is
> > effectively the best bits (IMHO) of Rexx, C and even older languages such
> > as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
> > that much effort without reason :-)
> >
> > By definition it works the same interpreted or compiled, which brings a
> > couple of restrictions I'm willing to live with :-)
> >
> > Roops
> > p.s. I'm not convinced that that familiarity is a reason to criticise
> > choosing a language. Using something you know well is often a way of
> giving
> > bettet value and reliability for ones employers.
> >
> >
> >
> >
> >
> > On Sat, 16 Mar 2024, 11:49 David Crayford, <
> > 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Hey Rony,
> > >
> > > From what I understand, you haven't had experience working on z/OS.
> Let's
> > > stick to the topic and focus on discussing REXX as it functions on
> z/OS.
> > > This means no discussions about ooRe

Re: Learning one's tools

[Seymour J Metz]

We don't seem to have the same definition of clever. To me, code that has me 
asking "Why didn't I think of that?" is clever; code that has me asking for 
hours "How does this work?", not so much. Sometimes the difference is good 
choice of label and helpful comments.

Expect the code to be modified by someone with significantly less knowledge of 
the problem domain, even if they are an expert in the language.

Bad standards are stifling and inefficient; that doesn't mean that all 
standards are bad. Good standards save time in the long run.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Jared Hunter 
Sent: Sunday, March 17, 2024 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

Dave Beagle wrote:
> Code reviews are dumb and not needed by good programmers

Counterpoint: Code reviews are -most- essential when the authors are experts.

Why is that?  Because experts are most able to churn out code that functions 
correctly for today’s requirements, but that some less-expert future maintainer 
will have a difficult time modifying to suit a new requirement without 
introducing a bug.

“Standards” may feel stifling and inefficient to someone who wants to output 
“working” code as quickly as possible, and especially one with a deep desire to 
display their cleverness. [Dear reader, does that sound like anyone you know?]

In general, code written for the set of list-relevant platforms should be 
reviewed with the expectation that it will be maintained for decades longer 
than the original author is employed, and eventually by a generalist with 
significantly less overall depth of compiler-specific or arcane platform 
knowledge.  It’s an extremely hard balance to strike, to be sure, but it’s 
never too early or too late to start trying.

Jared Hunter
Rocket Software


Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
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: Learning one's tools

[zMan]

+1
Remember, Bill isn't really a programmer, no matter what name he uses. He
was a sysprog at best.

On Sun, Mar 17, 2024 at 4:21 PM Jared Hunter 
wrote:

> Dave Beagle wrote:
> > Code reviews are dumb and not needed by good programmers
>
> Counterpoint: Code reviews are -most- essential when the authors are
> experts.
>
> Why is that?  Because experts are most able to churn out code that
> functions correctly for today’s requirements, but that some less-expert
> future maintainer will have a difficult time modifying to suit a new
> requirement without introducing a bug.
>
> “Standards” may feel stifling and inefficient to someone who wants to
> output “working” code as quickly as possible, and especially one with a
> deep desire to display their cleverness. [Dear reader, does that sound like
> anyone you know?]
>
> In general, code written for the set of list-relevant platforms should be
> reviewed with the expectation that it will be maintained for decades longer
> than the original author is employed, and eventually by a generalist with
> significantly less overall depth of compiler-specific or arcane platform
> knowledge.  It’s an extremely hard balance to strike, to be sure, but it’s
> never too early or too late to start trying.
>
> Jared Hunter
> Rocket Software
>
> 
> Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA
> 02451 ¦ Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy -
> http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> notify Rocket Software immediately and destroy all copies of this
> communication. Thank you.
>
> --
> 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: With IBM planning (planned) dropping support for SNA / 802.3

[Radoslaw Skorupka]

AFAIK, LU6.2 will not be affected.

The drop of support does not cover SNA higher level functionality, just 
physical layer.
So the change is from OSA OSE native SNA to Enterprise Extender, which 
means SNA over IP.

Note: mainframe is last platform still supporting that layer.
Microsoft HIS aka SNA Server no longer support native SNA.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 16.03.2024 o 21:47, Binyamin Dissen pisze:

With IBM planning (planned) dropping support for SNA / 802.3, does that mean
that application code using LU6.2 will stop working?

Or will VTAM continue to support LU6.2 code?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

--
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: Learning one's tools

[Jared Hunter]

Dave Beagle wrote:
> Code reviews are dumb and not needed by good programmers

Counterpoint: Code reviews are -most- essential when the authors are experts.

Why is that?  Because experts are most able to churn out code that functions 
correctly for today’s requirements, but that some less-expert future maintainer 
will have a difficult time modifying to suit a new requirement without 
introducing a bug.

“Standards” may feel stifling and inefficient to someone who wants to output 
“working” code as quickly as possible, and especially one with a deep desire to 
display their cleverness. [Dear reader, does that sound like anyone you know?]

In general, code written for the set of list-relevant platforms should be 
reviewed with the expectation that it will be maintained for decades longer 
than the original author is employed, and eventually by a generalist with 
significantly less overall depth of compiler-specific or arcane platform 
knowledge.  It’s an extremely hard balance to strike, to be sure, but it’s 
never too early or too late to start trying.

Jared Hunter
Rocket Software


Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

CLIST will never go away, but I avoid it as much as possible. There is a very 
limited set of use cases for it, IMHO, and REXX has been my goto scripting 
language for decades, with a grudging nod to Perl when CPAN can make my life 
easier.

PowerShell suggests that you're not limited to Z, inwhich case it's worth 
looking at ooRexx.

Have you looked at Ruby?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 15, 2024 7:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx numeric digits and scientific notation question

I can tell you how it happened to me, at any rate.  I was a long-time CLISTer, 
and then one day, back in the mid '80s it might have been, I ran across a 
warning from IBM that someday soon CLIST might go away and REXX would be the 
only supported language for system automation (or something like that).  I took 
them seriously - I didn't know at the time that they used to issue that warning 
periodically - and sat down with a manual to start learning REXX.  I quickly 
realized that it's ~much~ superior to CLIST, and have been an enthusiast ever 
since.

But that needn't stop me from tacking on other languages; I'm not tired of that 
yet, and I still have ambitions of adding more.  Python is better, you say?  
But can I use it in the TSO environment?  If it's only for Unix, I may pass for 
now.  I still work for multiple clients and it seems to me I could usefully 
focus on languages that the clients are likely to use themselves.  That means 
TSO REXX, VBA and VBS, SQL, assembler, probably PowerShell, maybe PL/1...  What 
else?  Seriously I'm open to the next one I should tackle.  I keep hearing 
about Python, Lua, Ruby, C++ and others, but in what environment(s) would I use 
them?

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

/* Sometimes you feel like a nut.  After a day of working on a walnut farm, you 
don't.  -Mike Rowe of the TV show "Dirty Jobs" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Friday, March 15, 2024 18:41

REXX can indeed be quite tricky to navigate. I recently conducted a session 
titled "Python for REXX programmers" at work, and during the preparation, I was 
surprised (although not entirely) by the numerous traps and pitfalls inherent 
in REXX. When you add to this its absence of basic functionalities like sorting 
lists, it begs the question: Why opt for REXX when we have a plethora of 
alternatives available today?

The obvious answer may be familiarity, but in our industry, this argument seems 
rather weak unless you're confined to a limited environment. After all, I 
wouldn't want to revert to using a 1990s-era flip-top phone, let alone a rotary 
dial from the 1970s.

--
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: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

I probably would use ":=" for assignment and "=" for equality.

Are you supporting SMF-like structures?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Rupert Reynolds 
Sent: Sunday, March 17, 2024 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation 
question

It's too soon to publish much, especially when I have a full time job doing
something else. To be honest I probably never will, because it only suits
my pet bigotries :-)

But briefly, I looked at day 1 notes (on back of a gas bill). They included
these, not all of which will ever make it into use of course:

. fairly terse {} syntax, borrowing from 'C' etc.

. strongly typed by default

. one type is bignum--arbitrary precision and base arithmetic, trig, logs

. correctness and flexibility more important than speed (like external
functions in Rexx scripts, for example)

. project to include thorough test cases, and any bugs/unintended quirks in
either impl or tests will be fixed ruthlessly, not supported. If it fails
the test, it is not the real thing.

. compiled code could include interpreter for scripting

. preserves case, but keywords and functions etc. not case sensitive

. all keywords can be abbreviated (eg. if min abbreviation is 3, 'fun' is
same as 'function')

. '=' not required for assignment!

. ability to convert 'C' style strings and call 'C' code

. all built-in functions for handling null-terminated data and UTF-16 to be
prefixed gk_ (short for "ghastly kludge" ;-) )

Feel free to laugh/crjticise, but please be kind--I was drinking during
lockdown when I finished that list :-)

I made some progress on the bignum logarithms and trig early, borrowing
heavily on the external Rexx functions I used under Windows.

It does basics such as finding and moving files interpreted, so I can use
it to test my Rexx admin scripts, and vice versa, but there are *huge*
gaps, and I'm moving house this year, so... :-)

Roops


On Sun, 17 Mar 2024, 16:58 Seymour J Metz,  wrote:

> >  I'm developing a language
>
> Have you published any details?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Rupert Reynolds 
> Sent: Saturday, March 16, 2024 9:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> question
>
> My experience of modern scripting languages, compared with classic Rexx, is
> that they all do something new more easily, but also I can't think of one
> that doesn't have an obvious pitfall (such as, for example, stumbling badly
> over certain byte values such as NUL in strings).
>
> Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
> certain old-fashioned quirks, are still sometimes what I reach for when I
> want to process some data while avoiding those pitfalls.
>
> The differences are so strong to me that I'm developing a language which is
> effectively the best bits (IMHO) of Rexx, C and even older languages such
> as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
> that much effort without reason :-)
>
> By definition it works the same interpreted or compiled, which brings a
> couple of restrictions I'm willing to live with :-)
>
> Roops
> p.s. I'm not convinced that that familiarity is a reason to criticise
> choosing a language. Using something you know well is often a way of giving
> bettet value and reliability for ones employers.
>
>
>
>
>
> On Sat, 16 Mar 2024, 11:49 David Crayford, <
> 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Hey Rony,
> >
> > From what I understand, you haven't had experience working on z/OS. Let's
> > stick to the topic and focus on discussing REXX as it functions on z/OS.
> > This means no discussions about ooRexx or Java bridges, as they don't
> exist
> > and are unlikely to in the future on z/OS.
> >
> > The majority of REXX programmers here utilize classic TSO REXX and
> > primarily work within a TSO/ISPF environment. In this setup, REXX lacks a
> > module system. Therefore, any routines or libraries need to be manually
> > copied and pasted wherever they're needed, or you have to create a
> > pre-processor to merge source files together. If your language lacks the
> > fundamental basic features to sort an array then to me that’s a good
> > indication you should use one that does.
> >
> > I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating
> > my observations based on over 30 years of using REXX on z/OS, including
> > developing extensions. I believe this gives me a significant level of
> > expertise to offer commentary on the matter.
> >
> >
>
> --

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Rupert Reynolds]

It's too soon to publish much, especially when I have a full time job doing
something else. To be honest I probably never will, because it only suits
my pet bigotries :-)

But briefly, I looked at day 1 notes (on back of a gas bill). They included
these, not all of which will ever make it into use of course:

. fairly terse {} syntax, borrowing from 'C' etc.

. strongly typed by default

. one type is bignum--arbitrary precision and base arithmetic, trig, logs

. correctness and flexibility more important than speed (like external
functions in Rexx scripts, for example)

. project to include thorough test cases, and any bugs/unintended quirks in
either impl or tests will be fixed ruthlessly, not supported. If it fails
the test, it is not the real thing.

. compiled code could include interpreter for scripting

. preserves case, but keywords and functions etc. not case sensitive

. all keywords can be abbreviated (eg. if min abbreviation is 3, 'fun' is
same as 'function')

. '=' not required for assignment!

. ability to convert 'C' style strings and call 'C' code

. all built-in functions for handling null-terminated data and UTF-16 to be
prefixed gk_ (short for "ghastly kludge" ;-) )

Feel free to laugh/crjticise, but please be kind--I was drinking during
lockdown when I finished that list :-)

I made some progress on the bignum logarithms and trig early, borrowing
heavily on the external Rexx functions I used under Windows.

It does basics such as finding and moving files interpreted, so I can use
it to test my Rexx admin scripts, and vice versa, but there are *huge*
gaps, and I'm moving house this year, so... :-)

Roops


On Sun, 17 Mar 2024, 16:58 Seymour J Metz,  wrote:

> >  I'm developing a language
>
> Have you published any details?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Rupert Reynolds 
> Sent: Saturday, March 16, 2024 9:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> question
>
> My experience of modern scripting languages, compared with classic Rexx, is
> that they all do something new more easily, but also I can't think of one
> that doesn't have an obvious pitfall (such as, for example, stumbling badly
> over certain byte values such as NUL in strings).
>
> Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
> certain old-fashioned quirks, are still sometimes what I reach for when I
> want to process some data while avoiding those pitfalls.
>
> The differences are so strong to me that I'm developing a language which is
> effectively the best bits (IMHO) of Rexx, C and even older languages such
> as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
> that much effort without reason :-)
>
> By definition it works the same interpreted or compiled, which brings a
> couple of restrictions I'm willing to live with :-)
>
> Roops
> p.s. I'm not convinced that that familiarity is a reason to criticise
> choosing a language. Using something you know well is often a way of giving
> bettet value and reliability for ones employers.
>
>
>
>
>
> On Sat, 16 Mar 2024, 11:49 David Crayford, <
> 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Hey Rony,
> >
> > From what I understand, you haven't had experience working on z/OS. Let's
> > stick to the topic and focus on discussing REXX as it functions on z/OS.
> > This means no discussions about ooRexx or Java bridges, as they don't
> exist
> > and are unlikely to in the future on z/OS.
> >
> > The majority of REXX programmers here utilize classic TSO REXX and
> > primarily work within a TSO/ISPF environment. In this setup, REXX lacks a
> > module system. Therefore, any routines or libraries need to be manually
> > copied and pasted wherever they're needed, or you have to create a
> > pre-processor to merge source files together. If your language lacks the
> > fundamental basic features to sort an array then to me that’s a good
> > indication you should use one that does.
> >
> > I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating
> > my observations based on over 30 years of using REXX on z/OS, including
> > developing extensions. I believe this gives me a significant level of
> > expertise to offer commentary on the matter.
> >
> >
>
> --
> 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 subsc

Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

> every function call carries a potential side effect.

Function calls in most languages carry potential side effects. In that respect 
REXX is superior because PROCEDURE drops access to everything except what you 
expose.

> When I hear about adapting to quirks, it seems to translate to "I acknowledge 
> REXX's flaws,
>  but I stick with it because it's what I'm familiar with, even if I have to 
> tolerate it.”

Not even close: it translates to "as with any other language, you have to carve 
the bird at the joints."

> brought attention to the shortcomings and limitations of REXX as a 
> programming language.

IMHO, if you can't recognize the shortcomings and limitations of foo then you 
don't understand foo.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 15, 2024 7:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx numeric digits and scientific notation question

Working with REXX doesn't feel comfortable to me at all. I'm troubled by the 
fact that every function call carries a potential side effect. While we can 
resort to procedures, we then encounter the challenge of dealing with 
telescoping exposure lists. When I hear about adapting to quirks, it seems to 
translate to "I acknowledge REXX's flaws, but I stick with it because it's what 
I'm familiar with, even if I have to tolerate it.” The recent discussions on 
this forum have brought attention to the shortcomings and limitations of REXX 
as a programming language.

In comparison to other platforms, Z/OS used to offer limited options in terms 
of programming languages. However, that's no longer the case. What struck me as 
ironic during my recent presentation was that the majority of the audience were 
millennials who were unfamiliar with REXX. This might come as a surprise to 
seasoned veterans of mainframes who are used to REXX, but in today's landscape, 
familiarity with it isn't necessary.

> On 16 Mar 2024, at 7:19 am, Seymour J Metz  wrote:
>
> Every language has pitfalls. While I generally prefer strongly typed 
> languages, I find Rexx and ooRexx to be comfortable to work with, and it is 
> not difficult to adapt to its quirks:
>
> 
> 
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, March 15, 2024 6:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Rexx numeric digits and scientific notation question
>
> REXX can indeed be quite tricky to navigate. I recently conducted a session 
> titled "Python for REXX programmers" at work, and during the preparation, I 
> was surprised (although not entirely) by the numerous traps and pitfalls 
> inherent in REXX. When you add to this its absence of basic functionalities 
> like sorting lists, it begs the question: Why opt for REXX when we have a 
> plethora of alternatives available today?
>
> The obvious answer may be familiarity, but in our industry, this argument 
> seems rather weak unless you're confined to a limited environment. After all, 
> I wouldn't want to revert to using a 1990s-era flip-top phone, let alone a 
> rotary dial from the 1970s.
>
>> On 16 Mar 2024, at 2:47 am, Charles Mills  wrote:
>>
>> Well, that explains a mystery. I did not realize that SIGNAL ON was pushed 
>> and popped on subroutine calls. I have had this vague problem where my 
>> SIGNAL ON NOVALUE did not seem to work but at the time of an error it is 
>> always easier to fix the NOVALUE condition than troubleshoot the SIGNAL ON.
>>
>> Thanks!
>> Charles
>>
>> On Thu, 14 Mar 2024 12:04:00 -0500, Glenn Knickerbocker  
>> wrote:
>>
>>> On Wed, 13 Mar 2024 11:01:30 -0500, Charles Mills  wrote:
 And the answer is ... "The three numeric settings are automatically saved 
 across internal and external subroutine and function calls."
 I was setting numeric digits in an initialization subroutine, so Rexx 
 helpfully unset it on return from initialization. I thought I had done it 
 that way before but I guess I have not.
>>>
>>> Funny, I work with a lot of code that has a common subroutine for 
>>> retrieving a TRACE setting to set in the main routine, and I never even 
>>> thought about why, or about all the stuff that gets saved across calls!  
>>> From CALL HELPREXX on VM:
>>>
 The status of DO loops and other structures:
>>> --though, importantly, not the *indices* of the loops!
 Trace action:
 NUMERIC settings:
 ADDRESS settings:
 Condition traps: (CALL ON and SIGNAL ON)
 Condition information:

Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

CALL ON is intend for exception handlers that return; that code should never 
have survived review.

It's SIGNAL ON that unwinds the stack.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 15, 2024 7:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx numeric digits and scientific notation question

On Fri, 15 Mar 2024 23:24:38 +, Seymour J Metz wrote:

>CALL ON or SIGNAL ON?
>
???
CALL ON to a procedure coded in front of the main loop and drop
through without RETURN?  That would make things worse.

He would have wanted ITERATE ON.

>
>From:  Paul Gilmartin
>Sent: Friday, March 15, 2024 5:38 PM
>On Fri, 15 Mar 2024 19:36:12 +, Seymour J Metz wrote:
>
>>"unwinds" in a very disruptive and partial fashion.  I once debugged a naive 
>>co-workers
>program which handled an exception in a subroutine by SIGNAL to top of main 
>loop.
>Worked fine in a modest test data set.  Overflowed CALL/RETURN stack on a 
>larger
>data set.

--
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: Rexx numeric digits and scientific notation question

[Seymour J Metz]

For OMVS and z/Linux, ooRexx is the gold standard and comparisons to classic 
Rexx are irrelevant.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 15, 2024 8:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx numeric digits and scientific notation question

> On 16 Mar 2024, at 7:45 am, Jay Maynard 
> <05997213d6c2-dmarc-requ...@listserv.ua.edu> wrote:
>
> That depends. Can you use, say, Python to implement all the scripting kinds
> of things you can use REXX for?

Like what, TSO? I don’t find I need to do that any more as I work in a UNIX 
shell. Let me flip that around. Can I use REXX to implement the kind of 
scripting that I do in Python? For example, process a YAML configuration file. 
We need to do that stuff on z/OS now. CICS resource definitions can be defined 
as YAML documents, configuration as code and all that stuff. DevOps, Git repos. 
REXX is a pretty poor language for anything modern.

IBM and ISVs are working on Python APIs for products right now. And they will 
be better than the REXX versions.

>
> On Fri, Mar 15, 2024 at 6:36 PM David Crayford <
> 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Working with REXX doesn't feel comfortable to me at all. I'm troubled by
>> the fact that every function call carries a potential side effect. While we
>> can resort to procedures, we then encounter the challenge of dealing with
>> telescoping exposure lists. When I hear about adapting to quirks, it seems
>> to translate to "I acknowledge REXX's flaws, but I stick with it because
>> it's what I'm familiar with, even if I have to tolerate it.” The recent
>> discussions on this forum have brought attention to the shortcomings and
>> limitations of REXX as a programming language.
>>
>> In comparison to other platforms, Z/OS used to offer limited options in
>> terms of programming languages. However, that's no longer the case. What
>> struck me as ironic during my recent presentation was that the majority of
>> the audience were millennials who were unfamiliar with REXX. This might
>> come as a surprise to seasoned veterans of mainframes who are used to REXX,
>> but in today's landscape, familiarity with it isn't necessary.
>>
>>> On 16 Mar 2024, at 7:19 am, Seymour J Metz  wrote:
>>>
>>> Every language has pitfalls. While I generally prefer strongly typed
>> languages, I find Rexx and ooRexx to be comfortable to work with, and it is
>> not difficult to adapt to its quirks:
>>>
>>> 
>>> 
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>> עַם יִשְׂרָאֵל חַי
>>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>>>
>>> 
>>> From: IBM Mainframe Discussion List  on
>> behalf of David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu>
>>> Sent: Friday, March 15, 2024 6:40 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Rexx numeric digits and scientific notation question
>>>
>>> REXX can indeed be quite tricky to navigate. I recently conducted a
>> session titled "Python for REXX programmers" at work, and during the
>> preparation, I was surprised (although not entirely) by the numerous traps
>> and pitfalls inherent in REXX. When you add to this its absence of basic
>> functionalities like sorting lists, it begs the question: Why opt for REXX
>> when we have a plethora of alternatives available today?
>>>
>>> The obvious answer may be familiarity, but in our industry, this
>> argument seems rather weak unless you're confined to a limited environment.
>> After all, I wouldn't want to revert to using a 1990s-era flip-top phone,
>> let alone a rotary dial from the 1970s.
>>>
 On 16 Mar 2024, at 2:47 am, Charles Mills  wrote:

 Well, that explains a mystery. I did not rea

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

Every language has warts, including PL/I and REXX, but I believe that they are 
the best choices for writing ISPF dialogs, especially if you are allowed to use 
PCRE.

I don't supposed that a fully supported IBM port of Ruby to z/OS will ever 
happen, but it would catch my eye if it did. Likewise replacing the current 
backlevel REXX with ooRexx.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, March 16, 2024 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation 
question

Hey Rony,

From what I understand, you haven't had experience working on z/OS. Let's stick 
to the topic and focus on discussing REXX as it functions on z/OS. This means 
no discussions about ooRexx or Java bridges, as they don't exist and are 
unlikely to in the future on z/OS.

The majority of REXX programmers here utilize classic TSO REXX and primarily 
work within a TSO/ISPF environment. In this setup, REXX lacks a module system. 
Therefore, any routines or libraries need to be manually copied and pasted 
wherever they're needed, or you have to create a pre-processor to merge source 
files together. If your language lacks the fundamental basic features to sort 
an array then to me that’s a good indication you should use one that does.

I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating my 
observations based on over 30 years of using REXX on z/OS, including developing 
extensions. I believe this gives me a significant level of expertise to offer 
commentary on the matter.


> On 16 Mar 2024, at 6:03 pm, Rony G. Flatscher  wrote:
>
> On 16.03.2024 01:17, David Crayford wrote:
>>> On 16 Mar 2024, at 7:45 am, Jay 
>>> Maynard<05997213d6c2-dmarc-requ...@listserv.ua.edu>  wrote:
>>>
>>> That depends. Can you use, say, Python to implement all the scripting kinds
>>> of things you can use REXX for?
>> Like what, TSO? I don’t find I need to do that any more as I work in a UNIX 
>> shell. Let me flip that around. Can I use REXX to implement the kind of 
>> scripting that I do in Python? For example, process a YAML configuration 
>> file.
> Yes, if you wanted, it is fairly easy BTW and would not be as potentially 
> dangerous if done in REXX than done with Perl or Python (cf. 
> ).
>> We need to do that stuff on z/OS now. CICS resource definitions can be 
>> defined as YAML documents, configuration as code and all that stuff. DevOps, 
>> Git repos. REXX is a pretty poor language for anything modern.
>
> Again, unsubstantiated and derogative, please just stop behaving like a 
> religious warrior and stick to facts and discuss sorberly, stop your FUD 
> please!
>
>> IBM and ISVs are working on Python APIs for products right now.
> That is fine. On slides and in imaginations everything in the future is 
> always much better than what is available at present.
>> And they will be better than the REXX versions.
>
> Well, that has yet to be seen. If improvements materialize, then it would a) 
> be fine and b) be a reason to look into the existing, working REXX versions 
> for the same improvements then.
>
> A massive improvement for the mainframes were to make ooRexx available on 
> them.
>
> Combine ooRexx with the ooRexx-Java bridge and software engineers have 
> immediately gained the ability to use *any* Java API from ooRexx, without a 
> need to learn Java at all, it suffices to be able to read the HTML 
> documentation of Java classes. The easiness and the productivity gains can be 
> inferred if you know that my novices can do this successfully during the last 
> two months of the semester even becoming able to exploit the SSL/TLS Java 
> socket classes, besides awt/swing, JavaFX and some more.
>
> The potential savings for the mainframe users would be enormeous if they 
> started to exploit that combination. It is actually available already today 
> in the Linux subsystems such that one can assess the technology (I know of 
> deployments that exploit this combination in production, using ooRexx to run 
> programs that interact with DB2 using JDBC).
>
> ---rony
>
>>> On Fri, Mar 15, 2024 at 6:36 PM David Crayford <
>>> 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:
>>>
 Working with REXX doesn't feel comfortable to me at all. I'm troubled by
 the fact that every function call carries a potential side effect. While we
 can resort to procedures, we then encounter the challenge of dealing with
 telescoping exposure lists. When I hear about adapting to quirks, it seems
 to translate to "I acknowledge REXX's flaws, but I stick with it because
 it's what I'm familiar with, even if I have to tolerate it.” The recent
 discussions on this forum have brought att

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

>  I'm developing a language

Have you published any details?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Rupert Reynolds 
Sent: Saturday, March 16, 2024 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation 
question

My experience of modern scripting languages, compared with classic Rexx, is
that they all do something new more easily, but also I can't think of one
that doesn't have an obvious pitfall (such as, for example, stumbling badly
over certain byte values such as NUL in strings).

Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
certain old-fashioned quirks, are still sometimes what I reach for when I
want to process some data while avoiding those pitfalls.

The differences are so strong to me that I'm developing a language which is
effectively the best bits (IMHO) of Rexx, C and even older languages such
as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
that much effort without reason :-)

By definition it works the same interpreted or compiled, which brings a
couple of restrictions I'm willing to live with :-)

Roops
p.s. I'm not convinced that that familiarity is a reason to criticise
choosing a language. Using something you know well is often a way of giving
bettet value and reliability for ones employers.





On Sat, 16 Mar 2024, 11:49 David Crayford, <
0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:

> Hey Rony,
>
> From what I understand, you haven't had experience working on z/OS. Let's
> stick to the topic and focus on discussing REXX as it functions on z/OS.
> This means no discussions about ooRexx or Java bridges, as they don't exist
> and are unlikely to in the future on z/OS.
>
> The majority of REXX programmers here utilize classic TSO REXX and
> primarily work within a TSO/ISPF environment. In this setup, REXX lacks a
> module system. Therefore, any routines or libraries need to be manually
> copied and pasted wherever they're needed, or you have to create a
> pre-processor to merge source files together. If your language lacks the
> fundamental basic features to sort an array then to me that’s a good
> indication you should use one that does.
>
> I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating
> my observations based on over 30 years of using REXX on z/OS, including
> developing extensions. I believe this gives me a significant level of
> expertise to offer commentary on the matter.
>
>

--
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: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

On z/Linux? Already here? In TSO? I wish, but won't hold my breathe.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, March 16, 2024 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation 
question

Surely that's moon-pie and dreamscapes?  There's no serious suggestion that 
that will ever happen, is there?  I'm all for it, but don't expect it ever.

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

/* Sometimes you feel like a nut.  After a day of working on a walnut farm, you 
don't.  -Mike Rowe of the TV show "Dirty Jobs" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rony G. Flatscher
Sent: Saturday, March 16, 2024 06:03

A massive improvement for the mainframes were to make ooRexx available on them.

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

[Seymour J Metz]

ALGOL 68 was a big step forward, but the standard was hard to read because it 
lacked adequate comments in the formal definition.

Simula was based on ALGOL 60 and was arguably the first OO language. Ada was 
derived from ALGOL via Pascal.

And, of course, PL/I owes a lot to ALGOL 60.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, March 16, 2024 9:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Algol

I did a lot of coding in Algol during my time at a local University in the late 
'70s.  My impression at the time was that it had a serious paucity of built-in 
functions, but that it enabled me to write my own and make them easily 
available to my programs.  So I stuffed a library full of I/O and 
string-handling functions and got along just fine, it seemed to me.

Haven't encountered it since; I don’t know what advances may have been made in 
that arena.

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

/* That sort of wit which employs itself insolently in criticizing and 
censuring the words and sentiments of others in conversation is absolute folly; 
for it answers none of the ends of conversation.  He who uses it neither 
improves others, is improved himself, nor pleases anyone.  -Poor Richard’s 
Almanack, 1756 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rupert Reynolds
Sent: Saturday, March 16, 2024 09:07

developing a language which is effectively the best bits (IMHO) of Rexx, C 
and even older languages such as Algol 68 (much underrated in my book) and 
hints of PL/1

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


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

Re: Learning one's tools

[Seymour J Metz]

That looks more like programming around deficiencies in the compiler than 
finding better algorithms. Between PL/I F V4 and V5 there was a serious 
degradation of code quality, anf there were  cases where the "optimizing" 
compiler was worse than F. I ran into that processing SMF data.

I'd be interested in seeing what the current Enterprise PL/I did with, e.g., 
unaligned bit strings, refers.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Robert Prins <05be6ef5bfea-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 17, 2024 10:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

On Sun, 17 Mar 2024 at 11:42, Tom Harper <
05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:

> David,
>
> Yes, assembler can be used to improve performance.
>
> In the 64 years I have been programming, I have used COBOL for three
> years, C++ for six years, and assembler for 55 years.
>
> But it’s not just the language that affects performance. Design is
> critical and arranging your algorithms in the correct sequence is of the
> utmost importance.
>

It's way more important!

Here are statement counts obtained by the old PL/I Optimizing compiler for
the procedure(s) that produce one particular table:

My old algorithm:

NAT_SCAN  13,685,293,297  99.6441458%

The current algorithm, thanks to a Paul Greeen, and the result from a post
to comp.lang.pascal.borland, almost 26 years ago.

NAT_SCAN 246,805   0.6623430%
DISPOSE_RUN   14,064   0.0377431%
SETUP_RUN162,060   0.4349154%
CHECK_RUNS 1,229,773   3.3003039%

And for what it's worth, the old counts are probably correct, the transient
library of the optimizing compiler cannot handle counts over 2^31-1, so I
had to add code to emulate the loops according to the PL/I manual, using
FIXED DEC (15) variables.

Now this is only a private program <
https://prino.neocities.org/resources/lift.pli.html>, but I've updated PL/I
code myself reducing ***CPU*** time from well over three hours to just 20
minutes, by just changing two declarations, and while working at a Dutch
airline company, I reduced CPU usage of two PL/I programs calculating CRCs
by more than 99.5%, removing calls to the PL/I library. Hell, if you look
at the current Enterprise PL/I Programming Guide, GI13-5620-00, on PDF page
372 (book page 316) in the "Avoiding calls to library routines" paragraph,
the text that reads


When your code refers to a member of a BASED structure with REFER, the
compiler often has to generate
one or more calls to a library routine to map the structure at run time.
These calls can be expensive, and
so when the compiler makes these calls, it will issue a message so that you
can locate these potential
hot-spots in your code.

If you do have code that uses BASED structures with REFER, which the
compiler flags with this message,
you might get better performance by passing the structure to a subroutine
that declares a corresponding
structure with * extents. This will cause the structure to be mapped once
at the CALL statement, but there
will no further remappings when it is accessed in the called subroutine.


is almost a literal copy of text in an email I sent to IBM's Peter Elderon
close to 30 years ago, and if you use PL/I to build linked lists, and/or
trees using BASED storage, I'd suggest you think about the second
(area-reference) parameter of the ALLOC builtin function, and the NEXTALLOC
builtin, both are the result of my RFEs, and combining them with the EMPTY
builtin, well think about it. ;)

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


--
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: Learning one's tools

[Seymour J Metz]

The difference is that you not only learn how to do it better next time, you 
get to improve it this time. Taking ownership doesn't mean keeping people off 
your turf; a professional should always be open to informed criticism.

I've exchanged code with a number of people over the years, and have always 
been glad when they've showed me a better way to do something. Sometimes you 
can even learn from your students.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 17, 2024 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

I suppose code reviews are like post-battle debriefs, in which every choice of 
the commander is questioned, and when challenged with a better option he can 
only say "I didn't think of that at the time".  It must be extremely painful 
for the guy in the glare of the spotlight, but if it's done right -- too late 
to blame anyone now, we're just trying to make sure everyone has a chance to 
learn how to do it better next time -- it's also extremely valuable.  I truly 
hated having the code reviewers poke at my baby, and at the start of this 
thread I pointed out ways in which they didn't do it right.  But I agree with 
Shmuel, when done right you might even say they're necessary.

(And post-surgical reviews, too.  The patient lived, or the patient died, fine, 
but now we want to know what to do differently next time.)

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

/* The kingdom of Heaven is not for the well-meaning; it is for the desperate.  
-James Denney (1856-1917) */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, March 17, 2024 00:41

However, disagree vehemently about "Code reviews are dumb and not needed by 
good programmers." The first two things that a good programmer learns are that 
nobody has a monopoly on good ideas and that "Even Jove nods". Code reviews are 
like auditors and tech writers: when they are good they are very very good, and 
when they are bad they are horrid.

--
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: Learning one's tools

[Seymour J Metz]

Is this code clear? How can we improve the comments?

Have we considered all of the edge cases?

Is there a better way to do this?

How easy will it be to extend this?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Colin Paice <059d4daca697-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 17, 2024 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

I think code reviews are very useful, especially for not yet experts.  It
is good education for all levels.
We had reviews, and comments like
- Do you need a latch across these instructions for when there is
concurrent execution?
- If it abends here, how will the frr code ...
- Would it help capturing foot prints to show how we got here, before the
following code which may abend.
- Some customers will not send us a dump, so we need to capture as much as
we can in registers.
Colin

On Sun, 17 Mar 2024 at 13:40, Bob Bridges <
0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

> I suppose code reviews are like post-battle debriefs, in which every
> choice of the commander is questioned, and when challenged with a better
> option he can only say "I didn't think of that at the time".  It must be
> extremely painful for the guy in the glare of the spotlight, but if it's
> done right -- too late to blame anyone now, we're just trying to make sure
> everyone has a chance to learn how to do it better next time -- it's also
> extremely valuable.  I truly hated having the code reviewers poke at my
> baby, and at the start of this thread I pointed out ways in which they
> didn't do it right.  But I agree with Shmuel, when done right you might
> even say they're necessary.
>
> (And post-surgical reviews, too.  The patient lived, or the patient died,
> fine, but now we want to know what to do differently next time.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* The kingdom of Heaven is not for the well-meaning; it is for the
> desperate.  -James Denney (1856-1917) */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: Sunday, March 17, 2024 00:41
>
> However, disagree vehemently about "Code reviews are dumb and not needed
> by good programmers." The first two things that a good programmer learns
> are that nobody has a monopoly on good ideas and that "Even Jove nods".
> Code reviews are like auditors and tech writers: when they are good they
> are very very good, and when they are bad they are horrid.
>
> --
> 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

SDSF CSR

[esst...@juno.com]

,
Hello, 
. 
Im trying to understand an anomaly using SDSF CSR - (Common Storage Remaining)
I have read some of the documentation on SDSF CSR, however it didn't really 
give me an understand of the issue below -
.
I have two jobs which invoke the same program from the same load library -
Bothe jobs invokes IEFSSI REQUEST=ADD and the SSI INIT ROUTINE 
is the same for both JOBs. The SSI INIT Routine has multiple CSECTS and issues
IEFSSI REQUEST=ACTIVATE (Activate the subsystem), STORAGE OBTAIN (Key 0, 
Subpool 241, Length 
x'34'), and IEFSSI REQUEST=PUT (Store Sub System Data).
.
Granted the Key 0, subpool 241 may not be the best choice form allocating 
storage from MVS
common, that's not the issue for this discussion. 
.--   
In SDSF I see the following in CSR (Common Storage Remaining) -
JOBNAMECSACSA%   SQASQA%  ECSA   ECSA%
JOBNUMA3920.0076 0   0.56960.0079
JOBNUMB   0 0. 0   0.97920.0135
.--  
When I submit the first job (JOBNUMB) I see in SDSF CSR the job retains 9792 
bytes of ECSA and 0.0135% of ECSA. Im not sure where the 9792 bytes of ECSA 
came from - I suspect the majority of this allocation are various control block 
structures associated with the SSI -
.
The storage obtain macro in the INIT Routine acquires X'34' bytes of storage - 
.
However when I submit the second job (JOBNUMA), I see in SDSF CSR, the second 
job retains 5696 bytes of ECSA and 0.0079% of ECSA. Also JOBNUMA allocated 392 
byes of storage from CSA, why? 
.
Both jobs invoke the same program, and the same SSI INIT Routine from the same 
load library -
I expected to see the same ECSA values for both jobs/programs.
.
Can someone explain why there is such a difference in values?
I obviously don't understand this.
..
   Paul -
.
.

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

Re: Learning one's tools

[Colin Paice]

I think code reviews are very useful, especially for not yet experts.  It
is good education for all levels.
We had reviews, and comments like
- Do you need a latch across these instructions for when there is
concurrent execution?
- If it abends here, how will the frr code ...
- Would it help capturing foot prints to show how we got here, before the
following code which may abend.
- Some customers will not send us a dump, so we need to capture as much as
we can in registers.
Colin

On Sun, 17 Mar 2024 at 13:40, Bob Bridges <
0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

> I suppose code reviews are like post-battle debriefs, in which every
> choice of the commander is questioned, and when challenged with a better
> option he can only say "I didn't think of that at the time".  It must be
> extremely painful for the guy in the glare of the spotlight, but if it's
> done right -- too late to blame anyone now, we're just trying to make sure
> everyone has a chance to learn how to do it better next time -- it's also
> extremely valuable.  I truly hated having the code reviewers poke at my
> baby, and at the start of this thread I pointed out ways in which they
> didn't do it right.  But I agree with Shmuel, when done right you might
> even say they're necessary.
>
> (And post-surgical reviews, too.  The patient lived, or the patient died,
> fine, but now we want to know what to do differently next time.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* The kingdom of Heaven is not for the well-meaning; it is for the
> desperate.  -James Denney (1856-1917) */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: Sunday, March 17, 2024 00:41
>
> However, disagree vehemently about "Code reviews are dumb and not needed
> by good programmers." The first two things that a good programmer learns
> are that nobody has a monopoly on good ideas and that "Even Jove nods".
> Code reviews are like auditors and tech writers: when they are good they
> are very very good, and when they are bad they are horrid.
>
> --
> 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: Learning one's tools

[Bob Bridges]

I really gotta get back into PL/1.  It was my first language, and I still like 
it.  Just haven't used it in a few decades.

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

/* The more sophisticated the technology, the more vulnerable it is to 
primitive attack. People often overlook the obvious.  -Dr Who, 1978 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Prins
Sent: Sunday, March 17, 2024 10:44

I've updated PL/I code myself reducing ***CPU*** time from well over three 
hours to just 20 minutes, by just changing two declarations, and while working 
at a Dutch airline company, I reduced CPU usage of two PL/I programs 
calculating CRCs by more than 99.5%, removing calls to the PL/I library. Hell, 
if you look at the current Enterprise PL/I Programming Guide, GI13-5620-00, on 
PDF page
372 (book page 316) in the "Avoiding calls to library routines" paragraph, the 
text that reads


When your code refers to a member of a BASED structure with REFER, the compiler 
often has to generate one or more calls to a library routine to map the 
structure at run time.  These calls can be expensive, and so when the compiler 
makes these calls, it will issue a message so that you can locate these 
potential hot-spots in your code.

If you do have code that uses BASED structures with REFER, which the compiler 
flags with this message, you might get better performance by passing the 
structure to a subroutine that declares a corresponding structure with * 
extents. This will cause the structure to be mapped once at the CALL statement, 
but there will no further remappings when it is accessed in the called 
subroutine.


is almost a literal copy of text in an email I sent to IBM's Peter Elderon 
close to 30 years ago, and if you use PL/I to build linked lists, and/or trees 
using BASED storage, I'd suggest you think about the second
(area-reference) parameter of the ALLOC builtin function, and the NEXTALLOC 
builtin, both are the result of my RFEs, and combining them with the EMPTY 
builtin, well think about it. ;)

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

Re: Learning one's tools

[Bob Bridges]

I suppose code reviews are like post-battle debriefs, in which every choice of 
the commander is questioned, and when challenged with a better option he can 
only say "I didn't think of that at the time".  It must be extremely painful 
for the guy in the glare of the spotlight, but if it's done right -- too late 
to blame anyone now, we're just trying to make sure everyone has a chance to 
learn how to do it better next time -- it's also extremely valuable.  I truly 
hated having the code reviewers poke at my baby, and at the start of this 
thread I pointed out ways in which they didn't do it right.  But I agree with 
Shmuel, when done right you might even say they're necessary.

(And post-surgical reviews, too.  The patient lived, or the patient died, fine, 
but now we want to know what to do differently next time.)

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

/* The kingdom of Heaven is not for the well-meaning; it is for the desperate.  
-James Denney (1856-1917) */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, March 17, 2024 00:41

However, disagree vehemently about "Code reviews are dumb and not needed by 
good programmers." The first two things that a good programmer learns are that 
nobody has a monopoly on good ideas and that "Even Jove nods". Code reviews are 
like auditors and tech writers: when they are good they are very very good, and 
when they are bad they are horrid. 

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

Re: Algol

[Bob Bridges]

I wonder whether Alan Kay is the author of an article I read during the late 
'70s in PC Computing; the name sounds familiar.  I made copies and kept them 
for a while, but I've lost track of them now.  In that article the writer spoke 
of teaching students who came not knowing much about computer programming but 
being strong and certain on one point, that computer people were rigorously 
logical.  Then he had to disillusion them.

He mentioned their dismay at learning of the existence of TWO schemes, ASCII 
and EBCDIC, with different sort results.  Another of his points that sticks in 
my memory is a description of a chip that used 5 bits for instructions and had 
32 different instructions.  "Maybe it isn't immediately obvious, but that's an 
error in design.  It means that every possible bit combination is a valid 
instruction, so when your program has an error, the probability of it ending 
anywhere near the error point is nil."

I've often bewailed the loss of that article; many of its observations are 
still relevant today.

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

/* I know everyone thinks Republicans aren't funny. But if you get a bunch of 
us together, we can be a real riot.  -Nancy Mace at Washington Press Club */


From: IBM Mainframe Discussion List  on behalf of 
Rupert Reynolds 
Sent: Saturday, March 16, 2024 2:39 PM

Alan Kay described computing as a 'pop culture' and I see his point--we don't 
often learn from history and we often re-invent things and 'solve' problems 
that have already been solved before :-)

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

Re: Learning one's tools

[Robert Prins]

On Sun, 17 Mar 2024 at 11:42, Tom Harper <
05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:

> David,
>
> Yes, assembler can be used to improve performance.
>
> In the 64 years I have been programming, I have used COBOL for three
> years, C++ for six years, and assembler for 55 years.
>
> But it’s not just the language that affects performance. Design is
> critical and arranging your algorithms in the correct sequence is of the
> utmost importance.
>

It's way more important!

Here are statement counts obtained by the old PL/I Optimizing compiler for
the procedure(s) that produce one particular table:

My old algorithm:

NAT_SCAN  13,685,293,297  99.6441458%

The current algorithm, thanks to a Paul Greeen, and the result from a post
to comp.lang.pascal.borland, almost 26 years ago.

NAT_SCAN 246,805   0.6623430%
DISPOSE_RUN   14,064   0.0377431%
SETUP_RUN162,060   0.4349154%
CHECK_RUNS 1,229,773   3.3003039%

And for what it's worth, the old counts are probably correct, the transient
library of the optimizing compiler cannot handle counts over 2^31-1, so I
had to add code to emulate the loops according to the PL/I manual, using
FIXED DEC (15) variables.

Now this is only a private program <
https://prino.neocities.org/resources/lift.pli.html>, but I've updated PL/I
code myself reducing ***CPU*** time from well over three hours to just 20
minutes, by just changing two declarations, and while working at a Dutch
airline company, I reduced CPU usage of two PL/I programs calculating CRCs
by more than 99.5%, removing calls to the PL/I library. Hell, if you look
at the current Enterprise PL/I Programming Guide, GI13-5620-00, on PDF page
372 (book page 316) in the "Avoiding calls to library routines" paragraph,
the text that reads


When your code refers to a member of a BASED structure with REFER, the
compiler often has to generate
one or more calls to a library routine to map the structure at run time.
These calls can be expensive, and
so when the compiler makes these calls, it will issue a message so that you
can locate these potential
hot-spots in your code.

If you do have code that uses BASED structures with REFER, which the
compiler flags with this message,
you might get better performance by passing the structure to a subroutine
that declares a corresponding
structure with * extents. This will cause the structure to be mapped once
at the CALL statement, but there
will no further remappings when it is accessed in the called subroutine.


is almost a literal copy of text in an email I sent to IBM's Peter Elderon
close to 30 years ago, and if you use PL/I to build linked lists, and/or
trees using BASED storage, I'd suggest you think about the second
(area-reference) parameter of the ALLOC builtin function, and the NEXTALLOC
builtin, both are the result of my RFEs, and combining them with the EMPTY
builtin, well think about it. ;)

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: Learning one's tools

[Tom Harper]

David,

Yes, assembler can be used to improve performance. 

In the 64 years I have been programming, I have used COBOL for three years, C++ 
for six years, and assembler for 55 years. 

But it’s not just the language that affects performance. Design is critical and 
arranging your algorithms in the correct sequence is of the utmost importance.

Tom Harper
Phoenix Software International 


Sent from my iPhone

> On Mar 17, 2024, at 7:18 AM, David Spiegel 
> <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Hi Tom,
> Not new/difficult, but, must be used appropriately or it can cause 
> performance issues.
> When I worked at SIAC (NYSE) 2004-2010, one of the last mainframe activities 
> I did was to look into why 6 Batch Jobs (run nightly) took over the machine 
> to the point that TSO response time was painfully slow (after 1st period).  
> The original programmer decided to use UNSTRING to build CSV Data out of 
> records from a KSDS. On a hunch, I rewrote the UNSTRING call in Assembler. 
> The run times of these 6 (similar) Jobs went from 6 hours to just over a half 
> hour.
> 
> Regards,
> David
> 
>> On 2024-03-15 16:55, Tom Harper wrote:
>> I used STRING / UNSTRING back in the early 1970s it’s not new nor difficult.
>> 
>> Unbelievable.
>> 
>> Tom Harper
>> Phoenix Software International
>> 
>> Sent from my iPhone
>> 
 On Mar 15, 2024, at 4:20 PM, Farley, Peter 
 <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> +1 from me on continuing to learn the tools of our profession.  I use 
>>> STRING and UNSTRING where they make sense, and I am still learning new 
>>> things about their use every now and then.  Life-long learning is the only 
>>> path to happiness and success.
>>> 
>>> I got the same ridiculous pushback from a senior manager one time on the 
>>> use of “sophisticated” SORT verbs like JOIN because “. . . no one but you 
>>> will know how to fix it when it breaks . . . let someone do it in COBOL 
>>> instead . . .”.
>>> 
>>> Peter
>>> 
>>> From: IBM Mainframe Discussion List  On Behalf Of 
>>> Bob Bridges
>>> Sent: Friday, March 15, 2024 12:38 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Learning one's tools
>>> 
>>> 
>>> To rant on a related subject, I once worked at a company that instituted 
>>> code reviews; a new program would be gone over by a half-dozen coworkers to 
>>> be sure it adhered to local standards.  This sort of thing is always 
>>> painful to the coder, and nevertheless (I admit reluctantly) can have 
>>> considerable value if done right.  One problem I had with it, though, is 
>>> that the standards we created for ourselves admitted that there are times 
>>> when exceptions should be made for special cases, and yet when those cases 
>>> arose no exceptions were ever allowed; the team invariably flinched, leaned 
>>> back in their seats and said "no, that's not according to our standards".
>>> 



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: Learning one's tools

[David Spiegel]

Hi Tom,
Not new/difficult, but, must be used appropriately or it can cause 
performance issues.
When I worked at SIAC (NYSE) 2004-2010, one of the last mainframe 
activities I did was to look into why 6 Batch Jobs (run nightly) took 
over the machine to the point that TSO response time was painfully slow 
(after 1st period).  The original programmer decided to use UNSTRING to 
build CSV Data out of records from a KSDS. On a hunch, I rewrote the 
UNSTRING call in Assembler. The run times of these 6 (similar) Jobs went 
from 6 hours to just over a half hour.


Regards,
David

On 2024-03-15 16:55, Tom Harper wrote:

I used STRING / UNSTRING back in the early 1970s it’s not new nor difficult.

Unbelievable.

Tom Harper
Phoenix Software International

Sent from my iPhone


On Mar 15, 2024, at 4:20 PM, Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

+1 from me on continuing to learn the tools of our profession.  I use STRING 
and UNSTRING where they make sense, and I am still learning new things about 
their use every now and then.  Life-long learning is the only path to happiness 
and success.

I got the same ridiculous pushback from a senior manager one time on the use of 
“sophisticated” SORT verbs like JOIN because “. . . no one but you will know 
how to fix it when it breaks . . . let someone do it in COBOL instead . . .”.

Peter

From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Friday, March 15, 2024 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Learning one's tools


To rant on a related subject, I once worked at a company that instituted code reviews; a 
new program would be gone over by a half-dozen coworkers to be sure it adhered to local 
standards.  This sort of thing is always painful to the coder, and nevertheless (I admit 
reluctantly) can have considerable value if done right.  One problem I had with it, 
though, is that the standards we created for ourselves admitted that there are times when 
exceptions should be made for special cases, and yet when those cases arose no exceptions 
were ever allowed; the team invariably flinched, leaned back in their seats and said 
"no, that's not according to our standards".



One particular example always rankled:  Whenever someone felt the need to use a 
STRING or UNSTRING command (I should have said we were COBOL developers), the 
team always struck it down on the grounds that STRING and UNSTRING are unusual 
commands and some COBOL coders would be unfamiliar with it.  My contention here 
is that that's absolutely true, and it's the job of the COBOL coder to ~learn~ 
the STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.



---



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 communic



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


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

Re: IBM-MAIN Digest - 15 Mar 2024 to 16 Mar 2024 (#2024-76)

[Jason Dodd]

I haven't been able to find a case where GNU COBOL has been used on 
z/OS. Has it and I'm just not aware?


On 3/17/24 00:00, IBM-MAIN automatic digest system wrote:

Date:Sat, 16 Mar 2024 19:36:29 +
From:Mark Jacobs
Subject: GNU COBOL

GnuCOBOL "has reached an industrial maturity and can compete with
proprietary offers in all environments," boasted contributor Fabrice Le
Fessant, in a FOSDEM talk.

https://thenewstack.io/20-years-in-the-making-gnucobol-is-ready-for-industry/

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

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


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