Re: Unzip on z/OS ?

[Tom Brennan]

Thanks... I've used __asm with Windows C compilers, so I figured it was 
available on the mainframe too, but I didn't want to say anything since 
I didn't know for sure.


On 4/4/2023 8:17 PM, David Crayford wrote:

It certainly is possible using inline "__asm" blocks. Check out IBM's 
zoslib which has a really load/call/delete functions that can also AMODE 
switch 


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

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

[Bill Johnson]

I remember this.
David Crayford said:
”I'm calling BS. None of the challenger banks (Startling, Yolt, Monzo, Moneze, 
N26 etc) run mainframes. They have millions of customers and are gaining 
millions by the week at the expense of traditional banks.”




My response

Most of those “banks” aren’t banks and most of them are kaput.




How’s those challenger banks doing?
YOLT = owned by ING (who runs a mainframe) is being shut down.MONZO = CEO 
jumped ship. Not going well.N26 = pulled out of the US.

MONEZE = actually spelled MONESE. Doesn’t look like they are replacing JP 
Morgan any time soon.STARLING = tiny barely staying viable.
Many are charging fees now. Amazing that investors always want some revenue 
(and eventually profit) to justify the investment.
Having millions of mostly poor customers isn’t exactly a booming business model.
So I’ll repeat. 95% of banks use the mainframe. Not these fake banks.





Sent from Yahoo Mail for iPhone


On Monday, March 27, 2023, 11:33 PM, Bill Johnson 
<0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

You said internet banking was going to destroy large banks. How’s that working 
out?
Microfocus COBOL isn’t regular COBOL. And is a tiny fraction of the COBOL 
market.


Sent from Yahoo Mail for iPhone


On Monday, March 27, 2023, 11:26 PM, David Crayford  wrote:

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

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

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

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


>
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, March 27, 2023, 1:56 AM, Farley, Peter 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
> I am getting increasingly tired of snide or outright dismissive references to 
> COBOL and by extension to COBOL programmers.
>
> Programmers like me.
>
> Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
> SORT (at least as far as knowing and using JOIN's), SQL, JCL and various 
> other z/OS utilities, MetalC, and lately python and bash scripting.  I even 
> remember some of the PL/I and Fortran and Pascal I used in college and my 
> early employment days.  I even remember some SNOBOL, which I actually got to 
> use productively at a then-major NY bank very early in my career.
>
> COBOL pays my bills and keeps my employer operating successfully and 
> profitably.
>
> COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
> substances can, in fact, do that.  Intelligently devising business solutions 
> to business problems in ANY computer language does NOT rot the brain.
>
> It is not funny or acceptable to say so.  It never was.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Paul Gilmartin
> Sent: Sunday, March 26, 2023 8:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ASM call by value
>
> On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:
>
> 
>
>> In COBOL, for example, the following end up doing the same thing.
>>
> Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
> brain.
>
> --
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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




--
For IBM-MAIN subscribe / signoff / archive access i

Re: Unzip on z/OS ?

[David Crayford]

On 5/4/23 09:43, Bernd Oppolzer wrote:

Am 04.04.2023 um 23:37 schrieb Charles Mills:
I just had a similar problem: "how do you determine your entry R0 
from C?" I asked here and got no answer.


with native C, this is not possible IMO;


It certainly is possible using inline "__asm" blocks. Check out IBM's 
zoslib which has a really load/call/delete functions that can also AMODE 
switch 
https://github.com/ibmruntimes/zoslib/blob/cc10b7c1d6211a2c28b10b540bf406c7148fbf4f/src/zos.cc#L1946





what I did: I wrote a (very small) ASSEMBLER routine which can be 
called from everywhere and simply stores
the actual values of the registers 0 to 15 in a vector of 16 void 
pointers passed by the C caller.


something like

extern void ccregs (void **regs);

void *regtable [16];

...

ccregs (regtable);

this way, you get - for example - regtable [13], which is the content 
of GR 13 at the time of the ccregs call.
GR 13 points to the current save area a.k.a. stack frame. From this 
save area, you can walk up to the
save area of the caller and find the registers at the time of the call 
of the current function ... this can
all be done using C. It is, BTW, even possible to analyse the whole 
save area chain this way,
including the names and addresses etc. of the surrounding stack 
frames, and the entry point,
return addresses and so on ... a complete stack trace, if you want. 
All this can be done during program run,

without interrupting or abending the current process or function.

Finding the R0 at the time of the call is very simple, once you have 
the current R13.


HTH, kind regards

Bernd

--
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: Unzip on z/OS ?

[Bernd Oppolzer]

Found it, from 1996 :-)

 TITLE 'CCREGS - REGISTERSTAENDE VON C AUS ERMITTELN'
*
**
**
  
 PROGRAMM:  C C R E G S   
 PROGRAMMIERER: OPP   
 DATUM: 09.96 
  
 PROGRAMMBESCHREIBUNG:    
  
 AKTUELLE REGISTERSTAENDE INNERHALB EINES 
 C-MODULS ERMITTELN   
  
 DIE FUNKTION CCREGS ERHAELT ZWEI PARAMETER:  
  
 - EINEN ZEIGER AUF EINEN VEKTOR AUS 16 ZEIGERN   
   FUER DIE AUFNAHME DER REGISTER 0 BIS 15    
  
 - EINEN ZEIGER AUF EINEN VEKTOR AUS 4 DOUBLES    
   FUER DIE GLEITKOMMAREGISTER 0, 2, 4 UND 6  
  
 C-DEKLARATION: int ccregs (void **, double *);   
  
**
**
*
CCREGS   CSECT
*
R0   EQU   0
R1   EQU   1
R2   EQU   2
R3   EQU   3
R4   EQU   4
R5   EQU   5
R6   EQU   6
R7   EQU   7
R8   EQU   8
R9   EQU   9
RA   EQU   10
RB   EQU   11
RC   EQU   12
RD   EQU   13
RE   EQU   14
RF   EQU   15
*
 USING CCREGS,RF
 B WEITER  UEBERSPRINGEN DER KENNUNG
 DC    AL1(23)
 DC    CL23'CCREGS  /&SYSDATE/&SYSTIME'
