Re: z/OSMF PSWI

[Ed Jaffe]

On 9/24/2022 9:37 PM, Brian Westerman wrote:

... or when they try to do a accept and find that they have many of their DLIB 
datasets already in 16 extents.


I know there are target libraries that must be PDS as opposed to PDSE, 
but can the same be said of distribution libraries?


So far, I have not run across any distribution libraries that didn't 
work better as a PDSE, giving me both zEDC compression and up to 123 
extents.


--
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: z/OSMF PSWI

[Brian Westerman]

I think that the developers of z/OSMF have either forgotten or didn't care that 
after the installation, there will be far more customization which moves from 
the "might want to do" column to the "must do" column.  Something as simple as 
having a system that the size of the datasets fit when you first install only 
means that later (when you need the extra space), that the simple process of 
giving it some extra in advance, will become a failure which has to be resolved 
later.  

Making it "simple" to install but far harder to maintain is counter productive. 
 Unless your only object is to install. :)

Someone who can't figure out how to make a dataset larger (or in the cast of 
z/OSMF aren't allowed to), will find it infinitely more difficult later when 
SYS1.NUCLEUS goes into extents and they can no longer IPL.  Or when they try to 
install maintenance and they run out of space in libraries on the RES volume, 
or when they try to do a accept and find that they have many of their DLIB 
datasets already in 16 extents.  

I don't see how z/OSMF is making things all that much "easier" by disallowing 
them.

Brian

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

Re: System parmlib concat

[Brian Westerman]

Cool,

Thank you both very much.

Brian

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

Re: Assembler courses

[David Crayford]

On 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

