Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[David Crayford]

On 29/3/23 22:16, Robert Prins wrote:

  On Wed, 29 Mar 2023 at 11:20, Seymour J Metz  wrote:


"You can write FORTRAN in any language."

Too be fair, much of what I take for granted in PL/I control structures
was not in the original version, and IBM rejected the original SHARE
requirement for a CASE statement.


But the SELECT statement that they added (before my time) later beats the
crap out of CASE in C & Pascal.


No argument there but it still only supports scalars. It's pretty dusty 
when compared to structural pattern matching such as Pythons match [1] 
or Kotlins when expression or similar in any modern programming language.


[1] https://peps.python.org/pep-0636/
[2] https://kotlinlang.org/docs/control-flow.html#when-expression



Robert


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

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[David Crayford]

On 28/3/23 13:26, Tony Harminc wrote:

I use programming languages that I don't like all the time. C, in
particular, I dislike a lot. That doesn't mean they're not useful.

Whew! And I thought you were a C fanatic. Thanks for disabusing me of that.
Ha! I don't develop emotional attachments to programming languages, 
except for Lua which I find exceptionally elegant. Its power and 
conciseness are truly impressive. I'm still astonished how such a tiny 
language can be so powerful with such economy. Nonetheless, I tend to 
follow the crowd and use Python as my primary scripting language, even 
though I have a preference for Lua. While Kotlin appealed to me for our 
latest project, we ultimately opted for Java due to its abundant talent 
pool, which eliminated the need for additional training of new hires.



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

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[David Crayford]

On 28/3/23 13:56, Wayne Bickerdike wrote:

During my early training we were sent to learn Michael Jackson structured
programming.


I had a few brief years as an applications programmer back in the early 
90s. I came from operations so I had to take the IBM aptitude test. The 
interviewer held out both hands, one with an open palm the other with a 
clenched fist and asked me "what hand is the ball bearing in"?. Anyway, 
they shipped us all off for a months training in rural Berkshire just 
outside London for training. Very nice it was too, loads of nice quaint 
pubs. We learned Jackson Structured Programming methodology before we 
wrote any code. We drew org chart diagrams to design programs. Each box 
had a different character in the top right such as a asterix or a circle 
to determine iteration or selection. It was decent for designing COBOL 
programs. I think it only ever took of in the UK, maybe because Jackson 
was a Brit.




MJ quotes Dijkstra a lot, however, I didn't realise that he
was a PL/I hater. That was the first language I learned and still think it
was a masterpiece.


The PL/I specification was ahead of its time. It was too difficult to 
write a decent compiler so the guys at bell invented C. PL/I is arguable 
a better language then C but it's a niche language. IIRC, roughly 90% of 
mainframe applications are written in COBOL. I only worked with PL/I 
briefly but it was a breath of fresh air after COBOL. It had generic 
functions and lots of really nice features such as built-in multi-tasking.




I encountered COBOL after I left IBM and it happened to
be Microfocus COBOL, a very odd variant designed for Z80/CPM based
microcomputers. It barely did the job since it only supported a rudimentary
ISAM file system. A couple of years later as our software house was going
broke, I went for an interview for a DOS/VSE COBOL role. The customer was
doubtful that my MF COBOL would translate to a mainframe role. It didn't
prove to be a problem but oh how I wished it had been a PL/I shop.

Inverted programs in COBOL? Blech..

On Tue, Mar 28, 2023 at 4:27 PM Tony Harminc  wrote:


On Mon, 27 Mar 2023 at 23:22, David Crayford  wrote:

I think it was flippant Edsger W. Dijkstra  quote:

  “The use of COBOL cripples the mind; its teaching should,
therefore, be regarded as a criminal offense.”

Dijkstra wasn't hot on a lot of languages:

"If Fortran has been called an infantile disorder, PL/I must be
classified as a fatal disease."
-Edsger Dijkstra in Introduction to the Art of Computer Programming

Which prompted, or at least provided a juicy quote for, Ric Holt's
1972 paper "Teaching the Fatal Disease (or) Introductory Computer
Programming Using PL/I".


I use programming languages that I don't like all the time. C, in
particular, I dislike a lot. That doesn't mean they're not useful.

Whew! And I thought you were a C fanatic. Thanks for disabusing me of that.

Tony H.

--
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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[David Crayford]

On 27/3/23 22:07, Bill Johnson wrote:

+1
About a year or so ago I posted about the number of lines of COBOL code in use 
worldwide and stated COBOL was going to be the language of choice for many 
decades to come. Estimates say 800 billion lines (and growing) in use today. As 
usual, I was attacked for my fact based opinion. 
https://www.zdnet.com/article/programming-languages-how-much-cobol-code-is-out-there-the-answer-might-surprise-you/


Facts! You've quoted an article from the internet!

"The study, commissioned by IT company Micro Focus and conducted by 
research and analysis firm Vanson Bourne"


Micro Focus is a vendor who hawks COBOL compilers and IDE's. It's a bit 
like McDonalds commissioning research on the health benefits of Big Mac's.







Sent from Yahoo Mail for iPhone


On Monday, March 27, 2023, 1:56 AM, Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:




In COBOL, for example, the following end up doing the same thing.


Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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




--
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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[David Crayford]

I think it was flippant Edsger W. Dijkstra  quote:

    “The use of COBOL cripples the mind; its teaching should, 
therefore, be regarded as a criminal offense.”


I use programming languages that I don't like all the time. C, in 
particular, I dislike a lot. That doesn't mean they're not useful.


No COBOL, no mainframe! Simple as that.

On 27/3/23 13:55, Farley, Peter wrote:

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:




In COBOL, for example, the following end up doing the same thing.


Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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


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

Re: watching JIT generated machine instructions on z/OS

[David Crayford]

On 23/3/23 10:29, Andrew Rowley wrote:

On 23/03/2023 11:39 am, David Crayford wrote:
FYI, the OpenJ9 JIT can implement JIT intrinsics to generate native 
decimal instructions when running on z/OS. IBM have open source 
OpenJ9 and OMR so you can snoop around the code 
https://github.com/eclipse-openj9/openj9/blob/master/jcl/src/openj9.dataaccess/share/classes/com/ibm/dataaccess/DecimalData.java


More interesting is:
https://github.com/eclipse-openj9/openj9/blob/master/jcl/src/java.base/share/classes/com/ibm/jit/BigDecimalExtension.java 



Awesome! Thanks for the link, I hadn't seen that before. It just proves 
what some of us have known for a while and what others refuse to 
believe; Java on z/OS is a world class product. Now, if only IBM would 
sync the release cycles with the other platforms. Java 17 can't come 
soon enough for us as Spring Boot moves to Java 17 as the minimum 
supported version in December.




since that implies DFP is used for BigDecimal calculations.

However, BigDecimal is immutable so by specification calculations 
create a new object for every intermediate value. Hopefully the 
compiler can optimize away most of them, if you require maximum 
performance.


Immutable types can be a huge boost to optimization. That's why 
Functional programming languages like Clojure are so fast.


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

Re: watching JIT generated machine instructions on z/OS

[David Crayford]

On 23/3/23 01:03, René Jansen wrote:

That's another interesting take; but I have to be sure that it is used before I 
declare the winner.


I stand corrected. I just read the hardware specs. DFP was originally 
implemented in millicode (vertical microcode) on the z9 but has been on 
the hardware in a DFP unit since z10.


FYI, the OpenJ9 JIT can implement JIT intrinsics to generate native 
decimal instructions when running on z/OS. IBM have open source OpenJ9 
and OMR so you can snoop around the code 
https://github.com/eclipse-openj9/openj9/blob/master/jcl/src/openj9.dataaccess/share/classes/com/ibm/dataaccess/DecimalData.java



On 22 Mar 2023, at 18:00, David Crayford  wrote:

I can't answer you original question but I doubt if DFP is really that much 
faster. I would imagine it's implemented in millicode and not silicone so is a 
software implementation at heart. I would be surprised if it beats BigDecimal 
on a PC but I could be wrong.

On 23/3/23 00:42, René Jansen wrote:

Without reading any documentation (sorry!), the issue at hand is this. I want 
to show the performance gains of using DFP (Decimal Floating Point) for the 
typical financial application, after I noticed at some other client their 
bought packages seldom were compiled using the right compiler options (some 
could have run in 1966 or so - well I exaggerate, but a Z9 would not have been 
a problem).

This is for Java applications, and it proves slightly harder than I thought. I 
don’t have object modules to disassemble and while I can do 
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly on my mac or any Linux box, 
IBM’s J9 seems to ignore these altogether. For Linux and the mac there is a .so 
(or .dylib) that even disassembles what you’d otherwise are shown in hex - 
https://chriswhocodes.com/hsdis/ which is called hsdis but what I would not 
upload to other people’s machines lightly without building it myself.

Does anybody know how to ask the J9 (Java 8) on z/OS how to show me what it 
does when the JIT decides native code would be best?

many thanks in advance,

best regards,

René Jansen.



--
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: watching JIT generated machine instructions on z/OS

[David Crayford]

I can't answer you original question but I doubt if DFP is really that 
much faster. I would imagine it's implemented in millicode and not 
silicone so is a software implementation at heart. I would be surprised 
if it beats BigDecimal on a PC but I could be wrong.


On 23/3/23 00:42, René Jansen wrote:

Without reading any documentation (sorry!), the issue at hand is this. I want 
to show the performance gains of using DFP (Decimal Floating Point) for the 
typical financial application, after I noticed at some other client their 
bought packages seldom were compiled using the right compiler options (some 
could have run in 1966 or so - well I exaggerate, but a Z9 would not have been 
a problem).

This is for Java applications, and it proves slightly harder than I thought. I 
don’t have object modules to disassemble and while I can do 
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly on my mac or any Linux box, 
IBM’s J9 seems to ignore these altogether. For Linux and the mac there is a .so 
(or .dylib) that even disassembles what you’d otherwise are shown in hex - 
https://chriswhocodes.com/hsdis/ which is called hsdis but what I would not 
upload to other people’s machines lightly without building it myself.

Does anybody know how to ask the J9 (Java 8) on z/OS how to show me what it 
does when the JIT decides native code would be best?

many thanks in advance,

best regards,

René Jansen.



--
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: Simple C language dynamic CALL's?

[David Crayford]

It’s the same for z/OS. There is a chapter dedicated to ILC in the books 
https://www.ibm.com/docs/en/zos/2.4.0?topic=environment-zos-language-writing-interlanguage-communication-applications

> On 20 Mar 2023, at 12:53 pm, Farley, Peter 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Thanks, John, that is enlightening but it is VSE not z/OS.  I will search 
> for something similar in the z/OS docs.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> John McKown
> Sent: Sunday, March 19, 2023 8:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Simple C language dynamic CALL's?
> 
> Function pointers and fetch()
> 
> https://www.ibm.com/docs/en/zvse/6.2?topic=c-edcxbf11 
> 
>> On Sun, 19 Mar 2023, 15:02 Farley, Peter, < 
>> 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> The major z/OS programming languages (COBOL, PL/I, HLASM) allow one to 
>> write a subroutine and separately compile and link it and then call 
>> that subroutine dynamically at runtime without a whole lot of fuss.  I 
>> think even VS FORTRAN programming supports this capability.
>> 
>> From the reading I have done in the C language reference and runtime 
>> library manuals, it appears to me that dynamic subroutine calls in C 
>> can only be accomplished by setting up the separately compiled 
>> subroutine(s) in a DLL.
>> 
>> Is that a correct reading of the facts?  Or is there a simpler 
>> (non-DLL) way to set up single-procedure dynamically called subroutines in C?
>> 
>> The target environment is z/OS batch, not CICS or web.
>> 
>> Peter
> --
> 
> 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

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

Re: Git, and other Open Tools, Alternative for z/OS

[David Crayford]

On 17/3/23 22:41, Matt Hogstrom wrote:

Thanks for the information Lionel.  It’s good to share the efforts and let 
folks know.  Ideally, from my perspective, IBM should seriously consider adding 
an OpenTools offering in z/OS so customers do not have to piece meal these 
important tools.  My candidates would be:

bash
zsh
git
gzip
python (along with common packages)
virtualenv


I'm excited about the zsh shell. I use zsh with oh-my-zsh and 
Powerline10K on all my Linux systems. There is also a port of rsync 
which is awesome.




Have a package manager that would allow users to “install” them in their local 
user instance since everything is shared on z/OS.  Rocket did a nice job with 
Miniconda but it still more of a global solution.  I would expect the tools 
that are most important are those that are part of the CI/CD pipeline, app and 
infrastructure automation, etc.

My view is it would be nice if that the tools were available with the system 
and that they worked and didn’t turn into an easter egg hunt across projects 
and vendors … that hurts the platform; imho.

Matt Hogstrom
m...@hogstrom.org

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom




On Mar 17, 2023, at 10:20 AM, Lionel B. Dyck  wrote:

I was just pointing out an alternative. Obviously if you need official support 
then IBM or Rocket are your only options right now.


--
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: Amode 64 JSON library?

[David Crayford]

On 14/3/23 15:00, Robin Atwood wrote:

@David I take your point but I fear my management won't see it that way, 
reinventing the wheel and all that.


I can relate to that. Our products get branded and sold by IBM. Back in 
the day they had a no open source policy and we needed to pass a 
certificate of originality (COO). Luckily, everything has changed now 
and they just check for permissive licenses. To unfortunate truth is 
that open source is usually much better then what IBM deliver for stuff 
like JSON, REST etc. I had a look at the Web Enablement Toolkit samples 
and decided to never look at it again ;)




I shall spend today experimenting with rebuilding parameter lists, which is 
likely to be a useful technique in this whole exercise. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, March 13, 2023 10:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Amode 64 JSON library?

My advice is to abandon the horrible Web Enablement services and build a good C 
JSON parser like json-c. Even better if you can ditch C and use
C++ because then you have some very nice options.

https://github.com/json-c/json-c
https://github.com/nlohmann/json

On 13/3/23 18:07, Robin Atwood wrote:

Yes, we are linking in HWTJCSS. It only contains 18 entry points for the 31 bit 
routines, AFAICT.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Monday, March 13, 2023 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Amode 64 JSON library?

Are you using
Linkage stub method
<https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-programming-considerations>(Recommended)
Use the linkable stub routine HWTJCSS from SYS1.CSSLIB to link edit yourobject 
code.
<https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-programming-considerations>
Colin

On Mon, 13 Mar 2023 at 08:55, Robin Atwood  wrote:


I am investigating the implications of converting a large body of C
code to
64 bit. Compiling with LP64 seems
straightforward, the problems are at the binder step. I am currently
getting IEW2469E Reason 3:

"Either the reference or the target is in amode 64 and the amodes do
not match."

This I was expecting; what I wasn't expecting is an apparent lack of
64 bit entry points for the JSON routines. The IBM doc

https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-prog
rammin
g-considerations
<https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-pro
gramming-considerations> makes no mention of 64 bit calls. I have
searched, examined header files, looked at samples, but have found no
clue.
Am I missing something incredibly obvious or do I have to code stub
routines myself to convert the parameter lists?
Has anyone else encountered this?

TIA
Robin

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

--
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: Git, and other Open Tools, Alternative for z/OS

[David Crayford]

The major difference is that Rocket offer enterprise support for their 
open source tools which a lot of customers deem mandatory. YMMV.


On 14/3/23 22:09, Lionel B. Dyck wrote:

You no longer need to get the open tools for z/OS from Rocket Software -
there is a new player in town - the z/OS Open Tools project.

  


You can find them at https://zosopentools.github.io/meta/#/ and they offer
several different installation options from individual packages to a
generalized installation tool (zopen).

  


It's all on GitHub and they encourage participation, including via the use
of the new GitHub repository Discussions option - see
https://github.com/ZOSOpenTools/meta/discussions.

  


On their guild/project call last month one of the contributors mentioned the
ability to request formal support (that was the extent of that discussion)
in case your site requires it.

  


For Git they are more current than Rocket (2.26.2-78) with version 2.39.2
recently posted.

  