*
WEITER   DS    0H
 STM   RE,RC,12(RD)    REGISTER SICHERN
 LR    RB,RF   BASISREGISTER 11 SETZEN
 DROP  RF
 USING CCREGS,RB
*
 L R2,0(R1)
 MVC   0(52,R2),20(RD) REGISTER 0 BIS 12 AUS SAVEAREA
 ST    RD,52(R2)   REGISTER 13
 MVC   56(8,R2),12(RD) REGISTER 14 UND 15 AUS SAVEAREA
*
 L R2,4(R1)
 STD   0,0(R2) GLEITKOMMAREGISTER NULL
 STD   2,8(R2) BIS SECHS
 STD   4,16(R2)
 STD   6,24(R2)
*
 LM    RE,RC,12(RD)    REGISTER ZURUECKLADEN
 XR    RF,RF
 BR    RE
*
 END   CCREGS


Am 05.04.2023 um 03:43 schrieb Bernd Oppolzer:

Am 04.04.2023 um 23:37 schrieb Charles Mills:
I just had a similar problem: "how do you determine your entry R0 
from C?" I asked here and got no answer.


with native C, this is not possible IMO;

what I did: I wrote a (very small) ASSEMBLER routine which can be 
called from everywhere and simply stores
the actual values of the registers 0 to 15 in a vector of 16 void 
pointers passed by the C caller.


something like

extern void ccregs (void **regs);

void *regtable [16];

...

ccregs (regtable);

this way, you get - for example - regtable [13], which is the content 
of GR 13 at the time of the ccregs call.
GR 13 points to the current save area a.k.a. stack frame. From this 
save area, you can walk up to the
save area of the caller and find the registers at the time of the call 
of the current function ... this can
all be done using C. It is, BTW, even possible to analyse the whole 
save area chain this way,
including the names and addresses etc. of the surrounding stack 
frames, and the entry point,
return addresses and so on ... a complete stack trace, if you want. 
All this can be done during program run,

without interrupting or abending the current process or function.

Finding the R0 at the time of the call is very simple, once you have 
the current R13.


HTH, kind regards

Bernd

--
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: Unzip on z/OS ?

[Bernd Oppolzer]

Am 04.04.2023 um 23:37 schrieb Charles Mills:

I just had a similar problem: "how do you determine your entry R0 from C?" I 
asked here and got no answer.


with native C, this is not possible IMO;

what I did: I wrote a (very small) ASSEMBLER routine which can be called 
from everywhere and simply stores
the actual values of the registers 0 to 15 in a vector of 16 void 
pointers passed by the C caller.


something like

extern void ccregs (void **regs);

void *regtable [16];

...

ccregs (regtable);

this way, you get - for example - regtable [13], which is the content of 
GR 13 at the time of the ccregs call.
GR 13 points to the current save area a.k.a. stack frame. From this save 
area, you can walk up to the
save area of the caller and find the registers at the time of the call 
of the current function ... this can
all be done using C. It is, BTW, even possible to analyse the whole save 
area chain this way,
including the names and addresses etc. of the surrounding stack frames, 
and the entry point,
return addresses and so on ... a complete stack trace, if you want. All 
this can be done during program run,

without interrupting or abending the current process or function.

Finding the R0 at the time of the call is very simple, once you have the 
current R13.


HTH, kind regards

Bernd

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

Re: Unzip on z/OS ?

[Paul Gilmartin]

On Tue, 4 Apr 2023 16:37:39 -0500, Charles Mills wrote:

>I just had a similar problem: "how do you determine your entry R0 from C?" I 
>asked here and got no answer. I had to front end the C with a tiny assembler 
>program (57 lines including extensive comments; 11 executable instructions). 
>Why did the C need its entry R0? Because it is called from Rexx, and needs to 
>call IRXEXCOM, and so needs the Rexx environment block.
>
In: 
I read:
Register 0
Address of an environment block (optional)
"optional" is intriguing.  What are the other options?  Must R0 point to 
addressable
storage?  The environment block begins with an identifier, CL8‘ENVBLOCK’.
If the content of R0 doesn't match, is it simply ignored?

Does C provide access to the entry RSA?  If so, the STM 14,12,12(,13) leaves
R0 at RSA+20.

But you still need to pass the IRXEXCOM to 

>Why the ^%$^%$#$^% do people come up with these non-standard linkages? Rexx 
>passes a bunch of parameters -- why not pass the Environment Block address 
>that way?
>
I think the REXX code germinated on CMS where there's less discipline.

-- 
gil

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

Re: Unzip on z/OS ?

[Charles Mills]

I just had a similar problem: "how do you determine your entry R0 from C?" I 
asked here and got no answer. I had to front end the C with a tiny assembler 
program (57 lines including extensive comments; 11 executable instructions). 
Why did the C need its entry R0? Because it is called from Rexx, and needs to 
call IRXEXCOM, and so needs the Rexx environment block.

Why the ^%$^%$#$^% do people come up with these non-standard linkages? Rexx 
passes a bunch of parameters -- why not pass the Environment Block address that 
way?

Charles


On Tue, 4 Apr 2023 21:09:59 +, Frank Swarbrick 
 wrote:

>How do you set R0 in C?

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

Re: Unzip on z/OS ?

[Paul Gilmartin]

On Tue, 4 Apr 2023 21:09:59 +, Frank Swarbrick wrote:

>How do you set R0 in C?
>
I suspect it's an undocumented beneficial, whether accidental or deliberate.
side effect of TSO CALL or C function call.

