Address space dump for Exit usage

[Jake Anderson]

Hi

Cross posted

When we take a SVCDUMP for an active address space . Does the dump shows if
that particular address space uses particular EXIT ? I am just trying to
understand if a dump of an address space can help me to determine if a
particular exit is being used or not .

Any pointers would be appreciated.

Jake

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

Re: JES2 shutdown failure - OMVS will not shut down

[Brian Westerman]

At the point in time where I shut down ZFS, I want it to interfere, that's the 
whole point.

Brian

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

Re: LE question

[Brian Westerman]

HI,

ALL commands issued at a console or from a program or JCL are processed in the 
command exit, whether they are JES or MVS commands or just random text typed on 
the console.

When I developed our console message processing facility, I originally set it 
up to run as a command exit and then changed it's location when I found that I 
was getting EVERY command and not just the ones I wanted to get. :)

There is a lot of overhead in looking at everything, but when looking for 
individual items it's actually very efficient.

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

Re: CBU expiration and activate dynamic

[Peter]

For the benefit of other members

Test CBU Activation gave me 10 days plus 2 days of grace period

Then I was able to activate another CBU without IPLing or POR

Thanks all and thanks especially to Parwez .


On Tue, 14 May, 2019, 8:29 PM Peter,  wrote:

> So to activate another test CBU. Does it require a POR ?
>
> On Mon, 13 May, 2019, 6:02 PM Vielka-Lee Heitz, <
> vielkalee.he...@siriuscom.com> wrote:
>
>> CBU test activation is 10 days max for each test.
>> A CBU REAL ACTIVATION (you are in a DR situation) would be up to 90 days.
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Peter
>> Sent: Monday, May 13, 2019 5:01 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: CBU expiration and activate dynamic
>>
>> Parwez
>>
>> I was going through the z14 Zr1 guide . I don't see about grace period
>> for CBU test Activation.
>>
>> I am I missing something ?
>>
>> On Mon, 13 May, 2019, 1:38 PM Parwez,  wrote:
>>
>> > Re grace period. I believe its 2 days.
>> >
>> > However, my personal knowledge is a bit rusty now. Try this manual:
>> >
>> > z Systems
>> > Capacity on Demand User's Guide
>> > SC28-6943-01
>> >
>> > Regards
>> >
>> > Parwez Hamid​
>> >
>> > 
>> > From: IBM Mainframe Discussion List  on
>> > behalf of Peter 
>> > Sent: 13 May 2019 09:14
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: CBU expiration and activate dynamic
>> >
>> > Hi
>> >
>> > Will there be any grace period before it expires?
>> >
>> > On Mon, 13 May, 2019, 12:01 PM Peter,  wrote:
>> >
>> > > Hi
>> > >
>> > > We have activated CBU for our DR site and it remains for 10 days.
>> > > Now
>> > This
>> > > is nearing for expiration.
>> > >
>> > > Is it possible to activate another CBU token without IPLing the LPAR
>> > > ? Is there a way to activate CBU dynamically ?
>> > >
>> > > Hardware : z14 zr1
>> > >
>> > > Peter
>> > >
>> >
>> > --
>> > 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
>> This message (including any attachments) is intended only for the use of
>> the individual or entity to which it is addressed and may contain
>> information that is non-public, proprietary, privileged, confidential, and
>> exempt from disclosure under applicable law or may constitute as attorney
>> work product. If you are not the intended recipient, you are hereby
>> notified that any use, dissemination, distribution, or copying of this
>> communication is strictly prohibited. If you have received this
>> communication in error, notify us immediately by telephone and (i) destroy
>> this message if a facsimile or (ii) delete this message immediately if this
>> is an electronic communication. Thank you.
>>
>> --
>> 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: [External] Re: Ancient DASD connectivity

[Tom Marchant]

On Wed, 15 May 2019 20:31:55 +, Pommier, Rex wrote:

>The point I was making was that IBM had some DASD subsystems for large(r) 
>customers with integrated controllers

Oh. Sorry I misunderstood. Thanks for the clarification.

The s/360 POO (available on bitsavers), says, 
"A control unit may be housed separately or it may be physically 
and logically integral with the I/O device."

-- 
Tom Marchant

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

Re: z/OS specific commits (was: ... "awk" ...)

[Matt Hogstrom]

GPL requires that if you modify the source and redistribute the source or 
derivative works (binaries) you need to make the source available publicly.  If 
you get the source, modify it and use the mods in an org and are not 
redistributing it you do not have to make your private work public.  

You’ll notice for all the Rocket ports that they provide a source tar with the 
changes they made on their website.  The originating project does not need to 
accept the changes, you only have to “publish” them.

There are other implications to the license but I’ll stop here.

>> I understand GPL requires that the source be somehow available.
>> 
>> -- gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 


Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On May 15, 2019, at 8:14 AM, David Crayford  wrote:
> 
> On 15/05/2019 12:13 am, Paul Gilmartin wrote:
>> On Tue, 14 May 2019 13:58:20 +0800, David Crayford wrote:
>> 
>>> If you've got a C compiler you can build "gawk" yourself. It's already
>>> been ported to z/OS and I can see there are z/OS specific commits as
>>> recently as a few months ago.
>>> 
>>> https://github.com/redox-os/gawk
>>> 
>> Are the z/OS specific mods to other GNU utilities, mainly by Rocket, likewise
>> committed to the primary source tree(s), or independent forks?
> 
> Rocket doesn't offer "gawk" as part of ported tools.
> 
> The readme lists maintainers but from the commit history there are other 
> contributors.
> 
> z/OS (OS/390) Contact:
>   Daniel Richard G.
>   sk...@iskunk.org
> 
> z/OS (OS/390) Maintainer Emeritus:
>   Dave Pitts
>   dpi...@cozx.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: mainframe hacking "success stories"?

[Mike Schwab]

Yep.  Just updated my Win 10 machines.  So bad they issued patches for
Win XP and up, out of support for several years.

On Wed, May 15, 2019 at 12:14 PM Bill Johnson
<0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
> Microsoft (MSFT) is warning users about a monster computer bug. The company 
> says it has fixed the flaw but says it's “highly likely” that it will end up 
> being used by malicious software. The flaw mainly affects older systems such 
> as Windows 7 and Windows 2003.
>
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Ancient DASD connectivity

[Alan Altmark]

On Wed, 15 May 2019 21:41:20 +, Seymour J Metz  wrote:

>That may be true for 2314, but it is not true for anything later. The A unit 
>connects to the control unit, not to the channel.
>

I actually intended to say that the A units connected to the control unit.  I 
don't know why I said "channel".   (sigh)  Everyone knows an I/O device can't 
talk to a channel!  :-)

Thanks for noticing!

Alan

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

Re: Ancient DASD connectivity

[Seymour J Metz]

