Re: Migrate z/OS DASD volumes from Mainframe to Hercules Environment

[Brian Westerman]

How much would a hobbyist pay for a Harley, a really nice drone, or some of the 
other expensive hobbies.  People pay upwards of $1K a year for a new phone.  I 
did get a discount on that, but I suppose you are correct, if you can't justify 
the cost, then it might seem too much.  Although, the alternative of doing it 
illegally is not even what I would consider to be an option at 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 use of "legacy" programming languages

[zMan]

So you interpreted "If you are going to..." as "Because you are"; Charles
clearly meant it as "If one were to..."

English can be ambiguous, but comity will get you a lot further than
knee-jerk defensiveness. This applies in real life, too, and might explain
some folks' employment difficulties. Just sayin'.

On Thu, Jul 2, 2020 at 1:44 PM Seymour J Metz  wrote:

> > Why do you have to be so hostile?
>
> Why do you have to be such a hypocrite? I'm not hostile in general. But
> when you rant about imaginary hostility and gratuitously insult me, I see
> no reason to be concerned with your delicate feelings in subsequent
> messages.
>
> > I did not see any mention of OS compatibility. That is precisely why I
> mentioned it.
>
> You wrote "If you are going to include OS compatibility as well as
> hardware compatibility"; that certainly seems to be a false claim that I
> mentioned it.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Charles Mills [charl...@mcn.org]
> Sent: Thursday, July 2, 2020 1:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS use of "legacy" programming languages
>
> Why do you have to be so hostile? I did not see any mention of OS
> compatibility. That is precisely why I mentioned it. I raised additional
> issues beyond what you raised. WTF indeed.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Thursday, July 2, 2020 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS use of "legacy" programming languages
>
> WTF? Where do you see "OS compatibility"? The issues that I raised were all
> architecture and instruction set.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of
> Charles Mills [charl...@mcn.org]
> Sent: Thursday, July 2, 2020 12:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS use of "legacy" programming languages
>
> If you are going to include OS compatibility as well as hardware
> compatibility then there are issues such as control blocks that have been
> moved above line.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Thursday, July 2, 2020 9:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS use of "legacy" programming languages
>
> > The only thing which might not work would
> > be something which was CPU speed dependent.
>
> That's not the only thing. A program that relies on getting certain program
> interrupts might fail. Then there's the ASCII bit, although I would be very
> surprised if anybody actually used it. There are optional instructions that
> IBM carried over. There's probably more that I haven't thought of.
>
> --
> 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
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Civility (was z/OS use of "legacy" programming languages)

[Bob Bridges]

Mr Metz resolutely straightens everyone else's pictures, in this listserv,
but is very sensitive about his own.  Most of us, it seems to me, forgive
him and ignore it.

You did cross a line, though, Seymour, this time.  I perceive no hostility
in Mr Mills' post, and yours positively bristled with it.  I don't think
that's hypocrisy on your part, just self-blindness.  Ease back, man, and be
less eager to posture.  Go ahead and flame me immoderately, now, and then
forget it.

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

/* The wit of conversation consists more in finding it in others than
showing a great deal yourself.  He who goes out of your company pleased with
his own facetiousness and ingenuity will the sooner come into it again.
-Poor Richard's Almanack, 1756 */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, July 2, 2020 13:45

> Why do you have to be so hostile? 

Why do you have to be such a hypocrite? I'm not hostile in general. But when
you rant about imaginary hostility and gratuitously insult me, I see no
reason to be concerned with your delicate feelings in subsequent messages.

> I did not see any mention of OS compatibility. That is precisely why I
mentioned it.

You wrote "If you are going to include OS compatibility as well as hardware
compatibility"; that certainly seems to be a false claim that I mentioned
it.


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Thursday, July 2, 2020 1:28 PM

Why do you have to be so hostile? I did not see any mention of OS
compatibility. That is precisely why I mentioned it. I raised additional
issues beyond what you raised. WTF indeed.

-Original Message-
From: Seymour J Metz
Sent: Thursday, July 2, 2020 9:48 AM

WTF? Where do you see "OS compatibility"? The issues that I raised were all
architecture and instruction set.


From: Charles Mills [charl...@mcn.org]
Sent: Thursday, July 2, 2020 12:39 PM

If you are going to include OS compatibility as well as hardware
compatibility then there are issues such as control blocks that have been
moved above line.

-Original Message-
From: Seymour J Metz
Sent: Thursday, July 2, 2020 9:07 AM

That's not the only thing. A program that relies on getting certain program
interrupts might fail. Then there's the ASCII bit, although I would be very
surprised if anybody actually used it. There are optional instructions that
IBM carried over. There's probably more that I haven't thought of.

--- 
> The only thing which might not work would
> be something which was CPU speed dependent.

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

Re: IPSEC Configuration and Performance

[Grant Taylor]

On 7/2/20 1:27 AM, kekronbekron wrote:
Ditto, sorry to go "off-topic" again ... I hope IBM is reading this, 
and hope they look to adding WireGuard support on Z.


I would be mildly, but pleasantly, surprised to see WireGuard added to z/OS.

Adding WireGuard support to z/OS shouldn't be too much of a "deviation" 
too, considering that the Linux kernel and OpenBSD now come baked-in 
with WG.


I naively assumed that IPsec on z/OS would be transport mode, not tunnel 
mode.  I say this because I assume that most of the IP traffic to / from 
a mainframe is terminal on the mainframe and doesn't actually route 
through the mainframe as a router.  With this in mind, I wonder how 
effective IPsec tunnel mode would be, seeing as how additional IP 
traffic would need to go inside of it.  Conversely transport mode would 
be used to authenticate and / or encrypt traffic to / from the mainframe.


But, I am just speculating and could be completely wrong.



--
Grant. . . .
unix || die

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

Re: What is the real size of a 3390-27 and 3390-54 [EXTERNAL]

[Pew, Curtis G]

On Jul 2, 2020, at 9:21 PM, Pew, Curtis G  wrote:
> 
> I consider them while

“I consider them experimental while …”

-- 
Pew, Curtis G
curtis@austin.utexas.edu






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

Re: What is the real size of a 3390-27 and 3390-54 [EXTERNAL]

[Pew, Curtis G]

On Jul 2, 2020, at 7:25 PM, Feller, Paul 
<02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote:
> 
> In this shop a MOD-27 is 32,760 cyls and a MOD-54 is 65,520 cyls.  As for how 
> they are allocated, that I can't answer.

Several years ago I moved all our DASD to “3390-54” with 65,520 cylinders. This 
was on a Hitachi VSP. Just this February we migrated to an IBM DS8882F. I had 
some space left over so I created some EAVs, but I consider them while I work 
out how best to utilize them.

On the Hitachi I used the GUI to define the virtual volumes and LCUs, but on 
the IBM disk I used DSCLI.


-- 
Pew, Curtis G
curtis@austin.utexas.edu






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

Re: What is the real size of a 3390-27 and 3390-54 [EXTERNAL]

[Feller, Paul]

Tony to answer your questions.  In this shop a MOD-27 is 32,760 cyls and a 
MOD-54 is 65,520 cyls.  As for how they are allocated, that I can't answer.  We 
don't have IBM DASD and the vendor we have does the configuration based on what 
we ask for.  Just to round things out the EAVs we do have are 1,177,554 cyls.


Thanks..

Paul Feller
GTS Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, July 02, 2020 6:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the real size of a 3390-27 and 3390-54 [EXTERNAL]