>
>From: Steve Thompson
>Sent: Tuesday, April 4, 2023 12:06 PM
>
>A similar issue happened with BPXWDYN. COBOL can't set R0. So a
>new entry point in BPXWDYN was created that handled that problem.
>
Now I've looked at the TSO/E REXX Ref.  It's rife with mention of R0
used to address the ENVBLOCK.  Terrible design.  (I suspect it
came from CMS)  They used R0 because no one else used it,
oblivious that there's a reason for that.  It would have been better
design to follow the conventions of the CALL, LINK, and ATTACH
macros and add another argument to the R1 PL (after the alternate
DDNAME list if any.)

-- 
gil

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

Re: Unzip on z/OS ?

[Seymour J Metz]

I assume that the actual requirement is the R0 be either 0 or the address of an 
environment block for REXX.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, April 4, 2023 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unzip on z/OS ?

On Tue, 4 Apr 2023 14:06:37 -0400, Steve Thompson wrote:

>A similar issue happened with BPXWDYN. COBOL can't set R0. So a
>new entry point in BPXWDYN was created that handled that problem.
>
Why does BPXWDYN require R0 to be set?  I've done TSO CALL BPXWDYN
never worrying about R0, so perhaps the TMP sets R0 as needed.

Why did designers provide an alternate entry point rather than simply
removing the restriction?  Did that necessarily introduce a new,
undocumented restriction?

I read:
BPXWDYN can be called through an alternate entry point, BPXWDY2.
BPXWDY2 accepts the same parameter list but does not require R0
to be set to 0. This entry point will also preserve the program mask.

Thia is the first mention of "preserv[ing] the program mask."  Is it normal
for CALL or LINK to preserve the program mask?  Should modifying
the program mask be mentioned as a behavior of BPXWDYN?

--
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: Unzip on z/OS ?

[Frank Swarbrick]

How do you set R0 in C?

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Tuesday, April 4, 2023 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Unzip on z/OS ?

A similar issue happened with BPXWDYN. COBOL can't set R0. So a
new entry point in BPXWDYN was created that handled that problem.

This all started with me writing an RCF to tell them that they
didn't have a COBOL example. Then a C programmer (I'm guessing)
wrote the COBOL code. You can write c in any language (one of
those type of things). Problem is, it would confuse most COBOL
programmers that, well, it would confuse most COBOL programmers,
and so I suggested a few changes to solve the issue. Then one of
their own people onfirmed what I said, it would be confusing to
most COBOL programmers. And so it appears that IBM doesn't have
many product developers that actually know COBOL. That has
been my take-away from that exchange.

So you may need to do an RCF, and you may go a few rounds with them.

Just say'n'.

Steve Thompson

On 4/4/2023 1:46 PM, Farley, Peter wrote:
> The V2R5 Callable Services manual SA23-1377-50 pp 191-196 describes ONLY the 
> C language zlib library and functions.  There is no material on how to use 
> those functions from any other language than C.
>
> At the very least there is no mention of COBOL COPY members for the parameter 
> definitions nor any mention of a COBOL-compatible link library for inclusion 
> in an executable module.  Only the POSIX C link library and functions are 
> described.
>
> Am I missing something?  Like maybe the zlib C functions are compiled with 
> "#pragma linkage(entryname,OS)"?  There is no such statement in that manual 
> at all.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Ed Jaffe
> Sent: Tuesday, April 4, 2023 1:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unzip on z/OS ?
>
> On 4/4/2023 10:22 AM, Farley, Peter wrote:
>> I agree with Michael, neither that redbook nor the current (V2R5) z/OS 
>> Callable Services manual even mention COBOL or any other HLL interface or 
>> API.  Only the C language zlib library and functions are described.
> Tom provided the link to the book and on page 128 it states that the
> callable services "... are for use by any program coded in C, COBOL,
> Fortran, Pascal, or PL/I, and this information refers to programs
> written in these languages as high-level language (HLL) programs."
>
>

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

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

Re: IBM z16 Model A02 Announcement