That may be true for 2314, but it is not true for anything later. The A unit 
connects to the control unit, not to the channel.


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


From: IBM Mainframe Discussion List  on behalf of 
Alan Altmark 
Sent: Wednesday, May 15, 2019 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ancient DASD connectivity

On Wed, 15 May 2019 14:59:00 +0200, R.S.  wrote:

>In the old days there was a Storage Control Unit, i.e. 3830 and disk
>controller within disk cabinet, i.e. 3350-A2
>
>So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.
>
>I'm trying to understand separation of duties between 3830 and 3350A2
>controller.
>What was defined as CU - it was 3830 or controller within 3350 cabinet?
>Which cable was a channel (Bus)? I guess it is "cable1" connecting
>CPC and 3830.
>
>Not to mention that some old reference manual's diagram shows yet
>another box between CPC and 3830 SCU.

Depending on the year, you might find (rusty memory):

host
 - channel 0
 - channel 1
 - switch (2814/2914)
- channel 1
- Control unit 0 (bus & tag from channel/switch)
  - device 0 ("string header") (A-Unit)
  - device 1 (B unit)
  - device 2 (B unit)
  - device 3 (B unit)
- Control unit 1 (bus & tag) from CU 0
- repeat
 - channel 2
 - repeat

The A units handled the fan-out (signal and power) to dependent devices (B 
units) in the string and had the logic to talk to the channel.  The B units 
were just dumb slaves to the A unit.   The A units could only talk to B units 
of the same type since all the power and signaling was custom.  The interface 
between the CU and the A unit was generally such that a CU could handle strings 
of newer and older device types.   The number of A units required, the number 
of I/O devices included in an A unit, and the way B units were attached was 
generally model specific, so you would see variations on the above.  (Don't 
confuse with more modern UNIT=3390B to indicate a PAV to MVS!)

It was sheer size of the componentry that drove this design.   I think the 3990 
was the last stand-alone disk controller.  With the arrival of 2105s, the CU 
was inside the same cabinet as the drives and Logical CUs (LCUs) were born.  
One big black box (literally).  Adding additional cabinets no longer affected 
the I/O configuration - just capacity.

We still have switches, of course, but they're no longer pull-turn-push.  :-)

Alan Altmark
IBM Systems Lab Services

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

RES: Ancient DASD connectivity

[Bodra - Pessoal]

Ramac I and Ramac II (9394 Controllers and 9395 Drawers) comes first from 
2105/Shark and has controller (3990 like) inside same frame (small foot print) 
if compared with previous 3990 and 3380 or 3390 machines.


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


-Mensagem original-
De: IBM Mainframe Discussion List  Em nome de Alan 
Altmark
Enviada em: quarta-feira, 15 de maio de 2019 15:39
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: Re: Ancient DASD connectivity

On Wed, 15 May 2019 14:59:00 +0200, R.S.  wrote:

>In the old days there was a Storage Control Unit, i.e. 3830 and disk 
>controller within disk cabinet, i.e. 3350-A2
>
>So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.
>
>I'm trying to understand separation of duties between 3830 and 3350A2 
>controller.
>What was defined as CU - it was 3830 or controller within 3350 cabinet?
>Which cable was a channel (Bus)? I guess it is "cable1" connecting 
>CPC and 3830.
>
>Not to mention that some old reference manual's diagram shows yet 
>another box between CPC and 3830 SCU.

Depending on the year, you might find (rusty memory):

host
 - channel 0
 - channel 1
 - switch (2814/2914)
- channel 1
- Control unit 0 (bus & tag from channel/switch)
  - device 0 ("string header") (A-Unit)
  - device 1 (B unit)
  - device 2 (B unit)
  - device 3 (B unit)
- Control unit 1 (bus & tag) from CU 0
- repeat
 - channel 2
 - repeat

The A units handled the fan-out (signal and power) to dependent devices (B 
units) in the string and had the logic to talk to the channel.  The B units 
were just dumb slaves to the A unit.   The A units could only talk to B units 
of the same type since all the power and signaling was custom.  The interface 
between the CU and the A unit was generally such that a CU could handle strings 
of newer and older device types.   The number of A units required, the number 
of I/O devices included in an A unit, and the way B units were attached was 
generally model specific, so you would see variations on the above.  (Don't 
confuse with more modern UNIT=3390B to indicate a PAV to MVS!)   

It was sheer size of the componentry that drove this design.   I think the 3990 
was the last stand-alone disk controller.  With the arrival of 2105s, the CU 
was inside the same cabinet as the drives and Logical CUs (LCUs) were born.  
One big black box (literally).  Adding additional cabinets no longer affected 
the I/O configuration - just capacity.  


We still have switches, of course, but they're no longer pull-turn-push.  :-) 

Alan Altmark
IBM Systems Lab Services

--
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: [External] Re: Ancient DASD connectivity

[Pommier, Rex]

Tom,

The point I was making was that IBM had some DASD subsystems for large(r) 
customers with integrated controllers unlike the 3990/3390 before the Shark.  I 
never had physical 3390s in any of the shops I worked at, but had 9340, RAMAC, 
and RVA; and liked all of them.  Definitely shrunk the DASD footprint compared 
to the 3880/3380s they replaced.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Wednesday, May 15, 2019 3:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Ancient DASD connectivity

On Wed, 15 May 2019 19:53:07 +, Pommier, Rex wrote:

>where did the 9340 subsystem fit in the timeline between 3990 and 2105? or the 
>RAMAC2?

https://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_drives#IBM_9340_and_9345

--
Tom Marchant

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

Saving in memory data in case of operator cancel was Re: LE question

[Clark Morris]

[Default] On 14 May 2019 11:23:01 -0700, in bit.listserv.ibm-main
idfli...@gmail.com (scott Ford) wrote:

>All:
>
>I need to do some research on how job is cancelled via the Operator , Abend
>S222. I read through some of the Boston share doc of some time ago by Ed,
>Sam and Skip. Its great.
>I have a question in regard to something that was stated on the
>presentation.
>
>I have a job written in Cobol, this job has mission critical data storage
>in a table or array in program storage and that job has been cancelled by
>an Operator. I dont want to lose that data.

1. Did anyone ask the person who cancelled the job why it was done and
if so was there a  better alternative?

2.  If the data is that valuable checkpoint the program either with
z/OS supplied mechanisms or write your own.

Clark Morris
>I want to know how i should approach it. The other qualifier here is that
>this is Cobol v4.2 which i am stuck with.
>
>Would I have to write a non-LE assembler caller and somehow set and ESPIE
>or ESTAE and then somehow involve CALLRTM ?
>I have done a lot of digging and not sure recovery of this nature ( LE ) is
>mentioned. I understand Condition Handling can be called also but
>will it handle an Operator cancel ...I know there are products, thats not
>an option because of cost.
>
>Regards,

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

Re: mainframe hacking "success stories"?