Keep in mind that you are dealing with virtual DASD. There never was a 3390 
model 27 or 54, so DASD providers are free to use whatever sizes tey want. 
Using 3 times a model 9 capacity and 6 times a model 9 capacity is 
conventional, but there's noting wrong with using a slightly larger size. There 
is no architectural limit on a 3390-27, but if you're going to use a size 
larger than 32760 then it must be an EAV.


--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3=DwIFAg=9g4MJkl2VjLjS6R4ei18BA=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc=3g-wCGqKzy3im7XztVXg9Q9xNMtTbsrKV7VtsDUYL2k=Z9efFPF85QAkL5KSSAa5qUlO4Yr5lWD71KPaFqeL9To=
 


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Thursday, July 2, 2020 5:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What is the real size of a 3390-27 and 3390-54

I am seeing some DS8000s where a mod-27 is defined as 30051 cylinders. I am 
seeing other sites were the mod-27 is defined with 32760 cylinders.

I know the architectural limit of a mod-27 is 32760 cylinders, but if you work 
with multiples of mod-1 units, the 30051 number make sense.

I also know that when you use the DSCLI, you can specify any number of 
cylinders. What I don't know is what the old GUI did.

So, some questions:

1) What size is a mod-27 in your shop?
2) Was your DASD allocated using the DSCLI or the GUI?

--
Tony Thigpen

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

--
Please note:  This message originated outside your organization. Please use 
caution when opening links or attachments.

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

Re: What is the real size of a 3390-27 and 3390-54

[Seymour J Metz]

Keep in mind that you are dealing with virtual DASD. There never was a 3390 
model 27 or 54, so DASD providers are free to use whatever sizes tey want. 
Using 3 times a model 9 capacity and 6 times a model 9 capacity is 
conventional, but there's noting wrong with using a slightly larger size. There 
is no architectural limit on a 3390-27, but if you're going to use a size 
larger than 32760 then it must be an EAV.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Thursday, July 2, 2020 5:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What is the real size of a 3390-27 and 3390-54

I am seeing some DS8000s where a mod-27 is defined as 30051 cylinders. I
am seeing other sites were the mod-27 is defined with 32760 cylinders.

I know the architectural limit of a mod-27 is 32760 cylinders, but if
you work with multiples of mod-1 units, the 30051 number make sense.

I also know that when you use the DSCLI, you can specify any number of
cylinders. What I don't know is what the old GUI did.

So, some questions:

1) What size is a mod-27 in your shop?
2) Was your DASD allocated using the DSCLI or the GUI?

--
Tony Thigpen

--
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: What is the real size of a 3390-27 and 3390-54

[Mike Schwab]

Some physical devices only allocate volumes in multiples of Mod 1s, or
gather scattered Mod 1 segments into a full volume.  32K cylinders is
29.4 times a Mod 1 of 1113 cylinders.  Not much different, but need to
make sure DR site or replacement dasd unit uses same size or larger
for restores or replication.  Similar applies to Mod 54 is 58.8.  And
once into EAV territory each increment MUST be a MOD 1 multiple.

On Thu, Jul 2, 2020 at 9:52 PM Tony Thigpen  wrote:
>
> I am seeing some DS8000s where a mod-27 is defined as 30051 cylinders. I
> am seeing other sites were the mod-27 is defined with 32760 cylinders.
>
> I know the architectural limit of a mod-27 is 32760 cylinders, but if
> you work with multiples of mod-1 units, the 30051 number make sense.
>
> I also know that when you use the DSCLI, you can specify any number of
> cylinders. What I don't know is what the old GUI did.
>
> So, some questions:
>
> 1) What size is a mod-27 in your shop?
> 2) Was your DASD allocated using the DSCLI or the GUI?
>
> --
> Tony Thigpen
>
> --
> 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

What is the real size of a 3390-27 and 3390-54

[Tony Thigpen]

I am seeing some DS8000s where a mod-27 is defined as 30051 cylinders. I 
am seeing other sites were the mod-27 is defined with 32760 cylinders.


I know the architectural limit of a mod-27 is 32760 cylinders, but if 
you work with multiples of mod-1 units, the 30051 number make sense.


I also know that when you use the DSCLI, you can specify any number of 
cylinders. What I don't know is what the old GUI did.


So, some questions:

1) What size is a mod-27 in your shop?
2) Was your DASD allocated using the DSCLI or the GUI?

--
Tony Thigpen

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

Re: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Steve Smith]

It is irrelevant where the blame lies for the document.  I should have just
said that it got the capabilities of COPYGRP and COPYGROUP switched.

You might try copying from the PDS to a temporary PDSE, and then you can
unload that.  You can work on where and which COPYG* would work best.

I experimented some, but not with SELECT.  In fact I tried 9 different
operations, but the permutations were getting out of hand.

sas


On Thu, Jul 2, 2020 at 2:51 PM Steve Goetze  wrote:

> I'm not sure that I agree that this was a tech writer command mixup.  The
> COPYGROUP statement was created to be a superset of COPYGRP, adding better
> PDS support in addition to providing SELECT member name filter patterns.
>
> I'm not saying that it isn't working as designed, but it sure seems like a
> huge miss by IBM to not support the unloading of PDS groups with the new
> command, and then screw the documentation up to look like it does.
>
> In any case, thanks for the responses - it looks like I'm stuck with COPY
> for unload.
>
> --Steve
> Dovetailed Technologies
> www.dovetail.com
>
>
> On Thu, Jul 2, 2020 at 12:58 PM Steve Smith  wrote:
>
> > Obviously, there's an error in the documentation.  Evidently, the manual
> > writer got the two commands mixed up in your first quote.
> >
> > Which is hardly surprising.  Having two commands with a subtle difference
> > in names and behavior is ridiculous.
> >
> > sas
> >
> > On Thu, Jul 2, 2020 at 11:03 AM Steve Goetze 
> wrote:
> >
> > > I'm trying to use IEBCOPY to unload a single PDS member that has
> aliases.
> > > According to IBM's documentation:
> > >
> > >
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/cpogrp.htm
> > > this should be possible:
> > >
> > >  For unloading groups:
> > >   Using COPYGRP: PDSE to PS
> > >   Using COPYGROUP: PDSE to PS, or PDS to PS
> > >
> > >
> >
> > --
> > 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: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Steve Goetze]

I'm not sure that I agree that this was a tech writer command mixup.  The
COPYGROUP statement was created to be a superset of COPYGRP, adding better
PDS support in addition to providing SELECT member name filter patterns.

I'm not saying that it isn't working as designed, but it sure seems like a
huge miss by IBM to not support the unloading of PDS groups with the new
command, and then screw the documentation up to look like it does.

In any case, thanks for the responses - it looks like I'm stuck with COPY
for unload.

--Steve
Dovetailed Technologies
www.dovetail.com


On Thu, Jul 2, 2020 at 12:58 PM Steve Smith  wrote:

> Obviously, there's an error in the documentation.  Evidently, the manual
> writer got the two commands mixed up in your first quote.
>
> Which is hardly surprising.  Having two commands with a subtle difference
> in names and behavior is ridiculous.
>
> sas
>
> On Thu, Jul 2, 2020 at 11:03 AM Steve Goetze  wrote:
>
> > I'm trying to use IEBCOPY to unload a single PDS member that has aliases.
> > According to IBM's documentation:
> >
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/cpogrp.htm
> > this should be possible:
> >
> >  For unloading groups:
> >   Using COPYGRP: PDSE to PS
> >   Using COPYGROUP: PDSE to PS, or PDS to PS
> >
> >
>
> --
> 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: SuperWylbur Users

