subject:"\"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

2022-09-25 Thread Steve Smith

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&t=45s

Sorry for this side track



--
For IBM-MAIN subscribe / signoff / archive acc

Re: Assembler courses

2022-09-25 Thread Paul Gilmartin

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

2022-09-25 Thread Seymour J Metz

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 
>> https://secure-web.cisco.com/1o4CTqAeplBibdg4QNGSL-oBgUrCxA6v8SroEUyENIJO12B9JOE76XYyfw5RkmP-qVQzrbch32X3

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

Re: Assembler courses

2022-09-25 Thread Bob Bridges

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

2022-09-25 Thread Peter Sylvester


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

Re: Assembler courses

2022-09-25 Thread Bernd Oppolzer


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&t=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

2022-09-25 Thread Bernd Oppolzer


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: Assembler courses

2022-09-25 Thread Tom Brennan

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: 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&t=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

2022-09-25 Thread Peter Sylvester


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

Re: Assembler courses


On 24/09/2022 9:48 pm, Kirk Wolf wrote:

On Fri, Sep 23, 2022, at 6:09 PM, Paul Gilmartin wrote:

On Fri, 23 Sep 2022 23:18:21 +0200, Bernd Oppolzer wrote:


Many thanks for these links;

I especially appreciate the tutorials by Brian Will "Object-Oriented
Programming is Bad",
https://www.youtube.com/watch?v=QM1iUe6IofM


Far worse is the attempt to use OO techniques in non-OO languages.
"Where is this function called?"
"A pointer to it is saved in a struct."
After that, it's anyone's guess.


Some of the very best, most ubiquitous C-language software uses object-based techniques 
such as you describe ("struct with function pointer" interfaces).It's 
actually quite common, and when used correctly it provides for separation of concerns in 
large systems.   Granted, some bad software uses it too :-)


Indeed. A perfect example is the Linux VFS (Virtual File System) which 
sure looks like a polymorphic plugin implementation using function 
pointers to me ;) https://tldp.org/LDP/khg/HyperNews/get/fs/vfstour.html





Kirk Wolf
Dovetailed Technologies
http://coztoolkit.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: Assembler courses

2022-09-24 Thread Mike Schwab

On a screen, wouldn't PF keys be a kind of Object programming?
And how about a online transaction, where one screen updates a
particular table in your overall system.
And the different transaction ids would be like an Object / function.
Just leaves the batch job to use structure programming, because you
are dealing with a whole file at once.

On Sat, Sep 24, 2022 at 10:03 PM 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"!
>
> On 20/09/2022 5:46 pm, Peter Sylvester wrote:
> > Anyway, here some nice videos.
> >
> > https://www.youtube.com/watch?v=pH-q2m5sb04
>
> I enjoyed this video the most because it's not peddling dogma. It covers
> some very interesting topics on the current trend in programming, which
> is functional programming. Almost all popular OO languages support the
> FP paradigm, C++, Java, C#, Scala, Kotlin, JavaScript, Python etc.
> Immutability, value types, monads have been around for a least a decade
> and that is the way people are writing programs. I'm afraid I don't see
> a return to structured programming happening in my lifetime. Of course,
> the mainframe is an exception in that the huge legacy code base is
> mostly written in COBOL with a significant amount of PL/I. Having said
> that, most of the modernization initiatives in DB2, CICS, IMS are Java
> frameworks/libraries.
>
>
> >
> >
> > 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&t=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



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Assembler courses

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


On 20/09/2022 5:46 pm, Peter Sylvester wrote:

Anyway, here some nice videos.

https://www.youtube.com/watch?v=pH-q2m5sb04


I enjoyed this video the most because it's not peddling dogma. It covers 
some very interesting topics on the current trend in programming, which 
is functional programming. Almost all popular OO languages support the 
FP paradigm, C++, Java, C#, Scala, Kotlin, JavaScript, Python etc. 
Immutability, value types, monads have been around for a least a decade 
and that is the way people are writing programs. I'm afraid I don't see 
a return to structured programming happening in my lifetime. Of course, 
the mainframe is an exception in that the huge legacy code base is 
mostly written in COBOL with a significant amount of PL/I. Having said 
that, most of the modernization initiatives in DB2, CICS, IMS are Java 
frameworks/libraries.






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&t=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

Re: Assembler courses


On 25/09/2022 1:12 am, Bernd Oppolzer wrote:
IMO, there are some really interesting use cases for such techniques, 
for example


- sort routines where the comparison functions is generic, that is, a 
function pointer

- same for search routines
- same for dynamic arrays of structs, indexed by key structs (I 
implemented one, using AVL trees)

- a function package which prints or plots other functions

and so on.

In C, I did this using function pointers.
In Pascal, I can pass procedures or functions to procedure parameters 
(procedures passed as
parameters to other procedures), which is virtually the same as 
function pointers, but IMO
looks nicer. This is from the 1960s. I never considered this as being 
OO, but in fact,
all the above things, although implemented in procedural languages 
like C and Pascal,

are TEMPLATES.

If I really feel the need for such solutions (which I do sometimes), I 
anyway like to stick
with procedural languages like, see above, Pascal and C, and I don't 
use C++;

all the OO overhead makes me feel bad.


What is this overhead you talk about? The C++ mantra is "you don't pay 
for what you don't use". If you don't want to use virtual inheritance 
then don't! What you will gain is strong typing, RAII, STL with strings, 
containers etc.
Modern C++ is heavy on generics (templates) which are stored in header 
files so open up more possibilities for optimization at the cost of 
compile times and module size. I would take the Pepsi Challenge in a 
drag race between your AVL tree library using a callback with linkage 
overhead against std::map or
a similar generic library that generates bespoke code for the type.  To 
really make it interesting I could roll out the big guns and use a 
highly optimized library from Google 
https://code.google.com/archive/p/cpp-btree/wikis/UsageInstructions.wiki


--
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 1:38 am, Bernd Oppolzer wrote:
The link to the video once again, because it was damaged by my eMail 
client:

https://www.youtube.com/watch?v=IRTfhkiAqPw

Brian's videos are entertaining but his modus operandi is to take some 
really bad code and then demonstrate how to refactor it using structured 
programming. That may be convincing for folks that haven't used OO 
languages but it's not for those that have. For example, his Java 
command line parser is just bogus. Modern Java APIs (Java 1.5 +) use 
annotations https://rvesse.github.io/airline/. Sure beats the hell out 
of using getopt() in C.




HTH, kind regards

Bernd


Am 24.09.2022 um 19:12 schrieb Bernd Oppolzer:

Sorry for this topic drift, but this is interesting, anyway.

IMO, there are some really interesting use cases for such techniques, 
for example


- sort routines where the comparison functions is generic, that is, a 
function pointer

- same for search routines
- same for dynamic arrays of structs, indexed by key structs (I 
implemented one, using AVL trees)

- a function package which prints or plots other functions

and so on.

In C, I did this using function pointers.
In Pascal, I can pass procedures or functions to procedure parameters 
(procedures passed as
parameters to other procedures), which is virtually the same as 
function pointers, but IMO
looks nicer. This is from the 1960s. I never considered this as being 
OO, but in fact,
all the above things, although implemented in procedural languages 
like C and Pascal,

are TEMPLATES.

If I really feel the need for such solutions (which I do sometimes), 
I anyway like to stick
with procedural languages like, see above, Pascal and C, and I don't 
use C++;

all the OO overhead makes me feel bad.

See this video:

Object-Oriented Programming is Embarrassing: 4 Short Examples - 
YouTube 


Kind regards

Bernd


Am 24.09.2022 um 18:51 schrieb Tony Harminc:

On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

Far worse is the attempt to use OO techniques in non-OO languages.

"Where is this function called?"
"A pointer to it is saved in a struct."
After that, it's anyone's guess.

Years ago I inherited a good size (~200 kLOC) assembler program that 
had a
lot of old-fashioned techniques. But at the same time it had a 
structured
macro scheme that was quite advanced, and included an internal 
subroutine

call/stack mechanism. I updated the macros to generate symbols for the
assembler xref/ADATA about what was being called and from where, and 
only
then discovered that the subcall macro had the option to load the 
"function

pointer" (address) from a field in a "struct" (DSECT), thus making a
complete static xref of calls impossible. The best that could be done
(other than a complete control/data flow analysis) was to also log what
updated those pointers in the struct, but correlating them was almost
impossible.

Bad code can be written using just about any programming paradigm in 
any

language.

Tony H.

--
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: Assembler courses

2022-09-24 Thread Peter Sylvester




https://www.youtube.com/watch?v=SFv8Wm2HdNM

All software should be done top down except for the first time

Before writing reusable functions/classes/... write usable ones.

:-)


On 24/09/2022 19:57, Tom Brennan wrote:
Since we're drifting, I'm remembering another method I think they called Structured Programming or 
maybe Top Down Programming.  I was never an application programmer so I don't know all the terms.  
But I think I came across it one day while helping a COBOL programmer. Their main routine called a 
procedure, so I looked for that member.  It had only one line, which called another procedure, so 
I looked at that member. That last member only had one line, a MOVE statement which could have 
been in the main routine and saved me some browsing.