I have tested Git 2.39.1 and now 2.39.2 with ZIGI (see
https://github.com/zigi) with no problems.

  


As an example you'll find:

  


Bash 5.2

Bzip2 1.0.8

Curl 3.8

Git 2.39.2

Gzip 1.12

Less 608

Pcre2 10.42

Lua 5.1.5

Lynx 2.8.9

Openssl 1.1.1s

Perl 5-blead

Sed 629

Sqlite 598

Vim 9.0.0846

  

  

  


Lionel B. Dyck <><

Website:   https://www.lbdsoftware.com

Github:   https://github.com/lbdyck

  


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

  



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


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

Re: Amode 64 JSON library?

[David Crayford]

My advice is to abandon the horrible Web Enablement services and build a 
good C JSON parser like json-c. Even better if you can ditch C and use 
C++ because then you have some very nice options.


https://github.com/json-c/json-c
https://github.com/nlohmann/json

On 13/3/23 18:07, Robin Atwood wrote:

Yes, we are linking in HWTJCSS. It only contains 18 entry points for the 31 bit 
routines, AFAICT.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Monday, March 13, 2023 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Amode 64 JSON library?

Are you using
Linkage stub method
(Recommended)
Use the linkable stub routine HWTJCSS from SYS1.CSSLIB to link edit yourobject 
code.

Colin

On Mon, 13 Mar 2023 at 08:55, Robin Atwood  wrote:


I am investigating the implications of converting a large body of C
code to
64 bit. Compiling with LP64 seems
straightforward, the problems are at the binder step. I am currently
getting IEW2469E Reason 3:

"Either the reference or the target is in amode 64 and the amodes do
not match."

This I was expecting; what I wasn't expecting is an apparent lack of
64 bit entry points for the JSON routines. The IBM doc

https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-prog
rammin
g-considerations
 makes no mention of 64 bit calls. I have
searched, examined header files, looked at samples, but have found no
clue.
Am I missing something incredibly obvious or do I have to code stub
routines myself to convert the parameter lists?
Has anyone else encountered this?

TIA
Robin

--
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: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 7/3/23 16:59, René Jansen wrote:

On 7 Mar 2023, at 08:45, David Crayford  wrote:

The industry has spoken! Python is the most popular programming language in the 
world so haters will have to just suck that up.

That is a very funny statement. Nobody hates Python - the hype will blow over 
like Perl, Visual Basic, Ruby, COBOL, etc. O wait, there is still tons of COBOL 
around, like there will be tons of Rexx around for ages.


Agreed. And there is lots of REXX on the mainframe.




While we do not hate Python (it was a great television series in the seventies) 
we can do without the attacks on Rexx. Like the JCL replacement from IBM’s 
Clunkification department, the examples will speak for themselves. Look at it 
in all its glory, coming in at 190 lines plus lots of imported zooutils, at 
https://github.com/IBM/zoau-samples/blob/main/samples/smpe_list.py - it 
replaces about 15 lines of JCL. If that was meant to undercut the credibility 
of Python, it is a very, very clever attempt by an old mainframer.

If I now ask ChatGPT for a script to list some SMP/E zones, it shows me:

/* REXX program to list the status of all SYSMODs */

/* Set up the SMP/E commands to be executed */
smp_cmds.1 = "SET BDY(GLOBAL)."
smp_cmds.2 = "LIST SYSMOD(*) WHERE(SYMBOLICDATE GT 0)."
smp_cmds.3 = "SET BDY(LOCAL)."

/* Write the SMP/E commands to a temporary data set */
"ALLOC F(SMPCMD) NEW REUSE SPACE(80 80) TRK"
do i = 1 to smp_cmds.0
   "EXECIO 1 DISKW SMPCMD (STEM smp_cmds. " i ")"
end
"FREE F(SMPCMD)"

/* Invoke SMP/E to execute the commands */
"ADDRESS TSO"
"CALL 'SYS1.SMP.EB2A.EXEC(SMPXMSGS)'"
"EXECIO 0 DISKR SMPXMSGS (STEM smp_msgs. FINIS)"
"FREE F(SMPXMSGS)"

/* Display the results */
do i = 1 to smp_msgs.0
   say smp_msgs.i
end


There's bugs in that code ;)




I rest my case. Still not sure why JCL needs to be replaced but hey.


100% agree. Can't say I'm a big fan of JCL but it does the job.



The curious case with Rexx is that it has been under attack from the beginning, 
like all good things within IBM, like VM and JES2. Later, in OS/2, it was 
relentlessly attacked by Microsoft and almost left out of it, only to be 
introduced in the IBM EE “Extended Edition”, possibly because it was better 
than BASIC of the day.


Interesting. I know it seems like I'm always attacking REXX but I would 
suggest that I'm criticizing, not attacking. I used to work on NetMaster 
back in the 90s and danced a jig of joy when I could use REXX instead of 
NCL. I ways also delighted when ISPF supported inline REXX panel exits 
so I could avoid horrible panel logic.


These days I spend most of my time on z/OS using a bash shell. I have 
written REXX scripts that use the SDSF API to interact with the spool, 
console etc. I also like REXX to write scripts that call batch programs 
redirecting the output to stdout/stderr etc so I can spawn batch 
utilities from UNIX processes such as Java web servers. For short 
scripts REXX is an excellent language. However, I don't think it scales. 
One glance at the ISPF DTL compiler which is 42KLOC confirms this.


/* REXX */

parse arg script_file
if script_file = '' then do
  "Usage: kciomega "
  exit 2
end

call syscalls 'ON'
address syscall 'realpath . cwd'
address syscall 'realpath 'script_file' script_file'

call BPXWDYN("ALLOC DD(SYSPRINT) PATH('/dev/fd2') PATHOPTS(OWRONLY) 
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(SYSOUT) PATH('/dev/fd2') PATHOPTS(OWRONLY) 
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(KCIPRINT) PATH('/dev/fd2') PATHOPTS(OWRONLY) 
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(KCIFLOW) PATH('"script_file"') FILEDATA(TEXT) 
PATHOPTS(ORDONLY) MSG(2) REUSE")


address ATTCHMVS "KCIOMEGA"

call BPXWDYN("FREE DD(SYSPRINT)")
call BPXWDYN("FREE DD(SYSOUT)")
call BPXWDYN("FREE DD(KCIPRINT)")
call BPXWDYN("FREE DD(KCIFLOW)")



Rexx always has been the tool of systems staff, who, while disallowed to do any 
programming, saved many an application (and company) with Rexx, and rubber 
bands. This is why this is such a strange forum to attack Rexx on, and I wonder 
if you just cannot help yourself, or it is some officially sanctioned action, 
somewhat akin to the movement of replacing some easy to use SMP/E JCL (the plot 
comes together here, the unconscious hints give at away) with endless dialogs, 
like young IT people want to be turned into clerks doing spreadsheets.


I was just responding to Peter Farley's post WRT I/O performance which 
gave me an opportunity for a shameless pyzfile plug ;)




So why don’t you indeed port ooRexx to z/OS, and see what happens? You can 
change the threads structure, VS Studio Code has nice tools for that. It would 
be a constructive addition to the discussion. And it would prove some points, 
l

Re: REXX, ooRexx, BSF4ooRExx (Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 8/3/23 02:26, Rony G. Flatscher wrote:
There also appears to be bugs in SysThread where the "attached" 
member variable is not initialized in the constructor that takes a 
pthread_t argument.


Ah, interesting that this is regarded a stumbling block, how about 
pthread_getunique_np() or such then?



Obviously, the "_np" suffix stands for "non-portable". It doesn't exist 
on z/OS! I happen to know the internal structure of the opaque pthread_t 
structure on z/OS and to extract the thread ID (TCB address) one would 
implement something like:


int gettid() { return (int)(pthread_self().__ & 0x7fff); }



... cut ...

I you want to attract people to work on ooRexx then I suggest 
modernizing the development pipeline. Move everything to Github. 
Nobody wants to use Subversion anymore and you can create wikis and 
improve the documentation.


Sorry, there are lots of projects that use subversion, despite the big 
trend to Github and the likes. Therefore there are some who also 
shadow ooRexx in github informally.


Luckily I don't have to work on those projects. We converted all of our 
Subversion projects to Git 15 years ago. There's tooling for that. BTW, 
the shadow ooRexx repo on Github doesn't have branches and I couldn't 
find ooRexx 5.0. Subversion is not supported on z/OS so I'm stuck with Git.



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

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 7/3/23 02:39, Rony G. Flatscher wrote:

On 06.03.2023 02:43, David Crayford wrote:
I'm sure your BSF4ooRexx is a really nice library. But it's moot 
point talking about it on this forum because ooRexx has not been 
ported to z/OS, I'm sorry to say that I think it probably never will be. 


That would be unfortunate and actually a little bit unprofessional if 
other non-IBM-invented and great software gets ported to it. OTOH 
seeing the FUDding towards ooRexx it is not a surprise, keeping 
everyone in the wait-and-see room (the purpose of FUD marketing).


Unless, of course, there is a REXX enthusiast who has the time and 
skills to do the port. I can tell you from experience, it's not easy. 


Your experience stems from the days where ooRexx was coded to be 
32-bit only, with quite a few hacks from its history at IBM (written 
originally at a time where C++ was not yet standardized, every company 
had its own C++ (pre-)compiler, then the need to have it run on OS/2, 
AIX, Windows and the like).


In the meantime the kernel got totally rewritten and the build system 
changed from autotools to CMake, making it possible to create ports of 
ooRexx with any bitness and operating system targets quickly.



I did notice that CMake is being used for the build. That's good as IBM 
have ported CMake to z/OS. It's hidden away on a personal Github repo by 
an ex-IBMer who used to work in the Java JIT team. I may mention that to 
IBM.


Anyway, I digress. ooRexx still have the same portability issues as 
before. For example, it assumes that 'phread_t' is a integer. On z/OS, 
System i, BSD etc it's an opaque type, a struct.


In file included from 
/u/ts8004/git/ooRexx/common/platform/unix/SysSemaphore.hpp:51:
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:70:36: error: no 
matching constructor for initialization of 'pthread_t'

    SysThread() : attached(false), _threadID(0) { ; }
   ^ ~
/usr/include/sys/types.h:300:19: note: candidate constructor (the 
implicit copy constructor) not viable: no known conversion from 'int' to 
'const pthread_t' for 1st argument

  typedef struct {
  ^
/usr/include/sys/types.h:300:19: note: candidate constructor (the 
implicit move constructor) not viable: no known conversion from 'int' to 
'pthread_t' for 1st argument
/usr/include/sys/types.h:300:19: note: candidate constructor (the 
implicit default constructor) not viable: requires 0 arguments, but 1 
was provided
In file included from 
/u/ts8004/git/ooRexx/rexxapi/client/ClientMessage.cpp:41:
In file included from 
/u/ts8004/git/ooRexx/rexxapi/client/LocalAPIManager.hpp:47:
In file included from 
/u/ts8004/git/ooRexx/common/platform/unix/SysSemaphore.hpp:51:
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:86:17: error: 
cannot convert 'pthread_t' to 'uintptr_t' (aka 'unsigned long') without 
a conversion operator

 return (uintptr_t)_threadID;
    ^~~~
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:89:37: error: 
cannot convert 'pthread_t' to 'size_t' (aka 'unsigned long') without a 
conversion operator
    inline size_t hash() { return (((size_t)_threadID) >> :sunglasses: 
* 37; }


IBM warns about this in it's documentation 
https://www.ibm.com/docs/en/i/7.1?topic=ssw_ibm_i_71/apis/concep17.html


Amazon have been fixing this bug in their C SDK 
https://github.com/awslabs/aws-c-io/issues/217


There also appears to be bugs in SysThread where the "attached" member 
variable is not initialized in the constructor that takes a pthread_t 
argument.




I also wonder what will happen to ooRexx once Rick McGuire retires? 
Is there a big enough community to keep it going?


Again FUD (fear, uncertainty and doubts): make its future doubtful 
should anyone think of porting it to z/OS?


Seriously, ooRexx is open-source so no one can pull it from the market 
such that any investment in it is strategically safe. The current set 
of features add already a lot of wealth of help and flexibility to the 
REXX table, there would be no need to add new ones to keep ooRexx an 
extremely improved over classic REXX tool forever.


I you want to attract people to work on ooRexx then I suggest 
modernizing the development pipeline. Move everything to Github. Nobody 
wants to use Subversion anymore and you can create wikis and improve the 
documentation.



Back to your doubts: yes, there are plenty of highly skilled 
programmers in the ooRexx community to take on maintenance and even 
add new features if deemed necessary (one of the ooRexx developers has 
even an experimental branch of ooRexx where he tests all sort of 
interesting features).


So, there is no reason to doubt the future of ooRexx. It is a safe 
investment.


I would be interested to know to average age of the commiters.




FWIW, the Python Py4J and JPype (and others)  libraries are similar 
to BSF4ooRexx and both run on z/OS. Note: you 

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

I'm sure your BSF4ooRexx is a really nice library. But it's moot point 
talking about it on this forum because ooRexx has not been ported to 
z/OS, I'm sorry to say that I think it probably never will be. Unless, 
of course, there is a REXX enthusiast who has the time and skills to do 
the port. I can tell you from experience, it's not easy. I also wonder 
what will happen to ooRexx once Rick McGuire retires? Is there a big 
enough community to keep it going?


FWIW, the Python Py4J and JPype (and others)  libraries are similar to 
BSF4ooRexx and both run on z/OS. Note: you will need access to the 
xlclang/xlclang++ libraries to install those packages as PyPi doesn't 
have binaries for z/OS.


https://talvi.net/posts/a-brief-overview-of-python-java-bridges-in-2020.html

We use ReactorNetty for Java TCP servers [1]. Although it's far more 
common these days to use a layer 7 protocol such as HTTP(S) using a 
framework like Spring to do all the heavy lifting. It would be 
interesting to see how BSF4ooRexx could use ReactorNetty and if there 
would be any benefit over just using Java or Kotlin.


[1] https://projectreactor.io/docs/netty/release/reference/index.html

Python is not my favorite language by a country mile. For scripting I 
would choose Lua every day of the week and twice on Sundays. My younger 
colleagues, however, would not. A lot of universities use Python as the 
language for Introduction to Programming courses so the new hires 
already know the language from colleague. The reason I evangelize Python 
on z/OS is because I can see that IBM are backing it and it's strategic. 
I recently noticed IBM have released the Python AI Toolkit for z/OS 
which is free of charge. Exciting times ahead.


https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS223-021/index.html=en_locale=en


On 6/3/23 04:16, Rony G. Flatscher wrote:

Comment, asking:

    > Like what? Have you ever tried to write a TCP server in REXX?

Comment, receiving:

    > Start here and it is reasonably simple:


    - TCPIP.SEZAINST(RSSERVER)
    - TCPIP.SEZAINST(R6SERVER)


Comment: so writing a TCP server in REXX is not only theoretically 
possible, but a reality. Interesting what happens next:


    Thanks for the links. Now, there is code duplication between the 
two modules. How would one go

    about externalizing the common code to a module?

    The method of maintaining the socket descriptor list is crude and 
highlights the lack of data

    structures in classic REXX.

    Writing a non-blocking, multiplexing TCP server in Python is simple
    https://docs.python.org/3/library/selectors.html

Comment: surprisingly bringing up totally different items/aspects 
(somehow as "if you can, confuse/sidetrack/derail them"). The answer 
is: if one has a need for a TCP server or a TCP client in REXX one can 
create and use one as has been pointed out.


There have been no questions asked about how to go about "writing a 
non-blocking, mulitplexing TCP server in Python". If there was a need 
to "write a non-blocking, multiplexing TCP server in Python" why was 
that particular question not asked in the first place?


OTOH if the need is for REXX servers and/or clients (the original 
question) that employ "a non-blocking, mulitplexing TCP server" (the 
new, derailing questions) and one wishes to code that in REXX one can 
either look for REXX function libraries supplying the needed 
infrastructure, or create such interfaces to such libraries, or use 
NetRexx or BSF4ooRexx, which get one even more powerful abilities due 
to be immediately able to exploit the multiplatform, tested, cunning 
Java class libraries that come for free with Java. :)


Here slides where business administration students who learn 
programming (in a course named "Business Programming") as novices (!) 
in the second part of the semester (after two months learning Rexx and 
then ooRexx from scratch) having become able to use all of Java as a 
huge external ooRexx function and class library: 
 
(the slides also demonstrate how to take advantage of the Java SSL/TLS 
classes, it is actually quite easy). This demonstrates among other 
things how easy it becomes to exploit Java from ooRexx for creating 
TCP server and clients, and as one can see it is even easy doing the 
same with employing Java's SSL/TLS from the Rexx programs! [BTW this 
has become possible because of ooRexx dynamic and message based 
nature. Java objects suddenly understand ooRexx messages, the case of 
spelling method names or field names is not relevant anymore and some 
more. Or invoking Java methods on the Java RexxProxy class causes 
messages to be sent off to the proxied Rexx object and some more.]


Compare the Python library above with what Java allows for, here a 
nice overview article about it: 

Re: Common standard for number formatting equiv. to mainframe facilities?

[David Crayford]

On 6/3/23 05:07, Tony Harminc wrote:

On Sun, 5 Mar 2023 at 08:32, David Crayford  wrote:

strfmon() should do the trick.
Sigh... Binary floating point for currencies. Doesn't end well. Even
Bitcoin et al expect correct decimal results.



Yep. C was never really used for writing business applications. As you 
mentioned bitcoin I checked for golang decimal support as HyperLedger is 
written in go. It's implemented using a library 
https://pkg.go.dev/github.com/shopspring/decimal#section-readme that 
looks similar to the Java BigDecimal class.


gcc and clang both support the N1312 draft of ISO/IEC WDTR24732 for 
decimal floating point. However, the runtime I/O functions don't so you 
need to use a library authored by IBM [1]. On platforms that don't 
support decimal floating point in hardware it's implemented using 
Cowlishaw's decNumber library.


[1] https://github.com/libdfp/libdfp




https://pubs.opengroup.org/onlinepubs/009604599/functions/strfmon.html


There seems to be a newer version at
https://pubs.opengroup.org/onlinepubs/9699919799/functions/strfmon.html
Still binary FP though.

Tony H.

--
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: Common standard for number formatting equiv. to mainframe facilities?

[David Crayford]

strfmon() should do the trick. 

https://pubs.opengroup.org/onlinepubs/009604599/functions/strfmon.html

> On 5 Mar 2023, at 4:06 am, Rupert Reynolds  wrote:
> 
> To explain, I'm writing new PC code. I want the equivalent of EDMK in
> (something like) snprintf() format strings to print numbers with optional
> floating currency symbol and spaces/commas between thousands. (not
> forgetting n,nn,nn,nnn.nn style used in at least one country).
> 
> As far as I can see, snprintf() format strings can't handle it, but PL/I
> and even assembly (EDMK) make this easy.
> 
> Is there a common standard I should look at, please?
> 
> e.g. format 1234.56 with "$999,999,990.00"
> leads to "  $1,234.56".
> 
> I'm not going to be choosy about input data type--it's the presentation
> that matters and I'd rather not reinvent the wheel.
> 
> Any suggestions, please?
> 
> Roops
> 
>> On Sat, 4 Mar 2023, 18:39 Mike Schwab,  wrote:
>> 
>> 
>> https://www.researchgate.net/publication/342570694_Coupling_Facility_Configuration_Options_-_Updated_2020
>> 
>> CF is not counted on SCRT, shown on RMF reports.
>> Won't cost you on z/OS, may on some vendors.
>> 
>> Thin CFs go to enabled wait when work is completed, restart when
>> interrupt says there is work.
>> 
>> Estimate is 3% light sharing to 13% heaving sharing (of z/OS workload).
>> 
>> Thin CF would use internal links so no I/O overhead to another CPU.
>> 
>>> On Fri, Mar 3, 2023 at 9:35 PM Laurence Chiu  wrote:
>>> 
>>> The situation.
>>> 
>>> We share a couple of Z13's with another (larger client). Z13 B is where
>> we
>>> run our development LPARs and Z13 A is production.
>>> 
>>> For critical business reasons an online application on our production
>> LPAR
>>> needs to be highly available and that means in a parallel sysplex.  But
>> our
>>> outsourcer has told us it cannot be done for the following reasons
>> because
>>> there are no spare ICF engines on the host B - all are being used by
>> other
>>> CF instances, either to support production Sysplexes or development ones
>>> (not ours).
>>> 
>>> Host A does potentially have a spare ICF engine we could use to support a
>>> production parallel Sysplex but good practice does recommend you create a
>>> test one first of course.
>>> 
>>> I then asked the question, if host A has a spare ICF engine, can't it be
>>> used to support a CF to be used by the test Sysplex on B. I was advised
>>> this was not possible since there are no spare connections between host A
>>> and Host B (Infiniband possibly) so the Sysplex on B could not actually
>>> communicate with the CF on A.
>>> 
>>> Our requirement for the Sysplex is primarily to be able to share a VSAM
>>> dataset which is hit every time a transaction comes in with a peak of
>> about
>>> 99tps. So we would need VSAM RLS to share the dataset records between the
>>> two application instances. There is no DB2, CICS or IMS so I think the
>> only
>>> structures in the CF are those to support VSAM RLS, maybe some XCF
>>> structures and core systems.
>>> 
>>> Knowing that we would only bring up the test sysplex to make sure
>>> transactions routed correctly across the two LPARs and most of the time
>> we
>>> would have one member of the Sysplex off, I suggested that the test CF
>>> could be built using a CP.  To this suggestion I received the following
>>> (anti) advice
>>> - there would be MSU costs (we don't care since we think the MIPS load on
>>> the CF would be low). Plus we would ask that the CF be defined with
>> Dynamic
>>> Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going
>> to
>>> be idling most of the time, MSU consumption is not going to be a major
>> cost.
>>> - it's strongly recommended not to do this by IBM. Yet when I read this
>>> document
>>> 
>>> https://www.ibm.com/downloads/cas/JZB2E38Q
>>> the option is discussed in great detail and the only negatives are the
>>> incurring of MSU costs and some performance degradation if both a z/OS
>> and
>>> CF LPAR are trying to use the same CP at the same time.  But this can be
>>> managed.
>>> 
>>> - that a CF running on a CP would need a dedicated CP engine and there
>> are
>>> no spare engines in host B. That totally flies against the information I
>>> have read from IBM docs.
>>> 
>>> Of course for production the CF on host A would be configured to use an
>> ICF
>>> engine (or share one)
>>> 
>>> Finally, while I accepted the argument at the time there were no
>>> connections between Host A and Host B, further reading suggests that you
>> do
>>> not need to dedicate channels for communications but use XCF or by using
>>> Infiniband sub channels or sharing the same physical link with more than
>>> one Sysplex. Then the issue of running the CF on a CP goes away since I
>> can
>>> ask for two CF's to be defined on host A, one for production and one for
>>> test and DCFC ensures that that production CF is not impacted by the
>>> development one.
>>> 
>>> A lot to digest here but I really want to have some 

Re: Virtual Storage Manager - LDA.

[David Crayford]

On 4/3/23 05:45, Steve Smith wrote:

If you'd stick to the heap, which is much more efficient, you can request
storage usage reports with quite a bit of detail.


+1. And if you can also diagnose the heap using tools like Fault 
Analyzer and good old IPCS.




sas

On Fri, Mar 3, 2023 at 2:37 PM Seymour J Metz  wrote:


I doubt that you will get what you need that way. PL/I subaloocates
storage withing big blocks, and doing your own GETMAIN/STORAGE instead of
using native PL/I support may make matters worse.

MVS also suballocates storage, and I know of no GUPI to run the chains
with proper serialization and give the free/allocated counts.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
of Massimo Biancucci [mad4...@gmail.com]
Sent: Friday, March 3, 2023 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Virtual Storage Manager - LDA.

Hi everybody,

I've a PLI program who does ALLOCATE and FREE of some based areas in order
to build and manage a dynamic tree.

I'm debugging a problem where it runs out of memory.
To control how much memory it's using I refer to LDA.
To be sure I changed the ALLOC and FREE with explicit (via a ASM module) to
STORAGE OBTAIN and RELEASE.

Here is the question:
I display the LDA structure before and after freeing some areas (few KB,
anyway more than zero) and I see no immediate difference.
Is the information in LDA updated by VSM with any delay ?

Thanks a lot in advance.
Max

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 3/3/23 22:33, Sebastian Welton wrote:

On Thu, 2 Mar 2023 06:57:01 -0600, Jay Maynard  wrote:


I haven't tried to write anything in Rexx, let alone a TCP server. I'd
probably be inclined to use Go for that, though.


Start here and it is reasonably simple:

- TCPIP.SEZAINST(RSSERVER)
- TCPIP.SEZAINST(R6SERVER)


Thanks for the links. Now, there is code duplication between the two 
modules. How would one go about externalizing the common code to a module?


The method of maintaining the socket descriptor list is crude and 
highlights the lack of data structures in classic REXX.


Writing a non-blocking, multiplexing TCP server in Python is simple 
https://docs.python.org/3/library/selectors.html




Sebastian

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 3/3/23 12:51, Mike Schwab wrote:

They only got a few dongles out before they shut the program down.


That's disappointing. IIRC, IBM allow access to containerized z/OS 
images. I don't know anything about how one would procure access but I 
believe Peter Farley has experience in that space.




On Thu, Mar 2, 2023 at 10:22 PM David Crayford  wrote:

It's my understanding that IBM made the zPDT available at a much more
affordable price with quite restrictive T's. I do agree with your
sentiments. I work with young guys and they raised the same point,
accessibility to a system to kick tires is an issue for young guys
considering a career as a mainframer.

On 3/3/23 11:27, David Spiegel wrote:

Hi David,
You said: "... If we want to attract and retain young talent we need
tools that they are familiar with ...".
That is not the entire story. IBM also should realize that allowing
people to experiment with z/OS via Hercules (for free) is in their
best interest.
How many more decades will this take and will it be too late by the
tie IBM figures it out?

Regards,
David

On 2023-03-02 19:40, David Crayford wrote:

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:

I think 99% of the folks on this forum want a language that can run
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that
and it's orders of magnitudes faster then REXX with the advantage
of package management. The next gen guys don't use TSO/ISPF and
they're going to use Python and couldn't give a hoot about NetRexx.


Lua is great. (Got a link to the MVS version of it?)

Yes
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0
and the doc is here
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0
which includes the installation instructions.

Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the
package loader to support PDS source data sets. Check out lpeg [1],
it rocks and is frequently used to write transpilers [2]

[1]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
[2]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0



But language-centric ecosystems not so much. (everything from PIP to
Maven)

We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be
LESS able to choose and use the right language for the function.

It's great that there is more choice on z/OS now but we are still way
behind other platforms such as Linux. If we want to attract and
retain young talent we need tools that they are familiar with. IBM
are investing heavily on porting tools to z/OS and have a dedicated
team headed up by a distinguished engineer. IBM don't do altruism so
they obviously take this seriously. I see they have a port of rsync
which piqued my interest.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0




-- R; <><

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

It's my understanding that IBM made the zPDT available at a much more 
affordable price with quite restrictive T's. I do agree with your 
sentiments. I work with young guys and they raised the same point, 
accessibility to a system to kick tires is an issue for young guys 
considering a career as a mainframer.


On 3/3/23 11:27, David Spiegel wrote:

Hi David,
You said: "... If we want to attract and retain young talent we need 
tools that they are familiar with ...".
That is not the entire story. IBM also should realize that allowing 
people to experiment with z/OS via Hercules (for free) is in their 
best interest.
How many more decades will this take and will it be too late by the 
tie IBM figures it out?


Regards,
David

On 2023-03-02 19:40, David Crayford wrote:

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run 
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that 
and it's orders of magnitudes faster then REXX with the advantage 
of package management. The next gen guys don't use TSO/ISPF and 
they're going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)


Yes 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0 
and the doc is here 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0 
which includes the installation instructions.


Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the 
package loader to support PDS source data sets. Check out lpeg [1], 
it rocks and is frequently used to write transpilers [2]


[1] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
[2] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0



But language-centric ecosystems not so much. (everything from PIP to 
Maven)


We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be 
LESS able to choose and use the right language for the function.


It's great that there is more choice on z/OS now but we are still way 
behind other platforms such as Linux. If we want to attract and 
retain young talent we need tools that they are familiar with. IBM 
are investing heavily on porting tools to z/OS and have a dedicated 
team headed up by a distinguished engineer. IBM don't do altruism so 
they obviously take this seriously. I see they have a port of rsync 
which piqued my interest. 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0






-- R; <><

--
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: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers]

[David Crayford]

On 3/3/23 00:22, Farley, Peter wrote:

But I found that using them from the z/OS Unix command line embedded in a python script just as in 
the article link is a performance nightmare.  Definitely NOT ready for production use.  The idea is 
good but the implementation is awful.  Take a close look at the implementation of the ZOAU 
dataset-read function for an example of what I saw.  Substantially better performance can be had by 
using the python subprocess.run() function to execute the "cat" shell command to capture 
the z/OS dataset file contents you need in a python list (assuming your file contents will fit in 
available memory, of course; if not use "head" instead to read in chunks at a time)
Spawning a subprocess is a bizarre way to use cat. The idomatic UNIX 
method would be to pipe cat into your Python program and read from stdin.


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run 
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that 
and it's orders of magnitudes faster then REXX with the advantage of 
package management. The next gen guys don't use TSO/ISPF and they're 
going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)


Yes https://github.com/Lua4z/Lua4z and the doc is here 
https://lua4z.github.io/Lua4z/ which includes the installation 
instructions.


Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the package 
loader to support PDS source data sets. Check out lpeg [1], it rocks and 
is frequently used to write transpilers [2]


[1] https://www.inf.puc-rio.br/~roberto/lpeg/
[2] https://moonscript.org/


But language-centric ecosystems not so much. (everything from PIP to 
Maven)


We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be 
LESS able to choose and use the right language for the function.


It's great that there is more choice on z/OS now but we are still way 
behind other platforms such as Linux. If we want to attract and retain 
young talent we need tools that they are familiar with. IBM are 
investing heavily on porting tools to z/OS and have a dedicated team 
headed up by a distinguished engineer. IBM don't do altruism so they 
obviously take this seriously. I see they have a port of rsync which 
piqued my interest. https://github.com/ZOSOpenTools






-- R; <><

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

Respectfully, I think your performance testing is hopelessly outdated. 
Starting a Java application server on z/OS takes a few seconds.


 Starting DataStreamerApplication v1.1.5-SNAPSHOT using Java 1.8.0_351 