[Seymour J Metz]

JES TSO Interface Program.


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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, July 2, 2020 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SuperWylbur Users

On Thu, 2 Jul 2020 18:29:46 +, Seymour J Metz wrote:

>JTIP?
>
GIYF?  https://www.google.com/search?q=JTIP

-- 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: SuperWylbur Users

[Paul Gilmartin]

On Thu, 2 Jul 2020 18:29:46 +, Seymour J Metz wrote:

>JTIP?
>
GIYF?  https://www.google.com/search?q=JTIP

-- gil

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

Re: SuperWylbur Users

[Seymour J Metz]

JTIP?


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



From: IBM Mainframe Discussion List  on behalf of 
Longnecker, Dennis 
Sent: Thursday, July 2, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SuperWylbur Users

Yes I did.   Assembles just fine.  Even put the code in to indicate z/OS 2.4.  
Everything works okay except for the fetch...which is what we need.

Dennis

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Monday, June 29, 2020 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SuperWylbur Users

Did you reassemble (assuming Wylbur code is available) with new JES2 macros?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Longnecker, Dennis
> Sent: Monday, June 29, 2020 4:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SuperWylbur Users
>
> Hello -
> Anyone here still using SuperWylbur and have it up and running on a z/OS 2.4
> system?   Bringing up 2.4 now and the JES parts aren't working correctly.
> Before I start digging into the code, I wanted to see if anyone else
> has solved it.
>
> Thanks,
> Dennis
>
> --
> 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: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Tom Conley]

On 7/2/2020 2:06 PM, Kirk Wolf wrote:

How about the original question -
Is there a way to unload from a PDS the "group" (name plus aliases) for a
given member name and reload it to another PDS ?



Kirk,

If you don't have it already, you should install PDS (file 182 at 
cbttape.org).  It has member grouping capability, and supports the XMIT 
command to create an XMIT OUTDATASET that you can transfer and RECEIVE 
INDATASET on the system.  Contact me offline if you want to pursue this 
further.


Regards,
Tom Conley

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

Re: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Kirk Wolf]

How about the original question -
Is there a way to unload from a PDS the "group" (name plus aliases) for a
given member name and reload it to another PDS ?


On Thu, Jul 2, 2020 at 1:02 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 2 Jul 2020 08:40:23 -0700, Lizette Koehler wrote:
>
> >Also review
> >
> >COPYGROUP
> >COPYGRP
> >
> >They behave a little different
> >
> I recall this was discussed here several months ago.
>
> IBM's design was irresponsible.  The two terms are too easily
> confused, particularly in oral communication between two
> parties familiar respectively with one but not the other.
>
> IBM should do the right thing: provide two new commands,
> audibly distinct from COPYGRP, COPYGROUP, and each
> other.  Revise the documentation to:
> COPYGRP:  Obsolete; use  instead.
> COPYGROUP:  Obsolete; use  instead.
>
> RFE?
>
> IBM doesn't care.
>
> -- 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: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Paul Gilmartin]

On Thu, 2 Jul 2020 08:40:23 -0700, Lizette Koehler wrote:

>Also review
>
>COPYGROUP 
>COPYGRP
>
>They behave a little different
> 
I recall this was discussed here several months ago.

IBM's design was irresponsible.  The two terms are too easily
confused, particularly in oral communication between two
parties familiar respectively with one but not the other.

IBM should do the right thing: provide two new commands,
audibly distinct from COPYGRP, COPYGROUP, and each
other.  Revise the documentation to:
COPYGRP:  Obsolete; use  instead.
COPYGROUP:  Obsolete; use  instead.

RFE?

IBM doesn't care.

-- gil

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

Re: SuperWylbur Users

[Longnecker, Dennis]

Yes I did.   Assembles just fine.  Even put the code in to indicate z/OS 2.4.  
Everything works okay except for the fetch...which is what we need.

Dennis

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Monday, June 29, 2020 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SuperWylbur Users

Did you reassemble (assuming Wylbur code is available) with new JES2 macros?

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Longnecker, Dennis
> Sent: Monday, June 29, 2020 4:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SuperWylbur Users
> 
> Hello -
> Anyone here still using SuperWylbur and have it up and running on a z/OS 2.4
> system?   Bringing up 2.4 now and the JES parts aren't working correctly.
> Before I start digging into the code, I wanted to see if anyone else 
> has solved it.
> 
> Thanks,
> Dennis
> 
> --
> 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: Migrate z/OS DASD volumes from Mainframe to Hercules Environment

[Farley, Peter x23353]

+1

And it is more like $5600/yr if I read the ADCD pricing correctly at $900/yr to 
continue support for another year ($4700/yr for the one-CPU dongle, $900/yr for 
the ADCD stack).

So that is about equivalent to buying a new SUV on a 5- or 6-year purchase plan 
(not including insurance), or about $500/mo, and then continuing to pay for it 
for as many years as you want/need to run it.

Not like the one-time cost of a Harley at all.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Grant Taylor
Sent: Thursday, July 2, 2020 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrate z/OS DASD volumes from Mainframe to Hercules Environment

On 7/1/20 10:19 PM, Brian Westerman wrote:
> You can join developerworks and license z/PDT, which is what I and 
> most people do.  It's not that expensive, and it won't kill you like 
> buying that big old Harley-Davidson will.

Does joining DevelperWorks change the pricing?

Because z/PDT (or whatever it's called today) is quite expensive, particulalry 
for hobbyists / students.

I priced it out a few years ago and it was $5,000 per year or $10,000 one time 
w/o any support or updates.

That's decidedly outside of the reach of most hobbyists.

Buying physical equipment and powering it can be less expensive than that.

--

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: z/OS use of "legacy" programming languages

[Seymour J Metz]

> Why do you have to be so hostile? 

Why do you have to be such a hypocrite? I'm not hostile in general. But when 
you rant about imaginary hostility and gratuitously insult me, I see no reason 
to be concerned with your delicate feelings in subsequent messages.

> I did not see any mention of OS compatibility. That is precisely why I 
> mentioned it.

You wrote "If you are going to include OS compatibility as well as hardware 
compatibility"; that certainly seems to be a false claim that I mentioned it.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Thursday, July 2, 2020 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

Why do you have to be so hostile? I did not see any mention of OS
compatibility. That is precisely why I mentioned it. I raised additional
issues beyond what you raised. WTF indeed.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, July 2, 2020 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

WTF? Where do you see "OS compatibility"? The issues that I raised were all
architecture and instruction set.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Thursday, July 2, 2020 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

If you are going to include OS compatibility as well as hardware
compatibility then there are issues such as control blocks that have been
moved above line.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, July 2, 2020 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

> The only thing which might not work would
> be something which was CPU speed dependent.

That's not the only thing. A program that relies on getting certain program
interrupts might fail. Then there's the ASCII bit, although I would be very
surprised if anybody actually used it. There are optional instructions that
IBM carried over. There's probably more that I haven't thought of.

--
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: RACF-SailPoint

[Ron Wells]

Tks for the info--anything else will be helpful ..
Smartphones not that smart..

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Thursday, July 02, 2020 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

** EXTERNAL EMAIL - USE CAUTION **


I have and usually the biggest problem is the intigrator

Sent from my iPhone

I promise you I can’t type or
Spell on any smartphone

> On Jul 2, 2020, at 08:15, Ron Wells 
> <02ebc63ff5ef-dmarc-requ...@listserv.ua.edu> wrote:
>
> Unfortunately --- lol
> What experiences/problems you have had on MF
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jackson, Rob
> Sent: Thursday, July 02, 2020 8:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF-SailPoint
>
> ** EXTERNAL EMAIL - USE CAUTION **
>
>
> Unfortunately, yes.  We run it.
>
> First Horizon Bank
> Mainframe Technical Support
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ron Wells
> Sent: Thursday, July 2, 2020 8:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF-SailPoint
>
> [External Email. Exercise caution when clicking links or opening
> attachments.]
>
> Anyone have any dealing with Sailpoint product..
>
>
> Email Disclaimer
>
> This E-mail contains confidential information belonging to the sender, which 
> may be legally privileged information. This information is intended only for 
> the use of the individual or entity addressed above. If you are not the 
> intended recipient, or an employee or agent responsible for delivering it to 
> the intended recipient, you are hereby notified that any disclosure, copying, 
> distribution, or the taking of any action in reliance on the contents of the 
> E-mail or attached files is strictly prohibited.

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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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

Re: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Charles Mills]