[Edward Finnell]

Dang those pesky servers

https://www.usnews.com/news/national-news/articles/2019-05-07/baltimore-targeted-by-ransomware-attack-city-shuts-down-most-of-its-servers
In a message dated 5/15/2019 12:14:19 PM Central Standard Time, 
0047540adefe-dmarc-requ...@listserv.ua.edu writes:
Microsoft (MSFT) is warning users about a monster computer bug.

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

Re: [External] Re: Ancient DASD connectivity

[Tom Marchant]

On Wed, 15 May 2019 19:53:07 +, Pommier, Rex wrote:

>where did the 9340 subsystem fit in the timeline between 3990 and 2105? or the 
>RAMAC2?

https://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_drives#IBM_9340_and_9345

--  
Tom Marchant

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

Re: [External] Re: Ancient DASD connectivity

[Pommier, Rex]

It was sheer size of the componentry that drove this design.   I think the 3990 
was the last stand-alone disk controller.  With the arrival of 2105s, the CU 
was inside the same cabinet as the drives and Logical CUs (LCUs) were born.  
One big black box (literally).  Adding additional cabinets no longer affected 
the I/O configuration - just capacity.  


We don't hear much about them, but where did the 9340 subsystem fit in the 
timeline between 3990 and 2105? or the RAMAC2?  Both those devices had the 
controller built in the same frame as the disk spindles.  How about the RVA?  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Alan Altmark
Sent: Wednesday, May 15, 2019 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Ancient DASD connectivity

On Wed, 15 May 2019 14:59:00 +0200, R.S.  wrote:

>In the old days there was a Storage Control Unit, i.e. 3830 and disk 
>controller within disk cabinet, i.e. 3350-A2
>
>So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.
>
>I'm trying to understand separation of duties between 3830 and 3350A2 
>controller.
>What was defined as CU - it was 3830 or controller within 3350 cabinet?
>Which cable was a channel (Bus)? I guess it is "cable1" connecting 
>CPC and 3830.
>
>Not to mention that some old reference manual's diagram shows yet 
>another box between CPC and 3830 SCU.

Depending on the year, you might find (rusty memory):

host
 - channel 0
 - channel 1
 - switch (2814/2914)
- channel 1
- Control unit 0 (bus & tag from channel/switch)
  - device 0 ("string header") (A-Unit)
  - device 1 (B unit)
  - device 2 (B unit)
  - device 3 (B unit)
- Control unit 1 (bus & tag) from CU 0
- repeat
 - channel 2
 - repeat

The A units handled the fan-out (signal and power) to dependent devices (B 
units) in the string and had the logic to talk to the channel.  The B units 
were just dumb slaves to the A unit.   The A units could only talk to B units 
of the same type since all the power and signaling was custom.  The interface 
between the CU and the A unit was generally such that a CU could handle strings 
of newer and older device types.   The number of A units required, the number 
of I/O devices included in an A unit, and the way B units were attached was 
generally model specific, so you would see variations on the above.  (Don't 
confuse with more modern UNIT=3390B to indicate a PAV to MVS!)   

It was sheer size of the componentry that drove this design.   I think the 3990 
was the last stand-alone disk controller.  With the arrival of 2105s, the CU 
was inside the same cabinet as the drives and Logical CUs (LCUs) were born.  
One big black box (literally).  Adding additional cabinets no longer affected 
the I/O configuration - just capacity.  

We still have switches, of course, but they're no longer pull-turn-push.  :-) 

Alan Altmark
IBM Systems Lab Services

--
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: Ancient DASD connectivity

[Alan Altmark]

On Wed, 15 May 2019 14:59:00 +0200, R.S.  wrote:

>In the old days there was a Storage Control Unit, i.e. 3830 and disk
>controller within disk cabinet, i.e. 3350-A2
>
>So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.
>
>I'm trying to understand separation of duties between 3830 and 3350A2
>controller.
>What was defined as CU - it was 3830 or controller within 3350 cabinet?
>Which cable was a channel (Bus)? I guess it is "cable1" connecting
>CPC and 3830.
>
>Not to mention that some old reference manual's diagram shows yet
>another box between CPC and 3830 SCU.

Depending on the year, you might find (rusty memory):

host
 - channel 0
 - channel 1
 - switch (2814/2914)
- channel 1
- Control unit 0 (bus & tag from channel/switch)
  - device 0 ("string header") (A-Unit)
  - device 1 (B unit)
  - device 2 (B unit)
  - device 3 (B unit)
- Control unit 1 (bus & tag) from CU 0
- repeat 
 - channel 2
 - repeat

The A units handled the fan-out (signal and power) to dependent devices (B 
units) in the string and had the logic to talk to the channel.  The B units 
were just dumb slaves to the A unit.   The A units could only talk to B units 
of the same type since all the power and signaling was custom.  The interface 
between the CU and the A unit was generally such that a CU could handle strings 
of newer and older device types.   The number of A units required, the number 
of I/O devices included in an A unit, and the way B units were attached was 
generally model specific, so you would see variations on the above.  (Don't 
confuse with more modern UNIT=3390B to indicate a PAV to MVS!)   

It was sheer size of the componentry that drove this design.   I think the 3990 
was the last stand-alone disk controller.  With the arrival of 2105s, the CU 
was inside the same cabinet as the drives and Logical CUs (LCUs) were born.  
One big black box (literally).  Adding additional cabinets no longer affected 
the I/O configuration - just capacity.  

We still have switches, of course, but they're no longer pull-turn-push.  :-) 

Alan Altmark
IBM Systems Lab Services

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

Re: Concatenating VB and FB ?

[Paul Gilmartin]

On Tue, 14 May 2019 16:19:52 +, Jesse 1 Robinson wrote:

>... It has long been customary in the MVS world for each user to logon to TSO 
>with a concatenation of CLIST/EXEC libraries, some supplied by infrastructure, 
>some by the local 'department', and some by the individual user. 
>
???
It's no harder for infrastructure, the local 'department', or the individual 
user to add
a UNIX directory to a library concatenation than to add a PDS(E), and more 
flexible
since the UNIX directory imposes no RECFM restriction.

(Binder (only) limitation: a UNIX directory is accepted only solo, not 
concatenated.
I suspect this is because Binder's support of UNIX directories antedates BPAM's
-- it seems to have rolled its own.)

> ... A 'salable' solution cannot seriously compromise productivity. 
>
>I support users on two continents. Technical elegance ranks pretty far down 
>the list.
> 
Microsoft relies on that view.

-- gil

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

Re: mainframe hacking "success stories"?

[Bill Johnson]

Microsoft (MSFT) is warning users about a monster computer bug. The company 
says it has fixed the flaw but says it's “highly likely” that it will end up 
being used by malicious software. The flaw mainly affects older systems such as 
Windows 7 and Windows 2003.







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

Re: LE question

[John McKown]