on RSD6 with PID 33620928

 No active profile set, falling back to 1 default profile: "default"
 Tomcat initialized with port(s): 9070 (http)
 Starting service [Tomcat]
 Starting Servlet engine: [Apache Tomcat/9.0.60]
 Initializing Spring embedded WebApplicationContext
 Root WebApplicationContext: initialization completed in 3538 ms


On 2/3/23 22:36, David Spiegel wrote:

Hi Paul,
You said: "...JAVA is a good example of this. The mainframe's JAVA 
runtime is written to exploit machine assists and hardware 
instructions that a PC doesn't have..."
Every time I've watched mainframe Java since OS/90 V1, it has been 
painfully slow. Have you ever watched a WAS startup? ... It takes 
about 15 minutes on the fastest mainframes.

Good thing it has assists, otherwise it might take 2 days Feh!

Regards,
David

On 2023-03-02 08:31, Paul Gorlinsky wrote:

After watching this chain for awhile I have a couple of observations:

1) Not all compilers are equal in their tasks especially in the 
optimization area. Some are lazy and just convert the code to pseudo 
code and store it as an executable to remove one layer of processing.


2) The selection of a computer language for a given task should be 
based upon:

  A) Shop standards
  B) Limitations imposed by the OS or OS components the task is 
to be integrated with
  C) The performance requirements, that is does this new widget 
run once a day, hour,minute,second,etc.

  D) Time constraints ... execution time as well as development time
  D) The skill of the programmer


Understanding the PROS and CONS of each computer language is the key 
to a successful project.


Note: that a benchmark run with different languages on a commodity 
computer ( AKA PC ) is NOT transferable to the mainframe. JAVA is a 
good example of this. The mainframe's JAVA runtime is written to 
exploit  machine assists and hardware instructions that a PC doesn't 
have. For example, all the string manipulation instructions.


IMHO



--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 21:30, René Jansen wrote:

Not that anyone would do that, of course, being so much easier with ISPF and 
Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 but 
nothing beats Rexx for that, having not to VDEFINE everything first.

That's subjective. I find it much easier to write code in Lua. A programming 
language that supports OO, meta-programming, functional programming and 
co-routines with just 20 reserved words is a thing of absolute beauty and a 
testament to the designers. REXX is a niche language that's only used to any 
great extend on mainframes and it's popularity is constantly eroding. The 
mainframe needs to keep pace with the industry.


A very true word. And in trying to cast it in the image of Unix, it will always 
be some steps behind, and be an eternal disappointment to next gen people. Look 
at every github project or distribution repo, s390x is always a hanger-on. It 
is a platform of unique strength. What is the point of WebSphere when you have 
CICS? What is the point of then still running WebSphere on Java version 8? Why 
not build the ultimate cloud machine with all the middleware API’s but 
implemented in the best tools there are? Why doesn’t the next ChatGPT run on a 
Z17 with a Prolog/Asm combo using these enormous address spaces with all these 
new instructions on a small number of CPU’s instead of letting those 
datacenters use up all our natural resources with dinky but power hungry - even 
when idling - X86 machines. The problem with all the Z propaganda (still need 
to change that name, IBM) is that all these things about Green and Cloud were 
true, but nobody invested in the software for it, not like the /360 investment 
of the early sixties.

The problem now is pretending that it is leading edge, by running late and 
behind in rebuilding Unix tools from decades ago. The new mainframe should not 
be the old Unix, we have the new Unix in Linux and on the Mac already, and WSL 
for Windows people. IBM does need to invest in software for the mainframe, not 
to divest from it. And it should stop badmouthing its own past.


IBM are investing heavily in porting tools and have some top notch 
talent working on it https://github.com/ZOSOpenTools. Why not ask them 
to port ooRexx? I don't think they will as there just isn't a market for it.




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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 20:57, Jay Maynard wrote:

I haven't tried to write anything in Rexx, let alone a TCP server. I'd
probably be inclined to use Go for that, though.

JCL to Python:
https://medium.com/theropod/the-journey-from-jcl-to-python-so-easy-even-an-old-mainframer-can-do-it-f088cc49366a


Totally agree with you. JCL is what it is. The data set I/O classes are 
even more pathetic which is why I wrote https://github.com/daveyc/pyzfile





On Thu, Mar 2, 2023 at 6:54 AM David Crayford  wrote:


On 2/3/23 20:43, Jay Maynard wrote:

"The mainframe needs to keep pace with the industry."

I certainly hope that whatever the industry is doing that gets adapted to
the mainframe does so much more cleanly than, say, Python...

Like what? Have you ever tried to write a TCP server in REXX?



The absolute abortion that is Python's idea of replacing JCL makes COBOL

look like APL.

I haven't seen that. Can you post a link?



On Thu, Mar 2, 2023 at 6:37 AM David Crayford 

wrote:

On 2/3/23 19:48, René Jansen wrote:

I think 99% of the folks on this forum want a language that can run in

a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
orders of magnitudes faster then REXX with the advantage of package
management. The next gen guys don't use TSO/ISPF and they're going to

use

Python and couldn't give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered

with its JVM’s.

Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
I don't get the point of NetRexx.



They can do a lot more with conventional MVS than LUA, I am sure.

Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
VDEFINE. And  you can write packages and applications using PDS data
sets. REXX is impoverished in this respect and you can't share state or
data structures between modules.

/https://lua4z.github.io/Lua4z


Not that anyone would do that, of course, being so much easier with

ISPF

and Rexx and their shared variable pool. I have built dialogs in COBOL

and

PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
first.

That's subjective. I find it much easier to write code in Lua. A
programming language that supports OO, meta-programming, functional
programming and co-routines with just 20 reserved words is a thing of
absolute beauty and a testament to the designers. REXX is a niche
language that's only used to any great extend on mainframes and it's
popularity is constantly eroding. The mainframe needs to keep pace with
the industry.

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 20:43, Jay Maynard wrote:

"The mainframe needs to keep pace with the industry."

I certainly hope that whatever the industry is doing that gets adapted to
the mainframe does so much more cleanly than, say, Python...


Like what? Have you ever tried to write a TCP server in REXX?



The absolute abortion that is Python's idea of replacing JCL makes COBOL look 
like APL.


I haven't seen that. Can you post a link?




On Thu, Mar 2, 2023 at 6:37 AM David Crayford  wrote:


On 2/3/23 19:48, René Jansen wrote:

I think 99% of the folks on this forum want a language that can run in

a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
orders of magnitudes faster then REXX with the advantage of package
management. The next gen guys don't use TSO/ISPF and they're going to use
Python and couldn't give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered

with its JVM’s.

Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
I don't get the point of NetRexx.



They can do a lot more with conventional MVS than LUA, I am sure.

Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
VDEFINE. And  you can write packages and applications using PDS data
sets. REXX is impoverished in this respect and you can't share state or
data structures between modules.

/https://lua4z.github.io/Lua4z


Not that anyone would do that, of course, being so much easier with ISPF

and Rexx and their shared variable pool. I have built dialogs in COBOL and
PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
first.

That's subjective. I find it much easier to write code in Lua. A
programming language that supports OO, meta-programming, functional
programming and co-routines with just 20 reserved words is a thing of
absolute beauty and a testament to the designers. REXX is a niche
language that's only used to any great extend on mainframes and it's
popularity is constantly eroding. The mainframe needs to keep pace with
the industry.

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 19:48, René Jansen wrote:

I think 99% of the folks on this forum want a language that can run in a 
TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's orders 
of magnitudes faster then REXX with the advantage of package management. The 
next gen guys don't use TSO/ISPF and they're going to use Python and couldn't 
give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered with its 
JVM’s.


Hmm, I don't think so. NetRexx programs can not reside in PDS data sets. 
I don't get the point of NetRexx.




They can do a lot more with conventional MVS than LUA, I am sure.


Don't agree. Lua4z has a heap of integrations including TSO/ISPF without 
VDEFINE. And  you can write packages and applications using PDS data 
sets. REXX is impoverished in this respect and you can't share state or 
data structures between modules.


/https://lua4z.github.io/Lua4z


Not that anyone would do that, of course, being so much easier with ISPF and 
Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 but 
nothing beats Rexx for that, having not to VDEFINE everything first.


That's subjective. I find it much easier to write code in Lua. A 
programming language that supports OO, meta-programming, functional 
programming and co-routines with just 20 reserved words is a thing of 
absolute beauty and a testament to the designers. REXX is a niche 
language that's only used to any great extend on mainframes and it's 
popularity is constantly eroding. The mainframe needs to keep pace with 
the industry.


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 17:19, René Jansen wrote:

Time for a new pc, I think. I installed numpy (which did not came standard) and 
I got


I'm getting a m2 MacBook Pro (12-30) soon so I'll run it again and let 
you know.




➜  solution_3 git:(drag-race) ✗ python3 PrimePY.py
Passes: 11241, Time: 5.000303332984913, Avg: 0.00044482726919179013, Limit: 
100, Count: 78498, Valid: True

and speaking about ooRexx, on my daily machine, which is a glorified iPhone (a 
Mac Mini with the first m1 SOC) it runs 117 iterations instead of the 3 you 
reported. I’ll profile that later and will let the team know.

One look at the NetRexx solution gave me this (with one small change):

➜  solution_2 git:(drag-race) ✗ java PrimeNetRexx
joss_NetRexx;15686;5.54;1;algorithm=base,bits=8,faithful=yes

I’ll submit that as PrimeRexx solution_3 later today; I only changed the 
SquareRoot method to that from the JDK because there is no reason to do that 
with variable precision if you are going to trunc the result to int. There 
might be more to do, but I am rather pleased with this result already.


That shouldn't make any difference. SquareRoot is only called once. I 
had to laugh when I noticed that it was implemented using Newton–Raphson 
in REXX. How can a programming language not implement a sqrt() function?





I had a look at Kotlin. To build that example, I needed to download and install 
Gradle. Started compile.sh, this downloaded hundreds of megabytes, and then 
failed.
If I compare that to NetRexx:

nrc PrimeNetRexx


How do I build NetRexx programs using Gradle or Maven! It kind of sucks 
having to rub two sticks together using the command line!





with (sorry!) a CLASSPATH of .:NetRexxC.jar - I am not really convinced that we 
are that user unfriendly. Of course I will look into having a CLASSPATH env 
variable set in one of the scripts, but the moment the user includes something 
from another jar - they have to set a CLASSPATH anyway.

As Rony has shown, someone with mainframe experience could easily write bog 
standard Rexx and, when the performance is really needed, do a slight detour 
through NetRexx (with the added advantage that the NetRexx stays easy and 
understandable). As Colin said, we are not sieving primes all day.


I think 99% of the folks on this forum want a language that can run in a 
TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's 
orders of magnitudes faster then REXX with the advantage of package 
management. The next gen guys don't use TSO/ISPF and they're going to 
use Python and couldn't give a hoot about NetRexx.





I am interested in having a place to analyse Z arch vector instructions and DFP 
usage by compilers, also for an upcoming Rexx compiler for 64 bits. Would 
someone have such a place? I am reluctant to drive my customers lpars through 
the roof due to capping and tariffs (although slightly related to my work 
there). It would be open source, so there is no financial gain attached.

best regards,

René.



On 2 Mar 2023, at 05:24, David Crayford  wrote:

After struggling with NetRexx, I've found that it could benefit from being as 
user-friendly as Kotlin or Groovy if the maintainers want to attract more 
users. On my machine, NetRexx is slower than Python but still respectable.

However, both Python and NetRexx are outperformed by highly optimized Java 
solutions. Go is also impressive and available on z/OS using the IBM SDK.

It's important to note that NetRexx is not ooRexx, and the discussion was 
focused on the poor performance of ooRexx. While some may choose to bridge 
NetRexx with Java, I personally find it more convenient to use Kotlin or Groovy 
instead.


❯ python3 PrimePy.py
Passes: 6699, Time: 5.000532913953066, Avg: 0.0007464596079941881, Limit: 
100, Count: 78498, Valid: True
emillynge_numpy; 6699;5.000532913953066;1;algorithm=base,faithful=no,bits=8

❯ java -cp ~/NetRexx-4.04-GA/lib/NetRexxF.jar:. PrimeNetRexx
joss_NetRexx;5743;5.000354;1;algorithm=base,bits=8,faithful=yes

Optimized Java

❯ ./runSolution.sh
chrvanorleI32;6197;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32;19191;5.003000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI32C;7511;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32C;21451;5.003000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64;5957;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI64;18471;5.015000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64C;7161;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI64C;21167;5.006000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64PatternCalc;9308;5.00;1;algorithm=other,faithful=yes,bits=1
chrvanorleI64PatternCalc;29123;5.004000;4;algorithm=other,faithful=yes,bits=1
chrvanorleI8;4946;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI8;14963;5.016000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI32CUnroll;7927;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32CUnroll;25650;5.006000;4;algorithm=base,faithful=yes

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

After struggling with NetRexx, I've found that it could benefit from 
being as user-friendly as Kotlin or Groovy if the maintainers want to 
attract more users. On my machine, NetRexx is slower than Python but 
still respectable.


However, both Python and NetRexx are outperformed by highly optimized 
Java solutions. Go is also impressive and available on z/OS using the 
IBM SDK.


It's important to note that NetRexx is not ooRexx, and the discussion 
was focused on the poor performance of ooRexx. While some may choose to 
bridge NetRexx with Java, I personally find it more convenient to use 
Kotlin or Groovy instead.



❯ python3 PrimePy.py
Passes: 6699, Time: 5.000532913953066, Avg: 0.0007464596079941881, 
Limit: 100, Count: 78498, Valid: True

emillynge_numpy; 6699;5.000532913953066;1;algorithm=base,faithful=no,bits=8

❯ java -cp ~/NetRexx-4.04-GA/lib/NetRexxF.jar:. PrimeNetRexx
joss_NetRexx;5743;5.000354;1;algorithm=base,bits=8,faithful=yes

Optimized Java

❯ ./runSolution.sh
chrvanorleI32;6197;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32;19191;5.003000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI32C;7511;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32C;21451;5.003000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64;5957;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI64;18471;5.015000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64C;7161;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI64C;21167;5.006000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64PatternCalc;9308;5.00;1;algorithm=other,faithful=yes,bits=1
chrvanorleI64PatternCalc;29123;5.004000;4;algorithm=other,faithful=yes,bits=1
chrvanorleI8;4946;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI8;14963;5.016000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI32CUnroll;7927;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32CUnroll;25650;5.006000;4;algorithm=base,faithful=yes,bits=1
chrvanorleStrided32Blocks16k;12069;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleStrided32Blocks16k;37190;5.009000;4;algorithm=base,faithful=yes,bits=1

❯ go run .
Run for 5.0 seconds using 12 workers to builing a sieve up to 100...
Passes: 19506, Time: 5000 ms, Avg: 256336 ns/op, Limit: 100, Count1: 
78498, Count2: 78498, Valid: true

kpym-go-multi;19506;5.96;4;algorithm=base,faithful=yes


On 2/3/23 00:54, René Jansen wrote:

so this should work for you:

➜  test git:(master) ✗ cat hello.nrx
import java.lang.String

say 'hello java' System.getProperty("java.version")

loop i=long 0 to 10
hello(i)
end

loop i=long 0 to 10
hello(java.lang.String(i))
end

method hello(j)
   say "hello" j

   method hello(j=long)
 say "hello long" j

   method hello(j=java.lang.String)
 say "hello String" j
➜  test git:(master) ✗ unset CLASSPATH
➜  test git:(master) ✗ echo $CLASSPATH

➜  test git:(master) ✗ java -jar NetRexxC.jar hello
NetRexx portable processor 4.05-beta build 374-20230213-1052
Copyright (c) RexxLA, 2011,2023.   All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program hello.nrx
 constructor hello(Rexx)
 constructor hello(long)
 constructor hello(String)
Compilation of 'hello.nrx' successful
➜  test git:(master) ✗

I have a global CLASSPATH, and only for specific projects I have a -cp on the 
command line for Make or Ninja, to have control over versions and libraries.
A global classpath enables me to check if all code is still compatible with the 
combination of releases from different libraries I use.
But as you see it is not really needed. We are not mandating anything, and if 
you want to run from a jar, that is fine.

best regards,

René.


On 1 Mar 2023, at 17:23, David Crayford  wrote:

On 2/3/23 00:20, René Jansen wrote:

Well, it *is* an executable jar. Up to you.

Executable Jars don't require setting a CLASSPATH Rene



On 1 Mar 2023, at 17:17, David Crayford  wrote:

Why doesn't it just use an executable jar and use "-jar"?

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

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 00:54, René Jansen wrote:

maybe I was not clear.

it *is* an executable jar with the manifest built into it.


Then somebody needs to fix the scripts so it's usable by just setting 
PATH and using the current working directory.




On 1 Mar 2023, at 17:52, David Crayford  wrote:

On 2/3/23 00:34, René Jansen wrote:

Yes, I know. But linking to other code in .class files does. You can run 
NetRexx from the .jar file. This finds all NetRexx classes. But let’s say you 
want to use a Java TreeMap, or some crypto algorithm like FPE in your program - 
it will look on CLASSPATH for those.



Yes, I know that. I only want to execute the compiler without setting 
CLASSPATH. It should be an executable Jar with the main mainifest built in to 
the Jar. It makes NetRexx difficult to use and the documentation is Windows 
oriented.



On 1 Mar 2023, at 17:23, David Crayford  wrote:

On 2/3/23 00:20, René Jansen wrote:

Well, it *is* an executable jar. Up to you.

Executable Jars don't require setting a CLASSPATH Rene



On 1 Mar 2023, at 17:17, David Crayford  wrote:

Why doesn't it just use an executable jar and use "-jar"?

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

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 00:34, René Jansen wrote:

Yes, I know. But linking to other code in .class files does. You can run 
NetRexx from the .jar file. This finds all NetRexx classes. But let’s say you 
want to use a Java TreeMap, or some crypto algorithm like FPE in your program - 
it will look on CLASSPATH for those.


Yes, I know that. I only want to execute the compiler without setting 
CLASSPATH. It should be an executable Jar with the main mainifest built 
in to the Jar. It makes NetRexx difficult to use and the documentation 
is Windows oriented.




On 1 Mar 2023, at 17:23, David Crayford  wrote:

On 2/3/23 00:20, René Jansen wrote:

Well, it *is* an executable jar. Up to you.

Executable Jars don't require setting a CLASSPATH Rene



On 1 Mar 2023, at 17:17, David Crayford  wrote:

Why doesn't it just use an executable jar and use "-jar"?

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 00:20, René Jansen wrote:

Well, it *is* an executable jar. Up to you.


Executable Jars don't require setting a CLASSPATH Rene





On 1 Mar 2023, at 17:17, David Crayford  wrote:

Why doesn't it just use an executable jar and use "-jar"?


--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 1/3/23 23:54, René Jansen wrote:

yes. https://github.com/RexxLA/NetRexx

The problem there is, you have lots of other things on CLASSPATH if you do any 
real development. Also, someone might not use the nrc script at all - I don’t, 
because I just have an alias nrc=“java org.netrexx.process.NetRexxC”.


I don't set a global CLASSPATH environment variable! That's completely 
bonkers.




Also, when used in environments without a Java compiler (and we see those often 
in companies, only a JRE) use want NetRexxF.jar because that includes the 
ecilpse Java compiler. Everything is documented, of course.

But I am open to suggestions! At least it should add a $CLASSPATH, not only the 
NetRexxC.jar


Why doesn't it just use an executable jar and use "-jar"?




best regards,

René.




On 1 Mar 2023, at 16:39, David Crayford  wrote:

On 1/3/23 23:13, David Crayford wrote:

I'm happy to verify on my PC but I found NetRexx to be hopeless on Linux. I've 
added the /bin to my PATH but it's failing because it can't load the NetRexxC 
classes even though I have set the /lib directory on my CLASSPATH. Must be 
optimized for Windows weenies.


Argghhh. Let me know when it's fixed. I hate candy machine interfaces. It's so 
easy to set the working directory relative to the binary in *nix systems!!

java org.netrexx.process.NetRexxC $*
if test $? -eq 0; then
   if test "$netrexx_run" = "yes"; then
 echo "Running $1..."
 if [ ! -f $1".class" ]; then
 echo "-run error: class file not found - do not add .nrx to 
name"
 exit
 fi
 java $1
   fi
fi




On 1/3/23 22:35, René Jansen wrote:

by the way, thanks for that url. It seems my NetRexx smokes your Python with 
numpy - had not expected that.
Note that NetRexx runs on z/OS and is well-maintained.

➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes


On 1 Mar 2023, at 14:16, David Crayford  wrote:

❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
100, Count: 78498, Valid: True
emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

best regards,

René.
--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 1/3/23 23:39, René Jansen wrote:

No, and I use it mostly on macOS and Linux.it is just what Java requires: the 
NetRexxC.jar file must be on CLASSPATH. It (CLASSPATH) takes files, not 
directories, you might be successful with a /* but I never do that.


I can fix the "nrc" script to set the CLASSPATH relative to the binary. 
Is it on github?







On 1 Mar 2023, at 16:13, David Crayford  wrote:

I'm happy to verify on my PC but I found NetRexx to be hopeless on Linux. I've 
added the /bin to my PATH but it's failing because it can't load the NetRexxC 
classes even though I have set the /lib directory on my CLASSPATH. Must be 
optimized for Windows weenies.

On 1/3/23 22:35, René Jansen wrote:

by the way, thanks for that url. It seems my NetRexx smokes your Python with 
numpy - had not expected that.
Note that NetRexx runs on z/OS and is well-maintained.

➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes


On 1 Mar 2023, at 14:16, David Crayford  wrote:

❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
100, Count: 78498, Valid: True
emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

best regards,

René.
--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 1/3/23 23:13, David Crayford wrote:
I'm happy to verify on my PC but I found NetRexx to be hopeless on 
Linux. I've added the /bin to my PATH but it's failing because it 
can't load the NetRexxC classes even though I have set the /lib 
directory on my CLASSPATH. Must be optimized for Windows weenies.


Argghhh. Let me know when it's fixed. I hate candy machine interfaces. 
It's so easy to set the working directory relative to the binary in *nix 
systems!!


java org.netrexx.process.NetRexxC $*
if test $? -eq 0; then
  if test "$netrexx_run" = "yes"; then
    echo "Running $1..."
    if [ ! -f $1".class" ]; then
    echo "-run error: class file not found - do not add 
.nrx to name"

    exit
    fi
    java $1
  fi
fi




On 1/3/23 22:35, René Jansen wrote:
by the way, thanks for that url. It seems my NetRexx smokes your 
Python with numpy - had not expected that.

Note that NetRexx runs on z/OS and is well-maintained.

➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes


On 1 Mar 2023, at 14:16, David Crayford  wrote:

❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, 
Limit: 100, Count: 78498, Valid: True
emillynge_numpy; 
6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

best regards,

René.
--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

I'm happy to verify on my PC but I found NetRexx to be hopeless on 
Linux. I've added the /bin to my PATH but it's failing because it can't 
load the NetRexxC classes even though I have set the /lib directory on 
my CLASSPATH. Must be optimized for Windows weenies.


On 1/3/23 22:35, René Jansen wrote:

by the way, thanks for that url. It seems my NetRexx smokes your Python with 
numpy - had not expected that.
Note that NetRexx runs on z/OS and is well-maintained.

➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes


On 1 Mar 2023, at 14:16, David Crayford  wrote:

❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
100, Count: 78498, Valid: True
emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

best regards,

René.
--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

 of allowing it to wither and waste. And IBM should invent some good new 
stuff.

best regards,

René.





On 1 Mar 2023, at 12:15, Rony G. Flatscher  wrote:

On 28.02.2023 20:55, David Crayford wrote:

I respectfully express my opinion without intending to badmouth anyone. I 
believe that benchmarking the performance of reading a large file is not an 
artificial test but rather a real-world use case that we encounter regularly. 
It is no secret that REXX on z/OS can be slow. In fact, one of my colleagues 
who worked on the IBM File Manager product, which incorporates REXX scripting, 
developed their own subset of REXX because the performance of the TSO REXX 
interpreter did not meet their objectives.

If that is the case then it shows that IBM needs to maintain their mainframe 
REXX by replacing it with an up-to-date version of REXX (finally).

--
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: z/OS 3.1 Announcement US Letter

[David Crayford]

Interesting article on IBM SMF Explorer with Python 
https://zos-hot-topics.com/2022/SMF-Explorer/. Looks like the young'uns 
are gonna have some fun playing with SMF data in Jupyter.


On 1/3/23 06:30, David Crayford wrote:


There is a lot of AI related stuff in the announcement, including a 
new SMF explorder that leverages Jupyter Notebooks. The z16 Telum chip 
has integrated AI on die and a C library was published. Does anybody 
know if this has been ported to Python numpy or tensorflow?


In z/OS 3.1, AI and analytics solutions such as the following plan to 
be infused into the operating system using intelligent automation and 
accelerated inferencing at scale to extract and leverage valuable data 
insights:


  * AI Framework support, intended to augment z/OS with intelligence
that optimizes IT processes, simplifies management, improves
performance, and reduces skill requirements
  * The AI ecosystem, which z/OS 3.1 intends to extend by supporting a
leading AI portfolio with the ability to deploy AI co-located with
z/OS applications, designed for low latency response times
  * AI-Powered WLM, designed to intelligently predict upcoming batch
workload and react accordingly for optimized system resources
  * IBM SMF Explorer, a data access and analysis toolkit designed to
help even novice users access SMF data and extract insights in an
easy and modern way, leveraging Python and Jupyter Notebooks


On 28/2/23 23:35, Lionel B. Dyck wrote:

This is the US Version of the announcement letter

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/3/897/E
NUS223-013/index.html=en_locale=en


Lionel B. Dyck <><
Website:https://www.lbdsoftware.com
Github:https://github.com/lbdyck

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: zOSMF and zOWE for non-mainframers

[David Crayford]

Your points are quite compelling. Speaking of documentation, it's fair 
to say that most developers dread writing it! While I'd love to create a 
comprehensive tutorial for pyzfile, the package reference is already 
quite thorough.


https://daveyc.github.io/pyzfile/html/index.html

On 1/3/23 07:05, Jeremy Nicoll wrote:

On Tue, 28 Feb 2023, at 20:19, David Crayford wrote:


Utilizing
package managers to install packages is a fundamental aspect of
utilizing contemporary programming languages.

The package manager aspect os more or less irrelevant though.  What
matters is the wealth of add-ons.

(And to my mind, it's a problem.  There's too many alternatives.  If there
was - say - only one package for (eg) Perl that handled SMTP and only
one for JSON and only one for ... it'd be easy to decide which to use.
But there's not ... and they have interdependencies.)

That is, if there was a more complex, or indeed a simpler way of finding
and installing them, that'd be pretty much irrelevant.  Anyone wanting or
needing them would still find & install them,   What's fantastic is that - if
one can decide which add-ons to use, they smplify life a lot.  Then again
my (limited) experience of such things is that their documentation is
often very poor.



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

Re: z/OS 3.1 Announcement US Letter

[David Crayford]

It's my understanding that they are tensor cores, which are a type of 
vector processor optimized for matrix multiplication that can increase 
throughput per cycle. IBM have published the C API spec on Github [1]. I 
suspect they will create a Python tensorflow extension for ML/AI 
exploitation.


[1] https://github.com/IBM/zDNN/blob/main/README.md

On 1/3/23 07:12, Seymour J Metz wrote:

Take a look at PoOps and you'll see what I mean. AI  applications don't need 
the precision of the normal vector instructions, and Telum introduces a lower 
precision format. There's more than that, but again AI won't be the only 
exploiter.

The bad news is that Printing PoOps is even less practical than it used to be. 
;-)


From: IBM Mainframe Discussion List  on behalf of David 
Crayford 
Sent: Tuesday, February 28, 2023 5:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1 Announcement US Letter

On 1/3/23 06:37, Seymour J Metz wrote:

Telum isn't really an AI engine, but it has, e.g., vector capabilities 
motivated by AI applications. I expect to see it used for more than AI.

Naturally, it's not an AI engine on its own; software is required for
that functionality. An ACM article [1] suggests that a 32-chip system
can achieve 200 tflops, which is roughly double the output of a $1500
NVIDIA GeForce RTX 4090 graphics card with air cooling. In this context,
low latency is a critical factor.

[1] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F3470496.3533042=05%7C01%7Csmetz3%40gmu.edu%7C447117907cd547a158d208db19de700d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638132215394315103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ch%2FgCSGjamFVhWvs%2FMe786xAFd0K7%2BIyHSI6U%2F2T02E%3D=0




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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, February 28, 2023 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1 Announcement US Letter

There is a lot of AI related stuff in the announcement, including a new
SMF explorder that leverages Jupyter Notebooks. The z16 Telum chip has
integrated AI on die and a C library was published. Does anybody know if
this has been ported to Python numpy or tensorflow?

In z/OS 3.1, AI and analytics solutions such as the following plan to be
infused into the operating system using intelligent automation and
accelerated inferencing at scale to extract and leverage valuable data
insights:

* AI Framework support, intended to augment z/OS with intelligence
  that optimizes IT processes, simplifies management, improves
  performance, and reduces skill requirements
* The AI ecosystem, which z/OS 3.1 intends to extend by supporting a
  leading AI portfolio with the ability to deploy AI co-located with
  z/OS applications, designed for low latency response times
* AI-Powered WLM, designed to intelligently predict upcoming batch
  workload and react accordingly for optimized system resources
* IBM SMF Explorer, a data access and analysis toolkit designed to
  help even novice users access SMF data and extract insights in an
  easy and modern way, leveraging Python and Jupyter Notebooks


On 28/2/23 23:35, Lionel B. Dyck wrote:

This is the US Version of the announcement letter

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fcommon%2Fssi%2FShowDoc.wss%3FdocURL%3D%2Fcommon%2Fssi%2Frep_ca%2F3%2F897%2FE=05%7C01%7Csmetz3%40gmu.edu%7C447117907cd547a158d208db19de700d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638132215394315103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=MXKvWuepLdUIz0Azu%2FX6eqDIZ9LRGuDdRLf1ZI4iCDc%3D=0
NUS223-013/index.html=en_locale=en


Lionel B. Dyck <><
Website:https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lbdsoftware.com%2F=05%7C01%7Csmetz3%40gmu.edu%7C447117907cd547a158d208db19de700d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638132215394315103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Z6v%2FV086G7eBoPn9YwcwceqCXlUDJeL3Rm3qk6%2FxdmI%3D=0
Github:https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flbdyck=05%7C01%7Csmetz3%40gmu.edu%7C447117907cd547a158d208db19de700d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638132215394315103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=fGUilTYrLtJ8KMBgWWQ1zbfdHcjNIKwcv3zd9y0umi0%3D=0

“Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are.”   - - - Jo

Re: z/OS 3.1 Announcement US Letter

[David Crayford]

On 1/3/23 06:37, Seymour J Metz wrote:

Telum isn't really an AI engine, but it has, e.g., vector capabilities 
motivated by AI applications. I expect to see it used for more than AI.


Naturally, it's not an AI engine on its own; software is required for 
that functionality. An ACM article [1] suggests that a 32-chip system 
can achieve 200 tflops, which is roughly double the output of a $1500 
NVIDIA GeForce RTX 4090 graphics card with air cooling. In this context, 
low latency is a critical factor.


[1] https://dl.acm.org/doi/10.1145/3470496.3533042





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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, February 28, 2023 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1 Announcement US Letter

There is a lot of AI related stuff in the announcement, including a new
SMF explorder that leverages Jupyter Notebooks. The z16 Telum chip has
integrated AI on die and a C library was published. Does anybody know if
this has been ported to Python numpy or tensorflow?

In z/OS 3.1, AI and analytics solutions such as the following plan to be
infused into the operating system using intelligent automation and
accelerated inferencing at scale to extract and leverage valuable data
insights:

   * AI Framework support, intended to augment z/OS with intelligence
 that optimizes IT processes, simplifies management, improves
 performance, and reduces skill requirements
   * The AI ecosystem, which z/OS 3.1 intends to extend by supporting a
 leading AI portfolio with the ability to deploy AI co-located with
 z/OS applications, designed for low latency response times
   * AI-Powered WLM, designed to intelligently predict upcoming batch
 workload and react accordingly for optimized system resources
   * IBM SMF Explorer, a data access and analysis toolkit designed to
 help even novice users access SMF data and extract insights in an
 easy and modern way, leveraging Python and Jupyter Notebooks


On 28/2/23 23:35, Lionel B. Dyck wrote:

This is the US Version of the announcement letter

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fcommon%2Fssi%2FShowDoc.wss%3FdocURL%3D%2Fcommon%2Fssi%2Frep_ca%2F3%2F897%2FE=05%7C01%7Csmetz3%40gmu.edu%7C146e636a9e0d4228361708db19db8324%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638132202822676826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=T29yGFYduLO1l5NnTX%2F3R8rp7PvyftOfwGRRxo8%2FTJI%3D=0
NUS223-013/index.html=en_locale=en


Lionel B. Dyck <><
Website:https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lbdsoftware.com%2F=05%7C01%7Csmetz3%40gmu.edu%7C146e636a9e0d4228361708db19db8324%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638132202822676826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=2wcVQvDmJyMbVPtSX2kdfaeqT1adqj4WxavRksv6WZ4%3D=0
Github:https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flbdyck=05%7C01%7Csmetz3%40gmu.edu%7C146e636a9e0d4228361708db19db8324%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638132202822676826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=6uG8%2FMdtffGt3Vf34ruiOF7gz%2FsrqULbblyj5tD6geg%3D=0

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: z/OS 3.1 Announcement US Letter

[David Crayford]

There is a lot of AI related stuff in the announcement, including a new 
SMF explorder that leverages Jupyter Notebooks. The z16 Telum chip has 
integrated AI on die and a C library was published. Does anybody know if 
this has been ported to Python numpy or tensorflow?


In z/OS 3.1, AI and analytics solutions such as the following plan to be 
infused into the operating system using intelligent automation and 
accelerated inferencing at scale to extract and leverage valuable data 
insights:


 * AI Framework support, intended to augment z/OS with intelligence
   that optimizes IT processes, simplifies management, improves
   performance, and reduces skill requirements
 * The AI ecosystem, which z/OS 3.1 intends to extend by supporting a
   leading AI portfolio with the ability to deploy AI co-located with
   z/OS applications, designed for low latency response times
 * AI-Powered WLM, designed to intelligently predict upcoming batch
   workload and react accordingly for optimized system resources
 * IBM SMF Explorer, a data access and analysis toolkit designed to
   help even novice users access SMF data and extract insights in an
   easy and modern way, leveraging Python and Jupyter Notebooks


On 28/2/23 23:35, Lionel B. Dyck wrote:

This is the US Version of the announcement letter

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/3/897/E
NUS223-013/index.html=en_locale=en


Lionel B. Dyck <><
Website:https://www.lbdsoftware.com
Github:https://github.com/lbdyck

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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's Fall From World Dominance

[David Crayford]

IBM appears to have returned to its strength of conducting top-class 
research and development, which was always its forte. However, as the 
saying goes, nothing lasts forever. Google's reign as the world's 
dominant force may be the next to end. It seems that ChatGPT is on track 
to disrupt Google Search to such an extent that it will become 
irrelevant, and Microsoft is well-positioned to take advantage of the 
situation. While many people criticize Microsoft, it was a brilliant 
move by CEO Satya Nadella to reinvent the company, much like Lou 
Gerstner did with IBM in the 1990s. Those were certainly the days!



On 1/3/23 05:15, Phil Smith III wrote:

https://spectrum.ieee.org/ibms-fall-from-world-dominance

  


Not negative overall, just recognizing that things have changed, for the
most part.

  

  



--
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: zOSMF and zOWE for non-mainframers

[David Crayford]

On 1/3/23 00:48, Farley, Peter wrote:

David, my meaning was that timed comparisons like yours should use only python 
facilities available in the standard library, with NO PYPI packages installed.


I frequently work with Apache Kafka, and if I aimed to evaluate the 
performance of producing Kafka records using Python and Java, I would 
have to rely on open-source libraries since neither language 
incorporates Kafka clients in their standard libraries. Utilizing 
package managers to install packages is a fundamental aspect of 
utilizing contemporary programming languages. Given that pyzfile has 
been made available on PyPi, it should be deemed as the standard 
implementation for accessing MVS data sets from Python.




In my test comparison, Rexx wins because of its native access to z/OS files via 
EXECIO, but not by a huge margin.

WRT pyzfile source, the PYPI page for pyzfile provides downloads only for a 
python wheel, and specifically states that no source code is available.  Thank 
you for the github address though.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Tuesday, February 28, 2023 3:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and zOWE for non-mainframers

The pyzfile module source code has been available on Github [1] since its 
inception, and it can be considered the benchmark implementation for MVS data 
set I/O in Python. Many people, including IBM employees, have expressed 
interest in pyzfile [2]. Regarding your mention of standard Python modules, I'm 
not sure what you mean. While Python does have a large collection of modules, 
not all of them are part of the standard library. For instance, there is no 
standard YAML library in Python, but it's easy to install one using pip. This 
is commonplace in languages like Python, Java, and Perl.

[1] 
https://urldefense.com/v3/__https://github.com/daveyc/pyzfile__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!ONuSOYkmdaXS_aeXM5blMXvO7VEVMO9OjwxiaLTibjqgqcjdKHRzuyjnDudiUkcCn3tj2Uixwi_gx-HZGDUZYZU$
[2]
https://urldefense.com/v3/__https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!ONuSOYkmdaXS_aeXM5blMXvO7VEVMO9OjwxiaLTibjqgqcjdKHRzuyjnDudiUkcCn3tj2Uixwi_gx-HZxqVomhQ$

On 28/2/23 15:26, Farley, Peter wrote:

David, I will have to complain that your python benchmark is not a fair comparison.  Your python script uses a module named 
pyzfile to access z/OS files (which I see from PYPI is authored by you but for which you have published no source yet).  A fairer 
comparison would be a python script that only used standard python modules and shell commands.  My python-vs-Rexx testing was 
done using python's subprocess.run to execute the "cat" command to copy data from z/OS files (PDS, QSAM, VSAM) to 
STDOUT captured by the subprocess.run routine and then using the captured STDOUT data for the processing.  Writing to z/OS files 
(PDS member and QSAM only) was accomplished by first writing the output file data to the Unix file system (with encoding 1047 to 
write in EBCDIC) and then again using subprocess.run to execute "cp" to copy the written Unix file to the z/OS file.  
In both read and write cases I used the "//'DSN'" file name format for the z/OS files, supported by both 
"cat" and "cp".

Rexx using EXECIO or RXVSAM from CBT beats that type of python script by a small margin but not by 
a lot -- the process I was measuring averaged 23-24 "real" seconds per test for the 
python version and 19-20 "real" seconds per test for the Rexx version.

This was all done on the IBM Zxplore z/OS platform, which is x86 under the covers rather than 
"real iron", so probably zPDT.  In any case, "students" on Zxplore aren't 
permitted to install any python packages and venv/virtualenv are not available for the same reason 
(DASD-and-CPU-constrained system).  The platform only permits you to use standard python packages 
or one of the few non-standard ones pre-installed by the admins there.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of David Crayford
Sent: Tuesday, February 28, 2023 1:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and zOWE for non-mainframers

On 28/2/23 13:47, David Crayford wrote:

On 25/2/23 01:23, Farley, Peter wrote:

Python on the mainframe is pretty good, but still can't beat out
Rexx in performance even when the Rex script needs to use BPXWUNIX
and friends to access z/OS Unix file systems,


I have conducted a series of benchtests, and the results suggest that
REXX is not as fast as Python. In my testing, I compare the
performance of C, Lua, Python, and REXX, and the results are clear: C
is the fastest, followed by Lua, which is within an order of
magnitude of C. Python comes next, within an order of magnitude of
Lua, and REXX consisten

Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

I respectfully express my opinion without intending to badmouth anyone. 
I believe that benchmarking the performance of reading a large file is 
not an artificial test but rather a real-world use case that we 
encounter regularly. It is no secret that REXX on z/OS can be slow. In 
fact, one of my colleagues who worked on the IBM File Manager product, 
which incorporates REXX scripting, developed their own subset of REXX 
because the performance of the TSO REXX interpreter did not meet their 
objectives.



On 28/2/23 22:38, Rony G. Flatscher wrote:

On 28.02.2023 13:44, David Crayford wrote:
ooRexx has two main issues: its a superset of REXX, which is a subpar 
programming language, and it consumes a lot of CPU resources. Each 
language clause in ooRexx is a C++ object that invokes dynamic 
dispatch whenever it's executed. Unlike most other sensible 
programming languages, which compile to bytecode and use a virtual 
machine, ooRexx does not. When I benchmarked OoRexx against Lua, I 
was surprised to find that it was almost 100 times slower. I used 
valgrind to profile ooRexx's performance and discovered that most of 
the time was spent allocating and marking objects for garbage 
collection. These objects were language metadata used by the 
interpreter. ooRexx is an example of how not to implement a language 
interpreter in C++.


A lot of badmouthing and red herrings here (again), comparing apples 
with oranges (again). Totally ignoring what has been discussed and 
concluded a year ago, so no reliability on you.


Last year there was a discussion with the subject that over time got 
superceeded with mailings of different focuses:


- "Top 8 Reasons for using Python instead of REXX for z/OS", which 
then ended in the subject:


- "Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx 
(Re: Ad programming features (Re: ... Re: Top 8 Reasons for using 
Python instead of REXX for z/OS"


In that thread I demonstrated a little ooRexx program that did beat 
your impertinent "test program" that you implemented in C++, Lua and 
Python last year (still wondering why you did not implement that 
simple benchmark in Assembler and show those figures). After learning 
about that ooRexx program that actually performed faster than C++ (Lua 
and Python of course as well) you preferred to stop that thread of 
discussion about a year ago. Now you are back, maybe speculating 
everyone forgot about it?


The purpose of your "test program" was quite obviously to make Rexx 
and ooRexx look as bad as possible. The same intent as your current 
message in your posting like: "ooRexx is an example of how not to 
implement a language interpreter in C+." (which is nonsense).


Your artificial "test/benchmark program" that let C++, Lua, Python 
shine at first and make Rexx/ooRexx look quite bad was designed 
exactly for that purpose: let strictly typed and compiled languages be 
way ahead of dynamically typed and interpreted languages, so:


- create an array of size of ten million (sic!) of (primitive) type long
- fill the array in a loop and assign each index the result of taking 
the index value (an int being cast to long) to the square
- go through that array and get the largest stored long value and 
display it


BTW, who has a real need for such programs in her/his daily life here? 
(In this community who would really come up with the idea of 
implementing such a task in Rexx/ooRexx and not in Assembler if a real 
need existed?)


So this everyday (not!) "benchmark" is designed to make dynamically 
typed and interpreted languages look as bad as possible compared to 
strictly typed, compiled languages! It would be like comparing number 
crunching Rexx/ooRexx programs with the same programs implemented in 
Assembler and concluding Assembler is much better in general and 
forego Rexx/ooRexx (and ignoring the many other use cases in which 
Rexx/ooRexx is much better than Assembler can possibly be; any 
language has its strengths and its weaknesses, of course, including 
C++, Lua, Python, ...)!


It is an artificial test program. Still, it is possible to beat 
strictly typed, compiled languages with dynamically typed, interpreted 
languages like ooRexx as demonstrated last year in this mailing list! 
You just need to use your brain and the infrastructure that is 
available to you.


The technique has been rather simple: like it is the case with 
external function packages for Rexx/ooRexx (to e.g. interact with 
system services, RDBMS etc.) look for a package/environment that is 
strictly typed and compiled and which one can take advantage of. In 
this particular show case I picked Java/NetRexx (NetRexx compiles to 
Java byte code, so one can write with the Rexx syntax genuinely Java 
programs; NetRexx is rather easy to learn for Rexx-savvy programmers) 
as an external package.


BTW, in the meantime I added the respective ooRexx examples to the 
ooR

Re: zOSMF and zOWE for non-mainframers

[David Crayford]

You may want to take a look at MIR (Medium Internal Representation) 
which is a framework for writing JIT's. It's experimental but looks to 
build on and improve LLVM. It supports codegen for s390x so should run 
fine on z/OS.


[1] https://github.com/vnmakarov/mir
[2] https://github.com/dibyendumajumdar/ravi

On 28/2/23 20:57, René Jansen wrote:

That is interesting because I was benchmarking it years ago it was only slower 
with programs that did a lot of external calls, and all programs with 
arithmetic were a lot faster than the interpreter. Anyway, all very good 
observations for new Rexx implementations. I share your observations about the 
Object Rexx implementation, of which the garbage collection always was the 
achilles heel. But did you test with the IBM implementation or the new 5.0.0 
version? It seems to have become a lot faster over the years.

Is there a github repo with your benchmarks? Just because we are working on a 
new, VM and bytecode based Rexx system.

René.


On 28 Feb 2023, at 13:49, David Crayford  wrote:

On 28/2/23 20:41, René Jansen wrote:

Depending on what you test and what you want to see of course. You did use the 
Rexx compiler?

Yes, and the REXX compiler was slower than the interpreter. I profiled it using 
Application Performance Analyzer and it was spending 90% of it's time in 
GETMAIN calls so it has sub-optimal memory management. The REXX compiler should 
not be used if you are using medium to large stem variables or data stacks.



René.


On 28 Feb 2023, at 06:47, David Crayford  wrote:

On 25/2/23 01:23, Farley, Peter wrote:

Python on the mainframe is pretty good, but still can't beat out Rexx in 
performance even when the Rex script needs to use BPXWUNIX and friends to 
access z/OS Unix file systems,


I have conducted a series of benchtests, and the results suggest that REXX is 
not as fast as Python. In my testing, I compare the performance of C, Lua, 
Python, and REXX, and the results are clear: C is the fastest, followed by Lua, 
which is within an order of magnitude of C. Python comes next, within an order 
of magnitude of Lua, and REXX consistently performs the poorest. In addition to 
the performance factor, the vast Python ecosystem compared to the limited 
options available for REXX also make it an easy decision. Python is also 
simpler to extend with packages, while REXX requires more effort and 
potentially complex steps, such as using modern libraries that require Language 
Environment (LE).

--
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 <mailto: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 <mailto: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: zOSMF and zOWE for non-mainframers

[David Crayford]

On 28/2/23 20:41, René Jansen wrote:

Depending on what you test and what you want to see of course. You did use the 
Rexx compiler?


My tests are quite straightforward. I take a 12,000 cylinder SMF 
sequential file and read it using different programming languages and 
then compare the timing results.





René.


On 28 Feb 2023, at 06:47, David Crayford  wrote:

On 25/2/23 01:23, Farley, Peter wrote:

Python on the mainframe is pretty good, but still can't beat out Rexx in 
performance even when the Rex script needs to use BPXWUNIX and friends to 
access z/OS Unix file systems,


I have conducted a series of benchtests, and the results suggest that REXX is 
not as fast as Python. In my testing, I compare the performance of C, Lua, 
Python, and REXX, and the results are clear: C is the fastest, followed by Lua, 
which is within an order of magnitude of C. Python comes next, within an order 
of magnitude of Lua, and REXX consistently performs the poorest. In addition to 
the performance factor, the vast Python ecosystem compared to the limited 
options available for REXX also make it an easy decision. Python is also 
simpler to extend with packages, while REXX requires more effort and 
potentially complex steps, such as using modern libraries that require Language 
Environment (LE).

--
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: zOSMF and zOWE for non-mainframers

[David Crayford]

On 28/2/23 20:41, René Jansen wrote:

Depending on what you test and what you want to see of course. You did use the 
Rexx compiler?


Yes, and the REXX compiler was slower than the interpreter. I profiled 
it using Application Performance Analyzer and it was spending 90% of 
it's time in GETMAIN calls so it has sub-optimal memory management. The 
REXX compiler should not be used if you are using medium to large stem 
variables or data stacks.




René.


On 28 Feb 2023, at 06:47, David Crayford  wrote:

On 25/2/23 01:23, Farley, Peter wrote:

Python on the mainframe is pretty good, but still can't beat out Rexx in 
performance even when the Rex script needs to use BPXWUNIX and friends to 
access z/OS Unix file systems,


I have conducted a series of benchtests, and the results suggest that REXX is 
not as fast as Python. In my testing, I compare the performance of C, Lua, 
Python, and REXX, and the results are clear: C is the fastest, followed by Lua, 
which is within an order of magnitude of C. Python comes next, within an order 
of magnitude of Lua, and REXX consistently performs the poorest. In addition to 
the performance factor, the vast Python ecosystem compared to the limited 
options available for REXX also make it an easy decision. Python is also 
simpler to extend with packages, while REXX requires more effort and 
potentially complex steps, such as using modern libraries that require Language 
Environment (LE).

--
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: zOSMF and zOWE for non-mainframers

[David Crayford]

ooRexx has two main issues: its a superset of REXX, which is a subpar 
programming language, and it consumes a lot of CPU resources. Each 
language clause in ooRexx is a C++ object that invokes dynamic dispatch 
whenever it's executed. Unlike most other sensible programming 
languages, which compile to bytecode and use a virtual machine, ooRexx 
does not. When I benchmarked OoRexx against Lua, I was surprised to find 
that it was almost 100 times slower. I used valgrind to profile ooRexx's 
performance and discovered that most of the time was spent allocating 
and marking objects for garbage collection. These objects were language 
metadata used by the interpreter. ooRexx is an example of how not to 
implement a language interpreter in C++.


On 28/2/23 20:28, Seymour J Metz wrote:

What about Java? How well does JIT work?

The gold standard for REXX is ooRexx, but IBM has not seen fit to integrate it 
into z/OS or z/VM.

However, for off the shelf package libraries, Perl and Python are admittedly 
ahead of REXX. What are the Python and Ruby equivalents of CPAN?

I've found extending REXX for CMS and TSO to be easy, although admittedly 
assembler is mothers' milk to me and I didn't have to deal with LE issues.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, February 28, 2023 12:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and zOWE for non-mainframers

On 25/2/23 01:23, Farley, Peter wrote:

Python on the mainframe is pretty good, but still can't beat out Rexx in 
performance even when the Rex script needs to use BPXWUNIX and friends to 
access z/OS Unix file systems,


I have conducted a series of benchtests, and the results suggest that
REXX is not as fast as Python. In my testing, I compare the performance
of C, Lua, Python, and REXX, and the results are clear: C is the
fastest, followed by Lua, which is within an order of magnitude of C.
Python comes next, within an order of magnitude of Lua, and REXX
consistently performs the poorest. In addition to the performance
factor, the vast Python ecosystem compared to the limited options
available for REXX also make it an easy decision. Python is also simpler
to extend with packages, while REXX requires more effort and potentially
complex steps, such as using modern libraries that require Language
Environment (LE).

--
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: zOSMF and zOWE for non-mainframers

[David Crayford]

The pyzfile module source code has been available on Github [1] since 
its inception, and it can be considered the benchmark implementation for 
MVS data set I/O in Python. Many people, including IBM employees, have 
expressed interest in pyzfile [2]. Regarding your mention of standard 
Python modules, I'm not sure what you mean. While Python does have a 
large collection of modules, not all of them are part of the standard 
library. For instance, there is no standard YAML library in Python, but 
it's easy to install one using pip. This is commonplace in languages 
like Python, Java, and Perl.


[1] https://github.com/daveyc/pyzfile
[2] 
https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility


On 28/2/23 15:26, Farley, Peter wrote:

David, I will have to complain that your python benchmark is not a fair comparison.  Your python script uses a module named 
pyzfile to access z/OS files (which I see from PYPI is authored by you but for which you have published no source yet).  A fairer 
comparison would be a python script that only used standard python modules and shell commands.  My python-vs-Rexx testing was 
done using python's subprocess.run to execute the "cat" command to copy data from z/OS files (PDS, QSAM, VSAM) to 
STDOUT captured by the subprocess.run routine and then using the captured STDOUT data for the processing.  Writing to z/OS files 
(PDS member and QSAM only) was accomplished by first writing the output file data to the Unix file system (with encoding 1047 to 
write in EBCDIC) and then again using subprocess.run to execute "cp" to copy the written Unix file to the z/OS file.  
In both read and write cases I used the "//'DSN'" file name format for the z/OS files, supported by both 
"cat" and "cp".

Rexx using EXECIO or RXVSAM from CBT beats that type of python script by a small margin but not by 
a lot -- the process I was measuring averaged 23-24 "real" seconds per test for the 
python version and 19-20 "real" seconds per test for the Rexx version.

This was all done on the IBM Zxplore z/OS platform, which is x86 under the covers rather than 
"real iron", so probably zPDT.  In any case, "students" on Zxplore aren't 
permitted to install any python packages and venv/virtualenv are not available for the same reason 
(DASD-and-CPU-constrained system).  The platform only permits you to use standard python packages 
or one of the few non-standard ones pre-installed by the admins there.

Peter

-----Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Tuesday, February 28, 2023 1:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and zOWE for non-mainframers

On 28/2/23 13:47, David Crayford wrote:

On 25/2/23 01:23, Farley, Peter wrote:

Python on the mainframe is pretty good, but still can't beat out Rexx
in performance even when the Rex script needs to use BPXWUNIX and
friends to access z/OS Unix file systems,


I have conducted a series of benchtests, and the results suggest that
REXX is not as fast as Python. In my testing, I compare the
performance of C, Lua, Python, and REXX, and the results are clear: C
is the fastest, followed by Lua, which is within an order of magnitude
of C. Python comes next, within an order of magnitude of Lua, and REXX
consistently performs the poorest. In addition to the performance
factor, the vast Python ecosystem compared to the limited options
available for REXX also make it an easy decision. Python is also
simpler to extend with packages, while REXX requires more effort and
potentially complex steps, such as using modern libraries that require
Language Environment (LE).


My benchtests

Lua

local file = assert(io.open(arg[1], "rb, type=record, noseek")) while true do
     local rec = file:read()
     if not rec then break end
end

Python

import sys
from pyzfile import *
try:
     with ZFile(sys.argv[1], "rb,type=record,noseek") as file:
    for rec in file:
   pass
except ZFileError as e:
     print(e)

REXX

/* REXX */
    arg dsname
    address MVS
    call bpxwdyn "ALLOC FI(INPUT) DA("dsname") SHR"
    do until eof
      "EXECIO 1 DISKR INPUT ( STEM rec."
      eof = (rc > 0)
    end
    "EXECIO 0 DISKR INPUT ( FINIS"