All I can guess is this was designed from the top, with separate members for various functions 
"just in case" those functions needed to be expanded later and the sections could be better 
reused.  But I'll bet a donut that never happened, and the end result was the structuring made 
things more complex and confusing.


On 9/24/2022 10:12 AM, Bernd Oppolzer wrote:

Sorry for this topic drift...


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

2022-09-24 Thread Tom Brennan

Since we're drifting, I'm remembering another method I think they called 
Structured Programming or maybe Top Down Programming.  I was never an 
application programmer so I don't know all the terms.  But I think I 
came across it one day while helping a COBOL programmer.  Their main 
routine called a procedure, so I looked for that member.  It had only 
one line, which called another procedure, so I looked at that member. 
That last member only had one line, a MOVE statement which could have 
been in the main routine and saved me some browsing.


All I can guess is this was designed from the top, with separate members 
for various functions "just in case" those functions needed to be 
expanded later and the sections could be better reused.  But I'll bet a 
donut that never happened, and the end result was the structuring made 
things more complex and confusing.


On 9/24/2022 10:12 AM, Bernd Oppolzer wrote:

Sorry for this topic drift...


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

Re: Assembler courses

2022-09-24 Thread Paul Gilmartin

On Sat, 24 Sep 2022 19:12:39 +0200, Bernd Oppolzer wrote:
>
>In C, I did this using function pointers.
>In Pascal, I can pass procedures or functions to procedure parameters
>(procedures passed as
>parameters to other procedures), which is virtually the same as function
>pointers, but IMO looks nicer. 
>...
Standard  Pascal does not provide function pointers, so passed
procedures must be in static scope at the point of the call that
passes them.  This is sometimes inconvenient.

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

2022-09-24 Thread Bernd Oppolzer

The link to the video once again, because it was damaged by my eMail 
client:

https://www.youtube.com/watch?v=IRTfhkiAqPw

HTH, kind regards

Bernd


Am 24.09.2022 um 19:12 schrieb Bernd Oppolzer:

Sorry for this topic drift, but this is interesting, anyway.

IMO, there are some really interesting use cases for such techniques, 
for example


- sort routines where the comparison functions is generic, that is, a 
function pointer

- same for search routines
- same for dynamic arrays of structs, indexed by key structs (I 
implemented one, using AVL trees)

- a function package which prints or plots other functions

and so on.

In C, I did this using function pointers.
In Pascal, I can pass procedures or functions to procedure parameters 
(procedures passed as
parameters to other procedures), which is virtually the same as 
function pointers, but IMO
looks nicer. This is from the 1960s. I never considered this as being 
OO, but in fact,
all the above things, although implemented in procedural languages 
like C and Pascal,

are TEMPLATES.

If I really feel the need for such solutions (which I do sometimes), I 
anyway like to stick
with procedural languages like, see above, Pascal and C, and I don't 
use C++;

all the OO overhead makes me feel bad.

See this video:

Object-Oriented Programming is Embarrassing: 4 Short Examples - 
YouTube 


Kind regards

Bernd


Am 24.09.2022 um 18:51 schrieb Tony Harminc:

On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

Far worse is the attempt to use OO techniques in non-OO languages.

"Where is this function called?"
"A pointer to it is saved in a struct."
After that, it's anyone's guess.

Years ago I inherited a good size (~200 kLOC) assembler program that 
had a
lot of old-fashioned techniques. But at the same time it had a 
structured
macro scheme that was quite advanced, and included an internal 
subroutine

call/stack mechanism. I updated the macros to generate symbols for the
assembler xref/ADATA about what was being called and from where, and 
only
then discovered that the subcall macro had the option to load the 
"function

pointer" (address) from a field in a "struct" (DSECT), thus making a
complete static xref of calls impossible. The best that could be done
(other than a complete control/data flow analysis) was to also log what
updated those pointers in the struct, but correlating them was almost
impossible.

Bad code can be written using just about any programming paradigm in any
language.

Tony H.

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

Re: Assembler courses

2022-09-24 Thread Gibney, Dave

I wrote a analyzer of DFHSM messages. Here, the most convient language is 
Natural. Which allowed me to generate the subroutine name base on the  error 
message id. With an error handler to catch subroutines not yet written.

So, I could write the code to handle messages I cared about and let the error 
handler tell me about messages I hadn't written yet.  

In this case, there was no confusion about where the programmatically derived 
names where call, as they were all called from the same gateway routine

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bernd Oppolzer
> Sent: Saturday, September 24, 2022 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler courses
> 
> [EXTERNAL EMAIL]
> 
> Sorry for this topic drift, but this is interesting, anyway.
> 
> IMO, there are some really interesting use cases for such techniques,
> for example
> 
> - sort routines where the comparison functions is generic, that is, a
> function pointer
> - same for search routines
> - same for dynamic arrays of structs, indexed by key structs (I
> implemented one, using AVL trees)
> - a function package which prints or plots other functions
> 
> and so on.
> 
> In C, I did this using function pointers.
> In Pascal, I can pass procedures or functions to procedure parameters
> (procedures passed as
> parameters to other procedures), which is virtually the same as function
> pointers, but IMO
> looks nicer. This is from the 1960s. I never considered this as being
> OO, but in fact,
> all the above things, although implemented in procedural languages like
> C and Pascal,
> are TEMPLATES.
> 
> If I really feel the need for such solutions (which I do sometimes), I
> anyway like to stick
> with procedural languages like, see above, Pascal and C, and I don't use
> C++;
> all the OO overhead makes me feel bad.
> 
> See this video:
> 
> Object-Oriented Programming is Embarrassing: 4 Short Examples - YouTube
> <https://urldefense.com/v3/__https://www.youtube.com/watch?v=IRTfhki
> AqPw__;!!JmPEgBY0HMszNaDT!s9tTUn_a7tgU7l_UQjPBgdsIbevvPpNynzvhic
> 9sFjG3dkRDKnfRJXug7RowAIc4HD4Pxc0R1AZTDDBeXLllf-GwHYU$  >
> 
> Kind regards
> 
> Bernd
> 
> 
> Am 24.09.2022 um 18:51 schrieb Tony Harminc:
> > On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin <
> > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Far worse is the attempt to use OO techniques in non-OO languages.
> >> "Where is this function called?"
> >> "A pointer to it is saved in a struct."
> >> After that, it's anyone's guess.
> >>
> > Years ago I inherited a good size (~200 kLOC) assembler program that had a
> > lot of old-fashioned techniques. But at the same time it had a structured
> > macro scheme that was quite advanced, and included an internal
> subroutine
> > call/stack mechanism. I updated the macros to generate symbols for the
> > assembler xref/ADATA about what was being called and from where, and
> only
> > then discovered that the subcall macro had the option to load the "function
> > pointer" (address) from a field in a "struct" (DSECT), thus making a
> > complete static xref of calls impossible. The best that could be done
> > (other than a complete control/data flow analysis) was to also log what
> > updated those pointers in the struct, but correlating them was almost
> > impossible.
> >
> > Bad code can be written using just about any programming paradigm in any
> > language.
> >
> > Tony H.
> >
> > --
> > 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

Re: Assembler courses

2022-09-24 Thread Bernd Oppolzer


Sorry for this topic drift, but this is interesting, anyway.

IMO, there are some really interesting use cases for such techniques, 
for example


- sort routines where the comparison functions is generic, that is, a 
function pointer

- same for search routines
- same for dynamic arrays of structs, indexed by key structs (I 
implemented one, using AVL trees)

- a function package which prints or plots other functions

and so on.

In C, I did this using function pointers.
In Pascal, I can pass procedures or functions to procedure parameters 
(procedures passed as
parameters to other procedures), which is virtually the same as function 
pointers, but IMO
looks nicer. This is from the 1960s. I never considered this as being 
OO, but in fact,
all the above things, although implemented in procedural languages like 
C and Pascal,

are TEMPLATES.

If I really feel the need for such solutions (which I do sometimes), I 
anyway like to stick
with procedural languages like, see above, Pascal and C, and I don't use 
C++;

all the OO overhead makes me feel bad.

See this video:

Object-Oriented Programming is Embarrassing: 4 Short Examples - YouTube 



Kind regards

Bernd


Am 24.09.2022 um 18:51 schrieb Tony Harminc:

On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

Far worse is the attempt to use OO techniques in non-OO languages.

"Where is this function called?"
"A pointer to it is saved in a struct."
After that, it's anyone's guess.


Years ago I inherited a good size (~200 kLOC) assembler program that had a
lot of old-fashioned techniques. But at the same time it had a structured
macro scheme that was quite advanced, and included an internal subroutine
call/stack mechanism. I updated the macros to generate symbols for the
assembler xref/ADATA about what was being called and from where, and only
then discovered that the subcall macro had the option to load the "function
pointer" (address) from a field in a "struct" (DSECT), thus making a
complete static xref of calls impossible. The best that could be done
(other than a complete control/data flow analysis) was to also log what
updated those pointers in the struct, but correlating them was almost
impossible.

Bad code can be written using just about any programming paradigm in any
language.

Tony H.

--
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: Assembler courses