On Wed, May 15, 2019 at 10:14 AM Jesse 1 Robinson 
wrote:

> I was banging away at a reply for JES2 Exit 5 when I realized that most
> CANCEL commands are issued to MVS, not JES. Where would a 'C my-pet-task'
> be intercepted?
>


Perhaps?
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieae400/svc34.htm




>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Brian Westerman
> Sent: Tuesday, May 14, 2019 10:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: LE question
>
> I think that one of the CBTtape files has a program that is a generic
> abend catcher and you execute it, passing it a parm of your program and it
> builds the ESTAEX cushion around your program.
>
> Alternatively, our SyzMPF/z product can intercept the cancel command and
> keep it from being done when you don't want it to be, so I'm sure that most
> if not all other automation products can do that same thing.
>
> You could also write a simple command exit which would intercept ALL
> cancel commands and do any kind of processing you want to it (including
> ignore it for certain jobs/tasks) and have that same exit allow some other
> command (like XANCLE instead of "CANCEL" or "C") to actually work for those
> jobs that are your favorites.
>
> Obviously our product makes this really easy, (it allows scripts with
> many, many variables to help decide if things should be allowed to happen
> or modify the commands and/or send email or text messages if/when commands
> are changed) and everyone should buy it from us, but it's really not that
> difficult to design and write your own for simple single use things like
> this.
>
> Brian
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


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: COBOL 6.2 and ARCH(12)

[Jon Butler]

As stated, the ARCH(n) limits the assembler instructions the compiler can 
generate based on hardware capabilities.  You won't get z14 vector register 
instructions with ARCH(11).

Your debugger may in fact have a problem  We just installed the latest PTFs for 
Expediter and have no ARCH(12) problems.  We also debug COBOL 4 code 
successfully, where ARCH is not an option, and probably is equivalent to the 
deprecated ARCH(6).

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

Re: LE question

[David Spiegel]

Hi Jesse,
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae400/svc34.htm#svc34__cdemvs

Regards,
David

On 2019-05-15 11:13, Jesse 1 Robinson wrote:
> I was banging away at a reply for JES2 Exit 5 when I realized that most 
> CANCEL commands are issued to MVS, not JES. Where would a 'C my-pet-task' be 
> intercepted?
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Brian Westerman
> Sent: Tuesday, May 14, 2019 10:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: LE question
>
> I think that one of the CBTtape files has a program that is a generic abend 
> catcher and you execute it, passing it a parm of your program and it builds 
> the ESTAEX cushion around your program.
>
> Alternatively, our SyzMPF/z product can intercept the cancel command and keep 
> it from being done when you don't want it to be, so I'm sure that most if not 
> all other automation products can do that same thing.
>
> You could also write a simple command exit which would intercept ALL cancel 
> commands and do any kind of processing you want to it (including ignore it 
> for certain jobs/tasks) and have that same exit allow some other command 
> (like XANCLE instead of "CANCEL" or "C") to actually work for those jobs that 
> are your favorites.
>
> Obviously our product makes this really easy, (it allows scripts with many, 
> many variables to help decide if things should be allowed to happen or modify 
> the commands and/or send email or text messages if/when commands are changed) 
> and everyone should buy it from us, but it's really not that difficult to 
> design and write your own for simple single use things like this.
>
> Brian
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: LE question

[Jesse 1 Robinson]

I was banging away at a reply for JES2 Exit 5 when I realized that most CANCEL 
commands are issued to MVS, not JES. Where would a 'C my-pet-task' be 
intercepted?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Tuesday, May 14, 2019 10:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: LE question

I think that one of the CBTtape files has a program that is a generic abend 
catcher and you execute it, passing it a parm of your program and it builds the 
ESTAEX cushion around your program.

Alternatively, our SyzMPF/z product can intercept the cancel command and keep 
it from being done when you don't want it to be, so I'm sure that most if not 
all other automation products can do that same thing.  

You could also write a simple command exit which would intercept ALL cancel 
commands and do any kind of processing you want to it (including ignore it for 
certain jobs/tasks) and have that same exit allow some other command (like 
XANCLE instead of "CANCEL" or "C") to actually work for those jobs that are 
your favorites.

Obviously our product makes this really easy, (it allows scripts with many, 
many variables to help decide if things should be allowed to happen or modify 
the commands and/or send email or text messages if/when commands are changed) 
and everyone should buy it from us, but it's really not that difficult to 
design and write your own for simple single use things like this.

Brian


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

Re: Ancient DASD connectivity

[Seymour J Metz]

The first question is how old.

In general, a channel connects to a control unit, which either connects to an 
I/O device or which also serves the role of an I/O device. A complication is 
that some processors had an option for an integrated adapter that served the 
role of both controller and device, e.g., IFA, ISC.

The 3830 or 3880 was the CU, since it was what connected to the channel.


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


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Wednesday, May 15, 2019 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Ancient DASD connectivity

(this is mostly historical question)

I'm trying to understand the role of old boxes in DASD connectivity.
 From IODF/HCD point of view we have
CPC-channels-CU-some_cable-DEVice

Nowadays in real world we have
CPC-ficon-DASDbox
and DASDbox is both CU+DEV (emulated).

In the old days there was a Storage Control Unit, i.e. 3830 and disk
controller within disk cabinet, i.e. 3350-A2

So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.

I'm trying to understand separation of duties between 3830 and 3350A2
controller.
What was defined as CU - it was 3830 or controller within 3350 cabinet?
Which cable was a channel (Bus)? I guess it is "cable1" connecting
CPC and 3830.

Not to mention that some old reference manual's diagram shows yet
another box between CPC and 3830 SCU.

--
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/1Lzj9zVRMTDFDNo4M7M8DN77CkXk2WwKjxggFK5bOAzJ9ymZvQtOryhCIWtwIGfzFgjCgGhx3jqsmmRUzK8UyoKVlWaloD7QWqqOTi3-85zptn8TXARBXIF6HMaBJR4m7Uj2iCFsfDrnhq8E3vBezbSn6n5PRnu5m389CcJs2szCnXQk34ulq1PlctcxfDqWatsHV6fDfS1b7TQR2Urdv6_rJKjsHo3ex15MuUxVQ993QvE15Fq6zrkheEgUpBUKMH0F8CkyGg5W3y41cnG3j60vFrbeXiSsdXeXqdyFZwNNyo8pwzg0gY5ZoYYZdFNwUHpDAfnC-6TZq8KqQIJURTQTaH4jiIyI1N68Reu6spyoeq-Zq9Xhnd7ZhLLGRaXeGsu5MoUVXGuL-bFONJ6InjaB4chOVGBWxt1XmpKbGHlb80NnvglwswCRfY4BR_m-T/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.2018 r. wynosi 
169.248.488 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/1Lzj9zVRMTDFDNo4M7M8DN77CkXk2WwKjxggFK5bOAzJ9ymZvQtOryhCIWtwIGfzFgjCgGhx3jqsmmRUzK8UyoKVlWaloD7QWqqOTi3-85zptn8TXARBXIF6HMaBJR4m7Uj2iCFsfDrnhq8E3vBezbSn6n5PRnu5m389CcJs2szCnXQk34ulq1PlctcxfDqWatsHV6fDfS1b7TQR2Urdv6_rJKjsHo3ex15MuUxVQ993QvE15Fq6zrkheEgUpBUKMH0F8CkyGg5W3y41cnG3j60vFrbeXiSsdXeXqdyFZwNNyo8pwzg0gY5ZoYYZdFNwUHpDAfnC-6TZq8KqQIJURTQTaH4jiIyI1N68Reu6spyoeq-Zq9Xhnd7ZhLLGRaXeGsu5MoUVXGuL-bFONJ6InjaB4chOVGBWxt1XmpKbGHlb80NnvglwswCRfY4BR_m-T/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 169,248,488 as at 1 
January 2018.