The results: Add user+system to get total CPU time

  > time lua benchio.lua "//'CPA000.QADATA.PMR9.SSA.HR1315PM'" && time python3 benchio.py 
"//'CPA000.QADATA.PMR9.SSA.HR1315PM'" && time ./benchio.rex "CPA000.QADATA.PMR9.SSA.HR1315PM"
real    0m47.019s
user    0m3.255s
sys 0m1.097s

real    1m0.710s
user    0m8.001s
sys 0m2.678s

real    1m17.772s
user    0m13.575s
sys 0m4.536s

--

This message and any attachments are intended only for the use of the addressee 
and may contain

Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 28/2/23 13:47, David Crayford wrote:


On 25/2/23 01:23, Farley, Peter wrote:
Python on the mainframe is pretty good, but still can't beat out Rexx 
in performance even when the Rex script needs to use BPXWUNIX and 
friends to access z/OS Unix file systems,




I have conducted a series of benchtests, and the results suggest that 
REXX is not as fast as Python. In my testing, I compare the 
performance of C, Lua, Python, and REXX, and the results are clear: C 
is the fastest, followed by Lua, which is within an order of magnitude 
of C. Python comes next, within an order of magnitude of Lua, and REXX 
consistently performs the poorest. In addition to the performance 
factor, the vast Python ecosystem compared to the limited options 
available for REXX also make it an easy decision. Python is also 
simpler to extend with packages, while REXX requires more effort and 
potentially complex steps, such as using modern libraries that require 
Language Environment (LE).



My benchtests

Lua

local file = assert(io.open(arg[1], "rb, type=record, noseek"))
while true do
   local rec = file:read()
   if not rec then break end
end

Python

import sys
from pyzfile import *
try:
   with ZFile(sys.argv[1], "rb,type=record,noseek") as file:
  for rec in file:
 pass
except ZFileError as e:
   print(e)

REXX

/* REXX */
  arg dsname
  address MVS
  call bpxwdyn "ALLOC FI(INPUT) DA("dsname") SHR"
  do until eof
    "EXECIO 1 DISKR INPUT ( STEM rec."
    eof = (rc > 0)
  end
  "EXECIO 0 DISKR INPUT ( FINIS"

The results: Add user+system to get total CPU time

> time lua benchio.lua "//'CPA000.QADATA.PMR9.SSA.HR1315PM'" && 
time python3 benchio.py "//'CPA000.QADATA.PMR9.SSA.HR1315PM'" && 
time ./benchio.rex "CPA000.QADATA.PMR9.SSA.HR1315PM"

real    0m47.019s
user    0m3.255s
sys 0m1.097s

real    1m0.710s
user    0m8.001s
sys 0m2.678s

real    1m17.772s
user    0m13.575s
sys 0m4.536s

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

Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 28/2/23 13:55, Gibney, Dave wrote:

LIKE=a good representative existing library.


How about: Don't bother kid, use the z/OS UNIX file system instead?



-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of David Crayford
Sent: Monday, February 27, 2023 9:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and zOWE for non-mainframers

[EXTERNAL EMAIL]

On 28/2/23 13:41, Gibney, Dave wrote:

How many decades have we had System Determined Blocksize, and other

artifacts of SMS. These details are surely not anything than new folks need to
deal with at the outset.

If a young programmer came to you and asked "what is the best DCB for a
C++ source data set?" what would you suggest?



-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of David Crayford
Sent: Monday, February 27, 2023 9:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and zOWE for non-mainframers

On 27/2/23 06:46, Andrew Rowley wrote:

On 25/02/2023 8:03 am, Bob Bridges wrote:

Oh, I was going to mention that surely allocating datasets, either in
batch or TSO, has got to seem like one of the dumbest and most
incomprehensible things we do on the mainframe, to a foreigner.

Allocating datasets shouldn't be that hard to grasp. "Dataset" is
actually a pretty common term and generally implies a collection of
data with more structure than just a file.

   From what I've seen while working with younger individuals, they tend
to find the MVS file system quite perplexing. In order to navigate it,
one must first grasp the archaic concept of CKD disk geometry, including
blocks, cylinders, blocking factors, and record formats, among other
things. And that's all before even introducing them to the intricacies
of VTOCs, catalogs, interblock gaps, spanned record formats etc.


If people have worked with databases, presumably they have

encountered

the concept of defining the schema.

A dataset is simply a collections of records (similar to a database
table) where each record has a fixed length or limited variable length
and the total collection has a size limit. Any structure within the
records is up to the application. This is not an unusual construct.

What is unusual is that z/OS uses such a structured format for almost
everything, not that it exists.


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


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

Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 28/2/23 13:41, Gibney, Dave wrote:

How many decades have we had System Determined Blocksize, and other artifacts 
of SMS. These details are surely not anything than new folks need to deal with 
at the outset.


If a young programmer came to you and asked "what is the best DCB for a 
C++ source data set?" what would you suggest?






-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of David Crayford
Sent: Monday, February 27, 2023 9:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and zOWE for non-mainframers

On 27/2/23 06:46, Andrew Rowley wrote:

On 25/02/2023 8:03 am, Bob Bridges wrote:

Oh, I was going to mention that surely allocating datasets, either in
batch or TSO, has got to seem like one of the dumbest and most
incomprehensible things we do on the mainframe, to a foreigner.

Allocating datasets shouldn't be that hard to grasp. "Dataset" is
actually a pretty common term and generally implies a collection of
data with more structure than just a file.

  From what I've seen while working with younger individuals, they tend
to find the MVS file system quite perplexing. In order to navigate it,
one must first grasp the archaic concept of CKD disk geometry, including
blocks, cylinders, blocking factors, and record formats, among other
things. And that's all before even introducing them to the intricacies
of VTOCs, catalogs, interblock gaps, spanned record formats etc.


If people have worked with databases, presumably they have encountered
the concept of defining the schema.

A dataset is simply a collections of records (similar to a database
table) where each record has a fixed length or limited variable length
and the total collection has a size limit. Any structure within the
records is up to the application. This is not an unusual construct.

What is unusual is that z/OS uses such a structured format for almost
everything, not that it exists.


--
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: zOSMF and zOWE for non-mainframers

[David Crayford]

On 25/2/23 01:23, Farley, Peter wrote:

Python on the mainframe is pretty good, but still can't beat out Rexx in 
performance even when the Rex script needs to use BPXWUNIX and friends to 
access z/OS Unix file systems,



I have conducted a series of benchtests, and the results suggest that 
REXX is not as fast as Python. In my testing, I compare the performance 
of C, Lua, Python, and REXX, and the results are clear: C is the 
fastest, followed by Lua, which is within an order of magnitude of C. 
Python comes next, within an order of magnitude of Lua, and REXX 
consistently performs the poorest. In addition to the performance 
factor, the vast Python ecosystem compared to the limited options 
available for REXX also make it an easy decision. Python is also simpler 
to extend with packages, while REXX requires more effort and potentially 
complex steps, such as using modern libraries that require Language 
Environment (LE).


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

Re: zOSMF and zOWE for non-mainframers

[David Crayford]

While I understand that it may be an unpopular opinion on this forum, I 
personally believe that the ISPF editor is outdated relic. As Peter 
mentioned, VS Code is a fantastic alternative. Additionally, Microsoft's 
GitHub offers the Copilot plugin, which functions as an AI programming 
assistant. In my own experience, using graphical user interface (GUI) 
editors over the past two decades has greatly increased my productivity 
through features like auto-completion, code navigation, and linting. 
Copilot has exceeded my expectations, and I now believe we have entered 
a new era of AI-assisted coding, similar to the game-changing 
capabilities of ChatGPT.


https://docs.github.com/en/copilot

On 25/2/23 01:23, Farley, Peter wrote:

Lionel, respectfully I must disagree.  I have been using the IBM Zxplore website on my own time for 
over a year now for enhanced learning of some of the "new" technologies available on our 
mainframe systems, and I have been consistently surprised to observe the actual difficulties that 
genuine newcomers to mainframe systems have with many fundamental concepts that we take for 
granted.  The "almost tree-like (but not really)" structure of mainframe datasets and the 
use (and mis-use) of JCL seem to be the most frequent cause of misunderstanding and errors, along 
with learning to read and understand the messages generated from a batch job or utility execution.

It isn't the client-side tool interface (VSCode vs TSO/ISPF) that gives most of 
the newcomers fits, they seem to pick that up without too many problems.  It's 
the fundamental system operational differences that make it harder for them to 
grasp, at least at first.

OTOH, the VSCode/ZOWE interfaces were (for me anyway) easy to learn and 
understand.  Sometimes annoying to use but very effective.  Especially Zowe 
utilities at a command prompt, the help features are annoyingly verbose though 
very helpful when you first start using them.

But all these open tools are only scratching the surface.  The real deal costs real money, because 
a Windows/Linux client cannot do dynamic compilation/binding/debugging on the mainframe without 
paid packages from IBM or other vendor add-on products.  At this point in time the best you can 
offer with open-source tools is batch job submission to compile and bind and execute, and review 
the batch job output in the VSCode client instead of in TSO/ISPF.  I'm not sure that is enough of a 
win to make it into a CIO's TODO list, especially when you add the DASD increment to supply all 
developers with large enough z/OS Unix file systems to do their work in the "new way" 
because that's a "real money" addition to the cost of operation.

And forget about CI/CD tool chains.  The CI/CD tool vendors seem to all be using the 
"normal" IBM and large ISV pricing schemes (i.e., lots of money) for mainframe 
versions of those tools.  Another (big!) minus in the CIO's view.

The other issue is CPU usage in today's frequently-CPU-constrained-due-to-cost mainframe shops.  In 
solving some of the Zxplore "challenges" (exercises to learn a feature or tool), many 
times the challenge solutions prove over and over that the performance of z/OS Unix tools lags far 
behind the "regular" mainframe tools like Rexx in the performance area, sometimes by 
large factors (ZOAU tools in particular are real CPU hogs, and the DB2 Command Line Interface tool 
as well).  Python on the mainframe is pretty good, but still can't beat out Rexx in performance 
even when the Rex script needs to use BPXWUNIX and friends to access z/OS Unix file systems, and 
both python and Rexx often beat shell-scripted solution performance by several multiples.  Again 
not a plus when trying to get into a CIO's TODO list.

And that's my USD$0.02 worth.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: Friday, February 24, 2023 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and zOWE for non-mainframers

Just my $0.01 (not worth $0.02).

These developers who want/need access to z/OS and don't want to learn how to 
work with z/OS, don't they learn new things all the time - new IDE's, different 
operating systems (windows, macos, flavors of linux, unix, ...)? IMHO it is 
easier to learn the TSO/ISPF interface than some of the distributed interfaces 
(which change in small to large ways with upgrades).

Just my curmudgeonly opinion after struggling with some challenges with using 
VSCode last weekend.

Lionel B. Dyck <><
Website: 
https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!MqpmHq_VRWuj8wK14SatSDQWJGXeGrVWi5_dAm8crRqLAJuu-eLagqlqYnH7U0D524MhnZpyL6Gq6WBEzt4$
Github: 
https://urldefense.com/v3/__https://github.com/lbdyck__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!MqpmHq_VRWuj8wK14SatSDQWJGXeGrVWi5_dAm8crRqLAJuu-eLagqlqYnH7U0D524MhnZpyL6Gqr7VuHgk$

“Worry more about your character than your reputation. Character is what you 
are, 

Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 27/2/23 06:46, Andrew Rowley wrote:

On 25/02/2023 8:03 am, Bob Bridges wrote:
Oh, I was going to mention that surely allocating datasets, either in 
batch or TSO, has got to seem like one of the dumbest and most 
incomprehensible things we do on the mainframe, to a foreigner.


Allocating datasets shouldn't be that hard to grasp. "Dataset" is 
actually a pretty common term and generally implies a collection of 
data with more structure than just a file.


From what I've seen while working with younger individuals, they tend 
to find the MVS file system quite perplexing. In order to navigate it, 
one must first grasp the archaic concept of CKD disk geometry, including 
blocks, cylinders, blocking factors, and record formats, among other 
things. And that's all before even introducing them to the intricacies 
of VTOCs, catalogs, interblock gaps, spanned record formats etc.




If people have worked with databases, presumably they have encountered 
the concept of defining the schema.


A dataset is simply a collections of records (similar to a database 
table) where each record has a fixed length or limited variable length 
and the total collection has a size limit. Any structure within the 
records is up to the application. This is not an unusual construct.


What is unusual is that z/OS uses such a structured format for almost 
everything, not that it exists.




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

Re: Irish data centers....an opportunity?

[David Crayford]

On 13/2/23 02:34, Hobart Spitz wrote:

IMHO, the fault lies in the character stream orientation of UNIX, C, HTML
etc.  The shorted-sighted design was motivated by the limited budgets and
underpowered systems of many early UNIX users.

On record oriented systems, (z/OS and z/VM) common operations are faster,
because the needed information is not embedded in the data.  For example:

- Read/skip-to the next record.
- Find/check the length of a string.


Can you please provide evidence to support that assumption?




On byte stream oriented systems, every single character, including the
otherwise uninteresting ones, must go through the CPU for such operations.
Record oriented systems can efficiently add the record length to the
current record address, or compare a target character position to the
length of the record to avoid string overflow (e.g).



What are you talking about? Writing a UNIX program that reads/writes 
length-prefixed records to a file is a simple task. Do you mean to say 
that all I/O performed on LUW systems involves line-delimited text files?





Anyone who understands that global warming and climate change are
existential threats and that it may be too late to avoid catastrophic
impacts would be well advised to keep their record oriented systems and
move away from UNIX, Linux, and Windows where feasible.



Arm servers outperform all competition in terms of performance per watt. 
One can buy an Ampere server with 128 cores per socket, consuming an 
impressively low 250W of power. A few years ago, I came across an 
excellent article regarding the IBM z196, written in collaboration with 
IBM. The article stated that, " "Even when aggressively cooled, the 
~250W z196 dissipates over 70W of leakage, which is more than the total 
power budget for many commodity server processors." Mainframes are 
designed to operate at maximum capacity with redundancy integrated into 
a single platform, which requires a significant amount of power.


[1] https://www.realworldtech.com/z196-mainframe/8/



Just my "buck three eighty", or two cents if you prefer.

OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Sat, Feb 11, 2023 at 8:37 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:


Correct. I copied the article from the NYT & then reposted the paragraph
in the article which discussed the study.



Heh - I don't think those are rankings - just (former) links from the
article in whatever publication Bill copied from.



...
The largest cloud data centers, sometimes the size of football fields,

are owned and operated by big tech companies like Google, Microsoft,

Amazon

and Facebook.

...
Over the years, data center electricity consumption has been a story of

economic incentives and technology advances combining to tackle a

problem.

Do they use:
o IBM z?
o IBM supercomputers?
o Others, such as overseas-sourced (specify)?


At one time Facebook published detailed specs for its homegrown PC servers,
in contrast to the likes of Google, Amazon, and Microsoft, for whom it's
all trade secrets. I've no idea if they've kept the specs current. Lynn
Wheeler wrote about this stuff a number of times when he was active on
IBM-MAIN, though mostly from an available-compute-power perspective rather
than a power efficiency one.

Tony H.

--
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: Open XL C++ debugging

[David Crayford]

On 4/2/23 02:57, Joseph Reichman wrote:

You are attempting to insert a record using an rvalue-reference with an
initializer list. That's not supported by the XL C++ standard library
which does not support C++11. I already told you that two posts back.
The function prototype is like so:

template< class P >
std::pair insert( P&& value );

Check the dochttps://en.cppreference.com/w/cpp/container/map/insert

The Documentation in the above link is from CPP reference which it would seem 
that the IBM XL C++ 2.4 compiler doesn’t support that level


These are the methods I see supported from XL C++ template library guide

pair insert(const value_type& x);
iterator insert(iterator it, const value_type& x);
template
  void insert(InIt first, InIt last);


If It only can  accommodate a rvalue that is it very limited in scope as you 
can tell I am not C++ expert but an rvalue is only literal or a function that 
would return the specified type


It can only accommodate an lvalue reference as rvalue references were 
not introduced until C++11.





If XL C++ is into at  C++ 11 at what level is it


I have lost count of how many times I have had to repeat myself. Let me 
be clear, this is the final time. For XL C++ C++11 compatibility, please 
refer to 
https://www.ibm.com/docs/en/zos/2.3.0?topic=xcle-c11-compatibility. It 
offers a limited subset of C++11, without support for features such as 
lambdas and initializer lists. The standard library (formerly known as 
the STL) is only compliant with C++98, meaning that there is no support 
for rvalue-references or move semantics.


To the best of my knowledge, XL C/C++ has reached functional 
stabilization. IBM uses xlclang/xlclang++ for its ports of Node.js, 
Python, and other projects, and has stated that Open XL C/C++ is a 
strategic priority.


Always select the appropriate tools for the task. You're using a 
sledgehammer to crack a nut.


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

Re: Open XL C++ debugging

[David Crayford]

On 2/2/23 21:25, Joseph Reichman wrote:

Thanks

First off, I am assembler programmer by trade I did learn C/C++ doing some 
TCP/IP stuff from an Assembler Server Started task.


There's a skill to reading documentation. For XL C++ C++11 compatability 
see https://www.ibm.com/docs/en/zos/2.3.0?topic=xcle-c11-compatibility. 
Note that the C++ standard library is *not* mentioned. We'll get to that 
later.





It would display the data program listing from a sysadata on Windows.


Why? Are you writing a GUI? I can understand you wanting to use an IDE 
as opposed to ISPF but why run anything on Windows that can run on z/OS?




I would like to use that code on z/os.

If you say clang, is the way to go okay.

You also say use the clang compiler instead of MSVC I hope I don’t end up with 
a millon more compile errors using clang as everything compiles cleanly using 
MSVC.


How can you write a cross platform program using MSVC++ without having 
to resort to #ifdef pre-processor nonsense? That's just bonkers.





I debug under Unix.


You are not making any sense. You want to edit/compile/run on windows 
and then debug on Unix? What Unix, z/OS Unix?





Since I am going to run this from z/os its going to be LE with runtime option 
POSIX(ON) ? right ?

Now as far as the doc for OPEN XL C++

I got a compile error using map::insert invalid call.

CCN5218 (S) The call does not match any parameter list for "insert".

Is referenced the following statement.
auto ret = procpointer->extsymcollector->insert({ *s, *exsympointer });


You are attempting to insert a record using an rvalue-reference with an 
initializer list. That's not supported by the XL C++ standard library 
which does not support C++11. I already told you that two posts back. 
The function prototype is like so:


template< class P >
std::pair insert( P&& value );

Check the doc https://en.cppreference.com/w/cpp/container/map/insert



the compiler initially gave me a problem with '{'

I took it out.

auto ret = procpointer->extsymcollector->insert( *s, *exsympointer );

That's also wrong. You need to pass a single lvalue-reference such as 
std::pair (please read the docs).


auto ret = procpointer->extsymcollector->insert( std::pair(*s, *exsympointer) );

I'm not picking holes but the code snippet you posted concerns me. It's 
heavy on pointers and the de-referencing alone makes me think it's poor 
quality. C++ is not C, it has reference types which are absolutely 
essential for RAII. If you have found you are using raw pointers 
allocated with "new" then that's a code smell.




then I got the above error

My question is if I got to Open XL C++

Regarding documentation for let's say map::inset I would reference Clang/LLVM 
link you sent me earlier.
  


I hope I don’t open a pandoras box if I change to clang and re-compile all my 
windows code.


The question you should be asking yourself is "should I use C++?". C++ 
is a large and complex language and in my experience with colleagues of 
mine who are excellent assembler programmers it can be a struggle to 
become proficient. Why don't you use a simpler language like Python 
which is easy to use and doesn't have portability issues? I'm an 
experienced C/C++ programmer and I certainly wouldn't entertain using 
C++ to process ADATA, when I can do it faster, with less code and less 
bugs in Python.


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

Re: Open XL C++ debugging

[David Crayford]

On 2/2/23 02:42, Joseph Reichman wrote:

Was looking at the compiler reference kind of small handful of options compared 
to pages and pages for XL C\C++ compiler option


Haha! You're joking right? There's significantly more compiler options 
as it's a port of clang 
https://www.ibm.com/docs/en/SSUMVNF_1.1.0/pdf/Clang.pdf#page=219.



One very important question when I looked at the Manuel doesn’t specify how to 
debug it


How do you debug any C/C++ program in z/OS UNIX. You compile with the 
"-g" flag which creates DWARF debugging records and the use dbx to 
debug. The interesting thing about Open XL C++ is that it embeds debug 
information into the binary as opposed to creating a *.dbg side file.


My advice to you use the XL C/C++ v2.4.1 web deliverable xlclang. I 
don't think you need to be on the bleeding edge of language standards :)




--
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: XL C\C+ strange compile errors

[David Crayford]

On 30/1/23 07:31, Joseph Reichman wrote:

Please accept my apologies the program consisted of hundreds of lines which
I complied cleanly using Visual studio.

  


Obviously, there are difference not in ANSI C++ which I Think XL is at 20
but in the window types.


There are three IBM C/C++ compiler products that run on z/OS. XL C/C++ 
is practically moribund. XL C++ implements a small subset of C++11 such 
as R-value references but not the standard library. That's what you're 
using as it's the only compiler with a JCL batch interface. All the 
others ship z/OS UNIX binaries only. You can still compile programs in 
PDS libraries but nobody in their right minds would want to do that in 
2023.


xlclang/xlclang++ is a Clang/LLVM front end to the XL C++ back-end. It 
implements the C11 and C++14 standards. It's 64-bit only.


Open XL C/C++ is a full blown port of Clang/LLVM and has partial support 
for C++20 https://clang.llvm.org/cxx_status.html.





  


To make the program compatible with types like DWORD I added typedef due to
my oversight I forgot to end one with a semi colon which was right before
the includes which caused one long error.

  


Hope I didn't waste any one time.

  


The only person whose time you're wasting is your own by using the wrong 
compiler (and IDE). Why are you pulling in all of the Windows API header 
file crap? Visual Studio Community is an amazing product for writing 
Windows programs in a multitude of languages but it's complete overkill 
for editing a program to be run on z/OS. If you really must use VS then 
configure it to use clang/LLVM 
https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170. 
You will then have a standard C/C++ environment without all the Windows 
garbage. Extra features such as clang-tidy will lint your code for 
errors as you type. My advice is to ditch VS for the much lighter weight 
VS Code which supports more languages and is designed from the get-go to 
be cross-platform.





Thanks  you.

  


From: reichman...@gmail.com 
Sent: Wednesday, January 25, 2023 2:28 PM
To: 'IBM Mainframe Discussion List' 
Subject: XL C\C+ strange compile errors

  


Hi

  


I have a very short C++ program compiling as /CXX   which all it does is
basically open a file

  


I am getting a whole slew of errors but they are not from my program they
are standard includes CEE.SCEEH.H(STDDEF) and in fact I didn't explicitly
include them (maybe they got included by 2 includes that I included in my
program of  and 

  


Thing is I don't know why I am getting these errors they would seem to be
okay for C++ such as "extern"  and size_t

  


Here is a screen shot of some of the errors

  


"//'CEE.SCEEH.H(STDDEF)'", line 39.4: CCN5063 (S) The text "extern" is
unexpecte"

"//'CEE.SCEEH.H(STRING)'", line 119.51: CCN5063 (S) The text "size_t" is
unexpec"

"//'CEE.SCEEH.H(STRING)'", line 120.54: CCN5063 (S) The text "size_t" is
unexpec"

"//'CEE.SCEEH.H(STRING)'", line 121.60: CCN5063 (S) The text "size_t" is
unexpec"

"//'CEE.SCEEH.H(STRING)'", line 122.45: CCN5063 (S) The text "size_t" is
unexpec"

"//'CEE.SCEEH.H(STRING)'", line 125.14: CCN5040 (S) The text "__strlen" is
unexpa

ambiguous.
"

"//'CEE.SCEEH.H(STRING)'", line 130.58: CCN5063 (S) The text "size_t" is
unexpec"

"//'CEE.SCEEH.H(STRING)'", line 131.58: CCN5063 (S) The text "size_t" is
unexpec"

"//'CEE.SCEEH.H(STRING)'", line 132.64: CCN5063 (S) The text "size_t" is
unexpec"

"//'CEE.SCEEH.H(STRING)'", line 144.51: CCN5063 (S) The text "size_t" is
unexpec"

"//'CEE.SCEEH.H(STRING)'", line 146.57: CCN5063 (S) The text "size_t" is
unexpec"

"//'CEE.SCEEH.H(STRING)'", line 148.43: CCN5063 (S) The text "size_t" is
unexpec"

  

  


Here is partial list of  my compile JCL

  


* Top of Data *

//JOER$ JOB 'ADCD V2R9','SYSPROG',NOTIFY=,REGION=0M

//*

//*---

//*  COMPILE STEP:

//*---

//COMPILE EXEC PGM=CCNDRVR,REGION=192M,PARM=('/CXX LIST,OBJ,DEBUG(FORMA

// T(DWARF),HOOK(LINE,NOBLOCK,PATH),SYMBOL,FILE(OPENFIL))')

//STEPLIB  DD  DSN=CEE.SCEERUN2,DISP=SHR

// DD  DSN=CBC.SCCNCMP,DISP=SHR

// DD  DSN=CEE.SCEERUN,DISP=SHR

  


Not sure why I am these are errors

  


 If anyone can point me in the right direction would appreciate it

  


Thanks


--
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: XL C++ compiler error message map template not included due to compiler version

[David Crayford]

On 23/1/23 22:29, Paul Gorlinsky wrote:

C++ is an extension to C… staying current with Visual Studio releases will 
help. Microsoft has been making lots of enhancements trying to catch up to the 
current C/C++ standards.


I wouldn't use the full fat Visual Studio. Far better off using VS Code 
and the Windows port of clang. You will get IntelliSense and all the 
usual stuff that's useful + the clangd language server which will lint 
your code as you type.


I use the Windows Subsystem for Linux for all of my work bar Eclipse 
Plugins which I try and avoid anyway. All C/C++, Java, Python 
development is done using a Jetbrain's IDE connected to WSL using Linux 
binaries. IMO, using Windows to develop code to run on *nix systems 
isn't a very good idea now that WSL. PowerShell might be awesome for 
Windows weenies but I prefer the predictability of a UNIX shell like zsh 
or the venerable bash on old systems. It's remarkable how similar zCX 
containers are to WSL :)


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

Re: XL C++ compiler error message map template not included due to compiler version

[David Crayford]

Looks like your invoking the C compiler not C++. 

> On 23 Jan 2023, at 11:15, Joseph Reichman  wrote:
> 
> Hi
> 
> 
> 
> I got this error when trying to include  template
> 
> 
> 
> 
> 
> // map standard header
> 
> 
> 
> 
> 
> #error This file to be used only with IBM z/OS C++ V1R2 and lat\  
> 
> er compilers  
> 
> 
> 
> I running z/os 2.5 ADCD B version seems that XL C\C++ V2R4
> 
> 
> 
> 
> 
> 
> --
> 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: Markup languages - more on the shortcomings of MS Word

[David Crayford]

On 27/12/22 10:43, Ed Jaffe wrote:
My team uses https://vuejs.org/. At the moment we only build HTML but 
there are packages to render a multitidue of different formats 
including PDF, word docs etc. Extensions are written in Typescript or 
Javascript so there is a massive eco-system to pull from.



For many years we used MS Word for our product documentation, but it 
was just too buggy and cumbersome.


Our team now uses MadCap Flare. It's a "best of breed" solution 
specifically designed for technical documentation.


https://www.madcapsoftware.com/products/flare/

We use it to deliver our documentation in three formats: Adobe PDF, 
HTML, and Eclipse plug-ins that can be used with IBM InfoCenter and 
KnowledgeCenter (including KC4Z on z/OS)


Looks great! It supports DITA which we use for our IBM marketed products 
that get published on KC. I like that it has extensive build automation 
including a CLI so integrating into a DevOps pipeline using Jenkins or 
other build automation is simple.


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

Re: Markup languages - more on the shortcomings of MS Word

[David Crayford]

MS Word is a great product for it's main use case. I don't consider it a 
good choice for technical documentation and neither does the Information 
Developer in my team. There are many better tools out there, some of 
which are free. Documentation in today's world can be published in many 
different formats. Text documents, HTML, PDF etc. Documentation should 
be considered code, which is why markdown is so popular. Documentation 
should go through the same development pipeline as source code with a 
pull request and a code review before being committed to a SCM and 
rendered into product artifacts. MS Word is useless for team 
collaboration. It's ok for a one person team but doesn't scale.


My team uses https://vuejs.org/. At the moment we only build HTML but 
there are packages to render a multitidue of different formats including 
PDF, word docs etc. Extensions are written in Typescript or Javascript 
so there is a massive eco-system to pull from.


On 27/12/22 00:54, Charles Mills wrote:

I have avoided replying on this thread. It is not my job to shill for Microsoft 
on a mainframe forum.

However, just to get the facts on the record, let me say that I have been 
composing very complex manuals with included text and generated TODs and 
indexes in MS-Word for years, and publishing them as PDFs, with 100% success.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Bridges
Sent: Monday, December 26, 2022 6:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Markup languages - more on the shortcomings of MS Word

Once we were done with Christmas morning, my son and his family took off for 
other Christmas venues and I spent most of the day downloading MiKTeX (an 
editor for LateX) and reading documentatino.  Finding the documentation was a 
bit of a chore and I'm not satisfied yet that I have everything I'll need, but 
the web eventually yielded up manuals whose titles, at least, claim they're 
about LaTeX, LaTeX2e, TeXWorks and MikTeX.  I have a lot of reading yet to do.

This morning I emailed the Word document to myself and tried saving it as PDF.  
Turns out Word is awful at that too.  It skipped over most of the ToC and 
jumped from there straight to the beginning of the second chapter, omitting the 
Intro.  I probably won't bother to see what else is wrong with it.

--
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: z/OS CP037 and OMVS CP1047

[David Crayford]

On 15/12/22 00:11, Paul Peplinski wrote:

David,

This whole process has been a massive learning experience. It started out being the 
"simple" task of getting a java11 jar running on the mainframe so we didn't 
have to stand up Linux servers. Oh, and have a CICS COBOL program talk to it (POST) using 
JSON.

I had never written EXEC CICS WEB or TRANSFORM code before, nor worked with 
DFHJS2LS or created JSON schemas.


Was it a good experience?



I have now gotten the POST to work while leaving my OMVS process in CP1047 and 
not using the jetty encoding java option. I've never worked with jetty either.


Are you already using Jetty with a servlet? Most vendors have moved to 
Spring Boot which embeds the web server into the application. Spring 
Boot is supported in CICS 
https://www.ibm.com/docs/en/cics-ts/5.6?topic=java-spring-boot-support-in-cics.




Currently, the jar is running under BPXBATCH in a job. I plan on converting it 
to a started task. Hopefully that will honor START and STOP commands.

We have JzOS batch launcher but I have never used it. Why is that preferable to 
BPXBATCH?


JZOS runs EVERYTHING on a zIIP if available
JZOS can be configured in MVS data sets
JZOS is locally spawned so can use configuration using DD: syntax
JZOS handles START/STOP commands
JZOS handles modify commands

BPXBATCH really sucks.



Paul

--
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: z/OS CP037 and OMVS CP1047

[David Crayford]

I wouldn't stray outside of IBM-1047 for OMVS other than ISO8859-1. Are 
you sure your issue is not server side with Jetty? I would try setting 
the -Dfile.encoding=ISO8859-1 java option. I would also strongly suggest 
using the JZOS batch launcher and not BPXBATCH for running Java programs 
unless you need a custom shell script.


On 14/12/22 07:25, Paul Peplinski wrote:

In all my years I never realized that OMVS uses CP1047. What I am trying to 
configure is giving me fits.

I have a CICS program that is trying to do a WEB CONVERSE with an embedded 
jetty server jar running under BPXBATCH. I might find that running the server 
this way will not work, but I am giving it a whirl.

All of my problems seem to be with square brackets. The script that runs the jar has 
square brackets surrounding the port number, JSON input to DFHJS2LS has square brackets 
surrounding "required" items, and the body of the POST have square brackets 
surrounding an array.

I can use CP1047 to execute the OMVS script and run the DFHJS2LS utility, but 
nothing I try works on the WEB CONVERSE. It looks to be trying CP037 square 
brackets. I've tried CCSID in DFHJS2LS, CODEPAGE in WEB CONVERSE (with and 
without CLICONVERT) to no avail. I have confirmed that the JSON in CICS has the 
CP1047 brackets.

It seems that the best solution is to get my OMVS process to use CP037, but what I tried 
doesn't work. I found documentation that BPXBATCH does this with STDENV of 
LC_CTYPE="En_US.IBM-037", but tit does not change the behavior of the script 
running under BPXBATCH. In the code below the server honors the port number if the 
brackets are in the right codepage. If not it defaults to 8080.

-Ddw.server.applicationConnectors[0].port=8192

Paul
  


--
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: thread local storage in XL C\C++

[David Crayford]

On 7/12/22 10:53, Joseph Reichman wrote:

David Crayford suggested I use uss pthread wonder if that corresponds to z/os 
task


Of course! Although the POSIX semantics are different. pthreads are not 
hierarchical and the thread can be detached from the thread that spawned 
it. This is implemented on z/OS by spawning all threads on the IPT 
(initial pthread-creating task) which is the main enclave.


https://www.ibm.com/docs/en/zos/2.4.0?topic=reference-using-threads-callable-services




Going to try and research that

Thanks


On Dec 6, 2022, at 9:30 PM, David Crayford  wrote:

We discussed this with the C/C++ compiler devs when we were beta testing the 
Open XL C/C++ compiler. They said it was on their radar but would need work 
from the binder team to implement similar plumbing to writeable static. I got 
the impression that it won't happen soon. It's a PITA as it makes porting 
modern code a lot more difficult.

You can implement thread specific data the old way using the pthread library 
and wrapping in C++ code https://stackoverflow.com/a/12053862/2434779.


On 7/12/22 04:15, Peter Relson wrote:
To my limited understanding, there is not currently support for thread-local 
storage on z/OS.
An LE enclave does not correspond 1 to 1 to a thread.

I think that "writeable static", for example, is on an enclave basis, not a 
thread basis.

I'm sure others know this far better than I.

Peter Relson
z/OS Core Technology Design


--
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: thread local storage in XL C\C++

[David Crayford]

We discussed this with the C/C++ compiler devs when we were beta testing 
the Open XL C/C++ compiler. They said it was on their radar but would 
need work from the binder team to implement similar plumbing to 
writeable static. I got the impression that it won't happen soon. It's a 
PITA as it makes porting modern code a lot more difficult.


You can implement thread specific data the old way using the pthread 
library and wrapping in C++ code 
https://stackoverflow.com/a/12053862/2434779.


On 7/12/22 04:15, Peter Relson wrote:

To my limited understanding, there is not currently support for thread-local 
storage on z/OS.
An LE enclave does not correspond 1 to 1 to a thread.

I think that "writeable static", for example, is on an enclave basis, not a 
thread basis.

I'm sure others know this far better than I.

Peter Relson
z/OS Core Technology Design


--
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: JZOS VSAM API equivalent VSAM ENDREQ?

[David Crayford]

It would be cool if IBM published the JZOS Jar on Maven central. We have 
a centralized company Artifactory server and have uploaded the z/OS 
specific Jars like JZOS, RACF etc which is so much better then uploading 
to your PC.


On 2/12/22 19:12, Steve Austin wrote:

Thanks Kirk,

The ibmjzos.jar in my IDE was too back level to show those methods. Now
I'm using 2.4.10 I can see them.

Steve

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Kirk Wolf
Sent: Thursday, December 1, 2022 10:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JZOS VSAM API equivalent VSAM ENDREQ?

You don't have to assume, the javadoc documents which C library functions
are used.
https://www.ibm.com/docs/en/sdk-java-technology/8?topic=SSYKE2_8.0.0/com.i
bm.java.zsecurity.api.80.doc/com.ibm.jzos/overview-summary.htm

And I'll correct what I said earlier, if you look at the javadoc you will
see that there are now wrappers for several of the C library "*_unlocked"
functions.

Kirk Wolf
Dovetailed Technologies, LLC
http://coztoolkit.com
Dovetailed Technologies: +1 636.300.0901

Note: Our website and domain name have changed from dovetail.com to
coztoolkit.com

On Thu, Dec 1, 2022, at 4:11 PM, Steve Austin wrote:

Thanks Kirk,

I have multiple threads reading from and writing to a KSDS. After some
reads I need to release the record lock. I can see there is a locate()
method which I assume is a wrapper to flocate() and flocate() releases
all record locks, according to the doc, so I'll try locate().

Steve

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Kirk Wolf
Sent: Thursday, December 1, 2022 3:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JZOS VSAM API equivalent VSAM ENDREQ?

1) There is no ENDREQ in the ZFile class.The methods are pretty much
derived from the C library I/O functions.

One common thing that ENDREQ is used for is for using a VSAM ACB to
submit jobs to the internal reader and give you back the jobid.  JZOS

does have a

class MvsJobSubmitter that does this.   It does not expose a low level
VSAM api.

2) There is no fread_unlocked in the ZFile class.

You can use the javadoc or open the class file in an IDE to see
exactly what methods are there.

Kirk Wolf
Dovetailed Technologies, LLC
http://coztoolkit.com
Dovetailed Technologies: +1 636.300.0901

Note: Our website and domain name have changed from dovetail.com to
coztoolkit.com

On Thu, Dec 1, 2022, at 6:31 AM, Steve Austin wrote:

Is the VSAM ENDREQ functionality available via the JZOS ZFile VSAM

API?

Also I imagine zfile.read() maps to the C fread(), but is there an
equivalent of the C fread_unlocked()?  Thanks

--
This e-mail message has been scanned and cleared by Google Message
Security and the UNICOM Global security systems. This message is for
the named person's use only. If you receive this message in error,
please delete it and notify the sender.


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

--
This e-mail message has been scanned and cleared by Google Message
Security and the UNICOM Global security systems. This message is for
the named person's use only. If you receive this message in error,
please delete it and notify the sender.

--
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: R: Assembler program attaching a C program

[David Crayford]

On 23/11/22 01:20, Fabio Massimo Ottaviani wrote:

We also tried to add what suggested by David

  