2022-09-24 Thread Tony Harminc

On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

Far worse is the attempt to use OO techniques in non-OO languages.
> "Where is this function called?"
> "A pointer to it is saved in a struct."
> After that, it's anyone's guess.
>

Years ago I inherited a good size (~200 kLOC) assembler program that had a
lot of old-fashioned techniques. But at the same time it had a structured
macro scheme that was quite advanced, and included an internal subroutine
call/stack mechanism. I updated the macros to generate symbols for the
assembler xref/ADATA about what was being called and from where, and only
then discovered that the subcall macro had the option to load the "function
pointer" (address) from a field in a "struct" (DSECT), thus making a
complete static xref of calls impossible. The best that could be done
(other than a complete control/data flow analysis) was to also log what
updated those pointers in the struct, but correlating them was almost
impossible.

Bad code can be written using just about any programming paradigm in any
language.

Tony H.

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

Re: Assembler courses

2022-09-24 Thread Kirk Wolf

On Fri, Sep 23, 2022, at 6:09 PM, Paul Gilmartin wrote:
> On Fri, 23 Sep 2022 23:18:21 +0200, Bernd Oppolzer wrote:
> 
> >Many thanks for these links;
> >
> >I especially appreciate the tutorials by Brian Will "Object-Oriented
> >Programming is Bad",
> >https://www.youtube.com/watch?v=QM1iUe6IofM
> > 
> Far worse is the attempt to use OO techniques in non-OO languages.
> "Where is this function called?"
> "A pointer to it is saved in a struct."
> After that, it's anyone's guess.
> 

Some of the very best, most ubiquitous C-language software uses object-based 
techniques such as you describe ("struct with function pointer" interfaces).
It's actually quite common, and when used correctly it provides for separation 
of concerns in large systems.   Granted, some bad software uses it too :-)

Kirk Wolf
Dovetailed Technologies
http://coztoolkit.com

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

Re: Assembler courses

2022-09-23 Thread David Crayford


On 24/09/2022 7:09 am, Paul Gilmartin wrote:

On Fri, 23 Sep 2022 23:18:21 +0200, Bernd Oppolzer wrote:


Many thanks for these links;

I especially appreciate the tutorials by Brian Will "Object-Oriented
Programming is Bad",
https://www.youtube.com/watch?v=QM1iUe6IofM


Far worse is the attempt to use OO techniques in non-OO languages.


What nonsense! JavaScript didn't get classes until ES6 but everybody was 
implementing objects using closures and the prototype. Same with Lua, no 
classes but OO can be implemented using meta-tables.




"Where is this function called?"
"A pointer to it is saved in a struct."
After that, it's anyone's guess.


In a language like C which lacks generics how would you write a generic 
data structure library without using function pointers for comparators?






the tips how to improve procedural programming from minute 33 ca.
This is so true, but certain tips require a language more powerful than C,
for example PL/1 or Pascal, which supports nesting of procedure and
function definitions.


I sometimes perceive nested procedure definitions as a primitive ancestor
of Objects -- they contain data and methods (so does a DCB.)
I suspect language designers eschew nested procedures for the poor
excuse that a procedure must be identified by two pointers, not just one.

I also liked the term "curly brace languages", which I never heard

before :-)


Which is PL/I?



Even if you don't agree with the opinions expressed here, it is IMO of
great value to look at these videos.

Am 20.09.2022 um 11:46 schrieb Peter Sylvester:

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&t=45s


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

Re: Assembler courses

2022-09-23 Thread Paul Gilmartin

On Fri, 23 Sep 2022 23:18:21 +0200, Bernd Oppolzer wrote:

>Many thanks for these links;
>
>I especially appreciate the tutorials by Brian Will "Object-Oriented
>Programming is Bad",
>https://www.youtube.com/watch?v=QM1iUe6IofM
> 
Far worse is the attempt to use OO techniques in non-OO languages.
"Where is this function called?"
"A pointer to it is saved in a struct."
After that, it's anyone's guess.

>the tips how to improve procedural programming from minute 33 ca.
>This is so true, but certain tips require a language more powerful than C,
>for example PL/1 or Pascal, which supports nesting of procedure and
>function definitions.
>
I sometimes perceive nested procedure definitions as a primitive ancestor
of Objects -- they contain data and methods (so does a DCB.)
I suspect language designers eschew nested procedures for the poor
excuse that a procedure must be identified by two pointers, not just one.

I also liked the term "curly brace languages", which I never heard
>before :-)
>
Which is PL/I?


>Even if you don't agree with the opinions expressed here, it is IMO of
>great value to look at these videos.
>
>Am 20.09.2022 um 11:46 schrieb Peter Sylvester:
>>
>> 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&t=45s

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

2022-09-23 Thread Bernd Oppolzer


Many thanks for these links;

I especially appreciate the tutorials by Brian Will "Object-Oriented 
Programming is Bad",

https://www.youtube.com/watch?v=QM1iUe6IofM

the tips how to improve procedural programming from minute 33 ca.
This is so true, but certain tips require a language more powerful than C,
for example PL/1 or Pascal, which supports nesting of procedure and 
function definitions.
I also liked the term "curly brace languages", which I never heard 
before :-)


Even if you don't agree with the opinions expressed here, it is IMO of 
great value

to look at these videos.

Kind regards

Bernd


Am 20.09.2022 um 11:46 schrieb Peter Sylvester:

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&t=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

2022-09-22 Thread David Crayford

Another example is the pthread library which uses a naming convention 
that describes the context it's operating on. For example, 
pthread_mutex_lock, pthread_cond_wait etc. I've used this kind of naming 
convention myself but I only write Metal/C these days and C++ when using 
LE.


FWIW, the term method is used to describe a virtual function. The reason 
Java refers to member functions as methods is because by default all 
functions are virtual unless you declare them final. It's the other way 
round in C++.


On 22/09/2022 11:29 pm, Charles Mills wrote:

You want an example of object oriented design on the mainframe? I have = no 
idea what the implementation language is but it could be PL/X, = assembler, C, 
etc. It does not matter. (It is clearly not a pure C++ =
library.)

IBM System SSL, a crypto library on z/OS.

Every call operates on one particular kind of data structure: an = "environment," a 
socket, etc. Each of those "packages" of {data = structure, one or more calls} could be 
thought of as an object and its =
methods.=20

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: Assembler courses

2022-09-22 Thread Charles Mills

You want an example of object oriented design on the mainframe? I have = no 
idea what the implementation language is but it could be PL/X, = assembler, C, 
etc. It does not matter. (It is clearly not a pure C++ =
library.)

IBM System SSL, a crypto library on z/OS.

Every call operates on one particular kind of data structure: an = 
"environment," a socket, etc. Each of those "packages" of {data = structure, 
one or more calls} could be thought of as an object and its =
methods.=20

Charles

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

Re: Assembler courses

2022-09-21 Thread Paul Gorlinsky

https://www.cbttape.org/ftp/asmbook/alnv200.pdf  - Assembler Language 
Programming for IBM System z Servers By John R Ehrman.

https://www.amazon.com/Simplified-Approach-Assembly-Language-Programming/dp/0138101191
   - I still have my copy

https://www.cbttape.org - has lots of examples 

Take care

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

Re: Assembler courses

2022-09-21 Thread Paul Gorlinsky

The LE runtime libraries are designed to be called by Assembler programs as 
well as all currently support compilers. As a developer, you can pick which 
language is best for the particular task and have that routine be callable by 
other programs. 

The book, z/OS Language Environment Writing Interlanguage Communication 
Applications SA38-0684, documents the process. 

And the book, z/OS Language Environment Programming Guide, provides samples for 
assembler main and "DLL" programs.

A typical assembler routine within the LE enclave could be used to build a 
callable service for SVC 99 - Dynamic allocation, or a RDJFCB interface, or a 
WTO, WTOR, interface. The point being is that it opens up all normally written 
assembler programs as callable services for C, COBOL, FORTRAN, or PL/1. 



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

Re: Assembler courses

2022-09-21 Thread Steve Smith

imho, using the LE framework is an excellent idea for beginning assembler
programming.  You can actually do "Hello World!" in just a few more lines
than C.  And it lets you defer the gritty details of linkage and DCBs and
such until after some visible results are obtained.  It's almost as easy as
ASSIST or SPASM from back in the day.

sas

On Wed, Sep 21, 2022 at 6:18 AM John McKown 
wrote:

> On Tue, Sep 20, 2022 at 4:32 PM Tom Brennan 
> wrote:
>
> > Spitting out messages with formatted values was always a hassle for me
> > in assembler.  So years ago I wrote some code to somewhat mimic printf,
> > and never looked back.  Invoked by macros something like this:
> >
> >   #PRINTF SYSPRINT,'THIS IS LINE %D OF %D',VAR1,VAR2
> >   #PRINTF SYSPRINT,'THIS IS STRING %S HERE',STR1
> >   #PRINTF SYSPRINT,'DATA IS %08X',POINTER
> >
>
> Being lazy, all my current HLASM code is LE compliant using the CEEENTRY &
> CEETERM macros. And I just use the C runtime library routine, snprintf() to
> format my messages.
>
> Yes, I have embraced the "dark side" of just using Language Environment.
>
> --
> 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