FWIW there was a long thread here on COPYGRP/COPYGROUP March 3 through 6 of 
this year.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Thursday, July 2, 2020 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

Obviously, there's an error in the documentation.  Evidently, the manual
writer got the two commands mixed up in your first quote.

Which is hardly surprising.  Having two commands with a subtle difference
in names and behavior is ridiculous.

sas

On Thu, Jul 2, 2020 at 11:03 AM Steve Goetze  wrote:

> I'm trying to use IEBCOPY to unload a single PDS member that has aliases.
> According to IBM's documentation:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/cpogrp.htm
> this should be possible:
>
>  For unloading groups:
>   Using COPYGRP: PDSE to PS
>   Using COPYGROUP: PDSE to PS, or PDS to PS
>
>

--
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 use of "legacy" programming languages

[Charles Mills]

Why do you have to be so hostile? I did not see any mention of OS
compatibility. That is precisely why I mentioned it. I raised additional
issues beyond what you raised. WTF indeed.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, July 2, 2020 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

WTF? Where do you see "OS compatibility"? The issues that I raised were all
architecture and instruction set.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Thursday, July 2, 2020 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

If you are going to include OS compatibility as well as hardware
compatibility then there are issues such as control blocks that have been
moved above line.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, July 2, 2020 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

> The only thing which might not work would
> be something which was CPU speed dependent.

That's not the only thing. A program that relies on getting certain program
interrupts might fail. Then there's the ASCII bit, although I would be very
surprised if anybody actually used it. There are optional instructions that
IBM carried over. There's probably more that I haven't thought of.

--
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: Migrate z/OS DASD volumes from Mainframe to Hercules Environment

[Grant Taylor]

On 7/1/20 10:19 PM, Brian Westerman wrote:
You can join developerworks and license z/PDT, which is what I and 
most people do.  It's not that expensive, and it won't kill you like 
buying that big old Harley-Davidson will.


Does joining DevelperWorks change the pricing?

Because z/PDT (or whatever it's called today) is quite expensive, 
particulalry for hobbyists / students.


I priced it out a few years ago and it was $5,000 per year or $10,000 
one time w/o any support or updates.


That's decidedly outside of the reach of most hobbyists.

Buying physical equipment and powering it can be less expensive than that.



--
Grant. . . .
unix || die

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

Re: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Steve Smith]

Obviously, there's an error in the documentation.  Evidently, the manual
writer got the two commands mixed up in your first quote.

Which is hardly surprising.  Having two commands with a subtle difference
in names and behavior is ridiculous.

sas

On Thu, Jul 2, 2020 at 11:03 AM Steve Goetze  wrote:

> I'm trying to use IEBCOPY to unload a single PDS member that has aliases.
> According to IBM's documentation:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/cpogrp.htm
> this should be possible:
>
>  For unloading groups:
>   Using COPYGRP: PDSE to PS
>   Using COPYGROUP: PDSE to PS, or PDS to PS
>
>

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

Re: z/OS use of "legacy" programming languages

[Seymour J Metz]

WTF? Where do you see "OS compatibility"? The issues that I raised were all 
architecture and instruction set.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Thursday, July 2, 2020 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

If you are going to include OS compatibility as well as hardware
compatibility then there are issues such as control blocks that have been
moved above line.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, July 2, 2020 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

> The only thing which might not work would
> be something which was CPU speed dependent.

That's not the only thing. A program that relies on getting certain program
interrupts might fail. Then there's the ASCII bit, although I would be very
surprised if anybody actually used it. There are optional instructions that
IBM carried over. There's probably more that I haven't thought of.

--
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 use of "legacy" programming languages

[Charles Mills]

If you are going to include OS compatibility as well as hardware
compatibility then there are issues such as control blocks that have been
moved above line. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, July 2, 2020 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

> The only thing which might not work would
> be something which was CPU speed dependent.

That's not the only thing. A program that relies on getting certain program
interrupts might fail. Then there's the ASCII bit, although I would be very
surprised if anybody actually used it. There are optional instructions that
IBM carried over. There's probably more that I haven't thought of.

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

Re: z/OS use of "legacy" programming languages

[Seymour J Metz]

Try running, e.g., IBM 7094 EMULATOR  FOR THE SYSTEM/360 MODEL 85 UNDER OS/360 
PROGRAM NUMBER 360C-EU-134. 


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe 
Monk [joemon...@gmail.com]
Sent: Thursday, July 2, 2020 6:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

Honestly, this whole discussion is kind of pointless, no?

z/os  IBM/390 IBM/370 IBM/360 all share ... instruction set. While the
newer models all have newer instructions, object code assembled on a 360 is
just as valid today as it was in 1960.

Joe

On Thu, Jul 2, 2020 at 4:13 AM R.S.  wrote:

> W dniu 01.07.2020 o 20:57, Frank Swarbrick pisze:
> > Thanks Tim.
> >
> > I can't imagine being comfortable writing new code, at least, for a
> compiler that has not been updated in 35 years, but maybe that's just me.
> 
> >
> > Now that we know what languages are still supported, I am still curious
> if anyone out there is actually still using them, and if so, why.
>
> 1. I'm pretty sure there are users of those compilers, this is the only
> reason to keep them under support.
> 2. I guess the users do not create new applications from scratch rather
> they maintain and update existing applications. Is it safe to use so old
> compiler? It is safe to use *supported* compiler. Age has no big meaning
> here, what would you say for 7 years old, but unsupported compiler?
>
> BTW: As a mainframe bigot I sometimes am forced to explain why so old
> things are still in use. Yes, z14 or z15 is veery old. As old as
> z/OS 2.4, or DB2. It is hard job, because usually nobody want to hear
> answers, but one of my favorite is the wheel. Wheel is quite old idea,
> but still in common use. They say M$ introduced a car without wheels or
> the the wheels are enhanced - square...
> Last, but not least: some 20 years old COBOL code is not obsoleted by
> changes in the OS/compiler/whatever, but code on Windows *had* to be
> rewritten several times during this period. Dot net? It was so modern
> just few years ago and now is obsolete. Note: that means programming
> effort just to upgrade system, without any application (business logic)
> changes.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> http://secure-web.cisco.com/11sx4kd-r24NXpEnvqzB6vJVt3n4xNQ8hlxyIlLyTqeHrBh1t2hGze1c5JQEIt_D_RMGFt79ys-IkwmwGK7jUxkvyIL-ectqjZzyax4H4NlPHAPAx2FRZRJNTG7AnOqAmA3SVqwmpqBOxYEHlgWCz-6-4z2xVMBrux_n9Ch_P-yZIiSPd3dBquoCrwyuV8TbN6SJ3uVVs5ji7jkk0pFMbKlmRq0y5CPBU3O_q3L5YuSdikHVRypkyIYrmSpJiD9QUwpEw4OWGDhXERbKj9cerUhwGLwRqVdqBZUaJmHuyJuYKLCZRls_1D7zpApiAsrw7iEafQCVLB-s5YIQwkPDn2JSBr-Jw2N_QiKVTBZfLDn02NLK_mwTMBCsYJQ-t7lld6AExqVz-t74oh2Z7urh8A4_hgVmval94Jur6sn7BEeFLI278OsRFwlz8YCQsKEHN/http%3A%2F%2Fwww.mBank.pl,
>  e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,http://secure-web.cisco.com/11sx4kd-r24NXpEnvqzB6vJVt3n4xNQ8hlxyIlLyTqeHrBh1t2hGze1c5JQEIt_D_RMGFt79ys-IkwmwGK7jUxkvyIL-ectqjZzyax4H4NlPHAPAx2FRZRJNTG7AnOqAmA3SVqwmpqBOxYEHlgWCz-6-4z2xVMBrux_n9Ch_P-yZIiSPd3dBquoCrwyuV8TbN6SJ3uVVs5ji7jkk0pFMbKlmRq0y5CPBU3O_q3L5YuSdikHVRypkyIYrmSpJiD9QUwpEw4OWGDhXERbKj9cerUhwGLwRqVdqBZUaJmHuyJuYKLCZRls_1D7zpApiAsrw7iEafQCVLB-s5YIQwkPDn2JSBr-Jw2N_QiKVTBZfLDn02NLK_mwTMBCsYJQ-t7lld6AExqVz-t74oh2Z7urh8A4_hgVmval94Jur6sn7BEeFLI278OsRFwlz8YCQsKEHN/http%3A%2F%2Fwww.mBank.pl,
>  e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 

Re: z/OS use of "legacy" programming languages

[Seymour J Metz]

> The only thing which might not work would
> be something which was CPU speed dependent.

That's not the only thing. A program that relies on getting certain program 
interrupts might fail. Then there's the ASCII bit, although I would be very 
surprised if anybody actually used it. There are optional instructions that IBM 
carried over. There's probably more that I haven't thought of.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
John McKown [john.archie.mck...@gmail.com]
Sent: Thursday, July 2, 2020 7:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS use of "legacy" programming languages

On Thu, Jul 2, 2020 at 5:56 AM Joe Monk  wrote:

> Honestly, this whole discussion is kind of pointless, no?
>
> z/os  IBM/390 IBM/370 IBM/360 all share ... instruction set. While the
> newer models all have newer instructions, object code assembled on a 360 is
> just as valid today as it was in 1960.
>

Yeap. IEFBR14 still works! {grin} The only thing which might not work would
be something which was CPU speed dependent. And such programs are
specifically mentioned in the POPS as "non-conformant" (my word). This
generally doesn't mean much, but it can lead to a "race" condition being
observed on a faster or slower machine in an improperly coded multitasking
environment. Or even an environment which has more or fewer CPs enabled.



>
> Joe
>
> --
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

--
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: RACF-SailPoint

[Steve Beaver]

I have and usually the biggest problem is the intigrator

Sent from my iPhone

I promise you I can’t type or
Spell on any smartphone 

> On Jul 2, 2020, at 08:15, Ron Wells 
> <02ebc63ff5ef-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Unfortunately --- lol
> What experiences/problems you have had on MF
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Jackson, Rob
> Sent: Thursday, July 02, 2020 8:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF-SailPoint
> 
> ** EXTERNAL EMAIL - USE CAUTION **
> 
> 
> Unfortunately, yes.  We run it.
> 
> First Horizon Bank
> Mainframe Technical Support
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Ron Wells
> Sent: Thursday, July 2, 2020 8:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF-SailPoint
> 
> [External Email. Exercise caution when clicking links or opening attachments.]
> 
> Anyone have any dealing with Sailpoint product..
> 
> 
> Email Disclaimer
> 
> This E-mail contains confidential information belonging to the sender, which 
> may be legally privileged information. This information is intended only for 
> the use of the individual or entity addressed above. If you are not the 
> intended recipient, or an employee or agent responsible for delivering it to 
> the intended recipient, you are hereby notified that any disclosure, copying, 
> distribution, or the taking of any action in reliance on the contents of the 
> E-mail or attached files is strictly prohibited.

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

Re: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Steve Goetze]

Hi Lizette,

Unfortunately, COPYMOD can't create an unload data set.

--Steve
Dovetailed Technologies
www.dovetail.com


On Thu, Jul 2, 2020 at 11:33 AM Lizette Koehler 
wrote:

> Are the members Source or LOAD modules?
>
> If Load modules, use COPYMOD
>
> Lizette
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Steve Goetze
> Sent: Thursday, July 2, 2020 8:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Using IEBCOPY COPYGROUP to unload a PDS member with aliases
>
> I'm trying to use IEBCOPY to unload a single PDS member that has aliases.
> According to IBM's documentation:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/cpogrp.htm
> this should be possible:
>
>  For unloading groups:
>   Using COPYGRP: PDSE to PS
>   Using COPYGROUP: PDSE to PS, or PDS to PS
>
> IBM even called out this new capability in a 2013 SHARE presentation.
>
> But this is contradicted by the usage notes:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/u1096b.htm
>
>  COPYGROUP cannot be used to load to a PDS or unload from a PDS.
>
> Some basic tests on my V2R3 system confirm that COPYGROUP can be used to
> unload PDSE members, but not PDS members (whether data members or load
> modules)
>
> Am I missing something, or misreading the documentation?  Is there a
> different way to unload a PDS member along with its aliases?
>
> Thanks,
> --Steve Goetze
> Dovetailed Technologies
> www.dovetail.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
>

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

Re: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Lizette Koehler]

Also review

COPYGROUP 
COPYGRP

They behave a little different

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lizette Koehler
Sent: Thursday, July 2, 2020 8:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

Are the members Source or LOAD modules?

If Load modules, use COPYMOD

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Goetze
Sent: Thursday, July 2, 2020 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

I'm trying to use IEBCOPY to unload a single PDS member that has aliases.
According to IBM's documentation:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/cpogrp.htm
this should be possible:

 For unloading groups:
  Using COPYGRP: PDSE to PS
  Using COPYGROUP: PDSE to PS, or PDS to PS

IBM even called out this new capability in a 2013 SHARE presentation.

But this is contradicted by the usage notes:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/u1096b.htm

 COPYGROUP cannot be used to load to a PDS or unload from a PDS.

Some basic tests on my V2R3 system confirm that COPYGROUP can be used to unload 
PDSE members, but not PDS members (whether data members or load
modules)

Am I missing something, or misreading the documentation?  Is there a different 
way to unload a PDS member along with its aliases?

Thanks,
--Steve Goetze
Dovetailed Technologies
www.dovetail.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

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

Re: When did .net become obsolete? was Re: z/OS use of "legacy" programming languages

[Joe Monk]

.NET 3.5 includes all earlier versions.

Current .NET is 4.8.x which include 4.6.2 and 4.7.2.