--
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: Ancient DASD connectivity

[Seymour J Metz]

> The first device to support "disconnect" was the 3330 

No; the 3330 was a Johnny come lately. The first device such was the 2305 fixed 
head disk attached to the 2835 controller.


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


From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: Wednesday, May 15, 2019 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ancient DASD connectivity

The first device to support "disconnect" was the 3330 which also connected to a 
3830.
Prior to that IO in both directions tied up the entire path from CPU to device 
and back for the duration (2314, 2311 dasd).

The flow of a "typical" IO request:
Channel passes commands to 3830 and disconnects.
3830 passes commands to "logic" boards in 3350A2 and disconnects
"logic boards" issue commands to individual  device (3350A2/B2) and disconnect.

The following processing will then occur:
Device handles requests and reconnects to logic boards.
"logic boards" reconnect to 3830
3830 communicate to CPC
Data transfer occurs.
Note  the entire path (device-logic boards-3830-channel) is "locked" for the 
duration of the data transfer.

The paradigm has generally not changed since the "old days".
The major differences between the "old days" and today:
There is no longer a "separate" control unit e.g. 3830 This logic is now in the 
DASD device itself.
The advent of cache controllers allows for the reconnection process to be 
performed "asynchronously". Again this is packaged in the device itself.

Once the data has been passed from the device to the cache, the devices are 
free to handle other requests.
This allows for greater DASD thruput.

BTW, between the 3830/3350 and "modern DASD". There were stand-alone 3880/3380 
and 3990/3390 "control units" with cache capability.
The stand-alone logic represented by the 3830 , 3880 and 3990 control units 
have been absorbed into the device itself.
Externally it is "CPU-->DASD box" Internally, all of the components of the 
"original paradigm" are still present with the detail obscured by the hardware.




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Wednesday, May 15, 2019 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Ancient DASD connectivity

(this is mostly historical question)

I'm trying to understand the role of old boxes in DASD connectivity.
 From IODF/HCD point of view we have
CPC-channels-CU-some_cable-DEVice

Nowadays in real world we have
CPC-ficon-DASDbox
and DASDbox is both CU+DEV (emulated).

In the old days there was a Storage Control Unit, i.e. 3830 and disk controller 
within disk cabinet, i.e. 3350-A2

So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.

I'm trying to understand separation of duties between 3830 and 3350A2 
controller.
What was defined as CU - it was 3830 or controller within 3350 cabinet?
Which cable was a channel (Bus)? I guess it is "cable1" connecting CPC and 
3830.

Not to mention that some old reference manual's diagram shows yet another box 
between CPC and 3830 SCU.

--
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,https://apc01.safelinks.protection.outlook.com/?url=www.mBank.pldata=02%7C01%7Callan.staller%40HCL.COM%7C7e30a6a721eb4e26d65d08d6d935283d%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636935219702096401sdata=256aP9a0gLzpePAowqaLDRZ0r1BmkBk1Z%2BqFd3Ju9EI%3Dreserved=0,
 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.2018 r. wynosi 
169.248.488 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 

Re: Ancient DASD connectivity

[Allan Staller]

The first device to support "disconnect" was the 3330 which also connected to a 
3830.
Prior to that IO in both directions tied up the entire path from CPU to device 
and back for the duration (2314, 2311 dasd).

The flow of a "typical" IO request:
Channel passes commands to 3830 and disconnects.
3830 passes commands to "logic" boards in 3350A2 and disconnects
"logic boards" issue commands to individual  device (3350A2/B2) and disconnect.

The following processing will then occur:
Device handles requests and reconnects to logic boards.
"logic boards" reconnect to 3830
3830 communicate to CPC
Data transfer occurs.
Note  the entire path (device-logic boards-3830-channel) is "locked" for the 
duration of the data transfer.

The paradigm has generally not changed since the "old days".
The major differences between the "old days" and today:
There is no longer a "separate" control unit e.g. 3830 This logic is now in the 
DASD device itself.
The advent of cache controllers allows for the reconnection process to be 
performed "asynchronously". Again this is packaged in the device itself.

Once the data has been passed from the device to the cache, the devices are 
free to handle other requests.
This allows for greater DASD thruput.

BTW, between the 3830/3350 and "modern DASD". There were stand-alone 3880/3380 
and 3990/3390 "control units" with cache capability.
The stand-alone logic represented by the 3830 , 3880 and 3990 control units 
have been absorbed into the device itself.
Externally it is "CPU-->DASD box" Internally, all of the components of the 
"original paradigm" are still present with the detail obscured by the hardware.




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Wednesday, May 15, 2019 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Ancient DASD connectivity

(this is mostly historical question)

I'm trying to understand the role of old boxes in DASD connectivity.
 From IODF/HCD point of view we have
CPC-channels-CU-some_cable-DEVice

Nowadays in real world we have
CPC-ficon-DASDbox
and DASDbox is both CU+DEV (emulated).

In the old days there was a Storage Control Unit, i.e. 3830 and disk controller 
within disk cabinet, i.e. 3350-A2

So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.

I'm trying to understand separation of duties between 3830 and 3350A2 
controller.
What was defined as CU - it was 3830 or controller within 3350 cabinet?
Which cable was a channel (Bus)? I guess it is "cable1" connecting CPC and 
3830.

Not to mention that some old reference manual's diagram shows yet another box 
between CPC and 3830 SCU.

--
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,https://apc01.safelinks.protection.outlook.com/?url=www.mBank.pldata=02%7C01%7Callan.staller%40HCL.COM%7C7e30a6a721eb4e26d65d08d6d935283d%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636935219702096401sdata=256aP9a0gLzpePAowqaLDRZ0r1BmkBk1Z%2BqFd3Ju9EI%3Dreserved=0,
 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.2018 r. wynosi 