2022-09-21 Thread John McKown

On Tue, Sep 20, 2022 at 4:32 PM Tom Brennan 
wrote:

> Spitting out messages with formatted values was always a hassle for me
> in assembler.  So years ago I wrote some code to somewhat mimic printf,
> and never looked back.  Invoked by macros something like this:
>
>   #PRINTF SYSPRINT,'THIS IS LINE %D OF %D',VAR1,VAR2
>   #PRINTF SYSPRINT,'THIS IS STRING %S HERE',STR1
>   #PRINTF SYSPRINT,'DATA IS %08X',POINTER
>

Being lazy, all my current HLASM code is LE compliant using the CEEENTRY &
CEETERM macros. And I just use the C runtime library routine, snprintf() to
format my messages.

Yes, I have embraced the "dark side" of just using Language Environment.

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

Re: Assembler courses

2022-09-20 Thread David Crayford


On 20/09/2022 10:56 pm, Michael Stein wrote:

I have been coding in C++ and Java for so long OOP is second nature to me
now. Well, in C++ I prefer the interfaces using templates. Java has morphed
into into a hybrid OO/FP language since the introduction of the Streams API
in Java 8. It's common now not to code imperative loop statements at all.
One can use object based programming in any language that supports function
pointers. I have seen a lot of HLASM code that would benefit from such a
design. One of the key principles of OO was to replace conditional logic
with polymorphic types. An example in C is the z/OS stdio library. fopen()
is a factory function that returns an opaque handle with read/write/close
functions pointers set that can handle many different access methods using
the same abstract functions. This is a clean design that unfortunately isn't
as common as it should be.

And when you open a DCB for QSAM you don't care about the device type...


Not quite what I was talking about which is polymorphism. For example, 
fopen() can instantiate QSAM, BSAM, VSAM (KSDS, RRDS, ESDS), Hiperspace, 
z/OS UNIX file etc. I have no doubt that object based design is possible in
assembler but I have never seen it. I've seen plenty of structured 
programming using macros. The majority of HLASM programmers haven't been 
exposed to OOP so don't look to solve problems using that paradigm.





How old is that 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: Assembler courses

2022-09-20 Thread Paul Gilmartin

On Tue, 20 Sep 2022 14:31:55 -0700, Tom Brennan wrote:
>...
>in assembler.  So years ago I wrote some code to somewhat mimic printf,
>and never looked back.  Invoked by macros something like this:
>
>  #PRINTF SYSPRINT,'THIS IS LINE %D OF %D',VAR1,VAR2
>  
We once did something similar but simpler; only text substitutions:
WTOMSG 'This is line &1 of &2..',VAR1,VAR2

In an era when CMS was beginning to use Mixed Case messages, we
thought to get ahead of the trend.  But we provided customers a
configuration option to translate messages UPPER CASE.

I argued that only the template, not the substituted symbols should be
translated.  I was outvoted, even though I cited a Horrible Example:
In a CLIST I had unwittingly (mischievously?) coded "end".  The
resulting message was something like:
IKJ00WTF INVALID COMMAND 'END'
In the interest of convention, it had obliterated the essence of the error.
In extremis, it could have been displayed in hex.

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

2022-09-20 Thread Tom Brennan

Spitting out messages with formatted values was always a hassle for me 
in assembler.  So years ago I wrote some code to somewhat mimic printf, 
and never looked back.  Invoked by macros something like this:


 #PRINTF SYSPRINT,'THIS IS LINE %D OF %D',VAR1,VAR2
 #PRINTF SYSPRINT,'THIS IS STRING %S HERE',STR1
 #PRINTF SYSPRINT,'DATA IS %08X',POINTER

On 9/20/2022 12:23 AM, Colin Paice wrote:

For me, the challenge with learning assembler is how do you input and
output.  I would have an assembler program called from a C program - and
teach them how to use the C "printf" function from assembler  to output
data.  The class can then focus on the assembler code, and get it working.

I learned the hard way, using the CMS PRY debugging tool to step through
the code, and look at the effect of the instructions.

Colin

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

2022-09-20 Thread Michael Stein

> I have been coding in C++ and Java for so long OOP is second nature to me
> now. Well, in C++ I prefer the interfaces using templates. Java has morphed
> into into a hybrid OO/FP language since the introduction of the Streams API
> in Java 8. It's common now not to code imperative loop statements at all.
> One can use object based programming in any language that supports function
> pointers. I have seen a lot of HLASM code that would benefit from such a
> design. One of the key principles of OO was to replace conditional logic
> with polymorphic types. An example in C is the z/OS stdio library. fopen()
> is a factory function that returns an opaque handle with read/write/close
> functions pointers set that can handle many different access methods using
> the same abstract functions. This is a clean design that unfortunately isn't
> as common as it should be.

And when you open a DCB for QSAM you don't care about the device type...

How old is that design?
 

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

Re: Assembler courses

2022-09-20 Thread Seymour J Metz

I worked on a project in Assembler H that was influenced by OO ideas and used 
"late bound calls" (function tables).

--
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, September 20, 2022 3:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler courses

On 19/09/2022 7:59 am, Charles Mills wrote:
>> I've never had occasion to try write OO programs on the mainframe.
>> to me it seems that the chief value of classes and class methods is a
>> way of organizing my subroutines and functions and limiting their
>> scope to particular uses which seems to me would be useful in some
>> mainframe programs
>> I gather some OO languages are available to OMVS users here
> Let me jump in here with a very personal note and say I *have* written a very 
> successful* mainframe program in a totally OO paradigm. So yes, OO is totally 
> relevant to mainframe software.

And kudos to you because not everybody could make the jump from HLASM to
C++.

I have been coding in C++ and Java for so long OOP is second nature to
me now. Well, in C++ I prefer the interfaces using templates. Java has
morphed into into a hybrid OO/FP language since the introduction of the
Streams API in Java 8. It's common now not to code imperative loop
statements at all. One can use object based programming in any language
that supports function pointers. I have seen a lot of HLASM code that
would benefit from such a design. One of the key principles of OO was to
replace conditional logic with polymorphic types. An example in C is the
z/OS stdio library. fopen() is a factory function that returns an opaque
handle with read/write/close functions pointers set that can handle many
different access methods using the same abstract functions. This is a
clean design that unfortunately isn't as common as it should be.

>
> To me, yes, it is a method of organization of data and subroutines. It is a 
> totally different way of thinking about things. Let me see if I can express 
> this. You have a program. You want to add some functionality to it. Rather 
> than thinking separately "I will need some new data fields" and "I will need 
> some new subroutines" instead you think "I will need a 'package' of new data 
> fields and subroutines that operate on those fields." It is a way of 
> organizing the effort that I found to work extremely well for me. I cannot 
> picture writing a large program any other way: not as a hodgepodge of fields 
> and subroutines, but rather as a collection of smallish 'packages' of data 
> and their attendant subroutines.
>
> Utterly industry-standard C++ is available for developing both "legacy" and 
> UNIX programs on z/OS. The program I refer to above is run with JCL as an 
> STC; nothing external about it screams "C" or "OO" or "OMVS."
>
> *Licensed by quite a few "name" companies and then acquired by a big-name 
> software company for fairly big bucks.
>
> 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

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

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&t=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

Assembler courses

2022-09-20 Thread Colin Paice

For me, the challenge with learning assembler is how do you input and
output.  I would have an assembler program called from a C program - and
teach them how to use the C "printf" function from assembler  to output
data.  The class can then focus on the assembler code, and get it working.

I learned the hard way, using the CMS PRY debugging tool to step through
the code, and look at the effect of the instructions.

Colin

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

Re: Assembler courses

2022-09-20 Thread David Crayford


On 19/09/2022 7:59 am, Charles Mills wrote:

I've never had occasion to try write OO programs on the mainframe.
to me it seems that the chief value of classes and class methods is a
way of organizing my subroutines and functions and limiting their
scope to particular uses which seems to me would be useful in some
mainframe programs
I gather some OO languages are available to OMVS users here

Let me jump in here with a very personal note and say I *have* written a very 
successful* mainframe program in a totally OO paradigm. So yes, OO is totally 
relevant to mainframe software.


And kudos to you because not everybody could make the jump from HLASM to 
C++.


I have been coding in C++ and Java for so long OOP is second nature to 
me now. Well, in C++ I prefer the interfaces using templates. Java has 
morphed into into a hybrid OO/FP language since the introduction of the 
Streams API in Java 8. It's common now not to code imperative loop 
statements at all. One can use object based programming in any language 
that supports function pointers. I have seen a lot of HLASM code that 
would benefit from such a design. One of the key principles of OO was to 
replace conditional logic with polymorphic types. An example in C is the 
z/OS stdio library. fopen() is a factory function that returns an opaque 
handle with read/write/close functions pointers set that can handle many 
different access methods using the same abstract functions. This is a 
clean design that unfortunately isn't as common as it should be.