Joe

On Thu, Jul 2, 2020 at 9:39 AM Clark Morris  wrote:

> [Default] On 2 Jul 2020 02:13:34 -0700, in bit.listserv.ibm-main
> r.skoru...@bremultibank.com.pl (R.S.) wrote:
>
> >> snip
> >
> >BTW: As a mainframe bigot I sometimes am forced to explain why so old
> >things are still in use. Yes, z14 or z15 is veery old. As old as
> >z/OS 2.4, or DB2. It is hard job, because usually nobody want to hear
> >answers, but one of my favorite is the wheel. Wheel is quite old idea,
> >but still in common use. They say M$ introduced a car without wheels or
> >the the wheels are enhanced - square...
> >Last, but not least: some 20 years old COBOL code is not obsoleted by
> >changes in the OS/compiler/whatever, but code on Windows *had* to be
> >rewritten several times during this period. Dot net? It was so modern
> >just few years ago and now is obsolete. Note: that means programming
> >effort just to upgrade system, without any application (business logic)
> >changes.
>
> When did dot net become obsolete?  Versions earlier than 3 are no
> longer supported but when I did a search for dot net both the
> Microsoft pointers and the wiki article seemed to show it is very much
> alive and is now open source.  The original implantation was well
> before 2010 and was starting to be open sourced before then.
>
> Clark Morris
>
> Clark Morris
>
> --
> 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: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Lizette Koehler]

Are the members Source or LOAD modules?

If Load modules, use COPYMOD

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Goetze
Sent: Thursday, July 2, 2020 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using IEBCOPY COPYGROUP to unload a PDS member with aliases

I'm trying to use IEBCOPY to unload a single PDS member that has aliases.
According to IBM's documentation:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/cpogrp.htm
this should be possible:

 For unloading groups:
  Using COPYGRP: PDSE to PS
  Using COPYGROUP: PDSE to PS, or PDS to PS

IBM even called out this new capability in a 2013 SHARE presentation.

But this is contradicted by the usage notes:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/u1096b.htm

 COPYGROUP cannot be used to load to a PDS or unload from a PDS.

Some basic tests on my V2R3 system confirm that COPYGROUP can be used to unload 
PDSE members, but not PDS members (whether data members or load
modules)

Am I missing something, or misreading the documentation?  Is there a different 
way to unload a PDS member along with its aliases?

Thanks,
--Steve Goetze
Dovetailed Technologies
www.dovetail.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

Using IEBCOPY COPYGROUP to unload a PDS member with aliases

[Steve Goetze]

I'm trying to use IEBCOPY to unload a single PDS member that has aliases.
According to IBM's documentation:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/cpogrp.htm
this should be possible:

 For unloading groups:
  Using COPYGRP: PDSE to PS
  Using COPYGROUP: PDSE to PS, or PDS to PS

IBM even called out this new capability in a 2013 SHARE presentation.

But this is contradicted by the usage notes:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/u1096b.htm

 COPYGROUP cannot be used to load to a PDS or unload from a PDS.

Some basic tests on my V2R3 system confirm that COPYGROUP can be used to
unload PDSE members, but not PDS members (whether data members or load
modules)

Am I missing something, or misreading the documentation?  Is there a
different way to unload a PDS member along with its aliases?

Thanks,
--Steve Goetze
Dovetailed Technologies
www.dovetail.com

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

When did .net become obsolete? was Re: z/OS use of "legacy" programming languages

[Clark Morris]

[Default] On 2 Jul 2020 02:13:34 -0700, in bit.listserv.ibm-main
r.skoru...@bremultibank.com.pl (R.S.) wrote:

>> snip
>
>BTW: As a mainframe bigot I sometimes am forced to explain why so old 
>things are still in use. Yes, z14 or z15 is veery old. As old as 
>z/OS 2.4, or DB2. It is hard job, because usually nobody want to hear 
>answers, but one of my favorite is the wheel. Wheel is quite old idea, 
>but still in common use. They say M$ introduced a car without wheels or 
>the the wheels are enhanced - square...
>Last, but not least: some 20 years old COBOL code is not obsoleted by 
>changes in the OS/compiler/whatever, but code on Windows *had* to be 
>rewritten several times during this period. Dot net? It was so modern 
>just few years ago and now is obsolete. Note: that means programming 
>effort just to upgrade system, without any application (business logic) 
>changes.

When did dot net become obsolete?  Versions earlier than 3 are no
longer supported but when I did a search for dot net both the
Microsoft pointers and the wiki article seemed to show it is very much
alive and is now open source.  The original implantation was well
before 2010 and was starting to be open sourced before then.

Clark Morris

Clark Morris 

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

Re: RACF-SailPoint

[David Spiegel]

"... BREECH ..." Congratulations on the new baby!

On 2020-07-02 09:19, Ron Wells wrote:

That is what concerns me...too me it is a BREECH of security

Want to stay off list.. my email is ron.we...@omf.com

They only mentioned a exit/api needs to be installed >> bother me ... trying to 
get pros/cons and what others have experienced..

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Thursday, July 02, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

** EXTERNAL EMAIL - USE CAUTION **


Unfortunately, yes, a bit.  I only have to deal with the mainframe connector 
and at this point it's only used for reporting but they're looking at making it 
do a bunch more.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] RACF-SailPoint

Anyone have any dealing with Sailpoint product..


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

--
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 use of "legacy" programming languages

[Clark Morris]

[Default] On 1 Jul 2020 21:39:05 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>Do you mean only that IBM has changed the underlying hardware used to 
>implement what they called Machine Interface (MI) on the S/38, or do you mean 
>that they have changed the MI itself?
I don't know enough about the boxes to say.  I just was fairly certain
that the hardware instruction set for the s38/AS400 differed from IBM
i.

Clark Morris

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

Re: RACF-SailPoint

[Pommier, Rex]

Fortunately I didn't have to put my foot down.  We also only use the offline 
interceptor.  I agree that the SP folks only understand AD so when they brought 
it in, they dropped the mainframe manual on my desk and said "here, install 
this and let us know when it's done" so I got free rein and made the 'executive 
decision' to only use the offline interceptor.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jackson, Rob
Sent: Thursday, July 2, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: RACF-SailPoint

The exits are needed only if you use the Online Interceptor (send RACF admin 
commands to SailPoint).  We do not use that; I didn't put my foot down (but I 
would have); instead, I gently steered them to nightly/on-demand Aggregation 
only, and that has been good enough.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

[External Email. Exercise caution when clicking links or opening attachments.]

That is what concerns me...too me it is a BREECH of security

Want to stay off list.. my email is ron.we...@omf.com

They only mentioned a exit/api needs to be installed >> bother me ... trying to 
get pros/cons and what others have experienced..

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Thursday, July 02, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

** EXTERNAL EMAIL - USE CAUTION **


Unfortunately, yes, a bit.  I only have to deal with the mainframe connector 
and at this point it's only used for reporting but they're looking at making it 
do a bunch more.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] RACF-SailPoint

Anyone have any dealing with Sailpoint product..


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality 
notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
For 

Re: RACF-SailPoint

[Jackson, Rob]

The exits are needed only if you use the Online Interceptor (send RACF admin 
commands to SailPoint).  We do not use that; I didn't put my foot down (but I 
would have); instead, I gently steered them to nightly/on-demand Aggregation 
only, and that has been good enough.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

[External Email. Exercise caution when clicking links or opening attachments.]

That is what concerns me...too me it is a BREECH of security