169.248.488 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,https://apc01.safelinks.protection.outlook.com/?url=www.mBank.pldata=02%7C01%7Callan.staller%40HCL.COM%7C7e30a6a721eb4e26d65d08d6d935283d%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636935219702096401sdata=256aP9a0gLzpePAowqaLDRZ0r1BmkBk1Z%2BqFd3Ju9EI%3Dreserved=0,
 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,248,488 as at 1 
January 2018.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: Ancient DASD connectivity

[Tom Marchant]

On Wed, 15 May 2019 14:59:00 +0200, R.S. wrote:

>(this is mostly historical question)

It might be helpful to you to get a copy of the System/360 Principles 
of Operation, which describes this a little bit. You can find it on bitsavers.
http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf

The OEMI night also be of interest.
http://bitsavers.trailing-edge.com/pdf/ibm/360/A22-6843-3_360channelOEM.pdf

>I'm trying to understand the role of old boxes in DASD connectivity.
> From IODF/HCD point of view we have
>CPC-channels-CU-some_cable-DEVice

In those days, there was no IODF or HCD. There was only IOGEN. There 
was no channel subsystem until System/370 Extended Architecture. 
There were no subchannels as we know them, and no HSA. 

XA made a radical departure in the channel architecture, but the interface 
between the channel and the control unit remained the same, both 
physically and logically.

>Nowadays in real world we have
>CPC-ficon-DASDbox
>and DASDbox is both CU+DEV (emulated).
>
>In the old days there was a Storage Control Unit, i.e. 3830 and disk
>controller within disk cabinet, i.e. 3350-A2
>
>So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.
>
>I'm trying to understand separation of duties between 3830 and 3350A2
>controller.

Electronics were much larger in those days. Integrated circuits were in their 
infancy. As a result, the logic in the control unit took up a considerable 
amount of space.

>What was defined as CU - it was 3830 or controller within 3350 cabinet?

The control unit is the device that the channel cable connects to. It is a well 
defined interface from the point of view of the channel, and often did not 
concern itself with the details needed to access the device. 

The channel would, for example, send a seek command to the control unit. 
The control unit would communicate with the disk controller in the dasd 
box, which would handle the details of switching on and off hydraulic 
pumps and valves, etc. for the purpose of actually moving the heads. 
The control unit typically didn't deal with those details.

>Which cable was a channel (Bus)? I guess it is "cable1" connecting
>CPC and 3830.

Bus and tag cables are the cables used to connect a channel to a control 
unit. That standard allowed other vendors to supply compatible devices 
with some assurance that they would work on any processor. The interface 
between control unit and device was not similarly standardized in general. 
As a result, you couldn't connect one vendor's DASD to another vendor's 
control unit.

IIRC, the cables between control unit and dasd looked similar to bus and 
tag cables. I don't know if any vendors used the same cables for that 
purpose.

>Not to mention that some old reference manual's diagram shows yet
>another box between CPC and 3830 SCU.

That might be a channel switch, such as a 2914. It would be connected 
to some number of channels, typically on different processors and some 
number of control units. remember that there were no LPARs in those 
days. The switch allowed devices to be switched to different processors. 
It was a manual process to switch. The device(s) had to be varied offline, 
then the connection was switched by turning dials, then varied online to 
the other processor.

To further complicate things, on some early processors, the channels 
were located in a separate box from the CPU.

-- 
Tom Marchant

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

Ancient DASD connectivity

[R.S.]

(this is mostly historical question)

I'm trying to understand the role of old boxes in DASD connectivity.
From IODF/HCD point of view we have
CPC-channels-CU-some_cable-DEVice

Nowadays in real world we have
CPC-ficon-DASDbox
and DASDbox is both CU+DEV (emulated).

In the old days there was a Storage Control Unit, i.e. 3830 and disk 
controller within disk cabinet, i.e. 3350-A2


So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.

I'm trying to understand separation of duties between 3830 and 3350A2 
controller.

What was defined as CU - it was 3830 or controller within 3350 cabinet?
Which cable was a channel (Bus)? I guess it is "cable1" connecting 
CPC and 3830.


Not to mention that some old reference manual's diagram shows yet 
another box between CPC and 3830 SCU.


--
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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018.

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

Re: Logrec Logstream name

[Gadi Ben-Avi]

Thanks everyone,
Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Wednesday, May 15, 2019 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logrec Logstream name

In the logger policy, and IIRC, in LOGREC= in IEASYS00.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Wednesday, May 15, 2019 7:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logrec Logstream name

Thanks
Where do I define the name of the logstream for LOGREC?
Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Shorkend
Sent: Wednesday, May 15, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logrec Logstream name

Gadi
If you do not have a coupling facility, them the logstream has to be DASD- only 
and can not be shared between LPARS. See here:

https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.ieag200%2Fcfod.htmdata=02%7C01%7Callan.staller%40HCL.COM%7Cee80f11855ed498da82108d6d931de25%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636935205569327362sdata=iBIpkcaKtT54cLLoMjx4rS8m%2BZcAhzXvSBdmUqhuim8%3Dreserved=0

You will need to use a unique name for each logstream. You could use the 
 system symbol as part of the name to make things easier.

HTH

Mike





On Wed, 15 May 2019 at 14:57, Gadi Ben-Avi  wrote:

> Hi,
> We have a basic sysplex with two members.
> There is no coupling facility.
>
>
> 1.   Is it possible to use the same logrec logstream
> (SYSPLEX.LOGREC.ALLRECS) for both systems.
>
> 2.   If not, how do I specify different a logstream for each system?
>
> We are using z/OS v2.3
>
> Gadi
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Mike Shorkend
m...@shorkend.com
https://apc01.safelinks.protection.outlook.com/?url=www.shorkend.comdata=02%7C01%7Callan.staller%40HCL.COM%7Cee80f11855ed498da82108d6d931de25%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636935205569327362sdata=648QxhRsJFYClNtZszTw3zMJSXSaUwPnjSG4oDIwo8U%3Dreserved=0
Tel: +972524208743
Fax: +97239772196

--
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
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
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: Logrec Logstream name

[Allan Staller]

In the logger policy, and IIRC, in LOGREC= in IEASYS00.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Wednesday, May 15, 2019 7:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logrec Logstream name

Thanks
Where do I define the name of the logstream for LOGREC?
Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Shorkend
Sent: Wednesday, May 15, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logrec Logstream name

Gadi
If you do not have a coupling facility, them the logstream has to be DASD- only 
and can not be shared between LPARS. See here:

https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.ieag200%2Fcfod.htmdata=02%7C01%7Callan.staller%40HCL.COM%7Cee80f11855ed498da82108d6d931de25%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636935205569327362sdata=iBIpkcaKtT54cLLoMjx4rS8m%2BZcAhzXvSBdmUqhuim8%3Dreserved=0

You will need to use a unique name for each logstream. You could use the 
 system symbol as part of the name to make things easier.