To me, yes, it is a method of organization of data and subroutines. It is a totally different way of thinking 
about things. Let me see if I can express this. You have a program. You want to add some functionality to it. 
Rather than thinking separately "I will need some new data fields" and "I will need some new 
subroutines" instead you think "I will need a 'package' of new data fields and subroutines that 
operate on those fields." It is a way of organizing the effort that I found to work extremely well for 
me. I cannot picture writing a large program any other way: not as a hodgepodge of fields and subroutines, 
but rather as a collection of smallish 'packages' of data and their attendant subroutines.

Utterly industry-standard C++ is available for developing both "legacy" and UNIX programs on z/OS. The 
program I refer to above is run with JCL as an STC; nothing external about it screams "C" or "OO" 
or "OMVS."

*Licensed by quite a few "name" companies and then acquired by a big-name 
software company for fairly big bucks.

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: Assembler courses

2022-09-19 Thread Mike Schwab

Yes.  A 4K difference between registers would be USING label,R12,R11,R10 etc.

On Tue, Sep 20, 2022 at 12:22 AM Brian Westerman
 wrote:
>
> Can you do that and use multiple base regs?
>
> Brian
>
> On Mon, 19 Sep 2022 07:32:07 -0500, Paul Gilmartin  
> wrote:
>
> >On Sun, 18 Sep 2022 22:03:34 -0700, Ed Jaffe wrote:
> >>
> >>I prefer to use:
> >>
> >>LARL  R12,Constants
> >>USING (Constants,Constants_End),R12
> >>
> >>thereby dispensing with permanent base register coverage for program
> >>executable code.
> >>
> >Constants  LOCTR , and
> > LTORG
> >... then become your friends.
> >
> >--
> >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



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Assembler courses

2022-09-19 Thread Brian Westerman

Can you do that and use multiple base regs?

Brian

On Mon, 19 Sep 2022 07:32:07 -0500, Paul Gilmartin  wrote:

>On Sun, 18 Sep 2022 22:03:34 -0700, Ed Jaffe wrote:
>>
>>I prefer to use:
>>
>>LARL  R12,Constants
>>USING (Constants,Constants_End),R12
>>
>>thereby dispensing with permanent base register coverage for program
>>executable code.
>>
>Constants  LOCTR , and
> LTORG
>... then become your friends.
>
>-- 
>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: Assembler courses

2022-09-19 Thread Paul Gilmartin

On Sun, 18 Sep 2022 22:03:34 -0700, Ed Jaffe wrote:
>
>I prefer to use:
>
>LARL  R12,Constants
>USING (Constants,Constants_End),R12
>
>thereby dispensing with permanent base register coverage for program
>executable code.
>
Constants  LOCTR , and
 LTORG
... then become your friends.

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

2022-09-18 Thread Ed Jaffe


On 9/18/2022 4:15 PM, Tom Harper wrote:

Sometimes R15 contains the entry point.

If the routine receives control from ATTACHX or LINKX, for instance, and if it 
is to run in AMODE(64), then it does not.

A better solution is to use

LARL R12,PROGNAME
USING PROGNAME, R12

which has no dependency on R15.


I prefer to use:

LARL  R12,Constants
USING (Constants,Constants_End),R12

thereby dispensing with permanent base register coverage for program 
executable code.


The address range between Constants and Constants_End contains the 
literal pool and any other read-only constants the program might need. 
This area is virtually always less than 4K in size, even for very large 
programs.



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



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

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

Re: Assembler courses

2022-09-18 Thread Bob Bridges

Yes, I didn't think to put it that way at first but it's a good way of phrasing 
it:  In OO coding I'm creating a number of packages, and I find its easier to 
organize their interactions (and to remember how they must interact) when I do 
it that way.

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

/* Well-timed silence is the most commanding expression.  -Mark Helprin in The 
Wall Street Journal */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Sunday, September 18, 2022 19:59

Let me jump in here with a very personal note and say I *have* written a very 
successful* mainframe program in a totally OO paradigm. So yes, OO is totally 
relevant to mainframe software.

To me, yes, it is a method of organization of data and subroutines. It is a 
totally different way of thinking about things. Let me see if I can express 
this. You have a program. You want to add some functionality to it. Rather than 
thinking separately "I will need some new data fields" and "I will need some 
new subroutines" instead you think "I will need a 'package' of new data fields 
and subroutines that operate on those fields." It is a way of organizing the 
effort that I found to work extremely well for me. I cannot picture writing a 
large program any other way: not as a hodgepodge of fields and subroutines, but 
rather as a collection of smallish 'packages' of data and their attendant 
subroutines.

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

Re: Assembler courses

2022-09-18 Thread Charles Mills

> I've never had occasion to try write OO programs on the mainframe.  

> to me it seems that the chief value of classes and class methods is a 
> way of organizing my subroutines and functions and limiting their 
> scope to particular uses which seems to me would be useful in some 
> mainframe programs

> I gather some OO languages are available to OMVS users here

Let me jump in here with a very personal note and say I *have* written a very 
successful* mainframe program in a totally OO paradigm. So yes, OO is totally 
relevant to mainframe software.

To me, yes, it is a method of organization of data and subroutines. It is a 
totally different way of thinking about things. Let me see if I can express 
this. You have a program. You want to add some functionality to it. Rather than 
thinking separately "I will need some new data fields" and "I will need some 
new subroutines" instead you think "I will need a 'package' of new data fields 
and subroutines that operate on those fields." It is a way of organizing the 
effort that I found to work extremely well for me. I cannot picture writing a 
large program any other way: not as a hodgepodge of fields and subroutines, but 
rather as a collection of smallish 'packages' of data and their attendant 
subroutines.

Utterly industry-standard C++ is available for developing both "legacy" and 
UNIX programs on z/OS. The program I refer to above is run with JCL as an STC; 
nothing external about it screams "C" or "OO" or "OMVS."

*Licensed by quite a few "name" companies and then acquired by a big-name 
software company for fairly big bucks.

Charles

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

Re: Assembler courses

2022-09-18 Thread John McKown

On Sun, Sep 18, 2022, 18:16 Tom Harper 
wrote:

> Sometimes R15 contains the entry point.
>
> If the routine receives control from ATTACHX or LINKX, for instance, and
> if it is to run in AMODE(64), then it does not.
>
> A better solution is to use
>
> LARL R12,PROGNAME
> USING PROGNAME, R12
>
> which has no dependency on R15.
>

I have used that. In the past, I also used

BALR R12,0
USING *,R12


> Tom Harper
> Phoenix Software International
>
> Sent from my iPhone
>
> > On Sep 18, 2022, at 5:06 PM, Mike Schwab 
> wrote:
> >
> > When you enter a program, R15 points to the first byte of PROGNAME.
> > You usually have a USING R15,PROGNAME.
> > If you are going to be calling OS functions or programs, you will copy
> > R15 to another register (often R12), issue a USING R12,PROGNAME and
> > DROP R15,PROGNAME.  So when using a label within 4K of PROGNAME, the
> > assembler will use the USING register, and compute the offset from
> > PROGNAME.
> >
> >> On Sun, Sep 18, 2022 at 8:12 AM Bob Bridges 
> wrote:
> >>
> >> Twenty years ago I wrote a few programs for Excel, and didn't see what
> all the fuss was about: "object-oriented" didn't seem very different from
> traditional programming that I'd been doing for 25 years.  (At the same
> time I was frequently infuriated at the message "...does not support this
> property or method", exactly because I ~didn't~ understand what was
> different about OO coding.)
> >>
> >> Eventually a VBA programmer advised me a bit more, and I'm now an
> enthusiast, about OO at least.  Not so much about the Visual flavors of
> Basic itself, but it was my introduction to OO and it is at least available
> on all Windows machines and in all MS Office apps, which is handy.
> >>
> >> What confuses me (so far) is the concept of addressability in HLASM.
> Every time I make a stab at writing my first assembler program I get a
> little closer, but I'm still not there yet.  In other assemblers I got
> quite familiar with indirect and offset addressing - it isn't that - but
> what exactly happens with the USING instruction still eludes me.
> >>
> >> ---
> >> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >>
> >> /* Revenge can be bitter-sweet.  But if you sit back and watch, karma
> can be pure entertainment.  -found on Facebook 2015 */
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Brennan
> >> Sent: Sunday, September 18, 2022 00:59
> >>
> >> As for programming, I seem to do better starting at the bottom, with
> instructions, registers, PSW bits and such, and moving up from there.
> Higher level languages and especially Object Oriented code tend to confuse
> me.
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> > --
> > Mike A Schwab, Springfield IL USA
> > Where do Forest Rangers go to get away from it all?
> >
> > --
> > 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, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Assembler courses

2022-09-18 Thread Tom Harper

Sometimes R15 contains the entry point. 

If the routine receives control from ATTACHX or LINKX, for instance, and if it 
is to run in AMODE(64), then it does not. 

A better solution is to use 

LARL R12,PROGNAME
USING PROGNAME, R12

which has no dependency on R15.

Tom Harper
Phoenix Software International 

Sent from my iPhone