Want to stay off list.. my email is ron.we...@omf.com

They only mentioned a exit/api needs to be installed >> bother me ... trying to 
get pros/cons and what others have experienced..

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Thursday, July 02, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

** EXTERNAL EMAIL - USE CAUTION **


Unfortunately, yes, a bit.  I only have to deal with the mainframe connector 
and at this point it's only used for reporting but they're looking at making it 
do a bunch more.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] RACF-SailPoint

Anyone have any dealing with Sailpoint product..


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

Re: RACF-SailPoint

[Jackson, Rob]

As with Rex, I deal only with the Connector.  The install is kind of kludgy, 
but it's not bad.  If I remember correctly, the security setup for the service 
accounts (requires two) was not well documented.

Unlike Rex, we use ours for dynamic provisioning right now.  Users request and 
get approvals for entitlements in SailPoint; they are immediately provisioned 
in RACF.

The hardest part, by far, was mapping RACF resources to the SailPoint 
structures on the other end.  They still don't match up quite right (and TSO 
segments, etc., are still manual; they couldn't figure that out).  The folks on 
that end speak AD; RACF is a foreign concept to them.  It took them at least a 
year, and perhaps eighteen months, to roll it out.

A few things if you implement it:
Don't wait until it fails--grow your QUEUE file by at least ten times over 
delivered values right at the start.
Expect issues with Aggregation (we use online; offline _sounds_ problematic); 
it is slow and fails often.  The latest Gateway has improved it a lot, but it 
has taken years.
When de-provisioning users, SP disconnects all groups; you will find the need 
to set up a default group for most/all users with no permits and code that into 
SP as something it cannot remove.

Also, and my biggest gripe, which is only operational:  we have a limited 
number of sysplexes and RACF databases, so dev SP points at the sysprog 
sandbox; QA SP points at our "production integration" environment, and prod SP 
points at prod/dev.  I do not know how many times I have had to recover the 
RACF database in dev/QA from the console because the SP folks have 
deprovisioned all the sysprog accounts; they are also fond of removing groups 
from the operators, etc.  Forgive them, for they know not what they do, I 
suppose.

On the bright side, the user exits are in REXX and are easy to use and 
implement.  Lots of exit points as well.  (One we use, for instance, cleans up 
user datasets and aliases upon deprovisioning.)

There are other things I'm forgetting right now; if I think of any, I'll post 
again.

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 9:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

[External Email. Exercise caution when clicking links or opening attachments.]

Unfortunately --- lol
What experiences/problems you have had on MF

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jackson, Rob
Sent: Thursday, July 02, 2020 8:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

** EXTERNAL EMAIL - USE CAUTION **


Unfortunately, yes.  We run it.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 8:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF-SailPoint

[External Email. Exercise caution when clicking links or opening attachments.]

Anyone have any dealing with Sailpoint product..


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any 

Re: RACF-SailPoint

[Ron Wells]

That is what concerns me...too me it is a BREECH of security

Want to stay off list.. my email is ron.we...@omf.com

They only mentioned a exit/api needs to be installed >> bother me ... trying to 
get pros/cons and what others have experienced..

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Thursday, July 02, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

** EXTERNAL EMAIL - USE CAUTION **


Unfortunately, yes, a bit.  I only have to deal with the mainframe connector 
and at this point it's only used for reporting but they're looking at making it 
do a bunch more.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] RACF-SailPoint

Anyone have any dealing with Sailpoint product..


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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

Re: RACF-SailPoint

[Pommier, Rex]

Unfortunately, yes, a bit.  I only have to deal with the mainframe connector 
and at this point it's only used for reporting but they're looking at making it 
do a bunch more.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] RACF-SailPoint

Anyone have any dealing with Sailpoint product..


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: RACF-SailPoint

[Ron Wells]

Unfortunately --- lol
What experiences/problems you have had on MF

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jackson, Rob
Sent: Thursday, July 02, 2020 8:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF-SailPoint

** EXTERNAL EMAIL - USE CAUTION **


Unfortunately, yes.  We run it.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 8:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF-SailPoint

[External Email. Exercise caution when clicking links or opening attachments.]

Anyone have any dealing with Sailpoint product..


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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

Re: RACF-SailPoint

[Jackson, Rob]

Unfortunately, yes.  We run it.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Wells
Sent: Thursday, July 2, 2020 8:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF-SailPoint

[External Email. Exercise caution when clicking links or opening attachments.]

Anyone have any dealing with Sailpoint product..


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

RACF-SailPoint

[Ron Wells]

Anyone have any dealing with Sailpoint product..


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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

Re: Sort Jcl to build a Update table control card

[Ron Thomas]

Thanks a bunch Kolusu..

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

Re: Automation message id for TCPIP and monitoring

[John McKown]

On Thu, Jul 2, 2020 at 6:20 AM John McKown 
wrote:

> On Thu, Jul 2, 2020 at 6:04 AM Jake Anderson 
> wrote:
>
>> Hello
>>
>> Cross posted
>>
>> Could someone have list of message ID of vtam and TCPIP which you normally
>> monitor via automation product ?
>>
>> Jake
>>
>>
> The basics of our network startup.
>
> JES2 automatically starts at IPL.
> Message $HASP492 from JES2 starts VTAM (and others)
> Message IST020I from VTAM starts TCPIP (and others)
> Message EZAIN11I from TCPIP starts TN3270 (and others)
>
> --
> People in sleeping bags are the soft tacos of the bear world.
> Maranatha! <><
> John McKown
>
OOPS. I don't think that's what you were asking. I haven't had my morning
caffeine infusion, so my brain is sluggish. We don't actually have any
messages which we monitor, other than the above which are only for startup
of the system.



-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

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

Re: Automation message id for TCPIP and monitoring

[John McKown]

On Thu, Jul 2, 2020 at 6:04 AM Jake Anderson 
wrote:

> Hello
>
> Cross posted
>
> Could someone have list of message ID of vtam and TCPIP which you normally
> monitor via automation product ?
>
> Jake
>
>
The basics of our network startup.

JES2 automatically starts at IPL.
Message $HASP492 from JES2 starts VTAM (and others)
Message IST020I from VTAM starts TCPIP (and others)
Message EZAIN11I from TCPIP starts TN3270 (and others)

-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

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

Re: z/OS use of "legacy" programming languages

[John McKown]

On Thu, Jul 2, 2020 at 5:56 AM Joe Monk  wrote:

> Honestly, this whole discussion is kind of pointless, no?
>
> z/os  IBM/390 IBM/370 IBM/360 all share ... instruction set. While the
> newer models all have newer instructions, object code assembled on a 360 is
> just as valid today as it was in 1960.
>

Yeap. IEFBR14 still works! {grin} The only thing which might not work would
be something which was CPU speed dependent. And such programs are
specifically mentioned in the POPS as "non-conformant" (my word). This
generally doesn't mean much, but it can lead to a "race" condition being
observed on a faster or slower machine in an improperly coded multitasking
environment. Or even an environment which has more or fewer CPs enabled.



>
> Joe
>
> --
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

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

Automation message id for TCPIP and monitoring

[Jake Anderson]

Hello

Cross posted

Could someone have list of message ID of vtam and TCPIP which you normally
monitor via automation product ?

Jake

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

Re: z/OS use of "legacy" programming languages

[Joe Monk]

Honestly, this whole discussion is kind of pointless, no?