[Enzo D'Amato]

I think that it's very good that we now have something like the multiprise 3000 
back again. I think having smaller systems available for the "mainframe 
curious" will help a lot in getting new companies on the platform.

From: IBM Mainframe Discussion List  on behalf of 
Parwez Hamid <04843e86df79-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, April 4, 2023 5:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM z16 Model A02 Announcement

USA:

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/897/ENUS3932-_h01/index.html

EMEA:

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/877/ENUS3932-_h01/index.html

--
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: Unzip on z/OS ?

[Paul Gilmartin]

On Tue, 4 Apr 2023 14:06:37 -0400, Steve Thompson wrote:

>A similar issue happened with BPXWDYN. COBOL can't set R0. So a
>new entry point in BPXWDYN was created that handled that problem.
>
Why does BPXWDYN require R0 to be set?  I've done TSO CALL BPXWDYN
never worrying about R0, so perhaps the TMP sets R0 as needed.

Why did designers provide an alternate entry point rather than simply
removing the restriction?  Did that necessarily introduce a new,
undocumented restriction?

I read:
BPXWDYN can be called through an alternate entry point, BPXWDY2.
BPXWDY2 accepts the same parameter list but does not require R0
to be set to 0. This entry point will also preserve the program mask.

Thia is the first mention of "preserv[ing] the program mask."  Is it normal
for CALL or LINK to preserve the program mask?  Should modifying
the program mask be mentioned as a behavior of BPXWDYN?

-- 
gil

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

Re: Unzip on z/OS ?

[Farley, Peter]

You are probably right about that.  I will start one and see what they reply.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Tuesday, April 4, 2023 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unzip on z/OS ?

A similar issue happened with BPXWDYN. COBOL can't set R0. So a new entry point 
in BPXWDYN was created that handled that problem.

This all started with me writing an RCF to tell them that they didn't have a 
COBOL example. Then a C programmer (I'm guessing) wrote the COBOL code. You can 
write c in any language (one of those type of things). Problem is, it would 
confuse most COBOL programmers that, well, it would confuse most COBOL 
programmers, and so I suggested a few changes to solve the issue. Then one of 
their own people onfirmed what I said, it would be confusing to most COBOL 
programmers. And so it appears that IBM doesn't have many product developers 
that actually know COBOL. That has been my take-away from that exchange.

So you may need to do an RCF, and you may go a few rounds with them.

Just say'n'.

Steve Thompson

On 4/4/2023 1:46 PM, Farley, Peter wrote:
> The V2R5 Callable Services manual SA23-1377-50 pp 191-196 describes ONLY the 
> C language zlib library and functions.  There is no material on how to use 
> those functions from any other language than C.
>
> At the very least there is no mention of COBOL COPY members for the parameter 
> definitions nor any mention of a COBOL-compatible link library for inclusion 
> in an executable module.  Only the POSIX C link library and functions are 
> described.
>
> Am I missing something?  Like maybe the zlib C functions are compiled with 
> "#pragma linkage(entryname,OS)"?  There is no such statement in that manual 
> at all.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Ed Jaffe
> Sent: Tuesday, April 4, 2023 1:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unzip on z/OS ?
>
> On 4/4/2023 10:22 AM, Farley, Peter wrote:
>> I agree with Michael, neither that redbook nor the current (V2R5) z/OS 
>> Callable Services manual even mention COBOL or any other HLL interface or 
>> API.  Only the C language zlib library and functions are described.
> Tom provided the link to the book and on page 128 it states that the 
> callable services "... are for use by any program coded in C, COBOL, 
> Fortran, Pascal, or PL/I, and this information refers to programs 
> written in these languages as high-level language (HLL) programs."
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Unzip on z/OS ?

[Paul Gilmartin]

On Tue, 4 Apr 2023 17:46:30 +, Farley, Peter wrote:

>The V2R5 Callable Services manual SA23-1377-50 pp 191-196 describes ONLY the C 
>language zlib library and functions.  There is no material on how to use those 
>functions from any other language than C.
>
In view of the prevalence of zipped files; IBM makes some available; complete 
examples
in a User's Guide addressing the OP's question:
We have z/OS 2.4 and we are wondering if we can unzip an ASCII file that was
zipped on the Windows platform.

would be valuable.  Deciding gzip is only part of the chore.

>At the very least there is no mention of COBOL COPY members for the parameter 
>definitions nor any mention of a COBOL-compatible link library for inclusion 
>in an executable module.  Only the POSIX C link library and functions are 
>described.
>
>Am I missing something?  Like maybe the zlib C functions are compiled with 
>"#pragma linkage(entryname,OS)"?  There is no such statement in that manual at 
>all.

-- 
gil

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

Re: Unzip on z/OS ?

[Steve Thompson]

A similar issue happened with BPXWDYN. COBOL can't set R0. So a 
new entry point in BPXWDYN was created that handled that problem.


This all started with me writing an RCF to tell them that they 
didn't have a COBOL example. Then a C programmer (I'm guessing) 
wrote the COBOL code. You can write c in any language (one of 
those type of things). Problem is, it would confuse most COBOL 
programmers that, well, it would confuse most COBOL programmers, 
and so I suggested a few changes to solve the issue. Then one of 
their own people onfirmed what I said, it would be confusing to 
most COBOL programmers. And so it appears that IBM doesn't have 
many product developers that actually know COBOL. That has 
been my take-away from that exchange.


So you may need to do an RCF, and you may go a few rounds with them.

Just say'n'.

Steve Thompson

On 4/4/2023 1:46 PM, Farley, Peter wrote:

The V2R5 Callable Services manual SA23-1377-50 pp 191-196 describes ONLY the C 
language zlib library and functions.  There is no material on how to use those 
functions from any other language than C.

At the very least there is no mention of COBOL COPY members for the parameter 
definitions nor any mention of a COBOL-compatible link library for inclusion in 
an executable module.  Only the POSIX C link library and functions are 
described.

Am I missing something?  Like maybe the zlib C functions are compiled with "#pragma 
linkage(entryname,OS)"?  There is no such statement in that manual at all.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, April 4, 2023 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unzip on z/OS ?

On 4/4/2023 10:22 AM, Farley, Peter wrote:

I agree with Michael, neither that redbook nor the current (V2R5) z/OS Callable 
Services manual even mention COBOL or any other HLL interface or API.  Only the 
C language zlib library and functions are described.

Tom provided the link to the book and on page 128 it states that the
callable services "... are for use by any program coded in C, COBOL,
Fortran, Pascal, or PL/I, and this information refers to programs
written in these languages as high-level language (HLL) programs."




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

Re: Unzip on z/OS ?

[Farley, Peter]

The V2R5 Callable Services manual SA23-1377-50 pp 191-196 describes ONLY the C 
language zlib library and functions.  There is no material on how to use those 
functions from any other language than C.

At the very least there is no mention of COBOL COPY members for the parameter 
definitions nor any mention of a COBOL-compatible link library for inclusion in 
an executable module.  Only the POSIX C link library and functions are 
described.

Am I missing something?  Like maybe the zlib C functions are compiled with 
"#pragma linkage(entryname,OS)"?  There is no such statement in that manual at 
all.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, April 4, 2023 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unzip on z/OS ?

On 4/4/2023 10:22 AM, Farley, Peter wrote:
> I agree with Michael, neither that redbook nor the current (V2R5) z/OS 
> Callable Services manual even mention COBOL or any other HLL interface or 
> API.  Only the C language zlib library and functions are described.

Tom provided the link to the book and on page 128 it states that the 
callable services "... are for use by any program coded in C, COBOL, 
Fortran, Pascal, or PL/I, and this information refers to programs 
written in these languages as high-level language (HLL) programs."


-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Unzip on z/OS ?

[Schmitt, Michael]

I'm guessing it means that to use the interface from COBOL one must...

1. Read the zlib documentation (https://zlib.net) to figure out how to call the 
library from C.

2. Cross-reference this with the documentation for the zEDC zlib implementation 
to determine which parameters are supported by zEDC. Now you know how to call 
zEDC from C.

3. Figure out how to make an *equivalent call* from COBOL, so that the C zlib 
API sees the same parameter linkage as it would from a C program.

4. Figure out how to link a ZFS library into an MVS load module.

Am I wrong?


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, April 4, 2023 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unzip on z/OS ?

On 4/4/2023 10:22 AM, Farley, Peter wrote:
> I agree with Michael, neither that redbook nor the current (V2R5) z/OS 
> Callable Services manual even mention COBOL or any other HLL interface or 
> API.  Only the C language zlib library and functions are described.

Tom provided the link to the book and on page 128 it states that the
callable services "... are for use by any program coded in C, COBOL,
Fortran, Pascal, or PL/I, and this information refers to programs
written in these languages as high-level language (HLL) programs."


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.phoenixsoftware.com%2F&data=05%7C01%7Cmichael.schmitt%40dxc.com%7Cc7bec94c38c24aceaa1f08db353243db%7C93f33571550f43cfb09fcd331338d086%7C0%7C0%7C638162262225208685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=F1hJe%2B%2BgpLyzcqLJAHUYgb7oR9VOUVJRhJh%2FpHih%2FDA%3D&reserved=0



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: Unzip on z/OS ?

[Ed Jaffe]

On 4/4/2023 10:22 AM, Farley, Peter wrote:

I agree with Michael, neither that redbook nor the current (V2R5) z/OS Callable 
Services manual even mention COBOL or any other HLL interface or API.  Only the 
C language zlib library and functions are described.


Tom provided the link to the book and on page 128 it states that the 
callable services "... are for use by any program coded in C, COBOL, 
Fortran, Pascal, or PL/I, and this information refers to programs 
written in these languages as high-level language (HLL) 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: Unzip on z/OS ?

[Farley, Peter]

I agree with Michael, neither that redbook nor the current (V2R5) z/OS Callable 
Services manual even mention COBOL or any other HLL interface or API.  Only the 
C language zlib library and functions are described.

So where are the other-than-C language interfaces described?

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Harper
Sent: Friday, March 31, 2023 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unzip on z/OS ?

Michael,

The information is here on pages 127 to 128.

IBM states specifically that the callable interfaces can be invoked by COBOL. 

I have been using the authorized interface for zEDC for several years now, and 
I will be the first to admit that the documentation is obtuse and hard to 
follow with few examples, but it does work. 

Once you get it working, the technology is impressive. But not for the feint of 
heart. 

Tom Harper 

Phoenix Software International 

https://urldefense.com/v3/__https://www.redbooks.ibm.com/redbooks/pdfs/sg248259.pdf__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KQuC-N294Kx-lC2OwHUkCB3LzjGR2QnfnFh-rbsrLMLeH1bVEXRuLFy9uc7dErg_Qp2kkgeQz9cv-3Xxk-x6n2GCVqt1QsqM$
 



Sent from my iPhone

> On Mar 31, 2023, at 11:14 AM, Schmitt, Michael  
> wrote:
> 
> I'm missing how you would call zEDC from a COBOL programming running in 
> CICS. The Redbook has no examples - it just says there's a callable service 
> for High Level Languages. But the Services for HLL languages just says that 
> unauthorized programs can use a Unix-side library.
> 
> And google has a dearth of hits for COBOL calling zEDC.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Tom Harper
> Sent: Thursday, March 30, 2023 5:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unzip on z/OS ?
> 
> Michael,
> 
> I would consider using zEDC which can be called by authorized and 
> non-authorized programs in z/OS, and C and JAVA.
> 
> It’s very fast, and requires zEC12 GA2, zBC12, z13 or later. You must have 
> certain PTFs applied.
> 
> z15 and later machines have it built in.
> 
> This is a standard format and can be used on non-IBM systems.
> 
> If applicable, you can do it without program changes using DATACLAS.
> 
> Tom Harper
> 
> Phoenix Software International
> 
> Sent from my iPhone
> 
>> On Mar 30, 2023, at 5:05 PM, Schmitt, Michael  
>> wrote:
>> 
>> What if the requirement is to compress or decompress an area of memory, by 
>> calling something from a COBOL CICS transaction running on z/OS, in a way 
>> that it could be compatibly decompress or compress by a program running on 
>> another platform?
>> 
>> For example: CICS > compress > send across some communication path > 
>> transaction on Linux > program > decompress > same data as started 
>> with
>> 
>> The actual algorithm isn't critical, as long as it is compatible on both 
>> ends.
>> 
>> The compressed data isn't in a file, nor are jobs being run. This is 
>> transaction processing.
>> 
>> My preference would be an algorithm that has the compression ratio of 
>> 7zip with the performance of RLE. 😊
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Rahim Azizarab
>> Sent: Friday, March 24, 2023 4:05 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Unzip on z/OS ?
>> 
>> File #865 on Downloads at cbttape.org
>> 
>> I used it many times.
>> 
>> 
>> regards;
>> 
>> Rahim
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: ASM call by value

[Paul Gilmartin]

On Mon, 3 Apr 2023 02:09:51 +0200, Bernd Oppolzer  wrote:

>Now I'll try an answer to the other question(s), see below ...
>
>Am 03.04.2023 um 01:32 schrieb Paul Gilmartin:
>> Are the external semantics (not examining the generated assembly) of
>> "pass by content" any different from "pass by value"?   How?
>
>maybe not
>
>> It would seem more efficient for the called function to perform the copy
>> rather than the caller because the code to perform the copy would exist
>> only once in the subroutine rather than at each point of call.
>
>I don't think so.
>
>If the copy would be done by the called routine, you would need two
>copies ...
>first you would need to copy the addresses of the parameters to the stack
>(because otherwise the called routine would not know where to copy the
>parameters from)
>and then the second copy in the called routine, which copies the values
>from the original place
>in the caller's area to the stack frame of the called routine. This
>takes more time to do it
>and additional stack space for the address list, and: this is true IMO,
>no matter what platform
>you are running on. It is therefore better to copy the values to the
>parameter list directly and
>this must be done by the caller; the caller has to prepare the parameter
>list. BTW: this is done
>this way by every compiler that I am aware of, my New Stanford Pascal
>compiler and every
>other compiler that I have examined in the last years, different platforms.
>
>This is maybe a time to space tradeoff, in the end ... but all compilers
>decide for time saving.
>
I doubt there's a significant performance difference between the caller's
copying the content and the callee's doing so.  It may have been more
important to preserve compatibility with support tools: debuggers and
dump analyzers which depend on the reg1 PL containing addresses of
parameters seen by the callee, even in an asynchronous snapshot.

From the HLL point of view, "call by content" is "call by value" with an
idiosyncratic name for identical semantics.

-- 
gil

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

Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary Kildall

[Bill Johnson]

I was around at the time and nobody thought PL/I was a COBOL killer. Just like 
nobody believes challenger banks are actual banks and certainly not going to 
replace actual banks. Many of the challenger banks that you previously 
mentioned are already history.


Sent from Yahoo Mail for iPhone


On Tuesday, April 4, 2023, 1:19 AM, David Crayford  wrote:

In the museum at IBM Hursley, they have a deck of punch cards containing 
the original PL/I compiler. With typical British wit somebody has 
written "the UNCOBOL" on the side. That was probably what they thought 
at the time, that PL/I was a COBOL killer. Funny how things turn out.

https://photos.app.goo.gl/pTFzN8twvoBCEWBR7

On 3/4/23 19:38, David Crayford wrote:
>
>
> On 3/4/23 18:11, Seymour J Metz wrote:
>> I, OTOH, was appalled by C ever since it came out, much preferring PL/I.
>
> Certainly, the reasons for PL/I's failure are subject to debate, but 
> there are several factors that may have contributed:
>
> 1.
>
>    IBM was the primary stakeholder and developer of PL/I, which may
>    have limited its adoption and prevented a more diverse community
>    from contributing to its development.
>
> 2.
>
>    IBM's focus on mainframe computing meant that PL/I was primarily
>    used in that context, which may have limited its appeal outside of
>    that niche.
>
> 3.
>
>    FORTRAN was already well-established as a language for scientific
>    computing, which may have made it difficult for PL/I to gain
>    traction in that area.
>
> 4.
>
>    Other languages, such as Ada, were designed with more open
>    standards and free toolchains, which may have made them more
>    attractive to developers than PL/I.
>
>> As for assembler, there are a lot of things that I can do in a single 
>> statement that are awkward and verbose in C. Further, 95% of my experience 
>> has been with macro assemblers, and C's macro language looks like a joke.
>
> You can't optimize for hardware that hasn't been invented yet! Almost 
> all C compiler can also compile C++. I recommend to people who whinge 
> about C string handling to just switch to C++ and use std::string. The 
> C++ gospel is ruled by the zero-overhead principle. In other words, 
> you only pay for what you use.
>
>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> Tom Brennan [t...@tombrennansoftware.com]
>> Sent: Monday, April 3, 2023 1:03 AM
>> To:IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Fascinating Interview with Steve Jobs [non-mainframe] - now 
>> Gary Kildall
>>
>> I actually always liked C, maybe because its original simplicity
>> reminded me of Assembler.  I mean, what other language can you goof up a
>> length value or pointer and overwrite a bunch of other data areas by
>> mistake?  Oh yeah, Assembler!
>>
>> On 4/2/2023 9:29 PM, Clem Clarke wrote:
>>> In my mind, Gary Kildall was a genius. Not only for his operating
>>> systems, but he also had PL/I running on PCs when everyone else said it
>>> was impossible. Now, we are stuck with "C".
>>>
>>> Also, Kildall had a GUI called GEM out years before Windows.
>>>
>>>
>>> Unfortunately, the same man that effectively killed that OS/2 and forced
>>> us all to suffer through Win95 and Win98 etc stopped much innovation.
>>>
>>> When the IBM PC came out, I used DRI's PL/I when I converted the
>>> mainframe version of Jol to run on the PC.  It did pretty much
>>> everything a System Programmer would need to do, far more simply than C
>>> (in my opinion).  Unfortunately, it only ran in the 8086 small model and
>>> after Kildall's death with no possibility of a large or flat memory
>>> model, I felt I had no alternative but to convert the Jol code to C,
>>> which took many years.  C's inefficient and dangerous string handling
>>> routines took ages to overcome.
>>>
>>> With regard to Kildall's flying when IBM went out, some old notes I
>>> looked at the other day place a slightly interpretation on it. Yes,
>>> apparently he was flying in the morning - delivering software to a
>>> customer.  He apparently met with IBM in the afternoon but IBM wanted
>>> them to sign a nondisclosure agreement which was very one sided. And it
>>> seems that IBM wanted to pay Kildall a one time payment for his
>>> operating system, instead of the more usual royalty agreement, which was
>>> not seen as acceptable.
>>>
>>> And it seems Bill Gates' mother was either on IBM's board, or was was
>>> closely associated with someone who was.  One comment from the short
>>> video is:
>>>      =
>>> "  What people seem to forget is that Bill Gate's mother worked on the
>>> board of IBM
>>> and Bill Gates Sr. was very well connected. (and was also on the board
>>> of Planned parenthood)
>>> "Bill Gates is also a Rockafeller's grandson..
>>> "so everything was pretty much set up for him to succeed."
>>>      =
>>>
>>>
>>> Who knows?  Is there a

Re: IBM z16 Model A02 Announcement

[Mark Regan]

The SOD is at
https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/897/ENUS123-002/index.html#sodx

Regards,

Mark Regan, K8MTR General, EN80tg
CTO1 USNR-Retired (1969-1991)
Nationwide Insurance, Retired, 1986-2017
z/OS Network Software Consultant (z NetView, z/OS Communications Server)
Email: marktre...@gmail.com
LinkedIn:  https://www.linkedin.com/in/mark-t-regan




On Tue, Apr 4, 2023 at 10:25 AM P H <
04843e86df79-dmarc-requ...@listserv.ua.edu> wrote:

> Re no statements of direction. Maybe there aren't any at this time. There
> were a few when the z16 Model A01 was announced.
>
> Sent from Outlook for Android
> 
> From: IBM Mainframe Discussion List  on behalf
> of Bodra - Pessoal <02eda2bc565a-dmarc-requ...@listserv.ua.edu>
> Sent: Tuesday, April 4, 2023 2:30:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: RES: IBM z16 Model A02 Announcement
>
> There are no Statement of Direction in announcement.
>
>
> Carlos Bodra
> IBM zEnterprise Certified
> São Paulo – SP – Brazil
>
>
> -Mensagem original-
> De: IBM Mainframe Discussion List  Em nome de
> Parwez Hamid
> Enviada em: terça-feira, 4 de abril de 2023 06:52
> Para: IBM-MAIN@LISTSERV.UA.EDU
> Assunto: IBM z16 Model A02 Announcement
>
> USA:
>
>
> https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/897/ENUS3932-_h01/index.html
>
> EMEA:
>
>
> https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/877/ENUS3932-_h01/index.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary Kildall

[Steve Thompson]

++1

On 4/4/2023 10:09 AM, Schmitt, Michael wrote:

The language I'd be interested in is PL/X 390.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, April 3, 2023 6:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary 
Kildall



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

Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary Kildall

[Seymour J Metz]

"You’re just making it up as you go along." is a blatant lie, not a reality. 
Whatever C++ is or is not has no relevance to that.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Monday, April 3, 2023 8:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary 
Kildall

On 3/4/23 22:57, Seymour J Metz wrote:
> ObDieJungfrauvonOrleans Believe that if you want' it wont change the reality.

I know it's reality as I'm an experienced C++ programmer. Modern C++ is
a thing. It's a term used to describe the C++ language from C++11 and
newer, when the language was reinvented.

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md


>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Crayford 
> Sent: Monday, April 3, 2023 10:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary 
> Kildall
>
>> On 3 Apr 2023, at 10:03 pm, Seymour J Metz  wrote:
>>
>> "You keep using that word. I do not think it means what you think it means."
>>
>> Modernity is determined by the original design, not by the latest tweak  C++ 
>> still has defects inherited from C; there are later languages that were 
>> designed ab initio, with no inherited  defects.
>>
> What nonsense. You’re just making it up as you go along.
>
>
>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> David Crayford 
>> Sent: Monday, April 3, 2023 9:53 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Fascinating Interview with Steve Jobs [non-mainframe] - now 
>> Gary Kildall
>>
>> OK, I’ll rephrase. Modern C++ is one of the most modern programming 
>> languages in use today. C compatibility is in the past. C++20 introduced 
>> modules and reflection is already available in some compilers.
>>
>>> On 3 Apr 2023, at 9:46 pm, Seymour J Metz  wrote:
>>>
>>> Contemporary and modern mean very different things, and [[C++]] mentions 
>>> neither. Stroustrup admitted that the design of C++was compromised by 
>>> compatibility concerns.
>>>
>>> 
>>> From: IBM Mainframe Discussion List  on behalf of 
>>> David Crayford 
>>> Sent: Monday, April 3, 2023 7:58 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Fascinating Interview with Steve Jobs [non-mainframe] - now 
>>> Gary Kildall
>>>
> On 3/4/23 19:48, Seymour J Metz wrote:
 Why switch to C++ rather than to a more modern language?
>>> It's widely acknowledged that C++20 is one of the most contemporary
>>> programming languages being used today [1]. With its compiled approach
>>> and low-level memory access, it's difficult to find a more robust
>>> systems level programming language available on z/OS. Although Rust
>>> could be seen as an improvement, it's important to note that IBM has
>>> declared that they currently have no intentions of creating a Rustc
>>> front-end for LLVM.
>>>
>>> [1] https://en.wikipedia.org/wiki/C%2B%2B20
>>>
>>>

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

 
 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf 
 of David Crayford [dcrayf...@gmail.com]
 Sent: Monday, April 3, 2023 7:38 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Fascinating Interview with Steve Jobs [non-mainframe] - now 
 Gary Kildall

> On 3/4/23 18:11, Seymour J Metz wrote:
> I, OTOH, was appalled by C ever since it came out, much preferring PL/I.
 Certainly, the reasons for PL/I's failure are subject to debate, but
 there are several factors that may have contributed:

 1.

 IBM was the primary stakeholder and developer of PL/I, which may
 have limited its adoption and prevented a more diverse community
 from contributing to its development.

 2.

 IBM's focus on mainframe computing meant that PL/I was primarily
 used in that context, which may have limited its appeal outside of
 that niche.

 3.

 FORTRAN was already well-established as a language for scientific
 computing, which may have made it difficult for PL/I to gain
 traction in that area.

 4.

 Other languages, such as Ada, were designed with more open standards
 and free toolchains, which may have made them more attractive to
 developers than PL/I.

> As for assembler, there are a lot of things that I can do in a single 
> statement that are awkward and verbose in C. Further, 95% of my 
> experience has been with macro assemblers, and C's macro language looks 
> like a joke.
 You can't optimize f

Re: IBM z16 Model A02 Announcement

[P H]

Re no statements of direction. Maybe there aren't any at this time. There were 
a few when the z16 Model A01 was announced.

Sent from Outlook for Android

From: IBM Mainframe Discussion List  on behalf of 
Bodra - Pessoal <02eda2bc565a-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, April 4, 2023 2:30:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: RES: IBM z16 Model A02 Announcement

There are no Statement of Direction in announcement.


Carlos Bodra
IBM zEnterprise Certified
São Paulo – SP – Brazil


-Mensagem original-
De: IBM Mainframe Discussion List  Em nome de Parwez 
Hamid
Enviada em: terça-feira, 4 de abril de 2023 06:52
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: IBM z16 Model A02 Announcement

USA:

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/897/ENUS3932-_h01/index.html

EMEA:

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/877/ENUS3932-_h01/index.html

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

PKCS #7

[Isabel]

Hello!

I have the following request:

We need to build a CICS Transaction to obtain a PKCS #7 (token) to
authenticate a user.

I am confused if I have to use a RACF certificate, ICSF or both.

Thanks in advance.

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

Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary Kildall

[Schmitt, Michael]

The language I'd be interested in is PL/X 390.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, April 3, 2023 6:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary 
Kildall

On 3/4/23 18:11, Seymour J Metz wrote:
> I, OTOH, was appalled by C ever since it came out, much preferring PL/I.

Certainly, the reasons for PL/I's failure are subject to debate, but
there are several factors that may have contributed:

 1.

IBM was the primary stakeholder and developer of PL/I, which may
have limited its adoption and prevented a more diverse community
from contributing to its development.

 2.

IBM's focus on mainframe computing meant that PL/I was primarily
used in that context, which may have limited its appeal outside of
that niche.

 3.

FORTRAN was already well-established as a language for scientific
computing, which may have made it difficult for PL/I to gain
traction in that area.

 4.

Other languages, such as Ada, were designed with more open standards
and free toolchains, which may have made them more attractive to
developers than PL/I.

>
> As for assembler, there are a lot of things that I can do in a single 
> statement that are awkward and verbose in C. Further, 95% of my experience 
> has been with macro assemblers, and C's macro language looks like a joke.

You can't optimize for hardware that hasn't been invented yet! Almost
all C compiler can also compile C++. I recommend to people who whinge
about C string handling to just switch to C++ and use std::string. The
C++ gospel is ruled by the zero-overhead principle. In other words, you
only pay for what you use.


>
>
> --
> Shmuel (Seymour J.) Metz
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=05%7C01%7Cmichael.schmitt%40dxc.com%7C8d893723bb834d07714608db343815ae%7C93f33571550f43cfb09fcd331338d086%7C0%7C0%7C638161187741160836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NT5%2BU6KOxqG0FvS5Q6MxRAUAJALqTX3xAxAC9ARDaNs%3D&reserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Tom Brennan [t...@tombrennansoftware.com]
> Sent: Monday, April 3, 2023 1:03 AM
> To:IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fascinating Interview with Steve Jobs [non-mainframe] - now Gary 
> Kildall
>
> I actually always liked C, maybe because its original simplicity
> reminded me of Assembler.  I mean, what other language can you goof up a
> length value or pointer and overwrite a bunch of other data areas by
> mistake?  Oh yeah, Assembler!
>
> On 4/2/2023 9:29 PM, Clem Clarke wrote:
>> In my mind, Gary Kildall was a genius. Not only for his operating
>> systems, but he also had PL/I running on PCs when everyone else said it
>> was impossible. Now, we are stuck with "C".
>>
>> Also, Kildall had a GUI called GEM out years before Windows.
>>
>>
>> Unfortunately, the same man that effectively killed that OS/2 and forced
>> us all to suffer through Win95 and Win98 etc stopped much innovation.
>>
>> When the IBM PC came out, I used DRI's PL/I when I converted the
>> mainframe version of Jol to run on the PC.  It did pretty much
>> everything a System Programmer would need to do, far more simply than C
>> (in my opinion).  Unfortunately, it only ran in the 8086 small model and
>> after Kildall's death with no possibility of a large or flat memory
>> model, I felt I had no alternative but to convert the Jol code to C,
>> which took many years.  C's inefficient and dangerous string handling
>> routines took ages to overcome.
>>
>> With regard to Kildall's flying when IBM went out, some old notes I
>> looked at the other day place a slightly interpretation on it. Yes,
>> apparently he was flying in the morning - delivering software to a
>> customer.  He apparently met with IBM in the afternoon but IBM wanted
>> them to sign a nondisclosure agreement which was very one sided. And it
>> seems that IBM wanted to pay Kildall a one time payment for his
>> operating system, instead of the more usual royalty agreement, which was
>> not seen as acceptable.
>>
>> And it seems Bill Gates' mother was either on IBM's board, or was was
>> closely associated with someone who was.  One comment from the short
>> video is:
>>   =
>> "  What people seem to forget is that Bill Gate's mother worked on the
>> board of IBM
>> and Bill Gates Sr. was very well connected. (and was also on the board
>> of Planned parenthood)
>> "Bill Gates is also a Rockafeller's grandson..
>> "so everything was pretty much set up for him to succeed."
>>   =
>>
>>
>> Who knows?  Is there anyone in IBM who would know the truth?
>>
>> Here are three videos that go into it in greater depth. "The Man Who
>> COULD Have Been Bill Gates [Gary Kildall]"
>> 1. A 

Auto: RES: IBM z16 Model A02 Announcement

[Frederic Mancini]

Je suis absent le 04 avril 2023.

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

RES: IBM z16 Model A02 Announcement

[Bodra - Pessoal]

There are no Statement of Direction in announcement. 


Carlos Bodra
IBM zEnterprise Certified
São Paulo – SP – Brazil


-Mensagem original-
De: IBM Mainframe Discussion List  Em nome de Parwez 
Hamid
Enviada em: terça-feira, 4 de abril de 2023 06:52
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: IBM z16 Model A02 Announcement

USA:

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/897/ENUS3932-_h01/index.html

EMEA:

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/877/ENUS3932-_h01/index.html

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

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

IBM z16 Model A02 Announcement

[Parwez Hamid]

USA:

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/897/ENUS3932-_h01/index.html

EMEA:

https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/877/ENUS3932-_h01/index.html

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

IBM z16 Model A02 ('Baby' z16) Redbooks

[Parwez Hamid]

https://www.redbooks.ibm.com/abstracts/sg248950.html

https://www.redbooks.ibm.com/redpieces/abstracts/sg248952.html

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