If you want to pass the address of a parameter list in R1 use the following.

#pragma runopts(plist(os))

And in main

struct plist * parms = ( struct plist * ) __R1;

  


But we got

pragma runopts syntax (CEE3611): The run-time option PLIST was an invalid 
run-time option or is not supported in this release of Language Environment.



I just tried it an it's not supported in 64-bit which sucks. I suggest 
using the 64-bit version of CELQPIPI [1] which is more upfront work but 
a much better way to call C/C++ code from HLASM. It's what CICS and IMS 
use.


[1] 
https://www.ibm.com/docs/en/zos/2.4.0?topic=tasks-using-preinitialization-services-amode-64


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

Re: Assembler program attaching a C program

[David Crayford]

If you want to pass the address of a parameter list in R1 use the 
following.


#pragma runopts(plist(os))

And in main

struct plist * parms = ( struct plist * ) __R1;



On 21/11/22 17:22, Fabio Massimo Ottaviani wrote:

Hello

I wrote an assembler program attaching a C program with ATTACHX

ATTCHATTACHX EP=PROGC,PARAM=R10,
ECB=AMYECB,
DISP=NO

I set the address of the field, I want to pass as parameter, in R10
I checked that argv in the C program is empty

Is there something I have to do in the C program to get the content of the 
field?

Thanks
Fabio

--
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: TNZ 3270 Emulator: Any Experiences?

[David Crayford]

On 20/11/22 23:13, Dave Jones wrote:

Now add GDDM graphics and it will be nearly perfect.  


Here we go again! tnz is a curses application, a TUI (text user 
interface) that runs in a shell. It's not X windows and doesn't run in a 
GUI container. It's my understanding on some Linux desktop systems like 
Ubuntu that xterm can use Sixel or ReGis to render graphics to a remote 
workstation but that is hopelessly antiquated and not at all portable. 
tnz runs on Windows, Linux, z/OS and any environment that supports Python.


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

Re: TNZ 3270 Emulator: Any Experiences?

[David Crayford]

On 19/11/22 12:20, kekronbekron wrote:

What? RMF can export to prometheus?
Do you mean zDG, with its own zOSMF / WAS Liberty deployment?


There's a Zowe project https://github.com/zowe/zebra. There is also zCDP 
integration with RMF to stream to Splunk/Elastic. Rocket are modernizing 
OMEGAMON and RMF to publish to modern analytics platforms. In most cases 
you can use Docker compose to stand up a stack like Elastic or 
Prometheus/Grafana from artifacts published on Github. 
https://z-open-data.github.io/odp-elastic-samples/





- KB

--- Original Message ---
On Saturday, November 19th, 2022 at 6:27 AM, David Crayford 
 wrote:



On 19/11/22 02:12, René Jansen wrote:


RMFIII is my main use case.


If it's graphics that you seek, RMF has been modernized to export to
Prometheus/Grafana.


Not supporting GDDM is a case of self-fulfilling prophecy. Quality of 3270 
terminal emulators has been going down since CM/2, with lots of products having 
funny and off color schemes, no or wrong terminal status symbols, terribly 
mixed-up key definitions, the wrong codepages as a default or make the terrible 
decision of blitting pixels over the network instead of tn3270 protocol.

I like Tom's Vista3270, but it is Windows only.


It works just fine on my Linux machine using Wine once I installed the
fonts.


Who actually wants to use Windows for work?


Oh no, a smug Mac user!

I don't have a choice any more. My employer used to offer the choice of
Windows or Mac but have since settled on Windows only citing support
issues. Since Windows launched WSL and IDEs such as Intellij and VS Code
integrate seemlessly I would pick Windows over a Mac with homebrew any
day of the week. I've got a Macbook Air and the killer features such as
high resolution retina display and long battery life don't justify the
cost when I hook my machine up to a external monitor and run it plugged in.


I don't miss it, and consider it technical debt ;-)

René.


On 17 Nov 2022, at 20:07, David Crayford dcrayf...@gmail.com wrote:

On 18/11/22 00:05, Dave Jones wrote:


Now if it would only support GDDM style graphics orders like PCOMM does...
Who actually uses GDDM? I use Tom's Vista and I couldn't care less that it 
doesn't support GDDM. Rocket Terminal Emulator Web edition can serve thousands 
of 3270 sessions on a single Node.js server instance. Rocket know how to 
implement GDDM but didn't bother with BlueZone Web as it wasn't deemed 
necessary and having to support it was considered future technical debt.
DJ

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

--
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: TNZ 3270 Emulator: Any Experiences?

[David Crayford]

On 19/11/22 02:12, René Jansen wrote:

RMFIII is my main use case.


If it's graphics that you seek, RMF has been modernized to export to 
Prometheus/Grafana.




  Not supporting GDDM is a case of self-fulfilling prophecy. Quality of 3270 
terminal emulators has been going down since CM/2, with lots of products having 
funny and off color schemes, no or wrong terminal status symbols, terribly 
mixed-up key definitions, the wrong codepages as a default or make the terrible 
decision of blitting pixels over the network instead of tn3270 protocol.

I like Tom's Vista3270, but it is Windows only.


It works just fine on my Linux machine using Wine once I installed the 
fonts.




Who actually wants to use Windows for work?


Oh no, a smug Mac user!

I don't have a choice any more. My employer used to offer the choice of 
Windows or Mac but have since settled on Windows only citing support 
issues. Since Windows launched WSL and IDEs such as Intellij and VS Code 
integrate seemlessly I would pick Windows over a Mac with homebrew any 
day of the week. I've got a Macbook Air and the killer features such as 
high resolution retina display and long battery life don't justify the 
cost when I hook my machine up to a external monitor and run it plugged in.




I don't miss it, and consider it technical debt ;-)

René.


On 17 Nov 2022, at 20:07, David Crayford  wrote:

On 18/11/22 00:05, Dave Jones wrote:

Now if it would only support GDDM style graphics orders like PCOMM does...

Who actually uses GDDM? I use Tom's Vista and I couldn't care less that it 
doesn't support GDDM. Rocket Terminal Emulator Web edition can serve thousands 
of 3270 sessions on a single Node.js server instance. Rocket know how to 
implement GDDM but didn't bother with BlueZone Web as it wasn't deemed 
necessary and having to support it was considered future technical debt.



DJ

--
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: TNZ 3270 Emulator: Any Experiences?

[David Crayford]

On 18/11/22 00:05, Dave Jones wrote:

Now if it would only support GDDM style graphics orders like PCOMM does...


Who actually uses GDDM? I use Tom's Vista and I couldn't care less that 
it doesn't support GDDM. Rocket Terminal Emulator Web edition can serve 
thousands of 3270 sessions on a single Node.js server instance. Rocket 
know how to implement GDDM but didn't bother with BlueZone Web as it 
wasn't deemed necessary and having to support it was considered future 
technical debt.




DJ

--
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: TNZ 3270 Emulator: Any Experiences?

[David Crayford]

> On 17 Nov 2022, at 10:23 pm, Paul Gilmartin 
> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Thu, 17 Nov 2022 19:06:03 +0800, David Crayford wrote:
> 
>> Thanks for sharing. I just tried it and it's cool. Much better than
>> c3270. Supports all the usual fruit. I spend a lot of time in shells and
>> this is a great utility.
>> 
> c3270?  A fairer comparison would be to x3270.
> 

Nitto. X3270 is an x windows application.  c3270 is curses, which is what tnz 
uses. That’s why it’s quite ridiculous to expect GDDM. 
> Does it support screen capture as text (not inage)?
> 
> 
>> On Thu, 17 Nov 2022 13:44:53 +, kekronbekron wrote:
>> 
>> It is cool indeed. I wish IBM did more to encourage enterprises (especially 
>> the mainframe domain) to use more open source.
>> It's quite obvious now that open source isn't broke man's software; it's a 
>> place for very talented people from around the world to solve common 
>> problems, in a way that a single vendor cannot.
>> Like how some folks write extremely performant this or that.
>> 
> That's somewhat the way things were a half-century ago, prior to OCO.
> 
> -- 
> 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: TNZ 3270 Emulator: Any Experiences?

[David Crayford]

Thanks for sharing. I just tried it and it's cool. Much better than 
c3270. Supports all the usual fruit. I spend a lot of time in shells and 
this is a great utility.


On 17/11/22 10:59, Timothy Sipples wrote:

There's a 3270 emulator (and automation) package written in Python that's 
available here:

https://github.com/IBM/tnz

You can run it on any platform that supports Python including macOS and z/OS itself. Any 
reports? Has anyone tried it? One of the fascinating things you can do with TNZ is to run 
it on z/OS, connect to z/OS via OpenSSH (using PuTTY or just about any other SSH client), 
and then start a "loopback" or other TN3270E session within your SSH terminal 
session. And then you can use ISPF (etc.) via SSH. (Got all that?)

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/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


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

Re: XLC C/C++, __R1 and Register 0

[David Crayford]

FINDENVB is reliable. It's designed for languages that don't have access 
to R0. I use it in all my REXX command processors written in C++.


On 29/10/22 08:55, Charles Mills wrote:

I would guess that FINDENVB is no better, no different really, than passing 0 and letting 
IRXEXCOM take a guess. Am I wrong? The way I read the docs is that method will fail if 
the caller is using a Rexx "reentrant environment." Am I wrong?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Friday, October 28, 2022 4:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC C/C++, __R1 and Register 0

There is a field in the LE Enclave Control Block called CEEEDB_R13_PARENT which is a 
pointer to a DSA containing the registers of the enclave parent. If you can be bothered. 
I would just use IRXINIT("FINDENVB ") to get the environment block as opposed 
to fiddling about with control blocks.

--
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: XLC C/C++, __R1 and Register 0

[David Crayford]

There is a field in the LE Enclave Control Block called 
CEEEDB_R13_PARENT which is a pointer to a DSA containing the registers 
of the enclave parent. If you can be bothered. I would just use 
IRXINIT("FINDENVB ") to get the environment block as opposed to fiddling 
about with control blocks.


On 29/10/22 06:46, Charles Mills wrote:

Thanks.

What is the relevance to my question? (How do I obtain the contents of R0 on 
entry to a C program from Rexx?)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Friday, October 28, 2022 3:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC C/C++, __R1 and Register 0

There are three cases

  1. address foo bar baz
 Pass command bar baz to environment foo
 address foo
 bar baz

  2. call bar baz
 Invoke bar with parameter baz; return value optional

  3. bar(baz) in an expression
 Invoke bar with parameter baz; return value required
 


The last two cases are essentially the same. In the first case the value of baz 
is passed as a single parameter even if it contains spaces or commas, but the 
command processor for the environment may parse it into subparameters.

In the second and third cases baz must be a list of expressions, separated by 
commas; there are no constrains on the values of those expressions.

z/OS 2.5 TSO/E REXX Reference, SA32-0972-5, contains details in Chapter 12. 
TSO/E REXX programming services and Chapter 14. Language processor environments

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

Python package for MVS data set I/O

[David Crayford]

I've written a Python package [1] to process record oriented MVS data 
sets. It supports QSAM, BSAM, VSAM (KSDS, ESDS, RRDS), hiperspaces and 
the file system. I would recommend not using it for the file system as 
the Python standard library does a better job and supports file tagging. 
The package API documentation is complete but the tutorial is not. It's 
a weekend fun project for me so I can only spend limited time on it. I 
also need to write an IVP and publish my test cases. Python is an 
enhanced ASCII product so code page conversion is part of the library or 
needs to be done explicitly. If you are reading binary records that 
contain EBCDIC data then you can decode the fields using the 
"decode("cp1047)" [2] or whatever on the string on byte string. To 
process structured data check out the "struct" package [3].


This library is a thin wrapper over the C/C++ STDIO functions. It's a 
Python port of the JZOS ZFile class. I have reused the ZFile name in a 
doff the cap to Kirk and Steve.


[1] https://github.com/daveyc/pyzfile
[2] https://pypi.org/project/ebcdic/
[3] https://docs.python.org/3/library/struct.html

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

Re: XLC C/C++, __R1 and Register 0

[David Crayford]

You can obtain the environment block by calling IRXINIT("FINDENVB ")

On 28/10/22 04:43, Charles Mills wrote:

But how does REXX invoke a program?

Ret = MYFUNC(parm1, parm2)


glue code puts the rexx parameters

Yeah, I know how to do a front-end to the C++ but I would rather not add that 
complexity.

If no one comes up with a better answer I will just go with passing 0 for the 
Environment Block and see what happens.

Why couldn't Rexx have put the Environment Block pointer somewhere *standard*? 
They pass a bunch of pointers off of R1 -- why not one more?

Charles

--
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 python documentation? [was: RE: IBM SMF Export with Python]

[David Crayford]

On 4/10/22 01:56, Farley, Peter x23353 wrote:

I have read that tagging behavior page and it makes sense when applied to files stored in 
the Unix file system.  MVS datasets could just as easily just be considered always tagged 
as cp1047 (with an option to change the CCSID to 037 or one of the European EBCIDIC code 
pages) and then you just go on from there.  Connecting to the MVS file system "under 
the covers" is the runtime implementor's job, not the application developer's job.

As to providing a package to specifically access MVS datasets, my first question is why IBM didn't 
provide one in the first place, or better yet build it into the python I/O subsystem from the 
start?  Why does the community need to provide such a basic functionality?  "zoautil_py" 
is one such implementation, but it is extraordinarily "heavyweight" and expensive to use, 
and is not an acceptable solution in a world where every second counts and costs real money.


I am quite sure an MVS I/O package will happen just like it did for 
golang and Node.js. Yet again, open source code documented in Github and 
the respective package manager repositories. You may not like that but 
it's how these things work.


https://github.com/ibmruntimes/go-recordio



The lack of easy-to-use and efficient MVS file access may well discourage more 
widespread use of python on z/OS for everyday computing tasks.


Maybe not as much as you think. The tooling coming online will require 
Python so it's mandatory. The vast majority on this forum would rather 
use REXX anyway!





And yes, I can accept that my expectations are not realistic.  It is just a shame that an 
easy-to-use and efficient access to MVS datasets isn't and won't be there unless the 
"community" provides it.  IMHO it should have been part-and-parcel of the 
original language implementation, but I know what my opinions and expectations are worth.


The community involves IBM and the team that ported Python, Golang, 
Node.js etc. The team from IBM Toronto have setup and open source 
community that are actively ported FOSS to z/OS. Interestingly, this 
includes the zsh which I'm delighted about.




Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, October 3, 2022 1:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM python documentation? [was: RE: IBM SMF Export with Python]

On 3/10/22 07:18, Farley, Peter x23353 wrote:

Where, for instance, in the documentation that you linked to is there information on 
whether the python "open()" function for files will or will not support direct 
access to MVS datasets without transferring them down to the Unix file system?  I.E.,  
are either of these calls to the open() function valid or not:

Myfile = open("//'MVS.DATA.SET.NAME", "rt", ccsid="1047")

Myfile = open("//:DDNAME", "rt", ccsid="1047") # This of course
assumes that a call to "bpxunix" (or by other means) has been used to
establish a DD allocation in the AS where the python program is
executing

This will *never* happen. If you read the doc WRT tagging behaviors you will 
understand why 
https://urldefense.com/v3/__https://www.ibm.com/docs/en/python-zos/3.9?topic=translation-tagging-behaviors__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!O2czdpcmZt_bBNIuRr4UXedStf34QpBfTBkZ-wQNwNFosWZR2zrDSP1nat8ZFfmZnRA9s7TVhDN6jaUYFy-CaGg$
  .
Rocket's Python port supported reading MVS data sets but it was not a 
documented feature and was used with great care. Patching the Python core I/O 
libraries to support MVS data sets is not a great idea. It's much better to 
write a specific library that *only* support MVS data sets and not z/OS UNIX 
files. A good reference implementation is the JZOS ZFile class. If you open an 
RFE IBM may do this. Or maybe the community can contribute? Either way it's 
going to be implemented as a specific package.

Porting tools to support MVS data sets in trivial. They use open() because it's 
a low-level API and read/write support sockets, FIFO's, pipes etc. It's not 
just a case of replacing open with fopen(). Python implements a fdopen()
https://urldefense.com/v3/__https://docs.python.org/3/library/os.html*os.fdopen__;Iw!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!O2czdpcmZt_bBNIuRr4UXedStf34QpBfTBkZ-wQNwNFosWZR2zrDSP1nat8ZFfmZnRA9s7TVhDN6jaUY6MzWLWc$
   method for wrapping
file descriptors.
--


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.

Re: IBM python documentation? [was: RE: IBM SMF Export with Python]

[David Crayford]

On 3/10/22 13:47, David Crayford wrote:

Porting tools to support MVS data sets in trivial.

I meant Porting tools to support MVS data sets is non trivial.

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

Re: IBM python documentation? [was: RE: IBM SMF Export with Python]

[David Crayford]

On 3/10/22 07:18, Farley, Peter x23353 wrote:

Where, for instance, in the documentation that you linked to is there information on 
whether the python "open()" function for files will or will not support direct 
access to MVS datasets without transferring them down to the Unix file system?  I.E.,  
are either of these calls to the open() function valid or not:

Myfile = open("//'MVS.DATA.SET.NAME", "rt", ccsid="1047")

Myfile = open("//:DDNAME", "rt", ccsid="1047") # This of course assumes that a call to 
"bpxunix" (or by other means) has been used to establish a DD allocation in the AS where the python program 
is executing


This will *never* happen. If you read the doc WRT tagging behaviors you 
will understand why 
https://www.ibm.com/docs/en/python-zos/3.9?topic=translation-tagging-behaviors. 
Rocket's Python port supported reading MVS data sets but it was not a 
documented feature and was used with great care. Patching the Python 
core I/O libraries to support MVS data sets is not a great idea. It's 
much better to write a specific library that *only* support MVS data 
sets and not z/OS UNIX files. A good reference implementation is the 
JZOS ZFile class. If you open an RFE IBM may do this. Or maybe the 
community can contribute? Either way it's going to be implemented as a 
specific package.


Porting tools to support MVS data sets in trivial. They use open() 
because it's a low-level API and read/write support sockets, FIFO's, 
pipes etc. It's not just a case of replacing open with fopen(). Python 
implements a fdopen() 
https://docs.python.org/3/library/os.html#os.fdopen method for wrapping 
file descriptors.


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

Re: IBM python documentation? [was: RE: IBM SMF Export with Python]

[David Crayford]

The only z/OS specific library is a utility package for tagging files 
which is documented here 
https://www.ibm.com/docs/en/python-zos/3.9?topic=package-documentation-zos-util.


Doc for disutils and building packages is here 
https://www.ibm.com/docs/en/python-zos/3.9?topic=information-using-distutils-module.


The README includes information about what additional packages have been 
included with the SDK. It's the same set as Rocket shipped with their 
Python. Maybe I'm missing a trick here because IMO IBM have done a great 
job with Python.


Post-Installation instructions:
-
Note:
In order for Python to operate correctly,
the following environment variables must be set:
    export LIBPATH=/usr/lpp/IBM/cyp/v3r10/pyz/lib
    export _BPXK_AUTOCVT='ON'
    export _CEE_RUNOPTS='FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)'
    # if you are using a bash shell, you should also set these:
    export _TAG_REDIR_ERR=txt
    export _TAG_REDIR_IN=txt
    export _TAG_REDIR_OUT=txt
Also please ensure that your PATH environment variable contains the 'bin'
directory for python.  e.g.:
   export PATH=/usr/lpp/IBM/cyp/v3r10/pyz/bin:$PATH
2. Python location
==
You will find the python executable in
the /usr/lpp/IBM/cyp/v3r10/pyz/bin/ directory.
For example:
    $ /usr/lpp/IBM/cyp/v3r10/pyz/bin/python3 --version
    or
    $ python3 --version
    Python 3.10.5
3. List of Bundled Packages
==
IBM Open Enterprise SDK for Python includes several packages in addition to
the packages included in the default CPython distribution.
Package  Version
 
cffi 1.14.6
cryptography 3.3.2
ebcdic   1.1.1
numpy    1.21.2
pip  22.1.2
pycparser    2.20
setuptools   58.3.0
six  1.16.0
zos_util 1.0.0


On 3/10/22 07:40, David Crayford wrote:


On 3/10/22 07:18, Farley, Peter x23353 wrote:
As the OP of the other thread on python documentation, let me answer 
that what I expected from IBM for python documentation was the same 
sort of Language Reference and Programmers Guide manuals as they 
provide for all of the other major programming languages that they 
support.  My understanding at the moment is that that hasn't been 
done and is not likely to be done.


Where, for instance, in the documentation that you linked to is there 
information on whether the python "open()" function for files will or 
will not support direct access to MVS datasets without transferring 
them down to the Unix file system?  I.E., are either of these calls 
to the open() function valid or not:


Where is the language reference and programming language for Java on 
z/OS? There isn't one, so why would Python be any different? The only 
language references and guides you will find for Java is for products 
such as DB2 or for z/OS specific toolkits such as JZOS.


There are no z/OS specific modifications to Python other than patches 
for the build. If you want to open an MVS data set then write a 
package using cutils to directly reference the C RTL without writing a 
single line of C code. Once you have a library put it on pypi so 
everybody can download it using "pip". Why do you expect IBM to 
provide the function? They are working on a completely new set of 
tooling and have limited resources.


https://medium.com/python-supply/working-with-foreign-functions-ee3b5e40f2ca 





Myfile = open("//'MVS.DATA.SET.NAME", "rt", ccsid="1047")

Myfile = open("//:DDNAME", "rt", ccsid="1047") # This of course 
assumes that a call to "bpxunix" (or by other means) has been used to 
establish a DD allocation in the AS where the python program is 
executing


In other words, where are the z/OS-specific enhancements to the 
standard python functions and libraries documented (assuming there 
are any such enhancements, which I am beginning to doubt)?  For other 
IBM-supported programming languages, that information would probably 
be available in the Language Reference manual and practical examples 
and performance-enhancing advice would be provided in the Programmers 
Guide manual.


The first link that you provided is fine for the systems programmer 
who installs the language on z/OS, but has basically nothing relevant 
for the python application programmer.


The "zoautil_py" library does provide some "direct access" to MVS 
datasets for python programs, but the package is quite "heavyweight" 
and consumes a large amount of elapsed and CPU time to use, as recent 
experimentation I have performed clearly showed.  I found that 
downloading an MVS dataset to the Unix file system with the "zowe" 
CLI interface and accessing that file with "normal" python file 
access functions proved far less expensive than using the 
"zoautil_py" functions to access the same data.  Nowhere in

Re: IBM python documentation? [was: RE: IBM SMF Export with Python]

[David Crayford]

On 3/10/22 07:18, Farley, Peter x23353 wrote:

As the OP of the other thread on python documentation, let me answer that what 
I expected from IBM for python documentation was the same sort of Language 
Reference and Programmers Guide manuals as they provide for all of the other 
major programming languages that they support.  My understanding at the moment 
is that that hasn't been done and is not likely to be done.

Where, for instance, in the documentation that you linked to is there information on 
whether the python "open()" function for files will or will not support direct 
access to MVS datasets without transferring them down to the Unix file system?  I.E.,  
are either of these calls to the open() function valid or not:


Where is the language reference and programming language for Java on 
z/OS? There isn't one, so why would Python be any different? The only 
language references and guides you will find for Java is for products 
such as DB2 or for z/OS specific toolkits such as JZOS.