[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=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: z/OS ISPF Git Interface (ZIGI) Version 3.15 Released

[Wayne Bickerdike]

Thanks David.

On Sun, Sep 25, 2022 at 12:11 PM David Crayford  wrote:

> There are no tar files anymore Wayne. You need to use conda unless you
> have enterprise support where you can use SMP/E.
>
>
> https://community.rocketsoftware.com/forums/forum-home/digestviewer/viewthread?GroupId=79=8cde99be-0255-49f5-87e6-e59b4016f965=1e694975-142d-4f2d-9b52-0e37e225db41=digestviewer#bm8cde99be-0255-49f5-87e6-e59b4016f965
>
> On 25/09/2022 7:19 am, Wayne Bickerdike wrote:
> > Trying the Zigi update. During the install says I need updated versions
> of
> > bash, perl, gzip etc. On the Rocket download site I can't find the .tar
> > files.
> >
> > Can someone point me to the correct location? Thanks.
> >
> > On Tue, Sep 13, 2022 at 12:28 AM Lionel B. Dyck 
> wrote:
> >
> >> We have released version 3.15 of ZIGI - the z/OS ISPF Git Interface.
> >>
> >> You can find it at
> >>   - https://zigi.rocks
> >> or
> >> - https://cbttape.org/ftp/updates/CBT997.zip
> >>
> >> Enjoy
> >>
> >> Lionel B. Dyck <><
> >> Website: https://www.lbdsoftware.com
> >> Github: https://github.com/lbdyck
> >>
> >> “Worry more about your character than your reputation. Character is what
> >> you
> >> are, reputation merely what others think you are.”   - - - John Wooden
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: Assembler courses

[David Crayford]

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=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: z/OS ISPF Git Interface (ZIGI) Version 3.15 Released

[David Crayford]

There are no tar files anymore Wayne. You need to use conda unless you 
have enterprise support where you can use SMP/E.


https://community.rocketsoftware.com/forums/forum-home/digestviewer/viewthread?GroupId=79=8cde99be-0255-49f5-87e6-e59b4016f965=1e694975-142d-4f2d-9b52-0e37e225db41=digestviewer#bm8cde99be-0255-49f5-87e6-e59b4016f965

On 25/09/2022 7:19 am, Wayne Bickerdike wrote:

Trying the Zigi update. During the install says I need updated versions of
bash, perl, gzip etc. On the Rocket download site I can't find the .tar
files.

Can someone point me to the correct location? Thanks.

On Tue, Sep 13, 2022 at 12:28 AM Lionel B. Dyck  wrote:


We have released version 3.15 of ZIGI - the z/OS ISPF Git Interface.

You can find it at
  - https://zigi.rocks
or
- https://cbttape.org/ftp/updates/CBT997.zip

Enjoy

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

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

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





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

Re: Assembler courses

[David Crayford]

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

[David Crayford]

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: z/OS ISPF Git Interface (ZIGI) Version 3.15 Released

[Wayne Bickerdike]

Trying the Zigi update. During the install says I need updated versions of
bash, perl, gzip etc. On the Rocket download site I can't find the .tar
files.

Can someone point me to the correct location? Thanks.

On Tue, Sep 13, 2022 at 12:28 AM Lionel B. Dyck  wrote:

> We have released version 3.15 of ZIGI - the z/OS ISPF Git Interface.
>
> You can find it at
>  - https://zigi.rocks
> or
> - https://cbttape.org/ftp/updates/CBT997.zip
>
> Enjoy
>
> Lionel B. Dyck <><
> Website: https://www.lbdsoftware.com
> Github: https://github.com/lbdyck
>
> “Worry more about your character than your reputation. Character is what
> you
> are, reputation merely what others think you are.”   - - - John Wooden
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: Assembler courses

[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

[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

[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

[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

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

[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: z/OSMF PSWI

[Colin Paice]

I remember working on a project which was told "you have to provide a GUI
to make it easier to customize".  A GUI was provided which made the easy
bits easier, and left the hard bits unchanged.  The GUI provided space for
1 VOLID - but most people needed multiple VOLIDs
My suggestions to change the configuration JCL to use JCL symbols, and have
these symbols in the DEFINE CLUSTER... etc was much easier to use, but did
not meet the spec of  providing a  GUI.  It ended up with the end user
having to use the GUI, saving the JCL, then editing the JCL so it worked.

On Sat, 24 Sept 2022 at 15:26, Tom Longfellow <
03e29b607131-dmarc-requ...@listserv.ua.edu> wrote:

> I am agreeing with Brian on some of his points.   I am viewing this issue
> with 20+ years of hindsight.
>
> What I see is that z/OSMF development is following the same path as all of
> the other 'lets get modern' projects.   You pick the pretty GUI you like
> and start applying that toolset against a currently working 'solved'
> problem.   Promising modernization according to latest hot topics in code
> development.
> Buzzwords come and go, languages come and go, software development kits
> come and go ad infinitum.
>
> What tends to be forgotten are all the time and effort spent on building
> the solution to the old solved problem.   I can remember many discussions
> here and elsewhere about ServerPac changes and difficulties that could
> benefit by more development changes.
>
> Who remembers all the IBM and OEM 'assistance' products created to buffer
> us poor feeble support teams from the evils of SMP or SMP/E.
>
> z/OSMF is just the latest way to 'dumb down' the complexities for the
> masses.But then reality steps in.   Somebody, Somewhere HAS to know
> what has to happen when the rubber meets the road.   And navigating from
> the GUI through the stack of products to get to the Road is a long and
> twisted path.
>
> IF (a big IF) you think the same way the GUI developer thinks, then life
> can get smoother.  Any attempt to repeat the processes that were repeatable
> and  have worked before will meet resistance.
>
> With the removal of old options like ServerPac and being forced to the new
> paradigm  of z/OSMF will eventually lead to a better z/OSMF tool.  But lood
> for years of development just like ServerPac needed to achieve its
> popularity.
>
> [End of Rant  For Now]
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Assembler courses

[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: z/OSMF PSWI

[Tom Longfellow]

I am agreeing with Brian on some of his points.   I am viewing this issue with 
20+ years of hindsight.

What I see is that z/OSMF development is following the same path as all of the 
other 'lets get modern' projects.   You pick the pretty GUI you like and start 
applying that toolset against a currently working 'solved' problem.   Promising 
modernization according to latest hot topics in code development.
Buzzwords come and go, languages come and go, software development kits come 
and go ad infinitum.

What tends to be forgotten are all the time and effort spent on building the 
solution to the old solved problem.   I can remember many discussions here and 
elsewhere about ServerPac changes and difficulties that could benefit by more 
development changes.   

Who remembers all the IBM and OEM 'assistance' products created to buffer us 
poor feeble support teams from the evils of SMP or SMP/E.  

z/OSMF is just the latest way to 'dumb down' the complexities for the masses.   
 But then reality steps in.   Somebody, Somewhere HAS to know what has to 
happen when the rubber meets the road.   And navigating from the GUI through 
the stack of products to get to the Road is a long and twisted path.

IF (a big IF) you think the same way the GUI developer thinks, then life can 
get smoother.  Any attempt to repeat the processes that were repeatable and  
have worked before will meet resistance.   

With the removal of old options like ServerPac and being forced to the new 
paradigm  of z/OSMF will eventually lead to a better z/OSMF tool.  But lood for 
years of development just like ServerPac needed to achieve its popularity.

[End of Rant  For Now]


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

Re: System parmlib concat

[Joe Monk]

"The SYS1.PARMLIB data set itself can be blocked and can have multiple
extents, but it must reside on a single volume. The parmlib concatenation
used at IPL must be a PDS. However, after IPL you may issue a SETLOAD
command to switch to a different parmlib concatenation which contains
PDSEs."

https://www.ibm.com/docs/en/zos/2.5.0?topic=time-description-use-parmlib-concatenation

Joe

On Fri, Sep 23, 2022 at 11:04 PM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> Hi,
>
> I was asked a question today that I have no idea what to answer to it.  I
> was asked if it is possible or advisable to change the system parmlibs from
> PDS to PDSE and if there was nay benefit to doing it.
>
> My first reaction was that it would be a bad idea, and that PDSe's might
> not be supported at actual IPL, but I'm not aware of any real
> restrictions.  I know that they are supported later int he IPL process, but
> I have zero idea if you can make the system parmlib a PDSE.
>
> Does anyone know if it's allowed or where I would find information on if
> it's disallowed and why?
>
> It's not vitally important, but it has been bugging me since I was asked
> earlier today.
>
> Brian
>
> --
> 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

[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