> On Sep 18, 2022, at 5:06 PM, Mike Schwab  wrote:
> 
> When you enter a program, R15 points to the first byte of PROGNAME.
> You usually have a USING R15,PROGNAME.
> If you are going to be calling OS functions or programs, you will copy
> R15 to another register (often R12), issue a USING R12,PROGNAME and
> DROP R15,PROGNAME.  So when using a label within 4K of PROGNAME, the
> assembler will use the USING register, and compute the offset from
> PROGNAME.
> 
>> On Sun, Sep 18, 2022 at 8:12 AM Bob Bridges  wrote:
>> 
>> Twenty years ago I wrote a few programs for Excel, and didn't see what all 
>> the fuss was about: "object-oriented" didn't seem very different from 
>> traditional programming that I'd been doing for 25 years.  (At the same time 
>> I was frequently infuriated at the message "...does not support this 
>> property or method", exactly because I ~didn't~ understand what was 
>> different about OO coding.)
>> 
>> Eventually a VBA programmer advised me a bit more, and I'm now an 
>> enthusiast, about OO at least.  Not so much about the Visual flavors of 
>> Basic itself, but it was my introduction to OO and it is at least available 
>> on all Windows machines and in all MS Office apps, which is handy.
>> 
>> What confuses me (so far) is the concept of addressability in HLASM.  Every 
>> time I make a stab at writing my first assembler program I get a little 
>> closer, but I'm still not there yet.  In other assemblers I got quite 
>> familiar with indirect and offset addressing - it isn't that - but what 
>> exactly happens with the USING instruction still eludes me.
>> 
>> ---
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>> 
>> /* Revenge can be bitter-sweet.  But if you sit back and watch, karma can be 
>> pure entertainment.  -found on Facebook 2015 */
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Tom Brennan
>> Sent: Sunday, September 18, 2022 00:59
>> 
>> As for programming, I seem to do better starting at the bottom, with 
>> instructions, registers, PSW bits and such, and moving up from there. Higher 
>> level languages and especially Object Oriented code tend to confuse me.
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> -- 
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
> 
> --
> 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, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Net nanny voodoo [was: RE: Assembler courses]

2022-09-18 Thread Tony Harminc

On Sun, 18 Sept 2022 at 12:16, Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> Wow, talk about "nanny state" link protection - have a gander at the
> hugely complex mess that René's perfectly reasonable links to the IDCP and
> Marist copies of Mr. Ehrman's opus turned into below.  Someone else's web
> link safety filter added "https://nam11.safelinks.protection.outlook.com";
> around René's link and then my employer's filter added "
> https://urldefense.com/v3"; around that filter.
>
> I know it is important to keep the untrained masses from clicking on
> dangerous links, but this is getting really ridiculous.
>

As I've suggested here before, I think LSOFT could provide some good added
value by removing as many layers of this crud as possible - certainly for
anything that goes in the archives. The safelinks and urldefense ones
contain the original URL only lighly obfuscated, and so could be easily
dealt with. (In fact there is a site https://www.o365atp.com that
deobfuscates the Microsoft ones, and I think I've seen one also for
urldefense.com .)

I suppose they have to worry that someone will sue them if a "bad" URL
creeps through. The main thing that would suffer from inaccuracy is
discussions like this of these very problems!

Tony H.

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

Re: Assembler courses

2022-09-18 Thread Bob Bridges