There are no z/OS specific modifications to Python other than patches 
for the build. If you want to open an MVS data set then write a package 
using cutils to directly reference the C RTL without writing a single 
line of C code. Once you have a library put it on pypi so everybody can 
download it using "pip". Why do you expect IBM to provide the function? 
They are working on a completely new set of tooling and have limited 
resources.


https://medium.com/python-supply/working-with-foreign-functions-ee3b5e40f2ca



Myfile = open("//'MVS.DATA.SET.NAME", "rt", ccsid="1047")

Myfile = open("//:DDNAME", "rt", ccsid="1047") # This of course assumes that a call to 
"bpxunix" (or by other means) has been used to establish a DD allocation in the AS where the python program 
is executing

In other words, where are the z/OS-specific enhancements to the standard python 
functions and libraries documented (assuming there are any such enhancements, 
which I am beginning to doubt)?  For other IBM-supported programming languages, 
that information would probably be available in the Language Reference manual 
and practical examples and performance-enhancing advice would be provided in 
the Programmers Guide manual.

The first link that you provided is fine for the systems programmer who 
installs the language on z/OS, but has basically nothing relevant for the 
python application programmer.

The "zoautil_py" library does provide some "direct access" to MVS datasets for python programs, but the package is 
quite "heavyweight" and consumes a large amount of elapsed and CPU time to use, as recent experimentation I have performed 
clearly showed.  I found that downloading an MVS dataset to the Unix file system with the "zowe" CLI interface and accessing that 
file with "normal" python file access functions proved far less expensive than using the "zoautil_py" functions to 
access the same data.  Nowhere in the IBM-provided ZOAU documentation did I find any reference to performance characteristics or 
performance-enhancing advice.

That separate python libraries for z/OS maintain separate python documentation of their 
functionality is OK, but then the IBM-specific library websites need to provide the same sort 
of automatic linking to the library documentation that the standard python documentation 
websites use.  I.E., the IBM-specific libraries need to have their documentation directly 
available on the ".readthedocs.io" website and linked to from 
their specific page on the Pypi indexing website and not just at their github location.


What IBM-specific library? There isn't one!



ISTM that IBM is a day late and a dollar short on application-level 
documentation for this language on their systems.


I disagree. Maybe your expectations are unrealistic.



Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Saturday, October 1, 2022 9:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM SMF Export with Python

On 2/10/22 01:31, Charles Mills wrote:

We LOVE Python.

When is IBM going to love it enough to ship it and document it as though they 
loved it?

You can order Python via zShop and install it via SMP/E or download a pax file. 
That's choice right there.

What's wrong with the doc? https://www.ibm.com/docs/en/python-zos/3.10 has all 
the information I need to install, customize and build extensions.

For z/OS specific Python libraries the doc is either shipped with the product 
so as ZAOU or for open source projects with the code in a repository. For 
example, the Python DB2 library and doc can be found on Github 
https://github.com/ibmdb/python-ibmdb  . z/OS specific doc here 
https://github.com/ibmdb/node-ibm_db*configure-odbc-driver-on-zos  . This is 
standard for any open source project. I understand th

Re: IBM python documentation?

[David Crayford]

100% agreement. And it's not just interesting glyphs I've had problems 
with. Any code point > 0x7F can get interesting.


On 2/10/22 11:09, Phil Smith III wrote:

David Crayford expounded on some issues with UTF-8 *on z/OS* and 
_BPX_AUTOCVT=ALL. All legitimate, all real problems, but really
z/OS issues, not UTF-8 issues. That is, these don't reflect problems with UTF-8 
itself. What we see all the time is data that's
ISO8859-1 and is treated as 7-bit ASCII (which mostly works) or UTF-8 (which 
sorta works). The problem, of course, is that every
character in this note works fine in that scenario, but as soon as you get into 
some interesting glyphs, Bad Things happen. And then
it's "Your product isn't handling this right"--no, you lied to it and are 
paying the price, sorry! Calling a tail a leg doesn't make
it one, even if you can whack things with both of 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: IBM python documentation?

[David Crayford]

On 2/10/22 01:40, Phil Smith III wrote:

Jay Maynard wrote:

OK, so what kind of issues are there with UTF-8? Especially since it's
pretty much the standard everywhere, these days?
  


Yeah, that caught my eye too. I suspect the answer is that *mixing* UTF-8
and EBCDIC gets complicated because you cannot always convert: e.g., if you
have  in the same string, UTF-anything
can handle it, but you cannot convert that string to EBCDIC because those
two characters are in different EBCDIC code pages.

  


All good points. There are other issues when setting _BPX_AUTOCVT=ALL 
and things start to break depending on your system configuration.
If you set _BPX_AUTOCVT=ALL and use Rocket ported tools they will break. 
There are other issues not related to UTF-8 to file tagging and text
conversion in general. Unnamed pipes only do auto-conversion on one side 
of the pipe so any ported tools using unnamed pipes will have to convert 
to named pipes. The language specification for Golang, Python, JSON, 
YAML etc all mandate UTF-8 but all the ported files on z/OS are tagged 
ISO8859-1.


Using the ISPF editor with tagged files can get interesting. It doesn't 
work at all with UTF-8 if AUTOCVT(ALL) is set in BPXPRMxx. If 
AUTOCVT(ON) is set and the user is using an emulator with a codepage 
that is not IBM-1047 then unpredictable results will occur. We had a 
case opened with IBM when a customer using a German code page created 
malformed YAML files using the ISPF editor. It took ages to diagnose and 
the PMR was closed WAD. IBM asked to to open an RFE to implement a new 
configuration option to prevent this unwanted translation occurring.




Combine that with UTF-8 normalization and variable-length characters and
it's bewildering for EBCDIC-based minds.

  


This does NOT really reflect deficiencies in UTF-8 but rather just
difficulties switching between EBCDIC and UTF-8.

  


ISO8859-1 is cleaner (for cases where it's sufficient!) because it CAN map
1:1 to EBCDIC. Of course it's not sufficient in many, many cases in a global
economy.

  


...phsiii


--
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 SMF Export with Python

[David Crayford]

On 2/10/22 01:31, Charles Mills wrote:

We LOVE Python.

When is IBM going to love it enough to ship it and document it as though they 
loved it?


You can order Python via zShop and install it via SMP/E or download a 
pax file. That's choice right there.


What's wrong with the doc? https://www.ibm.com/docs/en/python-zos/3.10 
has all the information I need to install, customize and build extensions.


For z/OS specific Python libraries the doc is either shipped with the 
product so as ZAOU or for open source projects with the code in a 
repository. For example, the Python DB2 library and doc can be found on 
Github https://github.com/ibmdb/python-ibmdb. z/OS specific doc here 
https://github.com/ibmdb/node-ibm_db#configure-odbc-driver-on-zos. This 
is standard for any open source project. I understand that may be 
uncomfortable to folks that have no experience working with open source.


Another example is https://github.com/ambitus/pyzkiln which is 
maintained by IBMers from Poughkeepsie but part of the OMP. Anybody 
interested in writing Python libraries that include calling HLASM should 
take a look at that repo.


Honestly, I don't see what the issue is with doc? It's no different to 
Java. If I need doc for the JRE I read the Oracle doc. If I need doc for 
Python I head on over to the Python doc. Everything I need for z/OS is 
covered.





(Rhetorical question. I know that David does not know the answer.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Friday, September 30, 2022 11:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM SMF Export with Python

I know Python is not well received on this forum but as an example of
IBMs investment they have announced a new Python toolkit to process SMF
data using Jupyter notesbooks, an industry standard visualization tool
for analytics and machine learning. I understand many people consider
this stuff buzz words and fads but if you dig in a bit it's very cool.

https://zos-hot-topics.com/2022/SMF-Explorer/

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

IBM SMF Export with Python

[David Crayford]

I know Python is not well received on this forum but as an example of 
IBMs investment they have announced a new Python toolkit to process SMF 
data using Jupyter notesbooks, an industry standard visualization tool 
for analytics and machine learning. I understand many people consider 
this stuff buzz words and fads but if you dig in a bit it's very cool.


https://zos-hot-topics.com/2022/SMF-Explorer/

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

Re: IBM python documentation?

[David Crayford]

On 27/9/22 19:26, Seymour J Metz wrote:

By "enhanced ASCII" do you mean ISO-8859-1? UTF-8? "E. None of the above."?


ISO8859-1 is more reliable. There are issues with UTF-8. There is a 
great blog post by an IBM DE who is working on porting FOSS to z/OS 
https://makingdeveloperslivesbetter.wordpress.com/2022/01/07/is-z-os-ascii-or-ebcdic-yes/. 







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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Monday, September 26, 2022 6:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM python documentation?

On 27/9/22 00:34, Farley, Peter x23353 wrote:

Thanks for the reminder about the zoautil_py functions, I did know about them but there 
are gaps -- e.g. ZOAU has no direct support for simple sequential processing of VSAM 
files (e.g., to download a copy of VSAM data to a flat file in the Unix Services 
environment for analysis there).  I have used a Rexx script that executes the FileManager 
batch utility program FMNMAIN to perform such functions.  The FileManager batch program 
proved to be the most compatible in generating correct Unix Services output files for 
various flavors of VSAM input files where IDCAMS REPRO or DFSORT "OPTION COPY" 
outputs were less so.

Re: "ADDRESS TSO" needs - Rexx is not necessarily needed, as there is also the Unix Services 
command "tso" (or "tsocmd" for authorized services) to execute a single TSO command.  The 
python subprocess.run() function could handle executing that command and capturing the output as needed.

For more complicated "ADDRESS TSO" needs, yes one can execute a Rexx script in the Unix Services 
environment which uses "ADDRESS TSO" to execute a Rexx script also stored in that environment (or 
in an MVS library assigned to SYSEXEC) that then actually uses "ADDRESS TSO" functions.  A bit Rube 
Goldberg, but it does work, as my recent experimentation with getting LISTDSI output from the Unix Services 
environment proved.  Conceivably one could write that first Rexx script to set up an ISPF environment (all 
the needed DD's, etc.) and execute the second (functional) script in an ISPF environment (I haven't tried 
that yet; here there be dragons).

Should have used my lua port :) It supports all access methods and has a
listdsi function that I wrote - io.listdsi(dsname)



Re: Writing an MVS I/O package for IBM python - ISTM that without documentation 
of the runtime architecture of the IBM python port (and also possibly access to 
the source of the port) it is not likely to succeed.  OCO strikes again.

It's certainly not OCO. IBM ship all the header files to write
extensions including a zos.h. What you need to know is that it's 64-bit,
enhanced ASCII and is compiled using the xlclang compiler. Extensions
are shared objects so you need to following compiler options: -q64
-qascii -qexportall. You may not need "exportall" if IBM have defined
PyMODINIT_FUNC for the platform.



The new DSFS functionality may or may not relieve the need for an MVS-specific 
I/O package.  That remains to be seen.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Monday, September 26, 2022 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM python documentation?

If IIRC IBM loosely paired the IBM ZOAU to “assist Python”.  
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.ibm.com%2Fcommunity%2Fuser%2Fibmz-and-linuxone%2Fblogs%2Faustin-wells1%2F2020%2F12%2F11%2Fusing-ibm-open-enterprise-python-for-zos-and-zoaudata=05%7C01%7Csmetz3%40gmu.edu%7Ccfa1d3f0cb6144907fa608daa0104277%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637998288955467761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=CSIi3EDh0%2Bl60cgC%2B2ZSh6zbr6omoi4FwR125vs76UE%3Dreserved=0

The challenge I see currently with Python is that is runs in a USS environment 
so if you need to “ADDRESS TSO” you need to call a REXX from Python in USS and 
do the other work.  Its probably not going to happen but a “System” Python 
might fill that gap.

Matt Hogstrom
m...@hogstrom.org

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom


On Sep 25, 2022, at 11:15 PM, David Crayford  wrote:

On 26/9/22 10:43, Charles Mills wrote:

It's trivial to write an MVS I/O package if you have a C compiler.

One might ask then why IBM has not done so.

I would suggest that they have not had a requirement. IBM use Python in their 
analytics products and for new stuff like Ansible. Same with golang, they need 
it for Kubernetes and OpenShift for z/CX containers. I doubt very much if many 
customers have tried golang. It's a great language now it supports generics. As 
fast as C++ with many advantages.



Charles

-Origi

Re: IBM python documentation?

[David Crayford]

On 27/9/22 00:34, Farley, Peter x23353 wrote:

Thanks for the reminder about the zoautil_py functions, I did know about them but there 
are gaps -- e.g. ZOAU has no direct support for simple sequential processing of VSAM 
files (e.g., to download a copy of VSAM data to a flat file in the Unix Services 
environment for analysis there).  I have used a Rexx script that executes the FileManager 
batch utility program FMNMAIN to perform such functions.  The FileManager batch program 
proved to be the most compatible in generating correct Unix Services output files for 
various flavors of VSAM input files where IDCAMS REPRO or DFSORT "OPTION COPY" 
outputs were less so.

Re: "ADDRESS TSO" needs - Rexx is not necessarily needed, as there is also the Unix Services 
command "tso" (or "tsocmd" for authorized services) to execute a single TSO command.  The 
python subprocess.run() function could handle executing that command and capturing the output as needed.

For more complicated "ADDRESS TSO" needs, yes one can execute a Rexx script in the Unix Services 
environment which uses "ADDRESS TSO" to execute a Rexx script also stored in that environment (or 
in an MVS library assigned to SYSEXEC) that then actually uses "ADDRESS TSO" functions.  A bit Rube 
Goldberg, but it does work, as my recent experimentation with getting LISTDSI output from the Unix Services 
environment proved.  Conceivably one could write that first Rexx script to set up an ISPF environment (all 
the needed DD's, etc.) and execute the second (functional) script in an ISPF environment (I haven't tried 
that yet; here there be dragons).


Should have used my lua port :) It supports all access methods and has a 
listdsi function that I wrote - io.listdsi(dsname)




Re: Writing an MVS I/O package for IBM python - ISTM that without documentation 
of the runtime architecture of the IBM python port (and also possibly access to 
the source of the port) it is not likely to succeed.  OCO strikes again.


It's certainly not OCO. IBM ship all the header files to write 
extensions including a zos.h. What you need to know is that it's 64-bit, 
enhanced ASCII and is compiled using the xlclang compiler. Extensions 
are shared objects so you need to following compiler options: -q64 
-qascii -qexportall. You may not need "exportall" if IBM have defined 
PyMODINIT_FUNC for the platform.





The new DSFS functionality may or may not relieve the need for an MVS-specific 
I/O package.  That remains to be seen.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Monday, September 26, 2022 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM python documentation?

If IIRC IBM loosely paired the IBM ZOAU to “assist Python”.  
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/austin-wells1/2020/12/11/using-ibm-open-enterprise-python-for-zos-and-zoau

The challenge I see currently with Python is that is runs in a USS environment 
so if you need to “ADDRESS TSO” you need to call a REXX from Python in USS and 
do the other work.  Its probably not going to happen but a “System” Python 
might fill that gap.

Matt Hogstrom
m...@hogstrom.org

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom


On Sep 25, 2022, at 11:15 PM, David Crayford  wrote:

On 26/9/22 10:43, Charles Mills wrote:

It's trivial to write an MVS I/O package if you have a C compiler.

One might ask then why IBM has not done so.

I would suggest that they have not had a requirement. IBM use Python in their 
analytics products and for new stuff like Ansible. Same with golang, they need 
it for Kubernetes and OpenShift for z/CX containers. I doubt very much if many 
customers have tried golang. It's a great language now it supports generics. As 
fast as C++ with many advantages.



Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Crayford
Sent: Sunday, September 25, 2022 6:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM python documentation?

On 26/9/22 07:34, Farley, Peter x23353 wrote:

I know Rocket's port of python has some documented enhancements to support MVS dataset access among 
other things, but I have failed to find any documentation on the IBM websites for an IBM-produced 
"python Programmers Guide" (or similar) that would describe and provide examples for any 
"IBM-specific" functional enhancements to the base language facilities.

Is there any such documentation?  Or are the python.org
documentation websites the only reference material available for the
IBM port of python? (i.e., no functional enhancements at all are
provided in the IBM port)

Correct! It's trivial to write an MVS I/O package if you have a C compiler.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is 

Re: IBM python documentation?

[David Crayford]

On 26/9/22 10:43, Charles Mills wrote:

It's trivial to write an MVS I/O package if you have a C compiler.

One might ask then why IBM has not done so.


I would suggest that they have not had a requirement. IBM use Python in 
their analytics products and for new stuff like Ansible. Same with 
golang, they need it for Kubernetes and OpenShift for z/CX containers. I 
doubt very much if many customers have tried golang. It's a great 
language now it supports generics. As fast as C++ with many advantages.




Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Sunday, September 25, 2022 6:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM python documentation?

On 26/9/22 07:34, Farley, Peter x23353 wrote:

I know Rocket's port of python has some documented enhancements to support MVS dataset access among 
other things, but I have failed to find any documentation on the IBM websites for an IBM-produced 
"python Programmers Guide" (or similar) that would describe and provide examples for any 
"IBM-specific" functional enhancements to the base language facilities.

Is there any such documentation?  Or are the python.org documentation websites 
the only reference material available for the IBM port of python? (i.e., no 
functional enhancements at all are provided in the IBM port)

Correct! It's trivial to write an MVS I/O package if you have a C compiler.

--
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: Assembler courses

[David Crayford]

From the book "Linux Device Drivers".

Error recovery is sometimes best handled with the goto statement. We 
normally hate
to use goto, but in our opinion, this is one situation where it is 
useful. Careful use of
goto in error situations can eliminate a great deal of complicated, 
highly-indented,
“structured” logic. Thus, in the kernel, goto is often used as shown 
here to deal with

errors.

The following sample code (using fictitious registration and 
unregistration func-

tions) behaves correctly if initialization fails at any point:

int __init my_init_function(void)
{
    int err;
    /* registration takes a pointer and a name */
    err = register_this(ptr1, "skull");
    if (err) goto fail_this;
    err = register_that(ptr2, "skull");
    if (err) goto fail_that;
    err = register_those(ptr3, "skull");
    if (err) goto fail_those;
    return 0; /* success */
    fail_those: unregister_that(ptr2, "skull");
    fail_that: unregister_this(ptr1, "skull");
    fail_this: return err; /* propagate the error */
}

This code attempts to register three (fictitious)facilities. The goto 
statement is used
in case of failure to cause the unregistration of only the facilities 
that had been suc-

cessfully registered before things went bad.

On 26/9/22 10:17, David Crayford wrote:


On 26/9/22 10:13, Steve Smith wrote:

lol... We definitely need a guide to refracturing code.

More seriously, a decent commentary on how to use goto "correctly" 
would be

a nice thing to see.
Here you go, just in case you missed it the first time I posted 
https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/ 



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

Re: Assembler courses

[David Crayford]

On 26/9/22 10:13, Steve Smith wrote:

lol... We definitely need a guide to refracturing code.

More seriously, a decent commentary on how to use goto "correctly" would be
a nice thing to see.
Here you go, just in case you missed it the first time I posted 
https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/ 


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

Re: Assembler courses

[David Crayford]

Here is another example of using a cleanup stack 
https://github.com/eclipse-openj9/openj9-omr/blob/openj9/port/win32/omrsignal.c. 
That's how we write our C code. SP evangelists would be inclined to nest 
if statements which would be harder to read and wouldn't pass code 
review in my team. Of course, withmore sophisticated languages cleanup 
is done using automatic finalization such as destructors in C++, 
try-with-resources in Java, using declarations in C#, "with" statements 
in Python etc. In programming languages that don't support finalization 
goto is a very good idea. I include COBOL in that statement. I've seen 
some god awful COBOL code with out of control nesting in my time.



On 26/9/22 02:07, Bernd Oppolzer wrote:

After looking at your example at
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c 


I would like to comment:

the "goto done" in the first function is only necessary, because in C 
the return statement

serves two purposes:

- setting the return value
- returning control to the caller

In Pascal, for example, the return value of a function is set by 
assigning a value to the function name
(inside the function) and control is returned by reaching the end of 
the function, or (in case of
Stanford Pascal and more recent Pascal dialects) the return statement 
(which has no parameters etc.).


So there is a separation between the two purposes.

In Pascal then, there would be no need to branch to the end of the 
function, because there is the
one and only place where you set the function result from the local 
temp variable. Hence,
no need for a goto (no use case). The return statement would be at the 
position where the
goto done is. The value is assigned to the function name instead of 
the temp variable

(can be done at multiple places).

IIRC, this (the two purposes of the C return statement) has been 
mentioned in one
of the videos posted by Peter Sylvester. This (IMO) is a flaw of the C 
language.
There are others, for example that it's impossible to declare 
functions inside of functions

(no true ALGOL block concept).

Kind regards

Bernd


Am 25.09.2022 um 13:51 schrieb David Crayford:
Another thing that makes me incredibly dubious about some of the 
opinions in these videos is the hackneyed nonsense about "goto 
considered harmful". The original paper was misunderstood in that all 
goto statements are harmful and brainwashed a generation. Some of 
these videos present a trivial example using goto and refactor it 
using if/ifelse. In programming languages without scope based cleanup 
goto is not harmful. In fact it's leads to clean code as the branch 
direction is always descending to a cleanup block. Happily for me, 
the young guys I work with writing systems level Metal/C code haven't 
been seduced by this dogmatic BS.  Good C code uses goto statements 
as opposed to heavily nested or superfluously functionally decomposed 
routines. The IBM Openj9 JVM C code is a case in point 
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c. 
I challenge anybody to write better code without goto statements.


On 20/09/2022 5:46 pm, Peter Sylvester wrote:

Hi,

49 years ago I 'stumbled' over Simula 67 (see video 1), well, at the 
university "informatik 1" course. I had gotten an Algol60 book given 
to me by my math teacher 2 years earlier. The student a year older 
learned PL/1. WE had an /168 and the Simula 67 system from the NCC 
(you can find it on the CBTTAPE, the turnkey system and elsewhere.


To assembler: On error, you got a nicely formatted storage dump of 
objects. One motivation


After two years and the first graduation (Vordiplom) with punched 
cards etc (but using the MFT like a PC), a got a job at at  the CS 
research center GMD:  MVS, TSO SPF, another universe. It would take 
to much here to explain all the reason why I did a lot of assembler 
(because of this I was able to work in an internship at the swiss 
Colony Computing Center), but I always more than mildly disliked aka 
hated the non structured way of assembled. My work was to write a 
fast program to create microfiches (block letters, index pages). The 
result were a set of structured programming macros (also on the 
cbttape).


Later  with UCLA/Mail, the formatting of "objects" on traces, dumps. 
and stack of function. Just read the "assembler" code (CBTTAPE).


Anyway, here some nice videos.

https://www.youtube.com/watch?v=pH-q2m5sb04

actually, why is smalltalk so close to objective C. Because of a 
Byte Magazine cover page.


https://www.youtube.com/watch?v=SFv8Wm2HdNM

https://www.youtube.com/watch?v=QM1iUe6IofM

https://www.youtube.com/watch?v=eEBOvqMfPoI

Some are provocative. There are many others. I really like "going 
virtually" to these conferences.


https://www.youtube.com/watch?v=_mZBa3sqTrI=45s

Sorry for this side track



---