z/os  IBM/390 IBM/370 IBM/360 all share ... instruction set. While the
newer models all have newer instructions, object code assembled on a 360 is
just as valid today as it was in 1960.

Joe

On Thu, Jul 2, 2020 at 4:13 AM R.S.  wrote:

> W dniu 01.07.2020 o 20:57, Frank Swarbrick pisze:
> > Thanks Tim.
> >
> > I can't imagine being comfortable writing new code, at least, for a
> compiler that has not been updated in 35 years, but maybe that's just me.
> 
> >
> > Now that we know what languages are still supported, I am still curious
> if anyone out there is actually still using them, and if so, why.
>
> 1. I'm pretty sure there are users of those compilers, this is the only
> reason to keep them under support.
> 2. I guess the users do not create new applications from scratch rather
> they maintain and update existing applications. Is it safe to use so old
> compiler? It is safe to use *supported* compiler. Age has no big meaning
> here, what would you say for 7 years old, but unsupported compiler?
>
> BTW: As a mainframe bigot I sometimes am forced to explain why so old
> things are still in use. Yes, z14 or z15 is veery old. As old as
> z/OS 2.4, or DB2. It is hard job, because usually nobody want to hear
> answers, but one of my favorite is the wheel. Wheel is quite old idea,
> but still in common use. They say M$ introduced a car without wheels or
> the the wheels are enhanced - square...
> Last, but not least: some 20 years old COBOL code is not obsoleted by
> changes in the OS/compiler/whatever, but code on Windows *had* to be
> rewritten several times during this period. Dot net? It was so modern
> just few years ago and now is obsolete. Note: that means programming
> effort just to upgrade system, without any application (business logic)
> changes.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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 use of "legacy" programming languages

[R.S.]

W dniu 01.07.2020 o 20:57, Frank Swarbrick pisze:

Thanks Tim.

I can't imagine being comfortable writing new code, at least, for a compiler 
that has not been updated in 35 years, but maybe that's just me.  

Now that we know what languages are still supported, I am still curious if 
anyone out there is actually still using them, and if so, why.


1. I'm pretty sure there are users of those compilers, this is the only 
reason to keep them under support.
2. I guess the users do not create new applications from scratch rather 
they maintain and update existing applications. Is it safe to use so old 
compiler? It is safe to use *supported* compiler. Age has no big meaning 
here, what would you say for 7 years old, but unsupported compiler?


BTW: As a mainframe bigot I sometimes am forced to explain why so old 
things are still in use. Yes, z14 or z15 is veery old. As old as 
z/OS 2.4, or DB2. It is hard job, because usually nobody want to hear 
answers, but one of my favorite is the wheel. Wheel is quite old idea, 
but still in common use. They say M$ introduced a car without wheels or 
the the wheels are enhanced - square...
Last, but not least: some 20 years old COBOL code is not obsoleted by 
changes in the OS/compiler/whatever, but code on Windows *had* to be 
rewritten several times during this period. Dot net? It was so modern 
just few years ago and now is obsolete. Note: that means programming 
effort just to upgrade system, without any application (business logic) 
changes.


--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

syslogd assist

[Lionel B Dyck]

I recently enabled syslogd and have it logging to operlog.  I now see
messages like this and could use some advice on how to resolve:

 

BPXF060I LOGGED BY SYSLOGD FROM A LOCAL SOURCE 000

Jul  2 08:33:52 S0W1 sshd[65785]: error: FOTS1503 __passwd: EDC5143I  

No such process. (errno2=0x090C05DD)  

BPXF060I LOGGED BY SYSLOGD FROM A LOCAL SOURCE 000

Jul  2 08:33:52 S0W1 sshd[65785]: error: FOTS3214 cleanup_exit:   

kill(65788): EDC5139I Operation not permitted. (errno2=0x0D100114)

 

thanks

 

 

Lionel B. Dyck <
Website:   https://www.lbdsoftware.com

"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

Re: Announcement: CICS Auxiliary Trace Visualizer (new version 2.0)

[kekronbekron]

Very cool, thank you!

- KB

‐‐‐ Original Message ‐‐‐
On Thursday, July 2, 2020 12:52 PM, Andrew Armstrong 
 wrote:

> Hi all,
>
> I've recently modernised the aux2svg rexx procedure - which, until now, was 
> packaged as an example in the RexxXMLParser github repository and CBT FILE647 
> - and moved it to a separate github respository at:
>
> https://github.com/abend0c1/aux2svg
>
> The new version (which I last updated in 2005!) now supports CICS TS 5 
> auxiliary traces. Not a lot has changed since CICS TS 3, except for a few new 
> trace domains, but quite a lot has improved in the SVG area since then so I 
> thought it was time for an update.
>
> In summary, aux2svg creates a graphical representation of a CICS auxiliary 
> trace printout by using Scalable Vector Graphics (SVG). The SVG markup 
> represents the trace data in the form of a Unified Modelling Language (UML) 
> Sequence Diagram (or at least something quite like it). You can view the 
> resulting HTML file using any modern web browser.
>
> The aim is to help you resolve CICS problems more easily.
>
> The aux2svg example in https://github.com/abend0c1/rexxxmlparser has been 
> replaced with a comment redirecting you to the new repository.
>
> Enjoy!
>
> Andrew.
>
> -
>
> 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: IPSEC Configuration and Performance

[kekronbekron]

Ditto, sorry to go "off-topic" again ... I hope IBM is reading this, and hope 
they look to adding WireGuard support on Z.
>From what little I know, WireGuard is far more manageable and performant than 
>IPSec & IKEv2.
Adding WireGuard support to z/OS shouldn't be too much of a "deviation" too, 
considering that the Linux kernel and OpenBSD now come baked-in with WG.

Link - https://www.wireguard.com/

- KB

‐‐‐ Original Message ‐‐‐
On Thursday, July 2, 2020 4:11 AM, Grant Taylor 
<023065957af1-dmarc-requ...@listserv.ua.edu> wrote:

> On 7/1/20 1:49 PM, Crawford, Robert C. wrote:
>
> > We're considering using IPSEC to secure traffic between an internal
> > router and a CICS application. Can anyone on this list give us any
> > hints, tips or gotchas they may have from doing something similar
> > themselves.
>
> I can't help.
>
> But I'd love to be a fly on the wall and learn.
>
> I've also got some questions, but that's more active than fly on the wall.
>
>
> --
>
> Grant. . . .
> unix || die
>
> -
>
> 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

Announcement: CICS Auxiliary Trace Visualizer (new version 2.0)

[Andrew Armstrong]

Hi all,

I've recently modernised the aux2svg rexx procedure - which, until now, was 
packaged as an example in the RexxXMLParser github repository and CBT FILE647 - 
and moved it to a separate github respository at:

https://github.com/abend0c1/aux2svg

The new version (which I last updated in 2005!) now supports CICS TS 5 
auxiliary traces. Not a lot has changed since CICS TS 3, except for a few new 
trace domains, but quite a lot has improved in the SVG area since then so I 
thought it was time for an update.

In summary, aux2svg creates a graphical representation of a CICS auxiliary 
trace printout by using Scalable Vector Graphics (SVG). The SVG markup 
represents the trace data in the form of a Unified Modelling Language (UML) 
Sequence Diagram (or at least something quite like it). You can view the 
resulting HTML file using any modern web browser.

The aim is to help you resolve CICS problems more easily.

The aux2svg example in https://github.com/abend0c1/rexxxmlparser has been 
replaced with a comment redirecting you to the new repository.

Enjoy!

Andrew.

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