You may be right; I've never had occasion to try write OO programs on the 
mainframe.  But when I write classes in VBA, I'm not thinking primarily of 
sending messages between GUI objects (though you may argue that's exactly what 
I'm doing whether I think of it that way or not); to me it seems that the chief 
value of classes and class methods is a way of organizing my subroutines and 
functions and limiting their scope to particular uses - which seems to me would 
be useful in some mainframe programs I write just as well as in Excel.

I gather some OO languages are available to OMVS users here; what do the rest 
of you say?

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

/* From four miles away, the scene was mystifying, surreal. The rocket moved -- 
it seemed to levitate, inching upward on a tower of incandescent fire -- but 
there was no sound, only the unsuspecting gulls wheeling in the silent sky. And 
then the surface of the lagoon in front of the press grandstand suddenly 
rippled as the shock wave flashed across, thudded into the chests of the 
spectators, shook the ground beneath their feet and filled their skulls with a 
crackling thunder that overwhelmed the atmosphere itself. To the million souls 
who watched dumbstruck as the great machine ascended, there could not have been 
the slightless doubt that this thing was leaving the planet.  -from "Angle of 
Attack", a description by Mike Gray of the launch of Apollo 11 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Sunday, September 18, 2022 12:53

Ah... Visual Basic.  OO certainly does make sense with Windows programming (and 
I assume other GUI's).  The idea of the GUI writers to send messages back and 
forth between "objects" is genius.  So each bit of code (say for a button or a 
text box object) just sits there doing nothing until a message is sent to it.  
But on other platforms, forcing me to turn something into a "class" that is 
just a bunch of subroutines and control blocks seems like more work than it's 
worth.

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

Re: Assembler courses

2022-09-18 Thread Mike Schwab

When you enter a program, R15 points to the first byte of PROGNAME.
You usually have a USING R15,PROGNAME.
If you are going to be calling OS functions or programs, you will copy
R15 to another register (often R12), issue a USING R12,PROGNAME and
DROP R15,PROGNAME.  So when using a label within 4K of PROGNAME, the
assembler will use the USING register, and compute the offset from
PROGNAME.

On Sun, Sep 18, 2022 at 8:12 AM Bob Bridges  wrote:
>
> Twenty years ago I wrote a few programs for Excel, and didn't see what all 
> the fuss was about: "object-oriented" didn't seem very different from 
> traditional programming that I'd been doing for 25 years.  (At the same time 
> I was frequently infuriated at the message "...does not support this property 
> or method", exactly because I ~didn't~ understand what was different about OO 
> coding.)
>
> Eventually a VBA programmer advised me a bit more, and I'm now an enthusiast, 
> about OO at least.  Not so much about the Visual flavors of Basic itself, but 
> it was my introduction to OO and it is at least available on all Windows 
> machines and in all MS Office apps, which is handy.
>
> What confuses me (so far) is the concept of addressability in HLASM.  Every 
> time I make a stab at writing my first assembler program I get a little 
> closer, but I'm still not there yet.  In other assemblers I got quite 
> familiar with indirect and offset addressing - it isn't that - but what 
> exactly happens with the USING instruction still eludes me.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Revenge can be bitter-sweet.  But if you sit back and watch, karma can be 
> pure entertainment.  -found on Facebook 2015 */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Tom Brennan
> Sent: Sunday, September 18, 2022 00:59
>
> As for programming, I seem to do better starting at the bottom, with 
> instructions, registers, PSW bits and such, and moving up from there. Higher 
> level languages and especially Object Oriented code tend to confuse me.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Net nanny voodoo [was: RE: Assembler courses]

2022-09-18 Thread Paul Gilmartin

On Sun, 18 Sep 2022 16:35:57 +, Seymour J Metz wrote:

>Net Nannies embody an advanced technology known as Artificial Stupidity (AS); 
>this same technology can be seen in rext to voice and voice to text features, 
>as well as in filters that block legitimate medical sites while failing to 
>block some pornographic sites. In this case I believe that the damage was 
>cause by the URL rewriting in GMU's email server. And, no, there is no way to 
>turn it off.
>
Where's rot13 when you need it?  And in days of yore I was accustomed to
seeing writers penetrate (euphemism) nannies by encrypting message bodies
and simply appending the decryption keys in the clear.

>Well thought out security measures are a blessing; shooting from the hip is a 
>curse. Sort of like auditors, when they are good they are very, very good, and 
>when they are bad they are horrid.
>
It would be less computational cost for nannies to verify blessed URLs and
pass them on untransformed.  But then they wouldn't be able to track the
recipients.  Similarly for URL shorteners: what's the likely business model
for providers of such services?

-- 
gil

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

Re: Net nanny voodoo [was: RE: Assembler courses]

2022-09-18 Thread Paul Gilmartin

On Sun, 18 Sep 2022 18:51:56 +, Robert Prins wrote:

>And ahem, human (self-censored) is not trimming the whole fluckin' mess
>when you reply to posts.
>
Ergonomics.  It wastes time and energy to press the Delete key
so many times.

And it may be illegal to remove the originator's legal notice or to
provide a quotation out of context.  And some readers are unaware
of the Archives.

-- 
gil

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

Re: Net nanny voodoo [was: RE: Assembler courses]

2022-09-18 Thread Robert Prins

And ahem, human (self-censored) is not trimming the whole fluckin' mess
when you reply to posts.

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


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

Re: Assembler courses

2022-09-18 Thread Tom Brennan

Ah... Visual Basic.  OO certainly does make sense with Windows 
programming (and I assume other GUI's).  The idea of the GUI writers to 
send messages back and forth between "objects" is genius.  So each bit 
of code (say for a button or a text box object) just sits there doing 
nothing until a message is sent to it.  But on other platforms, forcing 
me to turn something into a "class" that is just a bunch of subroutines 
and control blocks seems like more work than it's worth.


On 9/18/2022 6:11 AM, Bob Bridges wrote:

Twenty years ago I wrote a few programs for Excel, and didn't see what all the fuss was about: 
"object-oriented" didn't seem very different from traditional programming that I'd been 
doing for 25 years.  (At the same time I was frequently infuriated at the message "...does not 
support this property or method", exactly because I ~didn't~ understand what was different 
about OO coding.)

Eventually a VBA programmer advised me a bit more, and I'm now an enthusiast, 
about OO at least.  Not so much about the Visual flavors of Basic itself, but 
it was my introduction to OO and it is at least available on all Windows 
machines and in all MS Office apps, which is handy.

What confuses me (so far) is the concept of addressability in HLASM.  Every 
time I make a stab at writing my first assembler program I get a little closer, 
but I'm still not there yet.  In other assemblers I got quite familiar with 
indirect and offset addressing - it isn't that - but what exactly happens with 
the USING instruction still eludes me.

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

/* Revenge can be bitter-sweet.  But if you sit back and watch, karma can be 
pure entertainment.  -found on Facebook 2015 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Sunday, September 18, 2022 00:59

As for programming, I seem to do better starting at the bottom, with 
instructions, registers, PSW bits and such, and moving up from there. Higher 
level languages and especially Object Oriented code tend to confuse me.

--
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: Net nanny voodoo [was: RE: Assembler courses]

Net Nannies embody an advanced technology known as Artificial Stupidity (AS); 
this same technology can be seen in rext to voice and voice to text features, 
as well as in filters that block legitimate medical sites while failing to 
block some pornographic sites. In this case I believe that the damage was cause 
by the URL rewriting in GMU's email server. And, no, there is no way to turn it 
off.

Well thought out security measures are a blessing; shooting from the hip is a 
curse. Sort of like auditors, when they are good they are very, very good, and 
when they are bad they are horrid.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, September 18, 2022 12:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Net nanny voodoo [was: RE: Assembler courses]

Wow, talk about "nanny state" link protection - have a gander at the hugely 
complex mess that René's perfectly reasonable links to the IDCP and Marist 
copies of Mr. Ehrman's opus turned into below.  Someone else's web link safety 
filter added "https://nam11.safelinks.protection.outlook.com"; around René's 
link and then my employer's filter added " 
https://secure-web.cisco.com/1CV3RpwL6t7MZPGZcN8Utx2gCZKqPLTx1iFGwVkGWpgYveQ8nayN6dvptBZ_hyoVz-pRMje8ao7ZpGAXg_FJ4jhfoMfQ_40PFkOLJ58f7CFq2tqV8hN3VexA6QuDwJKoLcD0BJ-dvkop6qquiDoLC1rJPi4r1BEnyNAkT46LWdDBlUlRyV70ODznIQwitABH-2J0UO9daQCY_VAZ1rhYajV7DGnxa9n_cv5nOyo2RoDP_8eDFc1BFcEkPfgumQkJghZToYtb_HKDBxsXmX8DMb97NepIJYjGl-0w2DMr-3sjyFW2Dxes9uNPzm9X1-KFcVFjZhl6RezQrPKpWixz1VZ2O4GKWRjOK2hdWCvK2kmeIJt8N3x1Kk6TFU4MnNGOw_9NRanzQl7LM3vsmbxCQCIRCs27-kmk_FGvl0v3WvfYauFrAVYNK4euY9UdpiXqrHCEAnCiZNWDN-hJ08HzhMQ/https%3A%2F%2Furldefense.com%2Fv3";
 around that filter.

I know it is important to keep the untrained masses from clicking on dangerous 
links, but this is getting really ridiculous.

Strangely, I can only see René's actual email to the list on the IBM-MAIN 
archive.  I never received it here, and it did not wind up in my employer's 
email filter cache (off-prem quarantine of just plain junk and actually 
dangerous emails).  I only received Seymour's response to René's message.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, September 18, 2022 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler courses

I haven't read it, but surely nobody could question the credentials of the 
author (ז״ל). I miss him.

--
Shmuel (Seymour J.) Metz
https://secure-web.cisco.com/11HIy9-D0NNoIroFkGAgm9wFzXjVNB-0r0G3BobT9Fmi5Vx7wlaGVjd-zEg4r_CHMrF5Sx-JYAa4Lm3ouhBAcBU5xncOzedYpQv18SRk4mjIiW6O6qNXBksUfdF8x7WTLjfoHoSrliXT829YTLzk57tbJIT2YYrwi9bRjvV0jyn68vW6rRiUoaG-gGWNfguiq-cRhPL04bUPY29Tj9Y2aND49VbZZa9ZcGBdf-XPj-qfZjp0YdbUGaNnwXUQCwa-Bpdo0GmQyQp1dkSX_7MdW5SQF7WzdGECuXWy9WVY61W1ctD5VS4Ka5wummd3keeaHeaFg0Y1-Q5-rF0i2P_J8NyAPejoT7BRh3dsZ_tw-CxHunKG7xmpy8ZohpsAIwIm7hs-rUiU_SUrmk9kGSMsPs_DwtDsr-Qkw5pK2gh1iBjKz0Pltya9HjlzC1zDxm3IfIb1gxTWa-rESXzBfVatHoA/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fmason.gmu.edu%2F%2Asmetz3__%3Bfg%21%21Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg%21ImPNbMPUrUVpkPeOd2RbYZN1oF-ZEdWfIW9gt1rwgJYYfJKHkammPPpw_A4YtbGJGiCOG2-BZIOB8Q4AmqG0LA%24


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
René Jansen [rene.vincent.jan...@gmail.com]
Sent: Sunday, September 18, 2022 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler courses

I don’t know if someone on the assembler list mentioned this already, but 
https://secure-web.cisco.com/1XRm4nx9OjGCoTXFTwQ9_ryvBzB3Vi6bvgTSf0L36Us2w7mNS3nUvU6kC9GlIb0sieZjIM2gygrNcL7yuoQkzaq6E3ns1-YHo0DWYgKKBwoavzLGg3U6IOzH4c_hLFrm-XufhT2y9-VWNEuLdie2mOCBNl_9KJGvx390uCwljuA55p8-O2m6CQZqS-aedy-uAgJl-lammHDE1B-PK2eUUrxzW8XJ0LRpOMr-BM1Y1UXZ0iJHZjzTDS3UCjCWfut-O7dtkDGHhTfyHm73BjP0G6BsaEjsuhxcOM0yLWAevRHIP5EcLxGi6mNS9G9GutjNn3A3M7IxrPnngVzY-XeiicdzV-t3eRwTLzyxIkpaGOSXYkaLndqMAuagieP6gQrWUxP1q0b_m8R1e3IrRNNJjTyDwREY9dxoJlu-RKmvzDuMwCKZAL88uaFoZ9vGp1otNbpU1MoK8_IfKx9XY2x8tuQ/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%2A3A%2A2F%2A2Fidcp.marist.edu%2A2Fdocuments%2A2F33945%2A2F44724%2A2FAssembler.V2.alntext%2A2BV2.00.pdf%2A2Fad61965e-8485-65e1-f385-e5cd56f08c63%2A3Ft%2A3D1551806232272%26data%3D05%2A7C01%2A7Csmetz3%2A40gmu.edu%2A7Ca8141b8f50784d579bf208da9978d579%2A7C9e857255df574c47a0c00546460380cb%2A7C0%2A7C0%2A7C637991043314749524%2A7CUnknown%2A7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%2A3D%2A7C3000%2A7C%2A7C%2A7C%26sdata%3Dc0XkXdhzNBoLf%2A2Bu1AjGbrI9WXLtivAFVMotq8J32cc0%2A3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%21%21Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg%21ImPN

Net nanny voodoo [was: RE: Assembler courses]

2022-09-18 Thread Farley, Peter x23353

Wow, talk about "nanny state" link protection - have a gander at the hugely 
complex mess that René's perfectly reasonable links to the IDCP and Marist 
copies of Mr. Ehrman's opus turned into below.  Someone else's web link safety 
filter added "https://nam11.safelinks.protection.outlook.com"; around René's 
link and then my employer's filter added " https://urldefense.com/v3"; around 
that filter.

I know it is important to keep the untrained masses from clicking on dangerous 
links, but this is getting really ridiculous.

Strangely, I can only see René's actual email to the list on the IBM-MAIN 
archive.  I never received it here, and it did not wind up in my employer's 
email filter cache (off-prem quarantine of just plain junk and actually 
dangerous emails).  I only received Seymour's response to René's message.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, September 18, 2022 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler courses

I haven't read it, but surely nobody could question the credentials of the 
author (ז״ל). I miss him.

--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!ImPNbMPUrUVpkPeOd2RbYZN1oF-ZEdWfIW9gt1rwgJYYfJKHkammPPpw_A4YtbGJGiCOG2-BZIOB8Q4AmqG0LA$
  


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
René Jansen [rene.vincent.jan...@gmail.com]
Sent: Sunday, September 18, 2022 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler courses

I don’t know if someone on the assembler list mentioned this already, but 
https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fidcp.marist.edu*2Fdocuments*2F33945*2F44724*2FAssembler.V2.alntext*2BV2.00.pdf*2Fad61965e-8485-65e1-f385-e5cd56f08c63*3Ft*3D1551806232272&data=05*7C01*7Csmetz3*40gmu.edu*7Ca8141b8f50784d579bf208da9978d579*7C9e857255df574c47a0c00546460380cb*7C0*7C0*7C637991043314749524*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=c0XkXdhzNBoLf*2Bu1AjGbrI9WXLtivAFVMotq8J32cc0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!ImPNbMPUrUVpkPeOd2RbYZN1oF-ZEdWfIW9gt1rwgJYYfJKHkammPPpw_A4YtbGJGiCOG2-BZIOB8Q6vStHKog$
   
<https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fidcp.marist.edu*2Fdocuments*2F33945*2F44724*2FAssembler.V2.alntext*2BV2.00.pdf*2Fad61965e-8485-65e1-f385-e5cd56f08c63*3Ft*3D1551806232272&data=05*7C01*7Csmetz3*40gmu.edu*7Ca8141b8f50784d579bf208da9978d579*7C9e857255df574c47a0c00546460380cb*7C0*7C0*7C637991043314749524*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=c0XkXdhzNBoLf*2Bu1AjGbrI9WXLtivAFVMotq8J32cc0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!ImPNbMPUrUVpkPeOd2RbYZN1oF-ZEdWfIW9gt1rwgJYYfJKHkammPPpw_A4YtbGJGiCOG2-BZIOB8Q6vStHKog$
  > should be everything you need, and it’s free! Plus other resources on 
https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fidcp.marist.edu*2Fassembler-resources&data=05*7C01*7Csmetz3*40gmu.edu*7Ca8141b8f50784d579bf208da9978d579*7C9e857255df574c47a0c00546460380cb*7C0*7C0*7C637991043314749524*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=fIPsXHRJZ4VJO1kJdZzNvg*2FZCiI63Nb1yEpcTW49QQo*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!ImPNbMPUrUVpkPeOd2RbYZN1oF-ZEdWfIW9gt1rwgJYYfJKHkammPPpw_A4YtbGJGiCOG2-BZIOB8Q4zauEFww$
   
<https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fidcp.marist.edu*2Fassembler-resources&data=05*7C01*7Csmetz3*40gmu.edu*7Ca8141b8f50784d579bf208da9978d579*7C9e857255df574c47a0c00546460380cb*7C0*7C0*7C637991043314749524*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=fIPsXHRJZ4VJO1kJdZzNvg*2FZCiI63Nb1yEpcTW49QQo*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!ImPNbMPUrUVpkPeOd2RbYZN1oF-ZEdWfIW9gt1rwgJYYfJKHkammPPpw_A4YtbGJGiCOG2-BZIOB8Q4zauEFww$
  >.

Actually, it is so good that I tried to get the bookie source to modernise it a 
bit - make it searchable etc. I called John’s old boss and department … but 
it’s complicated …

Best regards,.

René.

> On 18 Sep 2022, at 15:11, Bob Bridges  wrote:
>
> Twenty years ago I wrote a few programs for Excel, and didn't see what 
> all the fuss was about: "object-oriented" didn't seem very different 
> from traditional programming that I'd been doing for 25 years.  (A

Re: Assembler courses

I've been around longer than that and have needed assembler in every job I've 
had, although there were a few short assignments that didn't require any 
assembler. YMMV/


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
T Roller [044ef325f6c3-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, September 17, 2022 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler courses

Learning assembler is like taking latin in high school. It might help you on 
Jeopardy but will not be of much help in real life. I took assembler in college 
& never used it and never worked at an employer that used it. That’s a dozen+ 
employers over 45 years.

Sent from Proton Mail for iOS

On Fri, Sep 16, 2022 at 10:11 PM, Gary Weinhold  wrote:

> To help a person who has COBOL and C language experience learn to write 
> assembler, I would like them to learn from the start both reentrant and 
> baseless coding techniques. Is there training available that assumes the 
> instruction set available on the z12 is the starting point and that teaches 
> reentrancy as the norm?
>
> (Cross-posted to IBM-Main and Assembler-list)
>
> Gary Weinhold
> Senior Application Architect
> DATAKINETICS | Data Performance & Optimization
> Phone:+1.613.523.5500 x216
> Email: weinh...@dkl.com
> Visit us online at 
> http://secure-web.cisco.com/1vqA2k6CTgjgg8mhdlf0YZ5DHsld_L3DqnLcBlHddEtmoI3aDgNAilQVnecYxA_qQtHy_d5QfsfSuV-yiqQLIm68Ggw5L5DKnFgzxb_HhgXnFWAirGJn0gYYsSYrztoyjqh1kZBN7tW_nor9miGMNOktiK8UmQ0_HMkAtTdkZ0hHQHmmbcBxMmNeFkA7BOSc_RpKx2XnUgjL3OoZ9dABlJQOfakUt4eAQtGZraFOzuu8dJzsbYzfIp-cP510meJ6ZaX3TtthhGal__CXieb8Pgge07M0AWhdGQAUeui6XyQmbJqNkLxBi9y_L5dKl8_rKug1GDjQX9WmaX3vTxeNPEVDweYwSxQcPYGZ3bsw57hPxAjpiTRO4eUMp-jAlzhCEj0d0FcAz6TkAttsZ4Mab1VZiudeb_yGNHwJbOa40M9aBjylkobPyUvElGpVAqHSM/http%3A%2F%2Fwww.DKL.com
> E-mail Notification: The information contained in this email and any 
> attachments is confidential and may be subject to copyright or other 
> intellectual property protection. If you are not the intended recipient, you 
> are not authorized to use or disclose this information, and we request that 
> you notify us by reply mail or telephone and delete the original message from 
> your mail 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: Assembler courses

Pascal doesn't have associative arrays. Perhaps you are thinking of Delphi?

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

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Saturday, September 17, 2022 5:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler courses

Never used PASCAL?  I'm surprised.  I haven't learned it yet, but when I first 
heard about it (it had associative arrays, which I thought of as pretty darned 
cool) I was fascinated.  But for the first few years it was all BASIC, PL/1, a 
little FORTRAN.  Later it was all COBOL and CLIST.  Nowadays it's all REXX and 
various flavors of Visual Basic.  Though I've never learned it myself, I had 
the impression that PASCAL is in pretty wide use.

I bought myself a C compiler at one point, but tried it and never took it up 
again; didn't like all the up-front code that had to be in a program for it to 
run.

(My very first employer handed me a task to write a Backgammon game in FORTRAN. 
 It turns out I like writing such things, and my ancient memory tells me the 
program I wrote played pretty well.  I never did figure out why in the world 
they wanted it, though.  And it occurs to me now that maybe they meant only a 
program that would allow two humans to play against each other.)

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

/* Justice: When you get what you deserve
Mercy: When you don't get what you deserve
Grace: When you get what you don't deserve */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Saturday, September 17, 2022 17:38

My GE 1101 (1st level Gen Engineering) class was PASCAL programming on a 
DecSystem running TOPS20.

Never used it again.

--- On Sat, Sep 17, 2022 at 3:55 PM Brian Westerman < 
brian_wester...@syzygyinc.com> wrote:
> ME Too!!   I can't remember ever using my Fortran after the class was
> over.  Luckily the instructor also offered an assembler class that he
> taught "on the side" for an extra $50.  I still use the stuff he
> taught us almost every day.
>
> --- On Sat, 17 Sep 2022 19:29:01 +, Farley, Peter x23353 <
> >I learned assembler early via OJT at one of my first permanent jobs, and
> got to use it more and more as I moved to other employers.  Knowing
> assembler got me in the door at more than one of those employers.
> >
> >It was the FORTRAN I learned in engineering college that I never used
> anywhere else.

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

The OO concepts might be clearer in, e.g., ooREXX, Smalltalk.

USING is a pseudo-op that tells the assembler how to translate between a 
symbolic address and a base-displacement pair. In its simplest form it is only 
a promise that particular registers will point to particular addresses. It's 
probably best that you master that form before trying dependent and labelled 
USING, but I strongly urge you to learn those as well.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Sunday, September 18, 2022 9:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler courses

Twenty years ago I wrote a few programs for Excel, and didn't see what all the 
fuss was about: "object-oriented" didn't seem very different from traditional 
programming that I'd been doing for 25 years.  (At the same time I was 
frequently infuriated at the message "...does not support this property or 
method", exactly because I ~didn't~ understand what was different about OO 
coding.)

Eventually a VBA programmer advised me a bit more, and I'm now an enthusiast, 
about OO at least.  Not so much about the Visual flavors of Basic itself, but 
it was my introduction to OO and it is at least available on all Windows 
machines and in all MS Office apps, which is handy.

What confuses me (so far) is the concept of addressability in HLASM.  Every 
time I make a stab at writing my first assembler program I get a little closer, 
but I'm still not there yet.  In other assemblers I got quite familiar with 
indirect and offset addressing - it isn't that - but what exactly happens with 
the USING instruction still eludes me.

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

/* Revenge can be bitter-sweet.  But if you sit back and watch, karma can be 
pure entertainment.  -found on Facebook 2015 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Sunday, September 18, 2022 00:59

As for programming, I seem to do better starting at the bottom, with 
instructions, registers, PSW bits and such, and moving up from there. Higher 
level languages and especially Object Oriented code tend to confuse me.

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