HTH

Mike





On Wed, 15 May 2019 at 14:57, Gadi Ben-Avi  wrote:

> Hi,
> We have a basic sysplex with two members.
> There is no coupling facility.
>
>
> 1.   Is it possible to use the same logrec logstream
> (SYSPLEX.LOGREC.ALLRECS) for both systems.
>
> 2.   If not, how do I specify different a logstream for each system?
>
> We are using z/OS v2.3
>
> Gadi
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Mike Shorkend
m...@shorkend.com
https://apc01.safelinks.protection.outlook.com/?url=www.shorkend.comdata=02%7C01%7Callan.staller%40HCL.COM%7Cee80f11855ed498da82108d6d931de25%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636935205569327362sdata=648QxhRsJFYClNtZszTw3zMJSXSaUwPnjSG4oDIwo8U%3Dreserved=0
Tel: +972524208743
Fax: +97239772196

--
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
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Logrec Logstream name

[Allan Staller]

With no coupling facility, you are limited to DASD-Only logstreams.
DASD-only logstreams *CAN NOT* be shared.

It is (IMO) not worth the effort to convert to logstreams for EREP when DASD 
only.
EREP, these days, is pretty much limited to software records, and thus there is 
limited value to a logstream.

HTH

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Wednesday, May 15, 2019 6:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Logrec Logstream name

Hi,
We have a basic sysplex with two members.
There is no coupling facility.


1.   Is it possible to use the same logrec logstream 
(SYSPLEX.LOGREC.ALLRECS) for both systems.

2.   If not, how do I specify different a logstream for each system?

We are using z/OS v2.3

Gadi


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Logrec Logstream name

[Mike Shorkend]

PARMLIB(IEASYSxx)
LOGREC parameter


On Wed, 15 May 2019 at 15:35, Gadi Ben-Avi  wrote:

> Thanks
> Where do I define the name of the logstream for LOGREC?
> Gadi
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Mike Shorkend
> Sent: Wednesday, May 15, 2019 3:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logrec Logstream name
>
> Gadi
> If you do not have a coupling facility, them the logstream has to be DASD-
> only and can not be shared between LPARS. See here:
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag200/cfod.htm
>
> You will need to use a unique name for each logstream. You could use the
>  system symbol as part of the name to make things easier.
>
> HTH
>
> Mike
>
>
>
>
>
> On Wed, 15 May 2019 at 14:57, Gadi Ben-Avi  wrote:
>
> > Hi,
> > We have a basic sysplex with two members.
> > There is no coupling facility.
> >
> >
> > 1.   Is it possible to use the same logrec logstream
> > (SYSPLEX.LOGREC.ALLRECS) for both systems.
> >
> > 2.   If not, how do I specify different a logstream for each system?
> >
> > We are using z/OS v2.3
> >
> > Gadi
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Mike Shorkend
> m...@shorkend.com
> www.shorkend.com
> Tel: +972524208743
> Fax: +97239772196
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Mike Shorkend
m...@shorkend.com
www.shorkend.com
Tel: +972524208743
Fax: +97239772196

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

Re: Logrec Logstream name

[Gadi Ben-Avi]

Thanks
Where do I define the name of the logstream for LOGREC?
Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Shorkend
Sent: Wednesday, May 15, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logrec Logstream name

Gadi
If you do not have a coupling facility, them the logstream has to be DASD- only 
and can not be shared between LPARS. See here:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag200/cfod.htm

You will need to use a unique name for each logstream. You could use the 
 system symbol as part of the name to make things easier.

HTH

Mike





On Wed, 15 May 2019 at 14:57, Gadi Ben-Avi  wrote:

> Hi,
> We have a basic sysplex with two members.
> There is no coupling facility.
>
>
> 1.   Is it possible to use the same logrec logstream
> (SYSPLEX.LOGREC.ALLRECS) for both systems.
>
> 2.   If not, how do I specify different a logstream for each system?
>
> We are using z/OS v2.3
>
> Gadi
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Mike Shorkend
m...@shorkend.com
www.shorkend.com
Tel: +972524208743
Fax: +97239772196

--
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: TCPIP.DATA file

[Allan Staller]

Set up the Resolver function. Pretty straightforward.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Thigpen
Sent: Tuesday, May 14, 2019 5:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TCPIP.DATA file

Currently, all the TCPIP jobs have to specify the //SYSTCPD DD statement. Since 
we only have one stach and one TCPIP.DATA file, are there any options at the 
system level that will eliminate the need for each batch job to have a 
//SYSTCPD DD?

--
Tony Thigpen

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Logrec Logstream name

[Mike Shorkend]

Gadi
If you do not have a coupling facility, them the logstream has to be DASD-
only and can not be shared between LPARS. See here:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag200/cfod.htm

You will need to use a unique name for each logstream. You could use the
 system symbol as part of the name to make things easier.

HTH

Mike





On Wed, 15 May 2019 at 14:57, Gadi Ben-Avi  wrote:

> Hi,
> We have a basic sysplex with two members.
> There is no coupling facility.
>
>
> 1.   Is it possible to use the same logrec logstream
> (SYSPLEX.LOGREC.ALLRECS) for both systems.
>
> 2.   If not, how do I specify different a logstream for each system?
>
> We are using z/OS v2.3
>
> Gadi
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Mike Shorkend
m...@shorkend.com
www.shorkend.com
Tel: +972524208743
Fax: +97239772196

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

Re: BCPii Community Name - HMC Access Level

[Mark Jacobs]

Found my answer in the manual (which in itself hard to find on the internet), 
SYSPROG access level doesn't get you there. You need ACSADMIN access rights.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Wednesday, May 15, 2019 7:28 AM, Mark Jacobs  
wrote:

> Got all that already, the "Customize API settings" task isn't there, hence my 
> thought that it's an access level problem.
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key - 
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, May 15, 2019 7:18 AM, Edgington, Jerry 
> jerry.edging...@westernsouthernlife.com wrote:
>
> > Not sure about the authority levels
> >
> > -   On the HMC, select the CEC, recovery, single object operations (getting 
> > into the SE)
> >
> > -   Select SE management, "customize API settings"
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> > On Behalf Of Mark Jacobs
> > Sent: Wednesday, May 15, 2019 7:12 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: BCPii Community Name - HMC Access Level
> > I'm trying to define the SNMP name in the support element on our z13s 
> > processor and can't find "Support Element Settings" task to do so. I'm 
> > logged with SYSPROG access rights. Do I need a different access level, or 
> > is it user error?
> > Mark Jacobs
> > Sent from ProtonMail, Swiss-based encrypted email.
> > GPG Public Key - 
> > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.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: z/OS specific commits (was: ... "awk" ...)

[David Crayford]

On 15/05/2019 12:13 am, Paul Gilmartin wrote:

On Tue, 14 May 2019 13:58:20 +0800, David Crayford wrote:


If you've got a C compiler you can build "gawk" yourself. It's already
been ported to z/OS and I can see there are z/OS specific commits as
recently as a few months ago.

https://github.com/redox-os/gawk


Are the z/OS specific mods to other GNU utilities, mainly by Rocket, likewise
committed to the primary source tree(s), or independent forks?


Rocket doesn't offer "gawk" as part of ported tools.

The readme lists maintainers but from the commit history there are other 
contributors.


z/OS (OS/390) Contact:
Daniel Richard G.
sk...@iskunk.org

z/OS (OS/390) Maintainer Emeritus:
Dave Pitts
dpi...@cozx.com


I understand GPL requires that the source be somehow available.

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

Logrec Logstream name

[Gadi Ben-Avi]

Hi,
We have a basic sysplex with two members.
There is no coupling facility.


1.   Is it possible to use the same logrec logstream 
(SYSPLEX.LOGREC.ALLRECS) for both systems.

2.   If not, how do I specify different a logstream for each system?

We are using z/OS v2.3

Gadi


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

Re: BCPii Community Name - HMC Access Level

[Mark Jacobs]

Got all that already, the "Customize API settings" task isn't there, hence my 
thought that it's an access level problem.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Wednesday, May 15, 2019 7:18 AM, Edgington, Jerry 
 wrote:

> Not sure about the authority levels
>
> -   On the HMC, select the CEC, recovery, single object operations (getting 
> into the SE)
> -   Select SE management, "customize API settings"
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Mark Jacobs
> Sent: Wednesday, May 15, 2019 7:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BCPii Community Name - HMC Access Level
>
> I'm trying to define the SNMP name in the support element on our z13s 
> processor and can't find "Support Element Settings" task to do so. I'm logged 
> with SYSPROG access rights. Do I need a different access level, or is it user 
> error?
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key - 
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.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: mainframe hacking "success stories"?

[R.S.]

W dniu 2019-05-07 o 23:46, Bob Bridges pisze:

Yeah, about that:  What ~is~ a "controled program"?  I noticed that
qualification, but my background is apps development and I'm woefully
ignorant in spots.


A controlled program is the program defined to RACF in PROGRAM class.
It can be CL(PROGRAM) ** ADDMEM('all.your.lib'), which means all 
programs from the library are to be considered as controlled.
What 'controlled' means? In short words no unknown/malicious code. It 
can be something from SYS1.LINKLIB (IBM delievered) or RYOU, but passed 
your own process.
Controlled programs and *no other programs* creat clean environment - a 
prerequisite for PADS and many other features.


--
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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018.

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

Re: BCPii Community Name - HMC Access Level

[Edgington, Jerry]

Not sure about the authority levels
- On the HMC, select the CEC, recovery, single object operations (getting into 
the SE)
- Select SE management, "customize API settings"  



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs
Sent: Wednesday, May 15, 2019 7:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BCPii Community Name - HMC Access Level

I'm trying to define the SNMP name in the support element on our z13s processor 
and can't find "Support Element Settings" task to do so. I'm logged with 
SYSPROG access rights. Do I need a different access level, or is it user error?

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.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

BCPii Community Name - HMC Access Level

[Mark Jacobs]

I'm trying to define the SNMP name in the support element on our z13s processor 
and can't find "Support Element Settings" task to do so. I'm logged with 
SYSPROG access rights. Do I need a different access level, or is it user error?

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

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

Re: JES2 shutdown failure - OMVS will not shut down

[Steve Horein]

IBM indicates ZFS is handled with ending OMVS:

"In general, do not stop zFS. Stopping zFS is disruptive to applications
that are using zFS file systems. zFS stops automatically when you shut down
z/OS® UNIX. To shut down an LPAR or to re-IPL an LPAR, use the MODIFY
OMVS,SHUTDOWN operator command to shut down z/OS UNIX. This action
synchronizes data to the file systems and unmounts or moves ownership in a
shared file system environment. A planned system shutdown must include the
unmount or move of all owned file systems and the shut down of zFS. The
MODIFY OMVS,SHUTDOWN command unmounts and moves the owned file systems and
shuts down zFS. For shutdown procedures using F OMVS,SHUTDOWN, see Planned
shutdowns using F OMVS,SHUTDOWN

 in z/OS UNIX System Services Planning

."

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ioea700/stopzfs.htm



On Wed, May 15, 2019 at 12:47 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> you left ZFS running.  It should come down before you issue the commands
> you listed.  As in:
>
> F OMVS,STOPPFS=ZFS
> F BPXOINIT,SHUTDOWN=FORKINIT
> SETRRS SHUTDOWN
> F OMVS,SHUTDOWN
> /DU,STA
> /PJES2
>
> --
> 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: JES2 shutdown failure

[Richards, Robert B.]

One of my coworkers produced this some years ago:

PROC to place in a common proclib:

//OESIG   PROC
//*** 
//*** This Procedure Terminates Processes in the UNIX Environment *** 
//*** 
//OESIG02 EXEC PGM=IRXJCL,REGION=30M,TIME=NOLIMIT,
// PARM='OESIGREX'
//SYSTSPRT DD  SYSOUT=X   
//STDOUT   DD  SYSOUT=*   
//STDERR   DD  SYSOUT=*   
//SYSEXEC  DD  DISP=SHR,DSN=your.SYSEXEC.dataset 

REXX exec OESIGREX:

/*rexx */ 
If syscalls('ON')>3 then  
   do 
say 'Unable to establish the SYSCALL environment' 
exit  
   end
address syscall   
'getpid'  
me=retval 
sig = SIGTERM 
'getpsent ps.'
process = '/usr/lpp/tcpip/sbin/timed -l'  
call kill_process 
process = 'EZANSNMD'  
call kill_process 
process = '/usr/lpp/tcpip/sbin/syslogd'   
call kill_process 
process = '/usr/sbin/inetd /etc/inetd.conf'   
call kill_process 
EXIT  
kill_process: 
do ent=1 to ps.0  
 if ps.ent.ps_cmd = process then  
  do  
   say 'TERMINATING THE FOLLOWING PROCESS ' process   
   'kill' ps.ent.ps_pid sig   
  end 
end   
return

Issue a S OESIG *before* shutting down JES2

Hope some find it useful. If not, don't shoot the messenger!

Another task that hangs around:  AXR   Issue P AXR

Bob

  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Wednesday, May 15, 2019 1:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 shutdown failure

At the end of the shutdown process, it's a good idea to issue these commands.  
The first one will ask you to verify that it's okay to stop ZFS., the rest 
won't ask you anything at all.


F OMVS,STOPPFS=ZFS
F BPXOINIT,SHUTDOWN=FORKINIT
SETRRS SHUTDOWN
F OMVS,SHUTDOWN
$DU,STA
$PJES2 

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