Re: z/OSMF PSWI
>What I see is that z/OSMF development is following the same path as all of the >other 'lets get modern' projects. You pick the pretty GUI you like and start >applying that toolset against a currently working 'solved' problem. >Promising modernization according to latest hot topics in code development. >Buzzwords come and go, languages come and go, software development kits come >and go ad infinitum. > >What tends to be forgotten are all the time and effort spent on building the >solution to the old solved problem. I can remember many discussions here and >elsewhere about ServerPac changes and difficulties that could benefit by more >development changes. > >Who remembers all the IBM and OEM 'assistance' products created to buffer us >poor feeble support teams from the evils of SMP or SMP/E. > >z/OSMF is just the latest way to 'dumb down' the complexities for the masses. > But then reality steps in. Somebody, Somewhere HAS to know what has to >happen when the rubber meets the road. And navigating from the GUI through >the stack of products to get to the Road is a long and twisted path. > >IF (a big IF) you think the same way the GUI developer thinks, then life can >get smoother. Any attempt to repeat the processes that were repeatable and >have worked before will meet resistance. > >With the removal of old options like ServerPac and being forced to the new >paradigm of z/OSMF will eventually lead to a better z/OSMF tool. But lood >for years of development just like ServerPac needed to achieve its popularity. > Amen. If I still had to install a new z/OS version before retirement, I'd go back to CBPDO. It's a bit more work because I have to do the apply myself, but it's tried and true, and I have used CBPDO on any product we have had to install except z/OS itself (Java, the compilers, ...) Regards, Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OSMF PSWI
>Create SYS1.IEBCOPY(IEBCOPY)? > >> Maybe, somewhere in the middle, IEBCOPY is relocated... Or a ptf hit the ibm command processor, so each and every command issued abends -- 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?
Shades of Monty Python: IBM: "Can I help you sir?" Customer: "I'm looking for an MVS IO package for Python". IBM: "You're the fifth bloke in here today asking for that, there's no demand for it.." On Mon, Sep 26, 2022 at 1: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. > > > > -- > > 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 > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM python documentation?
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: IBM python documentation?
> 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. 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
Re: Assembler courses
I did read that, I like reading LT... you don't spend much time wondering what his position really is. While it covers an important use case, and actually covers it pretty thoroughly, it's not a didactic document. Or maybe it is, but I can't find the word I want. Pedagogical maybe? Anyway, something written as a guide, not a debate transcript. And lo, your next example is more like that. sas On Sun, Sep 25, 2022 at 10:17 PM 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler courses
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
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
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. In my opinion, using it like REXX intends the signal statement to be used is fair. I can't at the moment recall much else that I'd normally write. Of course, signal in REXX is often as horribly misused as any regular goto. sas On Sun, Sep 25, 2022 at 9:44 PM Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 26 Sep 2022 01:21:03 +, Seymour J wrote: > > >As a companion to "Structured Programming with go to Statements" by > DONALD E. KNUTH, I see a great need for "Spaghetti Code Without go to > Statements". BTDT,GTS. > > That's almost trivial. Refracture any spaghetti code as a single DO > FOREVER > containing a SELECT in which each WHEN clause assigns to a variable used > to indicate the next WHEN. > > -- > gil > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler courses
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 -- For IBM-MAIN subscribe / signoff / archive
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
Re: Assembler courses
On Mon, 26 Sep 2022 01:21:03 +, Seymour J wrote: >As a companion to "Structured Programming with go to Statements" by DONALD E. >KNUTH, I see a great need for "Spaghetti Code Without go to Statements". >BTDT,GTS. That's almost trivial. Refracture any spaghetti code as a single DO FOREVER containing a SELECT in which each WHEN clause assigns to a variable used to indicate the next WHEN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler courses
As a companion to "Structured Programming with go to Statements" by DONALD E. KNUTH, I see a great need for "Spaghetti Code Without go to Statements". BTDT,GTS. From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Sunday, September 25, 2022 8:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler courses According to Linus you’ve been brainwashed by using a garbage language https://secure-web.cisco.com/1AljfkLGGdV0Jty3Ym1w5HatMtcmZ3H0SpTJozVJj2O2mM6H3lJxH92R9iS9tGEwnOKGf5Rr8czIZ8iKjU4KoGgWUmFEOawaqYUlplyg_3woqC2QpQRSTjOR4sIwCmDns8vaTmeMJKq6eofFVp9fmG57yGDYeCz9rdT8VSIt6TZkzleobRrY5rdT86wx1KIhAZEHfJF5zDA_uWnd38OsXN0anZzpfug3AppfFTvJQ-It7zFS7KY2N5rJ0Ra9yOGL2gVhKwo2tHOD85bBqqgJQcn_QXDj0dSlHHe99lnMWR-Pr6AX61h7P4xS0osB1N5s0WBgLIpc9QR6w222GOfpxWsi0wWSJx1b5r2pz_PJ8iPqHhvFQomCjjU4xqMF5kpDbhsUrSB_jVCFTf9ZoDwtEUS_h5UU0t4vTy8GaWhkdryKcd3_qAd17r94Ei2uABI-l/https%3A%2F%2Fkoblents.com%2FChes%2FLinks%2FMonth-Mar-2013%2F20-Using-Goto-in-Linux-Kernel-Code%2F > On 26 Sep 2022, at 1:43 am, Bernd Oppolzer wrote: > > I try to be not dogmatic about GOTO statements, > in fact, I am coding COBOL in my money (everyday) job, and there are lots of > GO TOs around; > I try to remove them, when I do larger refactoring, but if not, I leave them > untouched. > > But now for another GOTO story. > > When I started my Stanford Pascal compiler adventure in 2011, the first > compiler pass (PASCAL1) > had around 50 GOTO statements in it (in fact: 50 numeric labels which are > targets of GOTOs in Pascal; > in Pascal, BTW, GOTOs are allowed, but they are sort of uncomfortable; > you need a label declaration for them, not only the GOTO statement and the > target label - > because the label is local to a block, the label number may be reused in > different blocks). > The Stanford compiler, as many other Pascal compilers, is self-hosted, > that means, it is written in Stanford Pascal and compiled by itself. > The Stanford Pascal compiler pass 1 had 6.000 lines in 2011 ... with the 50 > labels mentioned above > (well, this was the 1982 McGill version, to be honest). > > One of my first extensions to Stanford Pascal was to add CONTINUE, BREAK and > RETURN statements > to it (semantics like in C). It turned out that almost all GOTOs were used to > implement the missing > statements CONTINUE, BREAK and RETURN using GOTOs. I then started (after some > time) > to remove the GOTOs by replacing them by the new statements, where this was > possible > without problems. > > Today the compiler pass 1 has almost 25.000 lines. It only contains 7 GOTO > statemens (I just checked it). > Because, see above, I am not dogmatic about GOTO, I will leave them, as long > as there is no need > to work on the procedures containing them. > The compiler story (including downloads) is here: > http://secure-web.cisco.com/1SeQcGdriYjXOUOZmJ0TQyNubfV-j2u1wqtZiAsKEVGvUnkEjGQlKIlwL_bHmG-eNMe96E878kRA-dAsBTTUloloysZCZ61Ay5d_7IMHDG1vnhQ2biIAO0BHVDrU887sf2-r95sv7ydGHB2OKEsX8CFPMYsVgfYgli-LImo7OJCItLF3Ez63AslXYlvIDO0U6FlG_STVPESyecE0q-KLvXvZdS6_tXxoI1MV4-6eOquKsggUhiR9uHzhfEkpmpdG73mC2LK4YBbf9I_Cr18yUsr7RBoYiO6J9vjDebBJb8dN43jWuw-E4Sg97svU2mcuLeTuTHgDMYocb4HY7NqR-kt9bU-02vf0UCnmP2ovV9icLKeqp8WD1gfnVj2yq2cNpnsP5qgY-QF37tfgpE-12yeTUm9O_9l4JK_tah8EgA2s7juJf9qDtqxY2RjLLg7BV/http%3A%2F%2Fbernd-oppolzer.de%2Fjob9.htm > > IMO, GOTOs (and the statements mentioned above) must be used with care. > If you don't use them right, nobody will be able to follow the logic in your > programs, > including yourself (after some time). Indentation is key, and meaningful > comments. > > 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 >>
Re: Assembler courses
According to Linus you’ve been brainwashed by using a garbage language https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/ > On 26 Sep 2022, at 1:43 am, Bernd Oppolzer wrote: > > I try to be not dogmatic about GOTO statements, > in fact, I am coding COBOL in my money (everyday) job, and there are lots of > GO TOs around; > I try to remove them, when I do larger refactoring, but if not, I leave them > untouched. > > But now for another GOTO story. > > When I started my Stanford Pascal compiler adventure in 2011, the first > compiler pass (PASCAL1) > had around 50 GOTO statements in it (in fact: 50 numeric labels which are > targets of GOTOs in Pascal; > in Pascal, BTW, GOTOs are allowed, but they are sort of uncomfortable; > you need a label declaration for them, not only the GOTO statement and the > target label - > because the label is local to a block, the label number may be reused in > different blocks). > The Stanford compiler, as many other Pascal compilers, is self-hosted, > that means, it is written in Stanford Pascal and compiled by itself. > The Stanford Pascal compiler pass 1 had 6.000 lines in 2011 ... with the 50 > labels mentioned above > (well, this was the 1982 McGill version, to be honest). > > One of my first extensions to Stanford Pascal was to add CONTINUE, BREAK and > RETURN statements > to it (semantics like in C). It turned out that almost all GOTOs were used to > implement the missing > statements CONTINUE, BREAK and RETURN using GOTOs. I then started (after some > time) > to remove the GOTOs by replacing them by the new statements, where this was > possible > without problems. > > Today the compiler pass 1 has almost 25.000 lines. It only contains 7 GOTO > statemens (I just checked it). > Because, see above, I am not dogmatic about GOTO, I will leave them, as long > as there is no need > to work on the procedures containing them. > The compiler story (including downloads) is here: > http://bernd-oppolzer.de/job9.htm > > IMO, GOTOs (and the statements mentioned above) must be used with care. > If you don't use them right, nobody will be able to follow the logic in your > programs, > including yourself (after some time). Indentation is key, and meaningful > comments. > > 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. >> >> > > -- > 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 python documentation?
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) 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
Re: Assembler courses
I'm glad someone else is saying this about GOTOs. I was a COBOL developer for years before getting into ACF2, and argued strenuously (and futilely) for limited use of GOTOs at a shop where they'd all fallen for the religious belief that GOTO is Satan. Three clear places where a GOTO can make a program better, not worse, in COBOL: 1) GOTO EXIT-PROGRAM, where last messages be issued and other shutdown processed. 2) GOTO END-OF-SECTION, sort of like a LEAVE statement in REXX. 3) GOTO TOP-OF-LOOP, which would correspond to the ITERATE in REXX. (Nowadays I would probably write that as GOTO BOTTOM-OF-LOOP, but that's a detail.) Now that I'm doing a lot of VBA programming, I often use that third example to goto a label placed immediately before the Next statement; the label is invariably IterateSomething (IterateRow, IterateRegion or whatever) to keep me from forgetting that gotos are not to be used carelessly. So far I haven't convinced myself that one of my VBA programs needs a GoTo of the second type, but usually the reason I want it is to avoid one of those long series of indented If statements you spoke of, and in VBA I can handle that with a one-time Do block: Do 'one time If RegionCode Like "W*" Then Exit Do If AddLimit < 99 Then Exit Do Set oaddr = User.GetAddress If Not CheckState(oaddr) Is Nothing Then Exit Do ' Now do what you wanted. Loop While False --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* October: The Boston Red Sox, ending an 86-year drought, defeat the St. Louis Cardinals to win the World Series. The Red Sox got into the Series thanks to the fact that the New York Yankees -- who were leading the American-League championships three games to none, and had all-stars at every position, not to mention a payroll larger than the gross national product of Sweden -- chose that particular time to execute the most spectacular choke in all of sports history, an unbelievable Gag-o-Rama, a noxious nosedive, a pathetic gut-check failure of such epic dimensions that every thinking human outside of the New York Metropolitan area experienced a near-orgasmic level of happiness. But there is no need to rub it in. -Dave Barry, 2004 in Review */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Sunday, September 25, 2022 07:52 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler courses
Hi,
I have the feeling that the author of
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c.
might not know/like/understand the && operator.
The huge case testing length and values can be contracted into a single if.
using (len = 3 && memcmp(v,"ddd",3)
Ah the || operator. :-)
not talking about a static inline or macro in order to avoid writing "3" twice. caution about
obfuscation)
This "smells" using C like simple assembler.
Or the used compiler optimations cannot be trusted ;-)
When I read if a if b if c I tend to expect some else. ==> if a && b && c
the "goto done" can either be return whatever, it is done in almost all other
situations).
I don't want to go into a length debate about 'return'.
if cond1 { ... return } if cond2 { ... return }
vs using "else" is sometimes "not so bad".
The "techniques" used in the code are not consistently used, and this *may*
hurt the reader.
Anecdote: In Simula (and Algol?) :
a & b is a AND b
a && b is if a THEN b else TRUE
==> if (a && b) { .. becomes
if if a then b else true then begin ...
you might or might not like it.
doing things before return or at the end of a block: syntactically "finally" or the infamous "else"
in a python "for".
I kind of cheated in assembler: Whatever "block" (block, (if, (loop, (while, (for, ...) there is a
"POSTLUDE name" (kind of named finally) and a "SIGNAL name" from the inside in order not to use
GOTO. Wording is all.
(block ... SIGNAL c1 ... SIGNAL c2 ... POSTLUDE c1 ... POSTLUDE
c2 ... block)
writing all kind of variations of
goto end;
case1: whatever := nonsense; goto end;
case2 :
end: return whatever
shows what: C can be regarded as a better macro assembler (and this very
useful for OS kernel dev)
The point is readability, expectation, avoiding noise ... and obfuscation is a
funny game.
I got used to hear (but extremely rarely to read) qualifications such as "c'est la merde" or "so'n
Scheiss mach i nett".
I know two generations considered "lost" (grandpa was in Verdun and "dad" was
born in 1922)
Best
Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
"Foo considered harmful" considered harmful
Any tool can be misused. That doesn't justify throwing out perfectly good tools. In many cases goto is inappropriate and better tools are available. That doesn't negate the legitimacy of using goto when it is the best tool for the task at hand. The same applies to object-oriented and functional programming; they are often, but not always, appropriate, and are not at fault if someone uses them inappropriately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler courses
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 -- 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
I try to be not dogmatic about GOTO statements, in fact, I am coding COBOL in my money (everyday) job, and there are lots of GO TOs around; I try to remove them, when I do larger refactoring, but if not, I leave them untouched. But now for another GOTO story. When I started my Stanford Pascal compiler adventure in 2011, the first compiler pass (PASCAL1) had around 50 GOTO statements in it (in fact: 50 numeric labels which are targets of GOTOs in Pascal; in Pascal, BTW, GOTOs are allowed, but they are sort of uncomfortable; you need a label declaration for them, not only the GOTO statement and the target label - because the label is local to a block, the label number may be reused in different blocks). The Stanford compiler, as many other Pascal compilers, is self-hosted, that means, it is written in Stanford Pascal and compiled by itself. The Stanford Pascal compiler pass 1 had 6.000 lines in 2011 ... with the 50 labels mentioned above (well, this was the 1982 McGill version, to be honest). One of my first extensions to Stanford Pascal was to add CONTINUE, BREAK and RETURN statements to it (semantics like in C). It turned out that almost all GOTOs were used to implement the missing statements CONTINUE, BREAK and RETURN using GOTOs. I then started (after some time) to remove the GOTOs by replacing them by the new statements, where this was possible without problems. Today the compiler pass 1 has almost 25.000 lines. It only contains 7 GOTO statemens (I just checked it). Because, see above, I am not dogmatic about GOTO, I will leave them, as long as there is no need to work on the procedures containing them. The compiler story (including downloads) is here: http://bernd-oppolzer.de/job9.htm IMO, GOTOs (and the statements mentioned above) must be used with care. If you don't use them right, nobody will be able to follow the logic in your programs, including yourself (after some time). Indentation is key, and meaningful comments. 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Utilites
Just to complement: look at IDCAMS REPRO ENCIPHER (My opinion) It is rather poor & obsolete feature, however it is still possible to use it. -- Radoslaw Skorupka Lodz, Poland W dniu 09.09.2022 o 19:19, Allan Staller pisze: Classification: Confidential Long long ago, in a land far far away... IBM supplied some simple batch utilities w/ICSF that would input a file and output and encrypted version of that file (and vice versa). I can't seem to find any references to these utilities in the current doc. Does anyone remember the name of these fine utilities? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler courses
I can work without goto for a long time, until suddenly I need it, usually when coding some kind of error logic. Then I'll have to either duplicate code or scoot a section into its own subroutine for no other reason than the lack of a goto. But yeah, it can be confusing later if used when not necessary. Maybe I should put a piggy bank on my desk and force myself to put $20 in each time I use it. On 9/25/2022 4:51 AM, David Crayford wrote: 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: An interesting article on the continuing demand for floppy discs
Correction: NOT ALL sorts of floppies are still in use - or the article does not mention other types. Only three form factors were mentioned: 3.5", 5.25" and 8" And I doubt about 5.25" 2.4MB format. Or fileware. However I have some CF-2 3" diskettes (and some hardware for them). And I know much more types, much less popular. Everything well described and pictured (one of my weird hobbies). -- Radoslaw Skorupka Lodz, Poland W dniu 16.09.2022 o 21:43, Bob Bridges pisze: Really interesting, at least for me. Apparently all sorts of floppies are still in use, and this one business is the last one selling them. https://eyeondesign.aiga.org/we-spoke-with-the-last-person-standing-in-the-floppy-disk-business/ --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler courses
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 -- 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
On 25/09/2022 3:56 pm, Peter Sylvester wrote: On 25/09/2022 05:02, David Crayford wrote: There's some interesting videos here. All entertaining in their own way. It's like any dogma, if you want to believe then you will. If you have spent your entire career using structured programming you probably think "hell yeah"! Is such a person the primary target audience of this presentation? I don't think so (the audience is younger). In some other presentation (I don't know the conf/presenter): "If you agree with me, you haven't understood". Maybe, but young people just want a decent job and that usually means using either an OO or FP language in todays job market. We've got a lot of HLASM in our code base and it's not easy to find young people who want to commit to learning a language they consider to be a dead end. Young people move around a lot and want to pick up skills that are transferable. The job market for HLASM programmers may get lively as more people start to retire. Same for COBOL and PL/I. Half of our team have moved to 3 day weeks with a view to retiring. One funny "critique/comment" is the fortran COMEFROM :-) Easy to implement btw. The spaghetti monster"s programming language, (R)amen. IMHO, your last sentence may provide a hint. If one spends all his career using the same "paradigm" (or whatever one may call a "religion") ... And then may even reinvent a square shaped wheel (where pi equals 4) ... Or a cubic sphere (in my neighborhood), which is actually fun :-) https://www.youtube.com/watch?v=cNSTJ2Y80OQ Lot's of things to be critized about the following, too. But whow, putting *all* this into a short presentation. (I missed some, e.g. SNOBOL, CDL). https://www.youtube.com/watch?v=0fpDlAEQio4 LOL. Agreed, good fun :) As already said, I was lucky to work as a student (and later as IBM systems programmer) in a mainframe environment of a CS and math research institute (GMD) with >1000 people. Chance to see "beyond and avove" and "play with" a multitude of different perspectives and experiments, some good, some no so, software (totally unstructured programs), hardware (lisp/reduction machine, Suprenum, Eumel), theories (Petri Nets, Interval arithmetic). And, of course, preachers, dogmas. Our ported tools team develop the SciPy libraries for IBM machine learning products on z/OS using highly optimized C/C++ code to implement Python libraries. The MIT "Introduction to programming" course is now taught in Python. SciPy supports both OOP and FP paradigms. https://docs.scipy.org/doc/scipy/ Best -- 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
On 25/09/2022 05:02, David Crayford wrote: There's some interesting videos here. All entertaining in their own way. It's like any dogma, if you want to believe then you will. If you have spent your entire career using structured programming you probably think "hell yeah"! Is such a person the primary target audience of this presentation? I don't think so (the audience is younger). In some other presentation (I don't know the conf/presenter): "If you agree with me, you haven't understood". One funny "critique/comment" is the fortran COMEFROM :-) Easy to implement btw. The spaghetti monster"s programming language, (R)amen. IMHO, your last sentence may provide a hint. If one spends all his career using the same "paradigm" (or whatever one may call a "religion") ... And then may even reinvent a square shaped wheel (where pi equals 4) ... Or a cubic sphere (in my neighborhood), which is actually fun :-) https://www.youtube.com/watch?v=cNSTJ2Y80OQ Lot's of things to be critized about the following, too. But whow, putting *all* this into a short presentation. (I missed some, e.g. SNOBOL, CDL). https://www.youtube.com/watch?v=0fpDlAEQio4 As already said, I was lucky to work as a student (and later as IBM systems programmer) in a mainframe environment of a CS and math research institute (GMD) with >1000 people. Chance to see "beyond and avove" and "play with" a multitude of different perspectives and experiments, some good, some no so, software (totally unstructured programs), hardware (lisp/reduction machine, Suprenum, Eumel), theories (Petri Nets, Interval arithmetic). And, of course, preachers, dogmas. Best -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
